Talk through the identified Problem. How do we know it’s a problem? What is the customer doing now to try to solve for it? Can we solve it better? How will we know if we’ve solved it? Break down even straightforward customer requests - what problem are they trying to solve for with this request? Are they being too prescriptive with the solution, and there is an easier approach they haven’t thought of?

With a comprehensive understanding of the problem domain, you can then articulate what the opportunities are. Then develop a clear and focused design direction that you can share with others and archive for those moments you need context later. Additionally, having some data points for its current state, discuss what failure looks like—and what success looks like. This will allow us to later measure how effective our approaches are.

Once the opportunity is clear, as a designer, it’s time to visualize the possible ways in which we can create an experience that will seize the opportunity and allow us to accomplish our goals.

Now with a clear understanding of the domain, an articulate view of the opportunities, and a visualization of the possible solution(s) you regroup with the team and see what feels worthy of continued investment. How well do the visualizations support the original intention? What did we learn or notice once we visualized the feature idea? What gaps or new problems might we have created in introducing this new flow?

Pursuing certain solutions to problems or new features both require a level of specificity to see at a granular level that not only have to solved for the problem at hand, but at the same time have not added any new problems or conflicts to the rest of the product. Sometimes that as simple as a few higher fidelity designs, sometimes it requires an intricate prototype and user testing. In any case, we are simply trying to outline the next steps with a level of specificity that can be clearly communicate to business stakeholders and tactically executable by engineers and testable by QA.

At this point you should have a clear idea of what to go build and only need a minor amount of additional clarity to delegate the work and get rolling on building out your feature. Think of closing a 10% gap in understanding, not 50%. In the unlikely event that your previous step proved unsuccessful, then regroup with the new information, develop a new approach and repeat that cycle until you’re ready to button up the marching orders and move forward into production.

At this point, you should be able to blindly hand over documentation and it should be handed back with perfect execution. However that never seems to happen, even in the most ideal of circumstances, so make space to sit down with the engineers to ensure that they have all they need to realize the vision that’s been laid out before them with designs, specs, and user stories.

Once it’s been built, launch it and see how effective it is in the real world, and study that reaction and look for ways in which you can further improve if it’s not performing as well as expected, or be thankful the process has served it’s purpose and the goal has been met, and move on to the next domain and opportunity to further the product towards achieving the larger business goals or mission.