Zach Willis

Building for the Team

From 0 to Product in 10 Weeks

Having spent the last 4 years primarily focused on front-end development, I felt it was time to resharpen my UX skills and what better way than by taking a class that would walk through all the aspects of UX and turn out a full fledged product in ten weeks.

Role of UX Wizard Played by Zach Willis


Focusing on a common theme I've experienced in the software development industry, I focused on exploring the pain points that teams experience as they try to develop processes that result in consistent delivery of high quality functionality. When first approaching this topic I walked into it with my own bias that much of the friction is rooted in cultural resistance to UX inputs. By conducting user interviews and suspending my own belief system as to what the cause was, I arrived at an updated focus that concentrated on the following thought.

"Product Managers need a way to visualize their product road-map because product teams have trouble understanding how their current tasking fits into the bigger picture."

" if we had known...we would have built it differently "

product manager clarity of vision empowering team agency


The goal of the project was to create a digital solution that could interface with the tools teams are already using to enhance awareness of the direction of the project while letting a manager set non-prescriptive tasks.

The research showed that there were two distinct audiences at play with different needs and the solution would need to:

Research and Insights

affinity mapping interviews

Phase 1: Interviews

I began by discussing general processes and perceptions with various practitioners including Product Managers, Designers, Full-stack Developers and a Scrum Master. What started out as a hypothesis that a great deal of team friction could be attributed to a lack of UX activities transformed into a seemingly simpler issue of collective vision. That's not to say my hypothesis was off-base, in actuality the interviews proved the hypothesis true, but the core issue appeared to be a lack of understanding among the teams about what the end-goal target looked like.

" wow, we really need to do a lot more thinking before we start making "

Phase 2: Competitor Analysis

Knowing that I should be focusing on a higher level issue I dove deeper into looking at the tools these teams were using. Oddly enough not one of them really seemed to do a good job of visualizing a product roadmap in the same place as where the team worked.

Secondarily, there appears to be great emphasis on a tool trying convert customers into using just their tool, not working with the tools a lot of teams are already using. This creates a high barrier to entry for new tech. It's easy to start off with any given tool but to migrate is an entirely different question and the was where I found the most resistance from leads. They don't have the time to migrate.



Does well...

  • Shows teams across projects
  • Has a lot of collaborative tools
  • Shared repositories of knowledge

Weak areas...

  • Requires full adoption
  • No representation of workflows

Does well...

  • Tagging to link things together
  • Advanced queries
  • Github integration

Weak areas...

  • Poor highlevel visualizations
  • Easy to loose track of things you've worked on

Synthesizing what I discovered from interviews with the functionality afforded by popular tools, I saw an opportunity to develop an overlay application that takes advantage of existing APIs to add a visual representation of what everyone already does with their existing tools.

Phase 3: Refinement

Before solutioning I developed the data I had gathered from interviews and turned them into personas to guide the rest of the process. Two key characters emerged from the various conversations I had held.

persona representing managers and leads

typical lead kick-off flow

persona representing designers and developers

typical designer kick-off flow

Revised Problem Statements

Product Manager
Derrick needs a way to inform the team of the product’s direction because the teams feels a sense of urgency without direction. Edith needs a way to build autonomy because she wants to demonstrate the positive impact of UX deliverables as part of an iterative development process.

Planning and Priorities

Having completed user interviews and analyzed the competion the next step was to determine what kind of features would best provide users with the functionality they needed to ease their friction points. Applying the principle "10x not 10%" I started off by ideating on a 2 by 2 matrix to determine a list of potential features.

two by two matrix to determine mvp features

The results of this exercise clearly identified the feature set of what the MVP should look like. I back tested these findings by relating them back to the established personas.

mvp features mapped to persona needs

Drawing It Out

With focused information I was prepared to start drawing out what the solution could look like in order to collect early feedback on my approach. Having the MVP mapping was extremely helpful with keeping me focused on the cirtical elements to convey the concept without chasing down every idea that came to mind.

The Prototype

I used Adobe XD to start iterating through the main screens but wound up switching to a new CSS framework I had heard about called Tailwind. It uses utility classes so you can quickly revise your design on the fly and I found it to be a very powerful way to assemble look and feel.

Launch Prototype

Check out the rest of my design portfolio here.