Whenever I hear words such as Design Thinking, Innovation, and Agile Transformation, two things come to my mind:
- There it is again; and
- It’s all just words unless one decides to do something with it.
There’s no better way to cut through the noise than putting words into action.
Let me preface this blog by saying what you all are thinking: ‘What do you (meaning I) really know about Design Thinking?’
I am in no way an expert on the subject. However, I have seen enough of what works and what doesn’t against the backdrop of my current job for the past 5 years to share some learnings and our approach.
Setting the scene:
Recently, I was approached by a customer in the insurance industry to define and build (using the Neota Logic no-code platform) two particular workflow automation use cases that fell outside their specific business division.
When approached by customers for consulting work, the Neota Logic team adopts our own design thinking framework to the build. These steps are not ground breaking when viewed on their own, but when combined with Neota’s no-code philosophy and platform, it makes for a great story.
While we follow industry recognized steps to design thinking, we approach this through our own defined framework of process re-engineering with a specific deliverable at the end of every stage.
The generally accepted steps for design thinking are as follows:
- Prototype; and
Our approach is aligned, albeit with a twist:
- Mapping of current state vs Desired State(s);
- Ideation & definition of future state;
- Prototype / MVP; and
Empathy: Mapping of current and desired state(s):
In its most literal form – empathy refers to one’s ability to understand and share the feelings of another.
In the context of design thinking, it’s the ability to gather information on your users:
- First, the identification of your end users; and then
- Second, the understanding of their behaviors, motivations and dear I say it – pain points.
Neota approaches empathy through running a workshop with both end users and other stakeholders on the confirmation of current state and desired state.
This typically involves a 2 – 3 hour design session with:
- Current stakeholders involved in the manual (or current state) of the process we are looking to automate through technology; and
- All intended users and stakeholders that has any touch point on the desired state of automation
Interestingly, our biggest challenge is not a lack of idea or inputs during the design session, but the diary alignment to get everybody in the same room!
True design thinking requires true collaboration.
The Design Council states that “In all creative processes a number of possible ideas are created (‘divergent thinking’) before refining and narrowing down to the best idea (‘convergent thinking’). While it may be hard, it’s imperative to do so.
Final deliverable at this stage:
- A process map / storyboard of the process’ current state; and
- A process map of 2 – 3 desired states – in this case, what that process should look like when automated using the Neota Logic platform.
Ideation & Definition:
Once the deliverable outputs from the first session are transmitted and digested by all involved, we run another 1 or 2 hour ideation sessions utilizing the 2 – 3 desired state storyboards as the centerpiece of the discussion.
To define and to ideate are often interchangeable.
While these steps are touched on during the first workshop, this second stage give everyone a chance to be involved and pitch ideas after digesting both the deliverables and what has been discussed in the first workshop.
It’s a chance to encourage reflection and evaluation on consideration of options such as:
We use the deliverables as the basis of the session to avoid the group starting with a blank piece of paper and to come up with ideas themselves.
Although that blank paper starting point sounds like the ultimate in ‘design thinking’ – it typically leads to failure.
The idea is to generate an outcome based on insights and guidance. Brainstorm all ideas – good or bad and don’t concentrate on the obvious.
The Lean Canvas template is a great tool to use here. The template helps you to quickly deconstruct your ideas into key assumptions for feedback prior to build and implementation. It provides for a quick snapshot validation of your idea by various stakeholders prior to actually investing further time and resources.
Final deliverable at this stage:
- Scope and process map of final MVP / Prototype to be built
Prototype & Test:
Design thinking is a non-linear process.
The first iteration of the end solution should always be subject to testing and change. Results garnered from testing should always be fed back into the definition and ideation journey. For this reason, we believe there is no better technology accompaniment to design thinking than no-code platforms.
However, we need to start somewhere and that’s where the Minimum Viable Product (MVP) approach comes into play.
Everyone has seen this image (or a version of it, I’m sure):
A MVP is a learning vehicle. ‘What is the smallest thing you can build that delivers customer value’
For a MVP to really work, there is no need to scope and build out every single function initially. Start in stages that demonstrate some value to the end client and iterate there based on continual feedback.
The image above illustrates this perfectly.
The concept of value is imperative.
The value in the image above is the ability to move. Therefore, while the end result is the same, how we got there is vastly different if the focus is on functionality and not value.
The MVP must not only provide immediate value to the end user, it must also be easy enough so that users are able AND willing to use it.
Therefore, the MVP must have three clear objectives:
- It must have a value proposition for early adopters. i.e. it solves a problem;
- It is used to validate the defined solution quickly and allows for immediate iterations; and
- It must be used as a feedback tool to guide future development.
I am a strong believer in picking out early adopters to be involved in this process.
If identified correctly, the early adopters will not only provide the correct feedback, but also recommend the technology to others.
I made the below image some years ago which shows how no-code platforms should be utilized through the prototyping and testing phases. Back then, I didn’t even know there was a name attributed to this approach. I’m glad I do now and I’ve learnt a lot along the way.
Remember it’s all just words unless you decide to action it!