3 design thinking techniques to run before a redesign

When someone asks me for a redesign, three questions rush into my mind. Whether it’s a product, an app, or a digital workplace environment, the questions are still the same:

• What are the main pain points of the current solution?
• How can I figure out solutions to those issues?
• How can I reveal what—or which parts, or features—are the most important for users?

The answers to those questions build the foundations of everything that comes later—which is usually a design sprint—and we need to be sure about them. We need reliable, weighted, specific, and focused feedback. And heck yeah, it’s complicated.

Related: How to introduce design thinking into your organization

During the last three years at Raona, we’ve tested more than 100 techniques to get reliable answers. Most of them related to design thinking, Manual Thinking, or Gamestorming. Some of them to less known sources, such as the DesignPedia, or even Lego® Serious Play®. And the UX gods know we’ve even tried to design our own techniques to get that info that helped us to do our jobs better.

Honestly, most of them didn’t work as expected. Some revealed irrelevant insights, some offered just a partial vision, and some of them weren’t guided or focused enough and users started complaining about a million things that were useless for us.

But good news! There are three design thinking techniques that really made the difference, and we now use them in every single workshop we run. They provide specific, focused, and weighted feedback for anything you might be redesigning.

And a big point: You’ll just need three hours.

The Speedboat

We use The Speedboat as a group/team focalized and guided critique activity. It helps us understand the main pain points of the current solution, and then prioritize or weigh them.

1. Start by drawing a speedboat in a whiteboard or a map. The boat represents our product, app, or system, so we put its name on it.
2. Explain to the group that the ​​boat’s goal is to go as fast as possible. But… it seems like there are some anchors slowing it down.
3. Give every participant six stickers and a thick pen. Give them seven minutes to write the six anchors (pain points) that they think that are slowing down the boat. No extra rules. This simple.
4. When the time is up (or everyone has finished) ask every one of them (one at a time) to stand up and explain which they think the main anchors are, and why.

Pro tip: Ask them to stick the anchors to the map. Do it even if previously another participant put on that very same anchor (ask them to place it next to the other, or on top of it). It helps keep people in flow and reduces that awful feeling we all experience when our opinion is discarded.

“The speedboat reveals the main painpoints of a system and how relevant they are for users.”

When everyone has explained their anchors, it’s time to weigh them. You may use any voting technique you like. We give five red dots (stickers) to every user and ask him or her to stick them on the anchors that are more relevant for him or her. It provides a sort of pain point heatmap.

And you’re done! You’ve just had a focalized 100-100 critique activity, and you end up with a weighted list of the most relevant pain points of your product.

It’s magic.

Tips and tricks

Aim for 4-8 participants. You’ll need seven minutes for the initial task, 2-3 minutes for every user to explain their anchors, and five more minutes for the democratic voting. For groups with more than eight participants, the group phase will last more than 30 minutes, and people will start disconnecting.

The original speedboat activity is designed to ask participants what they think that characterizes the optimal boat performance before doing the anchors exercise. We don’t use this approach because it assumes that the team can create in some minutes a shared vision of what the optimal performance is and aim for that when setting anchors (which doesn’t happen, and participants get less involved as they feel it’s not their goal). But feel free to use it if you think it helps.

4x4x4

I know. Someone asked you for a redesign, you just revealed the main pain points, and wooooosh! Your mind starts creating an infinite bunch of solutions that may help or solve them all, and you feel in a hurry to share those solutions with the participants to see how they are received.

Related: 7 qualities of design thinking leaders

But hold on. Fight the beast. You came here to get information, not to generate solutions. You’ll do that later in in your design sprint.

And keep this in mind: You’ve just discovered their pains, but users have suffered from them for a long long time. They’ve probably already been thinking and talking about solutions. And this information is gold for you because it won’t be the final solution, but it will definitely show you how users think and what they consider a solution to their problem.

4x4x4 is a group guided brainstorming activity designed to focus on a single issue.

