Design Sprints to improve organizational processes
A Design Sprint is a week-long process or framework that helps answer critical business questions through design thinking, prototyping, and testing with real (targeted) users. It consists of various exercises and intense teamwork to reach a tangible outcome faster. To know more about it, visit GV’s Design Sprint page or buy The Sprint Book (it’s a great value).
The NDA
Yes! We have to sign an NDA all the time, and we’re not allowed to share anything. Still, I got a chance to write this story with the client’s permission. I won’t mention anybody’s name anywhere in this story. I won’t share everything in detail, but this will give you glimpses on how a Design Sprint can work for organizational processes. I will be sharing what we and sprint members did feel, what went wrong, what worked, tips, learning, etc.
Doing it to improve organizational processes
At the early stage of SprintCube, I had experience of doing a few Design Sprints for digital products. And then, we got an inquiry from an agency to help them with development processes. It was a digital agency, designing and building eCommerce projects.
The challenge
The challenge was to streamline the development processes. Almost no project was getting delivered within the decided timeline. As a result, projects were struggling, and they were not able to achieve the desired ROI. It’s a high-level view of the challenge.
Then, we (I and Narendra) dived into the whole process from “inquiry to delivery.” We saw some gaps in it and felt those needs to be filled. Overall, we saw it as a good challenge to run a Design Sprint.
But the problem for us was, we never did a Design Sprint for the organizational processes. I had experience of doing sprints for digital products only. So they were not 100% ready (genuine and obvious) to lock an entire week of their key people to improve their process.
Fortunately, the CEO of the company had heard about the Design Sprint, so that was a plus for us. But, there was a myth that Design Sprints can be used for digital products only. At this point, showing some Sprint Stories helped me to convince him. He also got excited to see it in action. Wow! The stage was set.
Don’t tell, show it. It always works better.
Preparing for the Sprint
First, you need a big challenge to start with a Design Sprint. It should be big enough that locking the time of 4–7 key people for the entire week seems worth solving the challenge. And, we had that big challenge.
Building the Sprint team
The entire process involved members from various departments like sales, analysis, development, testing, and delivery. We needed key people from each department to run the Sprint. They knew how everything works within their departments. They also knew how other departments work in their process. So we picked leaders of sales, analysis, development, testing, and the project manager. From our side, Narendra was there with them. We built a Sprint team of 6 people. I was going to facilitate the Sprint. The CEO was the Decider. He was so enthusiastic and excited to see and experience a Design Sprint in action. So he was available all the time to make the decisions. That was a BIG PLUS point for us.
Finding the perfect time to execute the Sprint
We were going to run a 4-day Design Sprint. We were yet to figure out how to test the process prototype (like an app prototype), so we didn’t consider the user tests’ day (Day 4). So we had to lock the full 3 days to reach a process prototype. We decided to execute the Design Sprint when there is a less tight schedule for sprint team members. So we decided to start it on Wednesday rather than Monday.
Backup
We also prepared the second best senior members from each department to handle the department level work during the Sprint. The respective department leaders handed over necessary information to their second best members so that they can take necessary follow-ups and actions without having their leaders. This really helped us because Sprint members were able to focus on the Design Sprint without worrying about their routine. Also, we were taking regular breaks so that they can meet their teams and take follow-ups.
Setting up the expectation
It’s important to set the expectations before starting the Sprint. I collected expectations from each member of the Sprint team. I gave them glimpses of what we’re going to do on each day, explained purposes of each exercise of the Design Sprint quickly, and what would be the outcome. This helped me move faster with the Sprint.
One of the expectations was that they would get a perfect solution to each problem that they were facing within their process. Please note, the Design Sprint is not about getting perfect solutions. It’s about getting solutions that can work for you, and test them faster; so that you can iterate and improve fast.
We think that a perfect solution doesn’t exist in the world. A solution can only iterate and improve.
Day 1
Agenda: The entire team works together alone to define the challenge, and build plenty of solutions that they think can solve the challenge.
We already did go through the challenges within all departments before starting the Sprint. The CEO as the expert presented all the challenges to the Sprint team. The project manager was present with the CEO as a co-expert. Team members reframed the entire challenge in the form of HMWs, and we categorized them. After looking at the hanging and categorized HMWs on the wall, they started getting the inkling about where the most challenges are.
Tip: HMWs is the stage where you can see if someone from the team has bad handwriting. If you find this is a problem, you can ask them to write everything in CAPS throughout the Sprint. It’s even better not to wait until this stage. Give them a marker and sticky note to write down their expectations from the Design Sprint. This will give you ideas about what everyone expects and thinks, and it will help you throughout the week while facilitating. Also, you get to know if someone has bad handwriting within the team or not.
And then, we did prioritize the HMWs. We did go through the long-term goal and sprint questions.
Then, we created a user journey map. We started mapping the HMWs with the map. The purpose of this exercise is to decide a target to focus for the rest of the Sprint. Here, we had a tie to decide the target. We got two different parts of the map with an equal number of HMWs.
Hmm… The question was what part to target and move forward with. A discussion popped out for 3–5 minutes. Finally, we decided to go with the target on the left side.
Remember: When you want to decide a target, and you have a tie between map areas, it’s always better to choose the one on the left side. Because that’s the one users will pass by first, and then the one on the right side. It’s better to solve problems which occur at the early stage of the journey, and that will support you at the later stage.
We had a lot of high-fives 🖐, it’s important to keep everyone energized. We had a lunch break. I took everyone’s feedback about their experience so far; so that I can get ideas on how should I facilitate for the rest of the days.
Next, we started with the Lightning Demos. Everyone loved this exercise as they got access to the internet to look for ideas which can solve the challenge, and they presented ideas to the team.
Then, we started with the 4-part sketching. Everyone wrote down important notes from the first half. Then, they did go through the Sketching Ideas and Crazy 8s. One of the team members was like; he’s not creative. Participating in a Sprint till here made him feel like he can be creative.
And then, we took a short break so that they can get fresh air, tea/coffee, check emails, etc. And we were back then to start with the 3-step concept exercise. Everyone took 45 minutes to draw their own solutions that they think can solve the challenge. As a result, we did get 6 different solutions in total (one solution per member).
That’s the end of Day 1. We loved seeing the entire team happy as they all worked together but alone for a common goal. They got 6 different solutions to the problem with (almost) zero verbal discussion.
Day 2
Agenda: The entire team selects a solution or solutions to test that they want to go forward with. And, they create a storyboard of what they’re going to test.
All the solutions from Day 1 were on the wall. Team members started studying solutions and voting them. Basically, we had to generate a heat map from the voting.
Each team member voted and presented on his/her choice of solution that s/he thinks would be better to prototype and test. It’s a supportive exercise to help decider make the final decision.
And then, the decider was asked to make his final decision on a solution(s) which he wants to prototype and test. He chose an entire solution, and a small part from another solution.
Then, the entire team went through the user flow exercise. At this stage, we took a lunch break.
Post lunch break, the entire team started creating a Storyboard. It is a detailed user journey of the solution(s) which will be converted into a prototype on the Day 3. Basically, a storyboard is divided into 8 cells (stages). Here’s what does it look like.
That’s the end of Day 2. The entire team was so impressed with the Design Sprint. As a result of two days’ intensive teamwork, they got an overview of the solution that can work for their challenge.
Day 3
Agenda: Create a prototype from the storyboard to test with the targeted users.
Tool for the prototyping
As we were doing the Sprint for the process, we decided to create a presentation of the process. We decided to go with Keynote. You can also go with Microsoft PowerPoint or Google Slides. Or you can also create a doc using Pages, Microsoft Word, or Google Docs.
Creating a prototype
We had to draft (prototype) the entire process from the storyboard into a presentation. We looked into the storyboard and assigned each cell to the relevant department leader to draft in the Keynote. For example, two cells required major actions from the sales team, so we assigned those to the sales leader. The entire team did regular check-ins to know the status of the prototyping.
In the end, we all met together, collected slides from each team member, and stitched them together into a single presentation. We did go through it multiple times for the proofreading purpose and made corrections wherever needed. Finally, we had our process prototype.
On the other side, I and the decider were figuring out how to test the prototype because it’s a long process of a project from inquiry to delivery.
A blunder 🌪
How to test a process prototype which can take weeks or months? — That was a big challenge. The process would pass through each department, and we needed to get feedback from target users (key/senior members of each department). So we decided to explain the process prototype to them and planned to start following it in real from the next week. And we decided to collect feedback on a weekly basis. We didn’t get any major feedback from each department in the first week. We waited for the second week, the third week.
It was disappointing because we were not getting feedback faster enough. It took us 3 weeks to get feedback. A day (Day 4) of user tests converted into 3 weeks. And then, we did an Iteration Sprint to iterate the process prototype. It took almost 6 weeks to get confidence that the new process will work now.
The mistake and learning
Deciding to implement the process prototype was a big mistake. We kind of lost the momentum. We have to remember that a Design Sprint is not about implementing and getting real feedback, it’s about finding a solution and getting feedback to iterate it.
Once we got done with the process prototype in the Iteration Sprint, we only presented the prototype to 5 key people and got feedback. It worked for us in a better way than a real implementation.
Another Sprint for the process improvement
A month later, we did get another chance to work on a very similar process. Again, we needed to improve an existing process at the organization level. This time, we had experience of the earlier Design Sprint. For the user tests, we decided only to present the process prototype to the target users to serve the purpose of getting feedback. It worked better for us in the earlier Iteration Sprint for the process. This time too, it worked for us. We received feedback in a day, and then, we did an Iteration Sprint the next week. And, that agency was ready to implement the process with confidence just in 2 weeks. Yay! 🤩
The result
Design Sprints worked for us in both the above cases.
In the first case, it took a longer time to get confidence, so I would say it worked partially, but it worked well to improve the process in 6 weeks. That was still shorter than their default ways of getting to a better process.
In the second case, it worked really well as we expected.
Both agencies have implemented the revised process in their routine.
When we did take last follow up with them, they said that they attend the small/moderate level challenges in their process using the Design Sprint only. Now they know how a Design Sprint works, they don’t run a full Sprint, but they do some of the exercises from it and iterate their organizational process.
👉 Want to know more from us about Product Design, Development, and Startup stuff? Follow us on Instagram @sprintcube.
👉 Get the Design Sprint Quick Start Guide for FREE to start running Sprints on own.
👉 Get our Design Sprint Master Slide Deck to run and facilitate Sprints like a PRO at $30 off.
Happy Sprinting!
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by + 370,771 people.
Subscribe to receive our top stories here.
