Questions Constitute a Good Design Process

There are already some great articles out there exploring Design Processes.

Joanna Ngai’s short 4-step article on the subject is a great introduction & Thai Lam’s article are both great in-depth how-to guides on building a good design process.

However, I also think it’s important — and in some ways more simple — to consider the questions that lie at the core of each stage in any design process.

Because reading the theory is important, but are too easily washed out by our busy lives, distraction & passive reading.

Questions, on the other hand, tend to get us thinking & are applicable to any context.

The 4 key steps in any design process In the following article I will elucidate 4 key steps to any successful design process, explore the theory — as well as the reality of implementation — leaving with you with some key questions to contemplate at each stage.

All design processes differ from designer-to-designer, from problem-to-problem, from product-to-product, but these 4 steps should be at the heart of every design process in some form.

 1/4 • Discovery: What problem are we solving? Why? How do we define success?

Assuming you are starting on a problem from scratch, this is the stage where you are defining precisely why you are all sitting in a room together intending to work together for the next few years.

It’s the high-level stuff. It’s the vision. It’s the solution-agnostic, tangible problem you are going after.

Most likely, someone has come up with a smart idea, has done as much research as they can into the market, into the competition, into the potential users — they may have even tested a few ideas out.

The stakeholders are then gathered to consider — and answer — the following:

What problem are we solving? Why? For whom?

How do we know it’s a real problem?

 2/4 • Analysis: What do we know about our users? What insights have we gained?

Now that you’ve selected a specific problem to solve for a specific group of users, it’s now important to zoom in on both that problem & those users.

Theoretically, this stage should constitute a calm, considered approach to analysing the problem:

The team rationally sifts through any existing data (user interviews, surveys, feature requests, quantitative data from your product analytics) looking for insights & creating user personas (profiles of different user types) from those insights.

Those insights should reveal specific pain points for users that need alleviating. Once that pain point has been judged to be a priority to solve, we move on to considering how to solve it.

It is essential to remember that selecting one problem to solve means not only that you will be directing the entire team’s resources towards solving that problem. It means that you are also, therefore, not directing the entire team’s resources towards the other problems you could have solved.

It is therefore really, really important to make sure you are solving, firstly, a real problem &, secondly, the most important — not to be confused with urgent — problem facing your users.

That’s the theory.

But then, BANG, your theory face-plants into reality. And reality is pretty different.

Reality laying down a Smackdown on Theory In reality, it tends to be very different, in fact. It’s messy. Disorganised. You’re moving quickly. You’ve got a million other things to think about. No-one really knows what’s going on, because you’re trying to solve some new problem that doesn’t have a known solution.

A few specific problems tend to arise:

The team is likely to be stressed, busy & over-worked, leading to poor decision-making Sometimes we assume that, because someone (maybe higher up than you) suggested an idea, it’s therefore a good idea & they’ve likely already validated it (because they are more experienced, right?) An urgent problem appears that clouds our ability to differentiate urgent from important We rarely have concrete, conclusive data to champion one problem over another (because qualitative data is somewhat subjective & quantitative data produce various, inconclusive insights) It is therefore important to always consider the following questions:

What problem are we solving? Why? Is it a problem for our users?

How do we know that? What data do we have to support our assumptions? Have we even questioned our assumptions? Are our assumptions biased? If so, how have we mitigated those biases?

Have we prioritised effectively?

3/4 • Design: How we can test & validate possible solutions?

At this point you should have broken down the specific problem you are going after & organised its subsidiaries in priority order (i.e. which are most important to solve first). If not, then go back to the drawing board, as you’re about to commit a lot of time to building the wrong thing.

Once clear on the specific problems you need to solve, you can start testing possible solutions out on real and/or potential users. This is typically done testing wireframes or a prototype on users to judge whether the idea will help solve their problem.

The key is speed: Test as many ideas as you can on as many people as possible. The more you test, the better you can validate your assumptions.

But, again, theory is not like reality. Not only are you going to face difficulties in prioritisation from lack of clear information & internal biases, you will also face these same issues & some when determining possible solutions.

These are just a few of the difficulties that arise here:

We are human, meaning we tend to love our own ideas & think they are awesome. This means we inevitably try to look for data supporting our ideas, conveniently ignoring data that negates our ideas As mentioned before, qualitative testing can be subjective & messy, particularly if it’s only on a few people. There tend not to be conclusive answers unless you test on a large number of users, which is unrealistic in a small, fast-moving startup Prototypes are just that: Prototypes. Unless you have a big team using comprehensive prototypes that pull in real data (so there is full functionality), you can never fully replicate the functionality of a real product The person being tested will act differently than in real life: They will tend to say what they think you want to hear (“What an awesome product!”), they will focus more on the task than they usually would, they will think it’s a test of their intelligence to some extent (regardless of how much you assure them it’s not a test)

User testing: Whatever they really think, they’ll still say it’s “awesome, amazing, etc.” With this in consideration, it’s important to stop & ask yourself some of the following:

What problem is our potential solution solving? How can we validate that? What form of testing would be best in this context? What are the limitations of our test?

During testing, what assumptions have we made? What biases are we bringing to the table?

What about the person being tested? Are we noting what they say, or what they really mean?

4/4 • Implementation: What’s the final solution?

Now you’ve honed in on the best solution you’ve come up with, you need to deifne precisely what to implement.

This involves designers, programmers & a product manager sitting down together & defining the precise specification of what needs to be delivered.

At this point, the ideation stage is over. It’s time to commit to that solution, not explore potential alternatives.

As a designer, it’s easy to think your task is over once you hand over a final UI, but it’s really important to take ownership over implementation to save the whole team time. Ask yourself the following:

Is this the best possible solution for our problem, considering the constraints of development?

How have I simplified this to make it easier to develop? Have I made the specifications as clear as possible? Have I been clear on the technical aspects of development?

How can I ensure the final product reflects my designs as best possible? Checking in with developers? Providing more documentation? Helping them with implementation?

 Conclusion

Each design process is different. There is no secret formula, no clear answer, as each designer’s approach is valid, each problem is different.

By sticking to these 4 steps, however, you provide yourself with a strong framework to work within.

The contents may vary, but the questions posed at each step are relevant to each & every design process.

So start asking questions, rather than looking for definitive answers.