A bad idea—even well-executed—is still a bad idea. And, ultimately a waste of time and energy.
With so much at stake, learning how to identify and avoid these looming catastrophes is absolutely essential. At Simplease, we’ve developed a 7-step process using UXPin and Userbrain that identifies and kills bad design ideas before they have a chance to wreak havoc on our projects.
At its core, our process involves testing ideas as early as possible, rapid prototyping, and usability testing. We’ve shaped this approach to fit how we work and to make it as useful and accessible as possible.
These seven steps are easy to fit into your own projects, so I’m going to explain each one by walking you through one of our recent projects.
Step 1. Identify the problem
If people tell you what they want, it’s NOT your job to give it to them. Your objective is to understand WHY they want it—to learn more about the problem they hope to solve.
We do so by asking questions and listening closely to how our client and other stakeholders respond to a series of questions we pose. If you’re familiar with the TV series Columbo, you already know how this works. Let me explain.
Each Columbo episode is structured exactly the same way. In the beginning, you always see how someone is murdered. Though the viewer already knows the murderer, Inspector Columbo has no idea. For the rest of the episode, you watch him figuring out who committed the crime. (Needless to say, he catches the murderer every time.)
By NBC Television (eBay item photo) [Public domain], via Wikimedia Commons
Why am I telling you this? Because interpreting evidence and clues is very much like identifying a design problem. It requires reverse engineering.
When we started working with MegaCorp (not the client’s real name), we were overwhelmed by the sheer number of stakeholders and their differing perceptions of current problems and challenges. It was anything but obvious which problem we should aim to solve, and just like Inspector Columbo, we had to invest a lot of time conducting interviews and asking questions:
- When was the last time you had this problem?
- Can you please describe what exactly happened?
- That’s interesting! Can you please explain this in more detail?
- Did you use any tools, or maybe something else you can show us?
One thing you should notice when looking at these questions is that they are all asking for past behavior. Why? Because we’re interested in facts, not opinions or ideas.
In our interviews with MegaCorp employees, we discovered they were suffering from internal communication problems (which company isn’t?) and they used a wide range of tools to tackle this problem. One of these tools was an Excel file developed to help team leaders to plan, organize, and host weekly (or biweekly) meetings with their project teams.
The biggest problem with this Excel file was that most people at MegaCorp didn’t even know it existed. And those who knew about it didn’t like to use it because of its terrible usability. In contrast, those who used it considered it an invaluable tool. That’s why we scheduled interviews; we asked employees to show us how they used the Excel file, and then explain what they were using it for.
But unlike Inspector Columbo, we’re not done once we’ve identified a problem. That’s the point where we’re really getting started …
2. Sketch out ideas to solve the problem
If you’re thinking of a specific solution, you’ve already gone too far. Why? Because you can’t be sure that this one is actually the right solution for the problem.
Before we even started doing anything else, we got ourselves some sheets of paper and began drawing quick sketches to simply get ideas out of our heads. The reason for this is that your first ideas usually aren’t very good—because you don’t understand the problem well enough at this point.
Pushing out a multitude of potential solutions accelerates ideation in the same way a pressure cooker accelerates cooking. Once you get into a groove, it’s safe to tone it down and let the ideas percolate.
Sketching is the fastest way to get ideas out of your head and decide if they could actually work
Sketching is more about finding the right design, as opposed to getting your design right. That’s why we start the process by focusing on quantity—generating as many different designs as possible instead of latching onto our first solution and running with it. Sure, it’s a solution, but it might be the wrong solution. We have to find this out first, because if it is, there’s no point in perfecting it.
Ignore the details early on. You will have plenty of time to work on them once you’ve discovered a good idea for your design.
In the case of MegaCorp, my mind was set on the Excel file they had been using. I thought that if we could just make this Excel file better and turn it into a user-friendly web application, we would eventually solve their problem. Although this seems like the logical solution, it turned out to be fundamentally flawed, as you’ll see later.
But first, it’s time to show your sketches to colleagues for some quick feedback before you begin building a prototype.
3. Share your sketches with your team
At this stage, you’re looking for what doesn’t work. Find out which ideas to kill before you dive deeper. Typically, feedback from colleagues is a perfect way to filter before showing anything to one of your users.
The easiest way to share your sketches is to approach a colleague and ask for a few minutes of his or her time.
If this person is already familiar with the project, you can start asking for feedback right away. If he or she doesn’t know about the project, just explain the problem you’re trying to solve. (This also helps you better understand the problem because you have to explain it to someone else.)
Once your colleague understands the situation, begin to show your sketches—but DON’T explain any of them.
I usually only clarify the problem. My solution should be obvious, after that. If you keep asking for feedback without explaining or defending your solutions, you’re increasing your chances of achieving a design that really works.
How to ask for feedback: Ask people if they have a minute or so to help you with something. Most people like to help and will do so if they have the time. Also, tell them you’re interested in their thoughts and opinions; I have yet to meet someone who doesn’t like to know their opinion is valued.
That said, giving feedback is harder than asking for it.
How to give feedback: Before stating your (subjective) opinion, ask the designer to explain his or her thinking on the ideas you don’t think are good enough, yet. Ask why they made it the way it is. Asking why allows you to question the weak points without killing the morale of your colleagues by saying it’s bad, and it’s actually one of the best ways to understand a problem.
How to take feedback: With a grain of salt. Soak up everything, but don’t necessarily act on any of the reactions you receive. If the feedback was subjective, try to uncover the reason behind this thinking, or better yet, just ask for it. It’s hard for people to show their thought process instead of just revealing their opinions.
We’re so accustomed to talking about the tip of the iceberg that we forgot how to go deep, all the way down to the root of the issue. Your colleagues’ opinions are only supposed to provide you with input that will make it easier to pursue future design decisions—not to dictate them.