How to scope product design work
Estimating and scoping your product design work is important. Especially if you're in the fast-pace environment. Here's how.
Q: Hi Budi, I’m working in a fast pace environment—I don’t mind it, but I have difficulty estimating how long I will need to work on the design. Moreover, I often uncover some cases along the way, and it causes a delay in the project. Any tips?
Seems like you work in a modern product team often timebox their work. Which is awesome. Timeboxing prevents us from spending 3-6 months building something no one wants. The faster we ship the product to the customer’s hand, the sooner we get real-world signals from users.
Identifying the potential work upfronts can really help you in that environment.
When I was an individual contributor, I never get a practical advice about scoping. So I build my own process, which I’m gonna share with you.
Let’s imagine you only have two weeks to improve an existing feature. What can you get done? Which part of user interaction should you cover now, and which one can be ignored now?
That’s a tricky question. But an important one to answer.
How to break down the design scope
In this post, we’ll go through the step-by-step scoping process. We’ll use a hypothetical example from Uber to make this guide easy to follow. Paid subscribers can access the template.
1. Identify the users and their goals
To start, you want to identify who the users and what their goal is. If you still aren’t sure, you can use a simple problem rundown template:
Our users are _____(users)___
Their goal is ____(job to be done)____
Their struggles are ____(pain points)____
We know this true because ____(data / observation)____
Solving this will be great for our users because ________
and also benefit our organization because ________
Let’s use Uber as an example. Imagine that users still need to pay their Uber trip with cash. We want to provide a way for users to add a credit card as the payment method. The problem rundown could look like this: