The Design Thinking team at Assurity recently held a Twilight Session sharing valuable first-hand insights and lessons learned through applying design processes in business, providing links between Design Thinking and Agile, along with a hands-on activity to take home practical steps to make a meaningful impact on the business. Here, we recap the session for those who couldn't make it. You can see the full session here.
Before getting to the crux of the session, let’s explore what Design Thinking is
Design thinking is a repeatable problem-solving process that focuses on discovering desirable solutions for our customers.
It is action-oriented and can be applied to any manner of business problems, from designing organisational strategy through to tactical solutions.
It will allow you to routinely innovate and continue to unlock opportunities once all of your greatest ideas have been exhausted.
Design Thinking always begins with empathy, seeing your problems from the point of view of the intended user. The user or customer is not bound by the same constraints as you, often bringing clarity and a fresh perspective to problems, inspiring new directions and pathways.
The real needs and challenges of your user are then defined, before many options, and potential solutions are created within ideation. This is done purposefully to prevent teams from falling into familiar traps of solving problems the same way every time.
Finally, our best-bet concepts are prototyped or built in some way so that the user might interact with them. In effect, we are building to think and learn, moving far beyond perceptual debate and opinion towards hard results and customer feedback to direct our efforts.
Lessons learned #1: Minimum Viable Empathy
How much empathy research is enough? It depends on the scale of the challenge.
Be mindful of just getting enough data to move forward in the design thinking process. Don’t get bogged down trying to be too exhaustive. You don’t want empathy to become the new bureaucracy.
It's what you choose to do with the data that is more important than collecting it. We usually find within eight interviews we start getting ‘redundancy’, meaning we can pre-empt the answer before hearing it. At this moment – move on and forwards.
Lessons learned #2: Minimum Viable Product (MVP) vs. Minimum Desirable Product (MDP)
One of Assurity’s secrets is unlocking the Minimum Desirable Product and seeing this play out into development cycles.
Avoid MVP capitulation, where user insight is rejected for what is a minimally viable technology solution. What is minimally viable might be very different from what is actually desired by your customer.
Minimum desirability will ‘get you in the game’. Minimum viability might well result in a product that has no relevance for your customer.
Prototyping presents an opportunity to circumvent any fragility of a smaller sample size of users. The concepts developed in design thinking cycles will provide further access to customers for feedback and allow you to pivot. Also, you will have already built something and will be on your journey to solving a problem.
You need to be bold and hold true to the vision unlocked with design thinking. You will be rewarded in the long run.
Lessons learned #3: Design Thinking and Agile
How might we fuse Design Thinking and Agile methodologies into one cohesive framework for both problem solving and fluid delivery?
- Debrief design sprints into a backlog. Capture the most compelling user story once you have prototyped and tested concepts. This will help carry the intent and lessons learned from the design cycle output into Agile delivery
- Spend time to understand and transfer vision from DT to Agile teams. The full extent of what your designers are imagining may not easily transfer to another team, even if both processes share the same team members. Take time to build alignment and explore the full vision for your concept. It will ultimately save you time and energy
- As Scrum teams start delivering increments, they will inevitably discover new questions and opportunities to explore. Aggregate these questions and use them to reprioritise the backlog. When knowledge starts to impede Scrum delivery, it might be time to run another design thinking cycle to gain clarity and direction
- If you can remember one thing… Use DT to learn and Agile to deliver
Lessons learned #4: Fake it
The greatest rewards from design thinking are unlocked by faking it till you make it! What does this mean? Your customer is not a visionary who is going to instantly remedy the problems that you (in a full-time working capacity) struggle to solve. You need to help your customer to be able to help you. Do this by emulating the final experience you plan to deliver. Fake it. Everything can be prototyped to a point where a customer will readily suspend reality and provide you objective feedback on a concept as if it were alive and real in the market. Pop-up stores, fake packaging, a new type of service – with imagination and creativity, any of these things can be built in moments and provide you with enough direction to last years.
Lessons learned #5: Understand failure
And now to the focus of this article – failure. Get ready for it and embrace it. Failing is a wonderful tool to have at your disposal. Failure is necessary and is happening all of the time.
Consider ‘how aware are you of your failures?’
Do you fully understand where you are failing currently and the full extent to which you are failing?
Perhaps you are failing your customer in ways that you can’t imagine. The truth is these failures are probably your greatest opportunity to gain an unfair market advantage and genuinely differentiate your products and services.
How might we engineer failure?
Failure is an inevitable part of innovation. It’s a given.
The question becomes ‘how might we harness failure to our benefit?’.
How might we purposely engineer for failure, to learn ‘what to do’ through discovering ‘what not to do’?
What problem keeps you awake at night? (p9)
Discover how you might solve a problem through failing. Consider a current problem that keeps you awake at night.
01. Classify the type of problem you have (p10)
To get you started, we've grouped the types of problems we commonly see in organisations into eight categories. Problems range from knowing when to embrace change vs. staying on your course, through to having the right governance in place to ensure business success.
Take a few moments to review the common types of problems and select one that is relevant to you.
02. Define your problem (p11)
Now take a few minutes to define your problem. Write down your most pressing problem.
03. Classify your failure (p13)
We find that most people think that failure is bad… which is only natural. However, not all failures are created equal.
If you asked any elite sportsperson or athlete, they’ll tell you it’s essential to growth. The same can be said for companies.
Failure can range from preventable career-ending failures to an intelligent predictable failure to learn new knowledge that can give an organisation a competitive edge over their competition.
Now classify your failure. Tick the box in the pdf that best matches your failure. Think about what’s the worst that can happen.
04. Describe what might happen (p14)
We’ve given you an example as a starter.
If our problem is customer churn, what is the worst that can happen?
Fail fast and learn | Fail slow and burn
Slow failure is insidious. By the time it’s recognised and acknowledged, it’s often too late to act. You need to reframe your failure to the point where it becomes predictable.
Attributes of predicted failure are:
- You are empowered to fail and learn
- You are testing a binary variable; for 'x' to be true 'y' must happen
- It is a low fidelity and low-stress outcome
- It can be time-boxed and treated as an experiment
05. Design your experiment (p19)
Now that we have identified our problem and framed our failure, let's think what the core thing about our problem is. What is the riskiest assumption?
Let's say our problem is churn rate of our product.
The core of this would be our product. Is our product the most sought-after in the market?
How could we run an experiment to learn our customers and the market to test our assumption with minimal resources?
During this experiment, our focus is on the value of learning rather than building.
So, for our example, we could run an experiment to test with our customers what they think of our product and other alternatives they use.
06. Who are your actors? (p20)
Now that we've designed the experiment, think who will be in the office tomorrow to help you.
Who are the influences and supporters to this experiment?
For our example, it could be the product owner who could schedule interviews with customers.
07. Where can you run your experiments? (p21)
Consider the resources that you require in order to deliver the experiment. Think about the location where you would set up the team. Is there a meeting room or project area that you could use? Also, do you need stationery and other equipment?
At the same time, consider timings for the experiment. When would you run this? Keep in mind busier times of the year and other projects that are planned which may include the actors that you want in this experiment. Think about team leave and holidays, like the long weekend coming up.
08. Share your problem (p22)
A problem shared is a problem halved. Find somebody and share your experiment.
Use those listening skills to get feedback and suggestions on how you approached the experiment. Also listen out for tips on how your colleague approached a similar situation differently.
Gain valuable feedback and form an action pact. Commit to action and test your experiment. Share your results with us on Facebook.