Three Questions I Ask Before Starting a New Design Project
#32: How to get prepared to take on any design challenge?
Whether it’s an entirely new startup or just another initiative in an already productized tool, I always ask three core questions that help better draw the picture before I plunge into the work. Of course, answering them will not reveal everything you need to complete the project, but they will surely set the initial scene. We must remember that design processes are never linear, and all the particular steps can’t be well predicted.
Here are the three questions I ask before starting a new design project:
What are the measures of success?
How will the users benefit from this project?
What can go wrong, and how can I mitigate the risk?
Let’s take a deeper look at each of them.
Step into 2025 with a healthy dose of design knowledge!
For a price of 8 latte cups, you get:
Exclusive articles every month
Access to the full archive
Free access to Fundament Library (more titles to come in 2025)
Discounts on other educational content (2025)
Hurry! The yearly Premium plan is 35% off only until the end of January.
1. What are the measures of success?
What would be an indicator of meaningful work? How can you tell if the users are happy with the new feature or tool and if the business benefits from it? The answer is in numbers (and sometimes in words).
To answer this question well, you must first set a clear and measurable goal to define the metrics. It doesn’t have to be a single goal–usually, it would be a whole bunch of intertwined goals. Let’s look at the following example:
An internal application is used by hiring managers to handle HR processes within a tech organization. A product manager and designer have been collecting continuous feedback from users and stakeholders. From a few recent conversations, it turned out that users need to check manually for any status change in the system, and due to increased demand in the last two quarters, it became a real pain to keep up with all the updates to their HR processes. Users are struggling with the workload, so the product trio came up with the idea of introducing notifications.
What an awesome idea! Let’s build the notifications module in the system, and everyone should be happy, right? Well, maybe. How can we really tell? We must first define what will constitute happiness in this particular case.
Let’s assume the team has done the initial research and feasibility analysis of several possible solutions to the design problem:
In-app notifications,
E-mail notifications,
Slack bot,
SMS service.
All have pros and cons and different levels of complexity. The product team is quite lean, and the users need a solution relatively soon. It turns out that the e-mail notifications module would be the easiest to build and the most beneficial for the users. It will take about four sprints to design and develop the final solution.
Just before the first sprint starts, the product trio sits down and discusses the metrics for the project. They will call the project a success if:
After the first quarter of use, the quarterly e-mail open rate is at least 40%, and the CTR (Click-through Rate) is at least 10%.
At least 30% of respondents pick e-mail notifications as one of the most significant improvements to the system in the following quarterly user satisfaction survey.
User satisfaction level for the following quarter after introducing notifications is improved by 5%.
100% of the status change notifications for the HR processes are delivered to the respective users via email.
All of the metrics listed above are pretty easy to track. The first three metrics are more for the product manager and designer to own, track, and report. These are the lagging indicators of positive change for the end users. The engineering team could own the last one, a leading indicator that the feature was implemented properly and behaves as intended. If all of them are green, the team could call the project a success.
What else could be measured?
From the business perspective, the team might have wanted to demonstrate savings or contribution to the company’s revenue. If the team had baseline data on using certain features and time spent performing particular tasks needed to close an HR process, they could measure whether notifications show a significant drop in the time users spend completing tasks.
2. How will the users benefit from this project?
The job of a product designer can sometimes be tough, as we must address the needs and expectations of various parties. We try to find the right balance between the needs of our users, business ideas from our stakeholders, and technology constraints. While we do that, we must remember that we are ultimately the only users' advocates. Sometimes, we struggle to undoubtedly tell if the users will benefit from the project we were assigned to.
When I think about the user’s benefits, I tend to go deeper with these three additional questions:
Will what we're about to create be something they find truly helpful?
Will the users love it and keep using it in their workflows?
Won’t this new feature degrade the user experience of the entire system?
Without data, we wouldn’t know.
We need context to understand why we were tasked with a particular project. Hopefully, the reason is not another bright idea of a RHINO or ZEBRA kind of stakeholder, but the assumption was based on some evidence. Suppose we have collected feedback indicating that our users have a particular need or struggle with a specific type of task in our system. With such data, we could assume it’s worth building the feature.
Even if that’s true, we can’t yet be 100% sure that what we are after is exactly what our users need and that this would be the best way to solve their pain. To give ourselves a better chance, we still need to do more work and gather more data through product discovery and usability tests.
3. What can go wrong, and how can I mitigate the risk?
Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” Because of their nonlinear nature, design processes are complex to plan. We cannot plan every step and hope to tick off all the boxes one after another. Instead, we can try to identify potential risks and dependencies to better prepare for what may go wrong.
Everything we do is somehow framed in time. Executives ask us questions and set project deadlines. They help us seize opportunities, set priorities, and feel accountable, which influences our motivation. Without identifying risks and dependencies, we might fail to give our bosses correct estimates, miss deadlines, and lose credibility and trust.
How do you identify risks?
Start by listing all the actors involved in the process. For example, your exploratory study might include talking to three internal stakeholders and ten external participants. What can go wrong with the interviews?
The difficulty of finding a representative, diverse group of participants to avoid biased results.
Finding time to talk to busy stakeholders who juggle multiple projects at once can be complex.
The research objective might not be well-defined, leading to vague outcomes and wasted resources.
Product design can be tricky for various reasons. Sometimes, we need to simplify a complex process, and sometimes, a feature that looks super simple takes ages to implement because it communicates with many other systems under the hood. Recognizing those dependencies early in planning can save us months of wasted work and tons of stress. If you have never worked with dependencies, start by familiarizing yourself with the Dependency Map – a technique that product managers use to visualize how different components of the system depend on each other.