Product design process
Here is an overview of my personal process to bring a design sprint from start to completion. The flow may vary according to the type and size of the project, but I can generally break it down to the following steps:
Research and ideation
Design and prototyping
Review and alignment
Each design project begins with a kickoff meeting where relevant stakeholders from the company gather to discuss the goals of the project. This project team typically includes a product manager, a product designer (hi!) and an engineer. Depending on the company and the type of project, there may also be representatives of other teams. For instance if the support team has requested a new feature in response to a common help ticket, a representative from the support team will be part of the meeting.
The goal of this first meeting is to:
Get to a shared understanding of the problem we are trying to solve. What is the issue? Who does it affect?
Learn if there are any specific constraints (time, resources, etc.) or requirements.
Agree on the scope of the project. Are we trying to issue a quick fix or build a fully decked out feature?
Discuss potential metrics that would help measure the success of the solution.
2—Research and ideation
Once a consensus is reached, the project team splits up so that everyone can start working on their part of the solution. For me, this is the research and ideation phase.
I write down my initial thoughts and start mapping the problem. Which pieces of information do I need to collect or display? Am I designing a screen, a user flow, a larger feature? Does this project affect one or several parts of the product? What are the first solutions that come to mind? If this is a complex problem, I break it down into smaller pieces.
If there are similar products in the space, I review and compare their respective approaches. When I worked at Storenvy, I created an account with dozens of online marketplaces such as Etsy, Shopify, BigCartel and eBay. I also analyzed a number of shopping apps that were popular with our demographic, such as Zara and Urban Outfitters.
However, the most insightful references may not come from competition. While at Inflect, I found a striking parallel between our data center pages and Airbnb’s apartment listings. Just like apartments, data centers have a location, an owner, a number of specs… and they’re available for ‘rent’.
Based on my research and findings, I sketch possible user flows and layouts. I try and stay away from my screen at this stage, as paper makes it easier to explore fast without getting attached to a specific direction. I consider as many ideas and approaches as possible before I begin to narrow down my options.
These explorations may raise questions about our users and their current flows. I try and get answers as early as possible by asking experts on the team, looking at product analytics (Mixpanel, Heap), and/or speaking directly with users.
At the end of this phase, I’ll likely have one to three potential directions that I’m excited to push forward.
3—Design and prototyping
I start working in Sketch and play out my top solutions.
I prototype designs using Marvel’s plugin for Sketch. Prototyping provides valuable insights into each potential solution and makes it easy to ask for feedback. Some of my prototypes may be minimal, showing only one aspect of the interaction. Others are more fleshed out, telling the full story of how a user would interact with the feature.
My goal is to validate or discard ideas as soon a possible, and have a single prototype emerge as the obvious solution.
If I am working for a company that does not have a brand or design language yet, I keep initial designs in grayscale to allow stakeholders to focus on the interaction. If the company has an established design language, or a component library, I design in high-fidelity. Why waste time?
At Inflect, I created a structured Sketch library of all our common UI elements, including buttons, input fields, user avatars and company logos, dropdown menus, modals, and different states of the navigation bar. I also built a collection of text styles and a color palette. Creating a library requires a little bit of work upfront, but ends up saving hours on each project.
I like to share my work early and ask for feedback often. Feedback can be informal (a conversation with a fellow designer over lunch) or more structured (putting time on the calendar to answer technical questions with engineers and the product manager).
When I worked on Storenvy’s checkout flow, I designed a checkout experience allowing users to purchase products from multiple vendors with a single transaction. But after showing my prototype to the lead engineer, I learned that that there were a number of technical constraints associated with a single checkout. We had to require users to transact with each vendor individually. Had I not shared my work early, I would have invested more time into this unrealistic prototype.
When I feel confident about a prototype, I gather the project team for review.
4—Review and alignment
The review meeting is a checkpoint intended to create consensus around the proposed solution, ensure feasibility, and allow everyone to move forward.
After a recap brief of the project requirements, scope and goals to set the context, I walk everyone through the user flow and explain my design decisions. This is a good time for questions, notes, and verifying that the proposed solution meets the initial requirements. At this point, feedback should be minimal and adjustments easy to make. If there is a need to go back to the drawing board, it can be a sign that the process broke somewhere. For instance the goals of the project were too broad or I didn’t spend enough time in the research phase (oops!). In some cases, new requirements may have emerged since the beginning of the project, or the scope may have evolved. Even with the best intentions, it can be difficult to keep everyone in a busy team on the same page.
When this happens, I works with the project team to clarify the issue. What are the issues? What is missing from the prototype? Which new constraints or requirements have emerged? Is more research needed? We’re essentially looping the conversation back to phase 1: Project framing. Complex projects involving multiple teams can be very iterative.
If everyone feels good about the solution and the approach, we move the project forward. Engineers can start thinking about implementation. I start working on edge cases, empty states, and additional formats for the product. If I designed for iOS, how does the Android version differ? Is there a desktop version? If I designed for desktop, what does it look like at the different breakpoints? I may also need to adjust the prototype in preparation for usability testing sessions.
I share my prototypes and supporting material with the team and I make myself available for any additional questions and feedback.
Depending on the scope of the project and the resources of the company, I invite 4-12 people for usability testing sessions. A session typically follows these steps:
Introductions. I make the user feel comfortable and ask them for permission to record the session. I inquire about their background and their relationship to the product.
Process description. I explain that we are testing a new design and want to observe how people interact with it. I ask the user to think out loud and describe what they see or think. I sometimes tell them that the designer is not in the room so they can be comfortable sharing feedback ;)
Testing. I give the prototype to the user and ask them to complete a few tasks, making sure to not guide them. If the user stays silent for a while, I’ll ask a neutral question: “What do you see"?” or “What is happening here?” At the end, I ask them to summarize their experience and thank them for their time.
After a few interviews, themes start to emerge and I can prioritize revisions.
Usability testing sessions require time and resources, and it may be tempting for small teams to overlook that aspect of the design sprint. Yet, a lack of testing is a liability.
When I worked on Routefinder, at Inflect, the feature was massive and packed with complex interactions. Potential users were in high-responsibility roles, with fully packed schedules (CTOs, VPs of Engineering, Sales Architects). It was challenging to put time on their calendar, and we had to schedule sessions several weeks in advance.
I decided to get a head start by testing the prototype internally, with 6 colleagues who were not as familiar with it. These internal sessions allowed me to gather valuable feedback about the interaction and revise the prototype accordingly. Routefinder looked a lot more polished.
However this was not the full picture. When we tested Routefinder with industry experts, the feedback was on a completely different level. These users saw past the UI and shared highly technical input, pertaining to how to the product would help them do their job. We learned that users wanted to be able to search not only data centers and cloud locations, but also enterprise locations. We learned that our latency estimates were too aggressive, eroding trust in the data. We learned that level 3 connections were not always relevant to them, and they wanted to be able to filter them out. These findings were critical to the release, yet we would have missed them entirely had we not thoroughly tested the product.
If revisions are important and affect the core user flow, I go back to phase 2, 3, 4, etc. At times, this may feel like a step back, but it is an essential part of the process to ensure that I bring the best possible solution to the finish line.
By now, the engineers should be familiar with the designs, but I like to sit down with them again to go over the prototypes, clarify each interaction, and answer outstanding questions. If this is a new team, I also ask them about their preferred process:
Do they want me to post a detailed write up about the feature in their tracking tool (Github, Trello, etc.)? Or would they rather I explain everything in person?
Do they want detailed visual specs? Do they have an existing component library?
How should I deliver the assets? Do they prefer JPG, PNG, SVG? Do they want me to add icons to a custom font library?
What is the best way to report issues during the testing phase? Do they like to sit together and pair up?
I check in throughout the development process to make sure there aren’t any blockers. In some cases, a seemingly trivial aspect of the design turns out to be challenging to implement. Should we spend additional engineering resources and take the risk to delay the release, or can we find a sensible workaround? We decide on the best approach holistically.
When the feature is deployed to Dev, I check that the implementation is going in the right direction. I keep it high-level. The Dev environment is usually not stable and reporting subtler issues would be counterproductive.
When the feature is deployed to Staging, I begin the in-depth QA work. I open tickets to report anything that seems off: bugs, janky interactions, funky animations, loading delays, styling issues, typos… I try and enroll as many colleagues as possible to help me test. Strength is in the numbers!
I close my tickets one by one after verifying that issues have been resolved. New issues may appear, old issues reappear. It is a work that require patience and dedication, and it may help to block time in advance to ensure that it gets done. At Inflect, we organized testing parties where available team members would get together to “try and break things” for an hour or two at a time.
Surely, the tracking boards clear up and the feature starts to feel solid and reliable. When we get to a place where everyone is confident about the feature, we roll it out to our users on Production.
It’s time for a glass of champagne!