Building for the Team

Overview

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 "

Challenge

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:

• Give Product Managers tools to help communicate to their team the direction of the product
• Give Team Members the benefit of generalized tasking so they can develop the autonomy to operate more independently
• Empower the team to build their own knowledge service over time that can be linked into work items to speed up research and design
• Not force a team to fully transition onto a new platform that requires a dramatic on-boarding experience

Research and Insights

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.

Basecamp	Jira
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.

Revised Problem Statements

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.

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.

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.