Technology

Use this Exercise to Solve Any Product Design Challenge

This curated post is authored by UX designer and Product Strategist, Jonathan Courtney

Kill discussion and start executing

**If you’re not in the mood to read this giant article, just watch this giant video where I explain exactly how to run this exercise, you can always use the article as a reference later. I’m not exactly video “savvy” but hopefully got the basic points across! Thanks to my colleagues Brittni, Mike, Bruna and Kyle helping me make this nightmare!!!**

UX design, product design, service design — whatever you’re into — in the end, if you’re creating value, what you’re really doing is creative problem solving. It’s is the only non-commodatisable attribute of the design process, the only part of the process that you can’t just throw money at to get done right. It’s being able to assess what the real challenges are, prioritise them, produce solutions and measure their effectivity. Creative problem solving is a cornerstone skill that separates good designers from the best designers. Everything else is production work.

The problem with anything that requires creative thinking however, is that it’s easy to get lost—lose focus and fall into the trap of having useless, open-ended, unstructured discussions. Many products end up being released late and full of compromises to the original vision simply because the team is so fatigued from bashing heads together on endless, unprioritised problems.

This “project fatigue” (which I’ve written about a few times before) shows itself in many ways within teams; there’s an underlying passive-aggressive tension, there’s gossip, people start leaving and there are clear ego imbalances. The team has been fighting in the trenches for too long, and people begin to sabotage each other to promote their own ideas, whether they are “good” or not. So, how do you solve this extremely common problem that you’ll find at almost every company?

“Remember when working on this project was fun?”

The Solution

Here’s the most effective solution I’ve found: Replace all open, unstructured discussion with clear process. At first this will absolutely feel weird, I’ve seen the scepticism on the faces of designers who are used to battling through passionate back-and-forths with colleagues until eventually one person gives up, or someone says “let’s test it” (often used as a ‘get out of jail card’ for anyone wanting to end a tricky discussion). Freedom to discuss might seem conducive to creativity, when it’s in fact the enemy. Structure and Discipline create the Freedom needed to be creative.

Okay, okay, the only way you’re going to see the results of this principle of killing discussion is to try it for yourself. Let’s have a look at a very simple, 30 minute exercise we use whenever we want to kick off a short problem-solving meeting. Keep in mind, we have dozens of different exercises to pull out depending on the scenario — so take this as an introduction to the principle of Removing Discussion rather than the “only way to do it”.


The Exercise: Lightning Decision Jam (LDJ)

I know, LDJ sounds weirdly sexual. Come up with a better name, i’ll use it 😉

Supplies you’ll need (linked):
Rectangular post-its, I like yellow
– Square post-its (2 different colours, I like Pink and Blue)
– Voting dots, 2 different colours
– Sharpies or something similar
– Time Timer or any timer that Clearly shows remaining time
A nice playlist of focus music, this is one I created, feel free use it!

Total time needed:
The times i’ve suggested in the exercise are more of a guideline and may only be relevant to the first time you run through it. The exercise itself usually takes between 25–40 mins.

Choose a moderator
You absolutely need to select someone on the team to take the role of the moderator. They can join in on the process but must focus on making sure no discussion breaks out and has to keep time. We rotate this role at AJ&Smart.

What to use this exercise for
Anything which requires a group of people to make decisions, solve problems or discuss challenges. It’s always good to frame an LDJ session with a broad topic, here are some examples:

  • The conversion flow of our checkout
  • Our internal design process
  • How we organise events
  • Keeping up with our competition
  • Improving sales flow
Read More:  Beyond Big Data Basics: In-Stream Processing Cures Batch Processing Blues

Okay, let’s go!!!!!!!!!!!

Everybody Ready??

1. Start with Problems — 7 MINS

The first step is simple: Everybody in the team sits at a table and without discussion they spend 7 minutes writing all the challenges, annoyances, mistakes or concerns that happened during the week. These can really be anything from “I don’t feel like we’re making progress” to “I feel like project X is getting more attention than my project”. Really anything that is bugging us. Once the 7 minutes are up, each person will have a pile of problem post-its in front of them.

An example of the types of problems which may come up during this exercise. Also, yes i’m using Comic Sans, no, i’m not using it ironically. HAHA! You love it.

2. Present Problems — 4 MIN PER PERSON

The moderator now selects one person at a time to stand up at a wall/whiteboard to very quickly explain each problem as they stick them to the surface. Nobody else in the team is allowed to speak here. The moderator should give no more than 4 minutes per person.

Once everyone has spoken and added their problems (we even include personal/health/mood) then everyone in the group has shared their challenges without going on 100 tangents.

My colleague Bruna adding and presenting her “problems” to the wall on the left.

3. Select Problems to Solve— 6 MIN

The moderator gives each member 2 voting dots — Everybody must now vote on the challenges they consider to be the most pertinent to solve, without discussion.

You can vote on your own posits here and you can put both your votes on one challenge if you feel strong enough about it. Once the 6 minutes is up, the moderator quickly takes the voted problems and arranges them in order of priority. What about the rest of the problems that were not voted on? Do they get lost? Well, more on that later.

