Don’t design anything until you get answers to these 3 questions

Too many times I’ve jumped eagerly into a project only to realize I have key knowledge gaps. The result was a mess of redesigns, rushed research, impossibly short timelines, frustrated team members, a grumpy designer (me.)

You won’t have ALL of the answers when you start a project, but pump the brakes until you know the answers to these questions:

What problem are we trying to solve?

And no, I don’t mean what you were asked to do. What is the actual issue you need to fix? Instead of being presented with a problem, we’re often tasked with deciding the interactions and visual style of a pre-conceived solution. As Sarah Gibbons from the Nielsen Norman Group says: “a great solution to the wrong problem will fail.”

Let’s say you work on a product full of educational content for parents.

A product manager gets a request from a few customers to add the ability to bookmark pages. That is easy for you to execute. You make wireframes and test the usability with users. Users are able to bookmark pages without issue. It can be built and released to users.

But what if you did some more digging into the problem before putting pen to paper (or cursor to frame?) You talk to the customers and realize the reason they want to bookmark pages is that they can’t find what they are looking for.

You start digging into more support requests and see that the theme of losing track of pages is common among your users. Some are requesting bookmarks, some want a better search tool, and many don’t know what they want, just that the way it is now isn’t working for them. Suddenly the possibilities in this problem space have opened up. The problem isn’t that users need to bookmark pages, it’s that ‘users can’t find the pages they are looking for.’ That gives you the room to do what designers do best — solve problems.

This template from uxspot.io is a simple place to start if your team is having trouble defining the problem.

How will we know we’ve solved this problem?

We can iterate forever, but what is the signal that we have done what we set out to do? It’s easy to jump into a project without this answer. It seems like something you worry about towards the end, but it’s difficult to hit a moving target.

Let’s take the scenario from above. Once we’ve defined the problem as finding different pages in our app we need to think about how to measure success. Our signals may be:

• A reduction in support requests
• An increase in user satisfaction
• A reduced time on task for finding particular pages

Collaborate with your product and development team to figure this out. You can start at a high level and move into more detail as you work. Using the model proposed by the HEART Framework is a helpful resource to start defining success.

Another reason to think about this upfront is so that you can measure a baseline. A baseline is an initial measure you use to compare to a new measure. This comparison is what will tell you and your team whether you were successful or not. Depending on what you’re measuring and the tools you have, you can’t always measure after you make a change. Play it safe and measure the baseline in the beginning.

Lastly, numbers can tell a great story for you and your prowess as a designer. Whether you add the results of your effort to your resume or use figures to prove the value of design to your organization internally, it’s great to have them on hand.

What is the timeline for this project?

Ensuring everyone involved in a project is in agreement on the timeline is a simple way to keep a project running smoothly. No one wants to be the squeaky wheel. In order to ensure everyone is on the same page make sure you discuss timelines. Nail down:

• When will the project be kicked off?
• What checkpoints will we have?
• When do we want development to start building?
• When do we want to release this to users?
• Are there any major milestones we have to meet?

You may need to get a little pushy, but in order to ensure you meet the expectations of stakeholders, you need to know the timeline they have in their heads. Use these questions to start a healthy conversation about how long it will take to do quality design and research. Speak to the risks associated with short timelines.

The other major benefit of this question is protecting yourself from changing timelines. Have the agreed timeline documented and refer to it often. We all know that timelines change and that’s ok, but you want to be able to refer to the previously agreed timeline if anyone has concerns about the status of design work.

Lastly, document it all.

New team members will join, leadership will change, folks will leave the team, etc. Documenting these decisions helps your team to be more resilient to change.