How Design Sprint improved our collaboration and problem-solving culture
Compilation of insights from our experience with Design Sprint that makes the methodology not just about finding the solution to one’s particular problem, but also about nurturing organisation-wide design culture in a fast-growing company like Mapan.
Tl;dr.
After conducting more than 6 full-fledged 3–5 days Design Sprints and countless 2–3 hours mini Design Sprint in the last 6 months with multiple team at Mapan—including Logistics, New Products and Field Sales team, I am confident in saying that practicing Design Sprint regularly is one of the most effective tool to develop company-wide mindset in solving problem collaboratively — regardless the size of your organisation.
…and this post is about how (and why) we did it.
Ever since my last write up on implementing Design Sprint methodology at Mapan. (previously known as Ruma.co.id), we have conducted numerous Design Sprint sessions at Mapan; each session tried to answer a different set of problems. The questions toward the problems can be as simple as how might we create a proper quiet working space that cultivates productivity for our team, or as complex as how might we scale our acquisition model to allow Arisan Mapan to reach more Ketua Arisan — thus helping more people to afford household goods by saving together with their trusted peers.
We learned that Design Sprint plays an essential role in scaling the impact of the UX and design team by making sure that the design — in general term, as per the definition above — is not solely being the responsibility of Creative, UX or Visual designer alone, not even the Product Owner or Product Manager.
At Mapan, we believe in ‘ownership’. Every individual shall contribute in the process of finding the solution that helps our members, directly or indirectly, to be more financially well-off.
Among others, Design Sprint is one essential tool to realise such idea.
First of All, Why Design Sprint?
Traditional brainstorming is one of the most common problem solving practice in the modern business world. We brainstorm because we know that expertise is distributed among our employees, especially with the specialisation of labor and organisations — not to mention that brainstorming is believed to enhance buy-in and subsequent implementation of the ideas generated, regardless of the quality of those ideas. However, as much as we are comfortable to use it for finding consensus, I guess we can all agree that most of the time, traditional brainstorming is ineffective to solve complex problems. This is where Design Sprint comes into place.
Formally, The Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
Design Sprint is one approach in executing Design Thinking methodology. If Design Thinking is a cooking class, then Design Sprint is a recipe that allows every person who wants to cook to execute and deliver results systematically—you might want to check this blog for further explanation.
As shared by Jake Knapp, the writer of Sprint book and the man behind the Google Venture’s Design Sprint process, each process of the Design Sprint is designed to allow every team member to share and process their ideas effectively while anticipating typical brainstorming issues:
1. Brainstorm problem: Shallow ideas from the group
In a group brainstorm, ideas are shouted out loud, rapid fire. The goal is quantity, with the assumption that there will be diamonds among the coal. But details matter, and good ideas require time for deep thought.
Sprint solution: Detailed ideas from individuals
In a sprint, each individual considers several approaches, then spends an hour or more sketching their solution. In the end, there are fewer solutions than in a group brainstorm, but each one is opinionated, unique, and highly detailed.
2. Brainstorm problem: Personality outshines content
If somebody has a reputation for being smart or creative, their ideas are frequently overvalued. And a group brainstorm can be a nightmare for an introvert. Charismatic extroverts who give great sales pitches often dominate.
Sprint solution: Ideas stand on their own
The sketches in a sprint don’t have the creator’s name on them. And when we critique them on Wednesday, the creator remains silent and anonymous, saving any sales pitch until after everyone else has given their opinions.
3. Brainstorm problem: Groupthink
The collaborative, encouraging environment of a brainstorm feels good, but often leads teams to talk themselves into watered-down solutions.
Sprint solution: Opinionated decisions
In a sprint, decisions are made by one person: the Decider. The Decider is a CEO, executive, product manager, or other leader. For example, in a sprint with Medium, the Decider was founder Ev Williams; in a sprint with a cancer data company called Flatiron Health, the Decider was Chief Medical Officer Amy Abernethy. With the Decider in the room making all the calls, the winning solutions stay opinionated.
4. Brainstorm problem: No results
Worst of all, brainstorms result in a pile of sticky notes — and nothing else. It’s a loose methodology to begin with, and there is no map to get you from abstract idea to concrete implementation.
Sprint solution: A prototype and data, every time
The sprint process requires your team to build a prototype and test it. By the time you’re done, you have clarity about what to do next.
How Design Sprint is being conducted at Mapan
At Mapan, we have exercised our first Design Sprint back in October 2016. Despite all the flaws and missteps in following the process, we were quite satisfied with the fact we got validated solution out of our first session. But we eventually decided not to set another session as we thought the process was not compatible with our working culture — or so we thought. Long story short, many of us at Mapan were skeptical with the idea of spending long hours in one location thinking about one particular problem only while at the same time spending the precious time of our engineers.
However, I considered myself lucky when we got a chance to meet with Jake Knapp himself during the 2 weeks course of Google Launchpad Accelerator. The sharing session with the man — alongside the following Q&A and the mentoring sessions with other Google mentors on UX (including Borrys Hasian, the UX Design Lead of Grab; Dr. Eunice Sari, Founder of UXindo.com; and Michael Dorka, UX Evangelist of Despegar.com) — gave us deeper context why Design Thinking matters and how Design Sprint framework can work as the easy-to-apply recipe.
Essentially, with the commitment from the whole team members to find the solution of the problems at hand, Design Sprint allows us to craft a more sustainable way out collaboratively to provide optimal solution for the long run — despite the 2–5 days ‘disruption’ in the process.
Like how other organisations did it in many countries, e.g. CanvasFlip, InvisionApp and FTB90.com, we adjusted the Design Sprint to each team’s problem statement. Some took full-fledged 5 days process, some took only a couple of hours.
For example, when I worked with the Last Mile logistic team (the logistic team that responsible for delivering the goods from the stock point to the delivery point, typically the residence of our Ketua Arisan), the key question was about how might we provide smooth and effortless platform, system and/or process for our team in the stock point to help them deliver qualified item on time to Ketua Arisan. Such question allowed us to take a step back and go back to the drawing board in order to properly review how the journey of the logistic team on daily basis should be designed. Since we wanted to find long term solution, not just a typical fire-fighting short-term hack, the process took full 5 working days—First 3 days to get detailed visual storyboard and another 2 working days to validate in 2 different stock points.
My experience working with the Employee Experience team was on another extreme. Since the objective is to get the answer on how might we design the solution for quiet working space at Head Office that allow our employees to work more effectively and efficiently with a very minimum distraction from other people around them, we only need to spend 2 hours to acquire the insights on what the team really need.
At the end of the day, whether it is a couple of hours or a full week session, what really matters is the mindset shift to find a more sustainable solution as the framework allows every participant to contribute effectively while reducing the issues of typical brainstorming and at the same time allow us to make sure every idea is properly understood and validated to the users.
The triple diamond visualisation above captures how we do things on each and every steps of the way — there is one ‘diverge’ and ‘converge’ in every diamond as a metaphor that we always try to keep our mind open and check on team understanding (not jumping to conclusion) before we eventually prioritise and conclude the next steps.
Phase 1: UNDERSTAND—To ensure everybody is on the same page
In the understanding phase, it is essential that we put ourselves in listening and exploring mode to acquire common ground as a group. Two common pitfalls that hindered many decision makers in being an effective problem solver: (1) jump to conclusion and (2) assume all team members have the same knowledge of the problem.
I lost count how many times we got typical ‘suggestion’ or `possible solution` in the phase of understanding. For example, in one of the Design Sprint session where we want to introduce one of Mapan new product to the users where there might be multiple touchpoints for product introduction, one of the participants asked: “how might we create a clear call-to-action for the website?”.
“We shall not speak of any solution (yet), only listen.”
While we would like to think that the intention to give solution yields no harm, but such behaviour might prohibit us in reaching the solution as we focus on the effect, not the cause.
In one of the earlier Design Sprint session we conducted, which objective is to improve the first-time user journey of Mapan app, we did not bother to follow the methodology because we assumed everybody precisely knew the problem. We even permissively allow some participants not to attend some of the processes as we thought we could just update them later, which of course did not work and resulting in massive misunderstanding on what the problem really was. The consequence? We needed to re-visit the understanding phase as we found that the solutions being presented during the following steps showed multiple interpretations of the problem being put on the table.
It was a waste of time.
Technicalities 1: Preparing the Sprint Brief and set the role
From the methodology, coupled by numerous Design Sprints we conducted earlier, we learned that Understand process is half of the Design Sprint process; meaning that if this phase is executed properly, the rest of the process can be relatively easier as it ensures every single participant to see the same set of problems — despite they see it from different angles.
The Sprint brief typically consist of compilation of (1) Current state of the project or product, (2) Sprint challenge or Problem Statement, (3) Pain points or set of detailed issues that currently exist as stated in the previous statement, and (4) Deliverables or the expected outcome of the Design Sprint process. This sequence shall allow every team member to get where we are, what the problem really is, what we want to achieve from the process and what is the end in mind that we want to create at the end of the day—you may download the template here.
Role of the participants also play a huge impact here. Every Design Sprint needs to have a Facilitator and the decision maker of the problems can be the CEO, COO, or Head of the function—which one of them will be decided to be the Decider.
Technicalities 2: Setup the Schedule
Setting the right expectation using proper scheduling on each task in the Design Sprint session is important to make sure the participants can have a sufficient amount of time to do think and come up with the solution properly.
The effective schedule was more or less as seen in the example below — as shared in the team’s Slack channel.
Technicalities 3: The Lightning Talks and User Persona sharing
Lightning Talks is a session where the Product Owner, or whoever considered being the expert of the problem, shares the narrative of the problems—from why we want to solve this, what are the pain points and why the pain exists in the first place. This is a crucial part of the process where the Facilitator and the Deciders needed to make sure that ALL participants are on the same page regarding the pain points that exist, including the User Persona of the users whose problems we want to solve.
The intention of sharing the persona is to ensure the participants can really understand the users, beyond their title and job description. The expectation is that the participants can empathise the users down to the level of how they think and feel as a person that we can relate to.
More relevant read on the persona and why it matters in Design Thinking framework can be seen here:
And more on the empathy mapping tool to understand user behaviour as a pre-requisite in finding solution to our users’ problem can be found here:
One more tip to make the Lightning Talk much more effective is through visualisation. A great example was shown by our Sales team who prepared the video of how our Field Sales Staffs operates on daily basis. The documentation acted as a tool to allow the team members who do not interact with the users on daily basis, e.g. engineers, can understand the users more easily through visual depiction of their daily life in regards to the issue we want to solve.
Technicalities 4: The How Might We, Affinity mapping and Voting
As part of the Understanding phase, this was to allow each and every team members to help thinking about the right question that would bring us closer to answering of our sprint challenge. The participants put all of their concerns in the post it before it was being put on the whiteboard and being clustered to the similar categories of problems.
The Design Sprint participants are expected to write down all of the questions in the format of “How Might We…” or “Gimana caranya kita…” to entice deeper questions on understanding the problems that we want to solve.
Once the HMWs are put out on the wall, then the team shall vote for which questions or sections that they think are the most burning questions that can help answering the Sprint Challenge.
The output of this exercise is to get a deeper collective understanding on the problems that the participants are facing. This exercise allows them to acquire more holistic view on how the participants interpret the Lightning Talks, its Persona sharing, and the pre-defined problem statement.
Technicalities 5: User Journey Mapping + Success Metrics and Goals Definition
User Journey Map, or Customer Journey Map, is visual or graphic interpretation of the overall story from an user’s perspective of their relationship with an organisation, service, product or brand, over time and across channels. This processes that allowed each and every team members to understand the user journey of the persona whose problem we want to solve.
Some team, like the Last Mile team, want to create a new user journey, some want to focus on how to improve the efficiency of current user journey, like the one we had with the Field Sales team.
In the example of our Last Mile team, we wanted to recreate the journey — thus we allowed the team to draft the ideal user journey for the users, individually. We eventually acquired 15 different user journeys from 15 participants, the patterns we saw eventually became the ‘collective minds’ user journey. This process hindered the team from having non-productive traditional brainstorm where the conversation was typically dominated by the better presenter/public speaker.
At the end of the session, we defined the success metrics and/or goals of the solution, i.e. the criteria on what success looks like.
Phase 2: SKETCH—To allow every team member to contribute their idea effectively and efficiently
“Explore all possibilities as a team, individually.”
Technicalities 1: Crazy 8 Development, Pitching and Voting
Crazy 8 (or sometimes if the participant numbers is quite numerous, Crazy 4) is the exercise to generate ideas quickly as a team, individually.
The highlight of this exercise is to generate ideas as many as possible in a relatively short time to answer the questions being compiled over the HMW exercise. We typically prohibited the participants from using pen or pencil, but marker instead, in order to force the brain to communicate the big idea to solve the problem, not the nitty-gritty detail of wording or button placement.
As soon as the ideas being sketched, we asked the team to pitch their idea in less than 3 mins before we allow the participants to vote the ideas that they like. Each participants can cast 3–5 votes, except the Deciders who can cast 5–7 votes.
Technicalities 2: Solution Sketch development
Now that the participants already have the big ideas from the Crazy 8, at this stage the participants should be able to start developing the Solution Sketch—a visualisation of the solution in the sequence of user journey.
This exercise allows each team member to spend more time articulating the one idea they are most interested in exploring. While the team voted on all the ideas in the previous step, it is still up to the individual to choose which idea to focus on. It’s ok to sketch a new idea or a combination of ideas, and your sketch can even include other people’s ideas.
The goal is to create one fully articulated idea per person for the solution that is thought to be the best. Each team member creates their own detailed Solution Sketch.
Phase 3: DECIDE — where we collectively choose the solution(s) to be tested
Technicalities 1: Solution Sketch Presentation and Voting
After the participants had already done with their sketch of the solutions, they have another 3 mins per person on how their sketch might help the team getting the answer towards the pre-defined sprint challenge questions. After the presentations, every participant will do another silent vote and review to give collective feedbacks on which solutions are considered to be worth exploring.
Technicalities 2: Defining Assumptions for the Solution
Before the team proceeds, as a group, each and every team members shall share their underlying assumptions on the solution they previously sketched—the assumptions are the list of prerequisite conditions that need to be fulfilled in order for their solution to work. This is an essential exercise to make sure that we anticipate such assumption during the validation process.
Phase 4: PROTOTYPE — where we collectively build a (working) model to be validated.
Technicalities: Storyboarding & Low-fidelity mock-up
As part of the first stage of Prototyping process, we shall integrate all the Solution Sketch into one viable solution which results are to be tested to the users.
Storyboarding is a tedious process that can be quite exhausting to many participants (and of course, the Facilitator :p) as they need to converge all the ideas being sketched and voted as alternative solutions into a compelling storyboard that should help the UI/visual designer to build a working prototype. This is one reference that helped us (a lot) in the Storyboarding process—and also the User Journey mapping:
Final storyboard sketching process and Low Fidelity sketch development (a tribute to Rully the artist!):
Technicalities: High-fidelity mock ups
As soon as the storyboard is clear, the UI designer can start working on the high fidelity solution that resembles its real functionality that can be felt and touched by the users.
Phase 5: VALIDATE — where the team members check the answer whether the idea is worth pursuing
The objective of the process is simply to validate the usability of the ideas we developed in the initial phases, whether it answers the needs of the users as shared in the Understanding phase. The step-by-step of the Usability testing process can be seen in the link below:
Be it formal Usability test at the office, or informal Usability test at public place e.g. Blok M Plaza or Blok M Square, we put the 10 Best Practices mentioned above as mandatory steps to acquire sharp validation result and also to promote user-centric culture at Mapan.
Key Learnings
- Design Sprint, if executed properly, opens the possibility for every team leader to extract tons of ideas to solve the problem(s) in a relatively short time—even from the quietest and buttoned-up team member.
At Mapan, we believe everybody wants to contribute, but not everybody has the same attitude, aptitude, and energy to share their thoughts effectively. Mostly will stay quiet and rely on their supervisor to share their ideas—which is prone to distortion and disengagement. Some researches on work culture also showed that organisations with low employee engagement scores, they experienced 18% lower productivity, 16% lower profitability, 37% lower job growth, and 65% lower share price over time. This also became the reason why we even positioned the Design Sprint process for the Last Mile Logistic team as a team building exercise to increase the engagement of the engineers. - The process was tailored to increase alignment between the business team and the tech team—thus more effective collaboration.
In the product development process, it is not uncommon to have information failure (or asymmetry) when some, or all, of the participants in an information exchange do not have perfect knowledge, or one participant in an information exchange knows more than the other.
In both of the Field Sales team and Last Mile logistics team cases, before the Design Sprint process, we found out that the process of designing solutions can take longer than expected because everyone tried to solve the issues based on what they know as we worked in silos—it took more than 2 weeks to develop solution for Last Mile team, only to scrap it right after we found out we did solve the pain point of our users at the stock point. Now we can get validated solution within 5 working days by allowing all stakeholders to be involved in sharing their idea with much less friction. - The structure of Design Sprint helps the UX team to scale Design Thinking to the whole organisation.
Currently we are serving almost a million members and more than 80,000 Ketua Arisan with more than 1,000 employees in more than 90 branches all over Java and Bali—and the only way for the UX team to contribute effectively is to scale the Design Thinking mindset to the whole organisation. Design Sprint enables each participant to follow Design Thinking process intensively in finding the validated ideas within 3–5 working days, with or without UX team members.
Thanks for reading! This (long) post is part of the UX Dojo we shared regularly at Mapan as part of our internal learning session.
Found anything interesting? Kindly share your thoughts in the comment section and let’s learn together!
We are (always) hiring! Check out https://www.mapan.id/career/ for more info.
