Design Your Design Process

There a couple of schools of thought around what makes a good designer. Some subscribe to the Genius Theory, which says some people are just innately more creative than others. The trouble with this theory is it puts a lot of faith in someone’s intuitive ability to shoot from the hip and nail the target each and every time. If you aren’t getting the results you want, what can you do about it? Hire more designers and hope they’re better than the last batch?

You’ve probably already figured out I’m not a fan of the Genius Theory. Design is about problem solving. To solve a problem effectively you first need to define it, then understand it from all angles, then come up with a lot of possible solutions before selecting the best one. That’s process son. If you aren’t getting you the results you want, refine your process.

To some designers, “process” is a four letter word. They equate it to assembly line manufacturing where the goal is to produce exact copies with minimal variance. Think of the design process more like the Scientific Method. People have used it to come up with all sorts of wild stuff, from gravity to vaccines to nuclear energy. A design process is nothing more than a framework for problem solving. It doesn’t say anything about what the solution should be, it just helps you get there.

Google “design process” and you’ll get plenty of different results. Some have three steps, some have five, while others have twelve or more. Look closely and you’ll notice they’re all saying the same thing, they’ve just broken it up differently. You can break it up more or group steps if that works better for you, but think carefully before removing any.

It’s worth mentioning that the process is linear, but there’s overlap between adjacent phases. While you should never jump to sketching ideas before you’ve defined your problem, you might need to go back and refine your problem statement and goals as you learn from your research.

I break it up into five phases - Define, Research, Imagine, Create and Test. Let’s look at each:

Define

What problem are you trying to solve?

Before you can solve a problem, you need to know what problem you’re trying to solve. Sounds obvious, right? The trick is to make sure you’re solving the right problem. Try to identify the root cause so you aren’t just treating symptoms. Your stakeholders won’t always know themselves, so as a designer this means asking a lot of questions to help clarify the goals. This can look a lot like a 2-year old asking “why” every time you say “put your shoes on,” so be cool.

Example:
Client: We need to increase the number of views on the FAQ page.
Designer: How does increasing FAQ views help the user? Or your business?
Client: Well, people are getting frustrated and calling the help line too much to get answers. We’ve had to hire another CSR just to handle the call volume.
Designer: What sort of questions are people calling about?
Client: Mostly it’s how to create an account and reset their passwords.
Designer: Gotcha. So the problem is our users are having trouble finding information on managing their accounts. Y’know, there just might be a better way to solve this than driving them to the FAQs...

  If you can learn something
from testing, test!

What comes out of the Define phase?

A clear problem statement with success criteria you can test against.

If you’re working in Agile, that means a user story and acceptance criteria. As a designer, I recommend completing a Creative Brief. However you do it, just make sure your stakeholders and the team agree to the problem definition and it’s documented somewhere.

What NOT to do in the Define phase

Don’t start coming up with solutions. If you start down that path now you’ll end up baking a single solution into your problem statement, eliminating all other possibilities. If your problem statement says, “we don’t have enough links to our FAQ content” you’ll just end up adding more links to your FAQs, when what you really need might be a better welcome experience and an obvious way to retrieve a lost password.

Research

What questions do you need answered?

Too often this step gets skipped. The stakeholders and/or the design team is overconfident in their own understanding of the problem and moves forward on assumptions rather than taking the time to do a little legwork.

“Research is all well and good,” I hear you say…” but who has that kind of time?”

You do. I promise. Research doesn’t have to mean spending weeks or months meticulously collecting data and compiling reports. Time-box it. Decide which questions you need answers to, then figure out how to get the best answers you can in the time you’ve got. If you only have an hour, learn what you can in that hour. If you’re never given more than an hour, you’ve got a systemic issue that needs to get addressed.

Let’s go back to our previous example of people having trouble managing their accounts. We need to know why people aren’t able to figure out how to create an account without help. We’ve only got budget for two days of research, so we take our tablets down to the corner coffee shop and offer to pay for folks’ lattes if they’ll give us some feedback on our app. What we learn will help us refine our goals and come up with ways to achieve them.

If you can learn something from testing, test!

What comes out of the Research phase?

Answers. You can get them any way you can imagine. Look at analytics reports, search for best practices or studies, and look at what the competition is doing or how other industries have handled the problem. If you can, talk to your users. Send out surveys, conduct interviews, or watch people use your product and see for yourself where it’s working for them, and where they’re struggling.

What NOT to do in the Research phase?

Don’t just Google “best FAQ design” and look at a few screenshots. The goal here is to understand the problem better, and while checking out other people’s ideas is part of that, if that’s all you do you’ll severely limit your possibilities.

Imagine

How many different ways can you solve the problem?

Your first idea isn’t always your best idea. Start with sketches. On paper. Here’s the problem with jumping right into Photoshop or HTML (or your tool of choice) - once a designer has invested an hour in an idea, they’re married to it. It’s seared into their brain and crowds out all other possible solutions, and they’ll defend it with their life rather than accept its shortcomings and start over. Sketches are quick and dirty, and created with minimal time investment so we don’t fall in love with them. We’re all about playing the field here, not jumping straight to commitment.

Rules for sketching:

• Don’t spend more than a minute or two on each sketch
• Don’t erase, cross out or throw away anything, just move on to another idea (you might come back to it later)
• Come up with as many ideas as you can, all of them solving the problem differently (10 is a good minimum, but shoot for 20 or more)

Once you’ve got a bunch of ideas, evaluate them against your problem statement and requirements. Decide on a few that have the most potential and refine those a bit further as larger, more elaborate sketches with more detail. This will help you think more about relationships between elements and uncover some issues you didn’t consider. At this point you may even break out Photoshop and start assembling some mockups for comparison. Maybe do some A/B testing on your ideas to get some audience feedback.

This is a great place to get some client and stakeholder input. Present your work by reminding them of the problem statement and requirements, and talk about how your ideas meet those criteria. This’ll help you get more meaningful feedback than “can the logo be bigger?”

Finally, you’ll select the best of the best to actually build.

If you can learn something from testing, test!

Create

Build the best solution.

I die a little inside every time someone calls this the “design” phase. This isn’t where you design, this is where you make the thing you designed.

If what you’re building is part of a larger ecosystem, use style guides and pattern libraries. Follow best practices, or if you’re breaking them know where, how and why you’re doing it. This is where people see the result of all your hard work, so pay attention to the details. If something’s misaligned by one pixel, fix it. This is no time to get sloppy.

  If you can learn something from testing, test!

Test

Did you solve the problem?

 
If you only do testing at the very end, you’re doing it too late (you didn’t think I kept shouting about testing up there for nothing, did you?). What if you find out your new design actually made things worse? You’ve wasted all that time on the wrong solution and have to start over. Could you have found out earlier by testing a prototype with users? Plan ahead. You can learn a lot from testing, but what good is it if you didn’t account for the possibility something might need to change?

This gets its own phase so you remember to do it, and to create an opportunity to conduct bigger tests over longer time periods. Ideally, you and your stakeholders agreed to some success metrics up front. If your goal was to reduce calls to the help desk for login issues, you should see that number go down over a given time period. If it goes up instead, you may have actually made things worse, or maybe something else is going on to influence the numbers (like a seasonal spike in traffic). Know the difference.

Wrapping it up

Without a process, your success relies on divine inspiration. Build your success around a proven method instead, and you show it's repeatable. Share it with your clients up front, walk them through it and show them how it'll create results. They'll be less anxious because they can see how you'll tackle their problem, and you'll build a brand that inspires confidence.