4. Reframe Problems as Standardised Challenges — 6 MIN

a.k.a reformat problems to standardised How Might We’s

Now, only focussing on the voted and prioritised problems — the moderator is going to rewrite each one as a standardised challenge, this will help us create an array of solutions and be a little bit more broad at the start.

Let’s look at an example: The top voted post-it here says “I have no idea what’s happening on “project x”. Because many people have voted on it, we can see it’s clearly an issue many people are having. Rephrasing the post-it in a “How Might We” format allows us to make it solvable and standardise the way the challenges are written. Here’s how that problem might be rewritten into a more general challenge:

The moderator should quickly rewrite all the problems as quickly as possible, making sure they are still prioritised before moving on.

5. Produce Solutions — 7 MIN

Now the top voted HMW problem will be used to produce solutions. If there are two top voted problems, or three just start with the one on the left first. Don’t worry about it and do not discuss!

To the left, to the left.

Now each team member is given in 7 minutes to write as many possible ways to tackle the How Might We challenge without any discussion. Removing discussion here also insures a variety of solutions. It’s important for the moderator to tell the team members here that we’re aiming for Quantity over Quality– Later we can curate.

Solutions don’t have to be written in any particular way– but they must be understandable to people reading. There is no individual presenting of solutions as this creates a bias towards the best presenters.

Once the 7 minutes is up— now everybody sticks their ideas on the surface (wall, whiteboard, whatever) as fast as possible, no need to be neat— just stick them anywhere – this should only require one-minute.

6. Vote on Solutions — 10 MINS

Remember this? We’ve done it before right? The moderator now gives each team member is stripped of six d0ts to vote on the solutions they think would best solve the HMW. Because the members will need to read each post-it, a little more time is given for this voting process: 10 minutes.

This image, out of context, zero sense.

7. Prioritise Solutions -30 Seconds

Deja vu! Just like we did with the problems, the team now has 30 seconds to make a prioritised list of solutions — Ignore anything with the less than two votes. You will now have something that looks like this:

Read More:  8 Ways Billionaires and Elite Athletes Perform at the Highest Level

8. Decide what to execute on — 10 MINS

It is clear that some solutions are more popular than others to test out, but it’s important to know how much effort is required to execute the solutions – so here we use a simple effort/impact scale to determine which solutions to try ASAP, and which should be added to a to-do list, or however you store your backlog.

The moderator needs to be very proactive at this step, as it is the only one that has a tendency to open up discussion. The Moderator will now take each solution one by one and add them to the effort/impact scale. Effort, in this case is how much effort we as a team think it will take to implement and impact is the degree to which we think it would solve our problem.

So here’s what the moderator needs to do: Take the top voted solution, hovers it over the center of the E/I scale and simply asks “higher or lower” — usually some small discussions break out here, so the moderator has to be diligent in finding a consensus and stopping any conversations extending past 20 seconds. Once the effort has been determined, the moderator uses the same drill for impact: “Higher or Lower.” Once all prioritised post-its have been added to the scale, you’ll have something that looks like this:

Now you have a clear overview of what which high-impact solutions could be executed on and tested very quickly (In the green sweet-spot on the top left), and which high-impact solutions will take more effort (top right). The moderator should now quickly mark all post-its in the sweet spot with a contrasting dot so we can identify them later.

9. Turn Solutions into Actionable Tasks — 5 MINS

The moderator now takes the “Sweet Spot” solutions off the E/I scale and asks the person who wrote the solution to give actionable steps toward testing the solution. When I say actionable, I really mean something that could be executed on in the timeframe of 1–2 weeks. My rule of thumb is a 1-week experiment, but of course this will depend on what the solution entails.

Let’s look at one example:

Once all these solutions are written up, your team now has actionable tasks that can be committed to (depending on how your team deals with task management, that’s for another day). As for the solutions that didn’t make it in to the “Sweet Spot”? We actually turn all the high impact solutions into actionable post-its and add them to our backlog so they don’t get forgotten. What you might see happening is that the sweet spot actions actually end up solving problems in a way that the higher effort solutions become obsolete and you can later rip them apart!


Structure and Discipline create the Freedom

That’s it! In a short amount of time, your team has been able to define important challenges, produce solutions and prioritise what to execute on almost entirely without discussion!

We use this principle of cutting out open discussion in almost everything we do, from designing new product features to planning events or improving our office space.

As I mentioned before: Creative problem solving is the core of design — so give it the respect it deserves and cut out the wasteful, demoralising, fatigue-inducing discussion.

If you read this far, thank you. ❤️ Please let me know if you used the LDJ exercise!!! Got questions? Of course i’ll try to answer any you post here, but i’ll definitely answer anything you DM/PM to me on Instagram or Twitter @jicecream.


Disclaimer: This is a curated post. The statements, opinions and data contained in this column are solely those of the individual authors and contributors and not that of iamwire or its editor(s). The article in its original form was published by the author here.

Share your experiences, opinions or solutions: Submit a Post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>