Context

• Stride shifted it's focus from a pure health-and-tax focus to helping self-employed people manage their finances.
• They knew they wanted to show users their income--many future product features can be built around this data--but were unsure what users wanted to do with this info right off the bat. 
• They asked me to design V1 of an "income feature," without knowing what that would turn out to be.

‍

Challenges

• Vision changes. The whole company had shifted away from healthcare in a recent vision shift. A lot of people joined to build a health company and the change was hard to digest; half the product team left while I was there.
• Team anxiety. The design, product and engineering team really needed direction and a sense of forward momentum; as senior leaders were translating product vision to a defined target customer, product progress had largely stalled.
• Timing. The team wanted to start building a V0 within two weeks. 

‍

Approach

• Involve the whole team in defining success, research and ideation.
• Start talking to customers to discover the right questions to ask. I've found that I often learn the most valuable questions to ask users once a round of research starts, so I treat the first interview or two as a warmup. 
• Go broad on possible problems we can solve and solutions that would solve those problems, then use a framework for choosing which we should start with.

It’s much easier to generate ideas on paper than in software, so I emphasize extensive paper prototyping before touching design software.

Outcomes

• The current solution has just been launched.
• The team has a roadmap for the next month that they believe in, because of work I've done and issues I've identified.
• I left the team with recommendations on what to build next and have follow-up calls with them to help them think through the incoming data and how it should affect their design strategy and product roadmap.

‍

‍

Takeaways

• Talk to customers, together. I’ve learned this lesson a few times, but I’m perpetually impressed by how involving everyone in customer research helps to build shared vision on the team.
• Ask for help on design challenges. A well-functioning group is far smarter than an individual designer. Always. So I included engineering and customer support in ideations on solutions. That lead to some unprecedented mental models on how to help users grok their finances. Trusting the group does not mean design by consensus. It means getting diverse inputs. I still owned design, but I trusted others to contribute to it and make it better.
• A good release plan lets you take more risks. There were a whole lot of ways for this release to go wrong. My PM counterpart did an amazing job of constructing our release in a way that we could easily roll it back without adversely impacting the business. Her insights on how to test this without blowing up the app gave all of us confidence to take more risks.