How We Attempted a Design Sprint in 5 Hours and Succeeded (mostly)
To give an overview, we were tasked with designing and creating a ‘thank you’ system that would replace the manual process that exists within ResponseTap. This was intended to be an internal application that allowed employees to give recognition to colleagues in the form of an online thank you and also add an element of gamification. This was something that we wanted to try in one of our hackathon days.
I thought it would be a good idea to run a design sprint that would precede the hackathon so we could test the design thinking methodology within this environment (more on that later) and end up with a user centred design solution ready for the guys in development. This included a mixture of individuals from different departments within the business.
Planning the day
The challenge from the business was to have a design ready for the hackathon in 1 day, so I couldn’t opt for the traditional 5 day sprint. Instead I opted for a 5 hour design sprint and I set about planning the day.
The aim was to have a sketched out design ready to be made into a prototype by 15:30
I decided that I was going to model the day similar to the design thinking methodology, which consists of the following stages:
- Empathy
- Define
- Ideate
- Prototype
- Test
I split the day into 2 parts with lunch breaking up the day.
Before Lunch
This is where we would brainstorm and debate on needs, problems and feature ideas for our ‘thank you’ system.
- Understanding — ⏳1 hour
- Defining — ⌛️ 1 hour
After Lunch
The afternoon would consist of everyone involved sketching out their own design ideas, followed by voting on the best “scenes’ and remixing everyones best ideas into one final design flow.
- Ideas Generation — ⏳1 hour
- Remix Ideas— ⌛️ 1 hour
Getting Started — 10:30
We kicked off at 10:30 with a brainstorming session of ideas, current problems and concerns.
This first stage is always about customer needs….so lucky for us, we were the customers so we could get the information straight from ourselves.
We started off by asking ourselves 3 questions:
- Why are we building this?
- What problems do we currently have or envision to have with the existing system?
- What features would we like to see?
The idea is that by 11:30 we would have a mass of ideas and notes on the board with quantity over quality being the mantra at this stage. No idea was a bad idea!
How did this go?
There was definitely some friction to begin with. There were some debates around which pre existing requirements from the business were hard and fast rules vs guidelines waiting to be validated by our needs.
This posed a bit of a problem as this first ‘empathy and understanding phase’ is about finding out users pain points & needs and capturing requirements through those needs.
Based on observations and also survey feedback when asked about what could be done better at this stage, this activity began to appear futile to a number of people. They felt that the requirements were already made so was no need to have these discussions and some people felt they wanted to contribute ideas but felt disappointed that boundaries were already set in place
communicate the restrictions / what we are designing first, because some of us came in with ideas we wanted to contribute or had been thinking of for a while, and it was disappointing to know there were already set boundaries as to what we were doing
This can be quite detrimental to User Centred Design because it was essentially taking the voice and requirements away from the actual users…the employees at ResponseTap.
What can be improved?
I need to make sure that when beginning future sessions, I have a clear definition of any constraints up front. Which of the requirements are an absolute must from the business and which are guidelines that are up for debate.
Additionally, I would try to allocate some time for people to write down their own ideas on post it notes first, to allow everyone to contribute ideas.
Definition Stage — 11:30
We began this stage by taking all suggestions and ideas that were written down on post it notes and began mapping them to a red routes matrix.
The concept behind using this method is to determine the critical tasks that deliver the most value to the users by measuring the volume of people of needing to complete those tasks and the frequency at which they need to do them.
This is how we find the diamonds amongst the rocks and can find out our MVP and more importantly, avoid scope creep.
How did it go?
At first there was a bit of confusion around the criteria as there were notes that were outlining features or solutions such as “slack notifications” rather than focusing on user needs and tasks and scenarios, such as; “I need to be able to be able to send thanks”, “I want to be notified when I have received thanks”.
Overall, this went well as we were able to identify the top users needs that we were all happy with following this process.
What could be improved?
Looking back, there was definitely 1 stage that we missed out, which would have been spent organising the content into categories. This would have helped the red routes stage become more efficient as we would have made sure only task related notes were left for this stage and filtered out the “features/solutions”.
Ideas stage — 13:00
We took a break for lunch and then began the next stage, which was coming up with how we would implement our ideas.
We started off by individually mapping out the user journey including how to ‘give thanks’, ‘receiving thanks’, how we would deal with end of month etc.
The journey was then mapped out on the wall and people individually began to sketch out their own scenarios based on the user journey.
Remix Ideas & conclude session —15:30
Once all the journeys were complete, everyone stuck their designs up onto the wall and we began to vote for the best scenes and components methodically moving through the tasks.
Eventually we had finished with a fully sketched design with all the critical tasks complete
Prototype & Test— 15:30 onwards
Ok, so technically this stage had not been completed within the 5 hours but I decided a prototype in Invision would be the best way of presenting our ideas as it involved some additional interaction that would be harder and more time consuming to be done with paper prototypes.
The wireframes were digitised and I did some quick guerrilla testing with colleagues and continued this loop until most of the issues were ironed out.
Conclusion
Overall, I think the day was a success as I got everything I needed to take away and move onto the next steps: to create the prototype within Invision.
I think there are definitely areas to improve and I think that just boils down to myself in future being explicitly clear what it is I’m trying to get out of each task, so it avoids any confusion.
I could have designed something from the get go but with the design sprint I was hoping to demonstrate that better results are achieved from getting feedback from the users and it should not purely be the ‘designers vision’.
It was great to try this out and my colleagues input was invaluable and I got some amazing ideas from everybody.
Have you tried running a Design Sprint? How did it go?
