My design process
The design process is a leadership tool that transforms needs and ideas into effective software solutions. It should actively integrate the insights and concerns of both the project team and the customer throughout the journey.
The diagram shows how the range of potential design solutions narrows as the design process advances. Each activity should move the team further down the decision funnel, refining the direction and building confidence in the level of detail for the final plan.
As an experienced designer I set up this process early on, anticipating outcomes and timelines so the team can review, give feedback, and plan smoothly.
Each step in the process acts as an agreement between the designer and the team. Once a step is completed, the team can trust that future steps will build on the established foundation.
Project planning
Problem statement, design brief and sprint plan
Each project kicks off with a design brief that outlines what we aim to achieve, how we'll measure success, who's responsible for what, and the proposed timeline. I usually include a RACI chart in the brief to clarify who makes decisions on the project.
At the same time, I start a discovery phase to gather all the relevant information that could benefit the project. This might include competitive analysis, literature reviews, and a look into the tech we'll have available. If needed, I can also provide foundational UX research, complete with reports that highlight findings and offer recommendations.
I like to store both the design brief and any findings in a project wiki, usually published in Coda or Confluence. This keeps everything transparent, centralizes our collective knowledge, and provides a solid base for future project presentations like decks or PRDs.
Collaborative Research
User research, collaboration workshop, user stories
An illustration from the Nielsen Norman Blog article on story mapping
During this phase, I run workshops to generate user stories, ideally working together with product, engineering, and customer experience teams.
The workshop format I use most often is story mapping, a method well-documented in the Nielsen Norman blog. Story mapping is a quick, collaborative way to break down large tasks into smaller, manageable pieces. These can then be enriched with input from various stakeholders and turned into user stories.
I’ve also had success with the hero flow workshop. This approach takes a bit more time, so I usually reserve it for larger efforts like roadmap planning, and established teams that I know well.
Low fidelity design
Flowmaps and mini-wireframes
The user stories created in the workshop are easy to share and collaborate on. I then translate them into IA maps and flowmaps that outline the user’s journey in the proposed solution.
These flowmaps can evolve into small screen layouts—essentially mini wireframes linked with annotations, starting to resemble a set of detailed screen designs.
While the small screens might seem redundant alongside flowmaps, I create them anyway because they're much easier for the team to interpret. I also receive significantly more feedback from the mini wireframes compared to the more abstract flowmaps.
Wireframes
Flowmaps and mini wireframes can be transformed into wireframe designs, allowing us to align on interaction models, page layouts, interaction design, and product copy.
At this stage, I usually create a clickable prototype to ensure that the interaction and storytelling work effectively. Some design leaders like to conduct user testing at this point, but I will ideally wait until I have a high-fildelity design.
Design validation
High fidelity mocks, design prototype and user testing
From the high-fidelity wireframes I prefer, moving to fully designed prototypes is a quick step. I pull components from the company design system to apply to the interactions and patterns I’m working on. If something’s missing, I’ll pitch the idea to the design system team to see if it can be added to the shared library.
I create the prototype in Figma, showcasing tasks for user testing. I like testing with high-fidelity mocks because they tend to be more convincing for participants, leading to more genuine feedback when users feel immersed in a realistic scenario.
I have often I collaborated with a research partner who handles the research plans and user interviews. If a research partner isn’t available, I’ll step in to create the research plan and discussion guide myself, using trusted templates that I review with the team. Once the plan is finalized, I recruit participants, conduct interviews, and deliver a research report with findings and design recommendations.
The research process is one of my favorite parts of the job. It’s when I feel most connected to the impact I bring, working directly with the design and the users I’m here to help.
Engineer support
If the design has tested well, it’s ready for build-out. Ideally, some of my technical partners have attended the user testing, so the team feels excited about the project.
Since the engineering team is usually involved early on, they’re already familiar with the design by handoff. I spend about 20% of my time each week working with them to address any questions.
I adjust the design or break it into milestones to fit their workflow. I also provide responsive versions that meet WCAG guidelines. Lastly, I supply application maps to clarify user interactions and ensure the team understands how the design should function.
