In the first part of this two-part series, I (Kennedy Kirui) talked about a UX research exercise iHub conducted in Nigeria, Senegal, and Tanzania to uncover insights for the development of a new data and information service primarily targeting small and medium-sized NGOs. I was part of the project as the senior UX research consultant. The goal of the study was to develop a better understanding of how the target users of the service design and implement programs/interventions, the challenges they face working with data, and the environment they work in. This information would be used to help design the proposed service. The output of the research exercise was a report detailing the findings.
How do you move forward quickly with research findings? For this project, we ran a five-day design sprint which helped us consolidate the findings from the UX research exercise, the social/economic research carried out by Africa Practice. and the knowledge Code for Africa had having worked with data since their inception.
Design sprints are a framework for teams of any size to solve and test design problems in 2-5 days. The idea of sprints originates with the Agile framework which is a framework that has been widely adopted to develop software.The two frameworks were adapted to the idea of “design sprints” thanks to the Google UX teams, Google Ventures and Google [x] and teams across the industry. It combines developing and testing software quickly with putting the users at the center of the process.
How exactly does it work and how do you ensure it is a success? In this post, I will share how we leveraged the design sprint process to develop and test a prototype of the proposed service.
To ensure you have run a successful sprint you need to have three key things in place:
- A good challenge
- The right team
- An uninterrupted schedule and a good location
The sprint challenge
The first step towards ensuring you have a productive sprint is having a good challenge. Design sprints take a lot of energy and focus and as a result, it is important to go after your biggest problems. The challenge should be ambitious enough but still something that can be tackled within the five days. It is also important to solve the surface first. This is where your customers interact with your product.
For the sprint we chose the following challenge:
Design a digital information service to provide players in the human development index in Africa with the key information to aid them develop more data-driven programs
We intentionally left it wide to allow the participants to explore the landscape but still limited it to designing an information service for a specific segment (The Human development index is explained here).
The right team
Since you are tackling one of your biggest problems it is imperative that you have the right mix of people in the room. You need the key decision makers involved alongside with the individuals in the trenches.
Being a consortium project, it was very important that we got the right balance of attendees. The easy way out is to invite a lot of people but this waters down the quality of your output. We chose the key individuals involved in the project from Code for Africa, Africa Practice, and iHub providing us with diverse and relevant experience in the room. The project coordinator was our Decider in the sprint. Being a Gates-funded project, we also had a representative from the Foundation attend the sprint.
In addition, we also had a participant from each of the countries involved in the UX research study (Tanzania, Senegal, Nigeria) fly to Nairobi for the sprint. Last but not least, we invited two participants based in Kenya playing in the agriculture and financial inclusion space. Typically, you would only involve 'external' participants on the first day but we felt it was very valuable having them for the entire sprint and we were lucky they agreed to.
Time and place
An uninterrupted block of time with minimal or no distractions is key to the success of the sprint.Sprints are best ran over consecutive days. A good location is a location that minimizes distractions or urges by your participants to run other errands. Your office, most times, is not the best location for a sprint as there are many distractions.
For our sprint, we chose iHub as the venue and booked a room for the five days. We had enough whiteboards, sticky notes, and pens for all the days.
How do you keep your participants engaged throughout the sprint? First, quality is better than quantity. Kick off the sprint at 10 am (we did 9:30 am) and be done by 5 pm. Have plenty of healthy snacks and breaks during the day. The Sprint book gives a time breakdown as depicted in the image below.
How does a design sprint actually work?
Day 1: Monday - map the problem & identify the focus area
Over the five days, we systematically worked on different aspects of the challenge. Monday and Tuesday are the most challenging days. The first reason is that your participants don't really understand the design sprint process. The second reason is that unpacking a problem is one of the hardest things someone can do. It will take a lot of effort to prevent your participants from jumping straight to the solutions.
On Monday, to unpack the problem, we first set our long-term and short-term goals. The consortium partners led this exercise and talked about what the project intended to achieve in 6 months, 1 year, and 5 years. This helped develop an understanding of both the short-term and long-term aim of the project. During this exercise, we also explored the reasons that might cause the project to fail.
Once this was done, it was time to identify the sprint focus area. This required that the participants understand the problem well. This was donethrough a series of expert talks and presentations from Code for Africa, iHub, and Africa Practice. The expert talks were presentations lasting 10-15 minutes given by the 'external' participants in the sprint. These sessions allowed the project target users to share their experiences and help shape the focus of the sprint.
The brainstorm sessions shunned the traditional approach and instead used the standard design thinking approach:
- Participants silently write down on sticky notes their ideas. Each idea is written in one sticky note
- All the ideas are pinned up on the whiteboard or any other surface
- The participants led by the facilitator quickly group similar ideas which in turn quickly shows recurring patterns
- If there are many ideas and there is the need to narrow down, participants use voting dots to indicate what they feel strongly about
- If there is an impasse, the Decider breaks the impasse by making the decision
This approach allowed us to leverage everyone's ideas in the room despite personality differences. The danger with traditional brainstorming is more often than not the loudest person will have their way.
At the end of the first day, we hadn't identified a focus area. The scope of the problem was wider than we had originally imagined.
Day 2: Tuesday - generate as many solutions as possible
Seeing that we didn't identify the focus area on the first day, we used a section of the morning on Tuesday to finalize on this. It came down to deciding whether to focus on surfacing sector specific data or providing national and sub-national data for as many users. The participants chose to take a stab at providing sector-specific information.
Once this was out of the way, the participants first identified some existing efforts in the space that could be used as the basis for improvement. They then spent the rest of the day sketching. Surprisingly, the team didn't find this daunting at all. In previous sprints, as the facilitator, I have had to provide a lot of guidance during the sketching phase as many participants usually think it is only artistic people who can sketch.
At the end of the day, we had a pile of promising ideas.
Day 3: Wednesday - storyboarding and branding
Personally, I find Wednesday to be one of the most interesting days. By the third day, the team has gotten a sense of how sprints work and understand the different activities. They have also seen how the methodology helps think through problems and are more willing to try out new techniques.
On Wednesday we got first started by choosing the two most promising ideas. These two were going to be explored for the rest of the day. Being a slightly large group (approx 13), we decided to break into two different working groups. This allowed us to take on more than one storyboard.
What are storyboards? Storyboards are visual representations of how the user will interact with a product. The storyboarding exercise was the fundamental basis for our prototyping exercise scheduled for Thursday. The team found this exercise particularly challenging but interesting too. It also helped the non-techies in the room to understand the process of software development. By the end of the day, the two different groups had regrouped and created one storyboard.
In the course of the day, we also had the opportunity to work on the branding. Going into the sprint, we didn't have a name or logo. By leveraging the same brainstorming and decision-making process highlighted earlier, we managed to go through this exercise in an hour. The graphics designer was then allowed to work on several logo and color concepts in the afternoon and he presented the same just before we wrapped up the day. The participants quickly voted for their favorite logo concept and we broke for the day.
Day 4: Thursday - prototyping
By the fourth day, the dev and design team from iHub were itching to get started on the prototype. When prototyping it is important to strike the right balance between quality and speed. Jake Knapp, the author of the sprint book, talks about "Goldilocks quality". If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish. With our storyboards ready and our basic branding in place, the development team started the prototyping exercise. Our graphic designer developed the look and feel while the front-end developer turned it into clickable interfaces using an interactive design and prototyping tool called Framer. The rest of the sprint participants continued fleshing out different aspects of the storyboards. At the same time, we started recruiting participants for Friday's test.
Day 5: Friday - testing
This was the day all the previous activities were building up towards. Friday allowed us to get feedback from users. On Thursday we recruited seven participants to test our prototype. Five is the magical number but always recruit more as one or two participants might not show up. That happened and because we had seven we still hit the right number. The test was designed to cover five screens that had been developed to capture the user journey for a user looking for sector-specific data. It kicked off with a series of leading questions covering the type of work the test participants did and the challenges they faced with data. We then showed the test participant the prototype and asked them to perform specific tasks. This helped the team understand if the design resonated with the users and to see how usable the interface was.
After the test, the team had a debriefing session. We recapped on what we learned, some of the challenges encountered during the week, and reviewed the feedback received from our testers. It had been an intense and productive week and everyone left for the weekend happy with what they had learned and accomplished over the five days.
Post sprint activities
To ensure we kept the momentum going, the consortium partners met the week after the sprint to plan how to move forward with the prototype and the findings from the sprint.
The first thing theproject team agreed on was to flesh out the brand and develop the full brand kit. The second key decision made was to develop a design brief tobe shared with several creative agencies so that they could bid for the development of the full user interface design.
Currently, the full user interface design is being worked on. The prototype, the design brief, and UX research and design sprint report act as guidelines in this process.
That is it. I hope you find this enlightening and will be looking forward to the launch of the platform. I also hope you will take a stab at utilizing the design sprint methodology when you are tackling your next problem.
Interested in learning more about our projects and services and how you can leverage design sprints to solve some of your most pressing problems? Drop us a line at consulting[at]ihub.co.ke