1. Choose the pain point or issue that you’ll attempt to solve. Yup, just one.
2. Give every participant four blank cards and a thick pen. Give them four minutes to generate four possible solutions to the issue (one on each card).
3. When the time is up, group the participants in pairs, because the playoff is about to start. Give every pair four minutes to choose just four of the eight cards they have now (four from every single user), and discard the other ones.
4. When the time’s up, make groups of four participants and again, give them four minutes to decide which of the eight they have they want to keep. Just like a playoff.

“4x4x4 is the most effective way to get lots of solutions in a short amount of time”

Short and simple. With eight users, in 12 minutes you generated a list of 32 possible solutions for the issue, and users (not you) had it filtered for you so that you end up with eight super cool solutions that users believe should help solve the issue. You now understand how your users think and feel about it.

All this in 12 minutes.

Tips and tricks

In the playoff phase, a couple of filtering rounds is fine. You can run a third one if you want (with the whole group), but make sure to save some time there. Having eight people agree on something is difficult and will take longer.

The Crazy 8s activity (described in GV‘s Design Sprints) works also really well in when facing a specific challenge (though it’s more focused on design). Anyway… 12 minutes. You can’t fight that.

Buy a feature

You got the pain points and even discussed some solutions, so we should think about our solution for that redesign, right?

At this point, activities like prune tree or the Osborn’s checklist may help you develop the strategy for the whole product evolution. But let me focus on a specific point that usually goes unnoticed.

You may get to this point with lots of possible solutions. Some coming from real users, some from the product team, and a lot coming from you and your team. So how do you choose the right ones?

Oh, I forgot—you do design sprints. You Crazy8, vote, pick up the ones you decide to test, and test with real users on Friday.

But who does this selection? You do (hopefully with the team).

And then cognitive bias shows up. Boom.

The buy a feature activity is a weighting and prioritizing group activity that will help you make that selection in a more reliable way—and it’ll save you effort.

1. Before the user group session, start listing all of your new ideas, features, concepts, and give each of them a price (yes, a price) regarding its complexity. Imagine complexity as a sum of everything around the feature: development cost, for sure, but also design cost, difficulties to ship it to production, user engagement, training, support, etc. Don’t even have a meeting with yourself for this. You know what’s complex and what will take time, and what won’t. Just put down the prices. It may be a good idea to standardize somehow. Say that ‘normal’ ideas cost 40 Oscars, “complex” ones cost 50 Oscars, and “easier” ones cost just 30 Oscars.
2. Now print fake money—something like Monopoly money that makes users feel like they’re playing a serious game.
3. During the session, make user groups (with 2-4 participants in each group) and give each group some fake money—but not enough to buy all of the new stuff, obviously. A good ratio is to aim that they can purchase 50 percent of the features.
4. Give them seven minutes to decide which features they want to buy with their money. When they’re done, or the time is up, ask them to get to the “shop” (that’s you) to buy their features. Take their money, and deliver a sticker with the feature name to them. Ask them to stick it in a map.

And then something magical happens: You realize that everything you thought you knew before doing this activity is wrong. That solution you spent two hours discussing with the group, the one everyone seem to agree with, hasn’t been purchased. The IT team main initiative was bought just once. And those small improvements that didn’t seem to help at all have been purchased by almost all groups. What the… ?

People have a deep sense of cost and savings, about what’s worth it and what isn’t, and what deserves investment and what not. And all of it comes to light in this purchase list.

This is real info. This is where your real discussion starts. Explore with the group (directly) why those have been purchased, and why others weren’t. You’ll not only understand your users better, but you’ll be able to make a proper selection.

“Buy a feature reveals which are the most relevant features for users, and how your product should grow.”

Conclusion

Imagine you include the previous activities in a single workshop with eight users. In less than three hours you’ll get the main pain points, some curated ideas that users believe solve their main issues, and a reliable prioritization about what should come next in your product and—who knows—maybe a product strategy plan. And a better and deeper understanding of the users relationship with your product/app/system.

All this in just three hours.