Here’s an outline of my standard design process. The stages may vary depending on requirements, product maturity, stakeholders, and other factors.
The purpose of this stage is to identify what needs to be achieved and align all stakeholders on a desired outcome. At this stage I discuss with stakeholders what the goals are, and then translate these goals into a design specification. Ideation involves back-and-forth discussion between designers, developers, and the business. And the outcome is usually a design-oriented prioritized feature backlog. The stage also includes user research, the purpose of which is to learn about the needs, pains, and constraints of the user. Sometimes I also conduct a competitor analysis to find out how other companies solve problems and create value for their users.
An app is a tool that helps users get from point A to point B. To get there a user must take a series of steps which together form the user journey. An interface usually has one or more core flows that enable this journey. In an e-commerce app this can be the checkout flow. In a banking app the payment flow. The purpose of user journey mapping sessions is to get everyone on the same line about the steps a user will take to achieve their goal. To improve the quality of a journey I involve subject-matter experts (project stakeholders) and use research and analytics data when available. User journey mapping sessions are done either on a physical whiteboard or a computer screen using drawing tools.
Tools: InVision Freehand, whiteboard, marker
Once a user journey has been agreed on I start working on the wireframes, which are low-fidelity representations of what the final design will look like. The purpose of wireframes is to create screens around each step of a user journey and decide which features go into which screens. When designing wireframes I focus on layout and functionality. This means that styling elements such as colors, icons, and fonts are left out. Wireframing usually requires several iterations in order to arrive at an optimal design.
Tools: Balsamiq, Sketch
At this stage it’s clear what the user flows and corresponding screens are. It’s time to translate the wireframes into high-fidelity mockups. This means adding colors, fonts, icons, images, and other visual elements. If a styleguide is available then I will design according to the existing brand. Otherwise I will create new brand elements based on a desired look and feel. Mockups represent the final design. Therefore they need to be precise and meticulously made. I design mockups on component level, meaning I first create the building blocks and then put them together into screens. Throughout the process I use various tools and techniques such as Atomic Design, symbols, layouts, grids, text and layer styles, and naming conventions, in order to achieve a high level of quality and consistency.
Tools: Sketch, Framer, Figma
The purpose of a prototype is to see how a design performs on an actual device, and if possible get it into the hands of the user. Prototypes can be used for testing and having a more in-context discussion about the product with project stakeholders. Any feedback from users is worked into the design or goes into the backlog for future use. I’m able to create simple click-through as well as complex animation- and code-based prototypes using various tools.
Tools: InVision, Marvel, Framer
After completing the design I hand it over to the developers. This is an important step since miscommunication can result in a product that is substantially different from the design. The goal of a handover is to make sure developers understand not only which colors and fonts to use, but also how different components relate to each other and how they behave on different device sizes. I design mobile-first, making sure that an app works well on smaller displays. In addition to the developer handover I also do a design file handover where I make sure that other designers are able to built on top of my work. This involves creating a robust component library with proper organization and naming conventions, and minimum technical debt.
Tools: Zeplin, InVision, Abstract
Tools: Visual Studio Code, Git
After a product has been released it is time to measure its performance. Remember that up to now the design is based on a hypothesis, and it’s only after we review usage data that we’re able to determine whether our hypothesis was sound. I use analytics tools to observe user behavior and conduct interviews to understand the reason for their behavior. Ideally we want to design based on a hypothesis only once, with any subsequent designs being based on user data and feedback.
Tools: Google Analytics, Hotjar