How to work out and test solutions to a business problem: is it doable in just 5 days?
A while ago we had to redesign a website for one of our clients. It just didn’t support the company’s strategy or their business goals anymore. And since we were on a tight schedule, we had to figure out how to get the job done in the most efficient way possible. So this is exactly what we did!
But first things first: what factors did we have to take under consideration?
- We knew we would need to cooperate with all the decision makers on the customer’s side in order to figure out the goal of the new website, together.
- Examining user needs and opinions was also a crucial element, as well as being able to test our ideas beforehand, so that we could make sure that we were moving in the right direction — one that would reach a wide spectrum of our client’s customers. Because how can you possibly achieve any business goals without finding a way into your potential customers’ hearts and minds?
So… we decided to try a design sprint, since the structure of this process fitted perfectly with our needs and all the challenges that we were about to face. There was only one catch with this methodology: we had to cover everything… in just 5 days. No wonder we had so many doubts and questions:
- Would it actually be possible to work out and validate our vision in such a short amount of time? More often than not, the analytical process alone can take weeks, not to mention the design phase of the project…
- The range of functionalities for any problem can be pretty broad, along with the business vision, so how could we go through all the details and come up with a reasonable solution in just 5 working days?
Well – having been charmed by this book and the vision of the creators behind this methodology from Google Venture – we weighed the pros and cons and decided to go with a design sprint anyway. After all, we had already had a great deal of previous successful workshop and project experiences, so a design sprint was just challenging but not risky.
Design sprint: what it really is
Design sprints are similar to regular sprints in the Agile methodology. These are time-boxed processes that place an emphasis on the efficiency of work. Moreover:
- Each sprint has to be broken down into 5 smaller chunks, each of which takes exactly 1 day
- It involves defining goals, rapid prototyping and usability testing
- It is user-centric
- It requires the full attention of the entire design team and decision-makers for one workweek, so they will need to clear their calendars
When done properly – a design sprint reduces the risks associated with introducing a new product to the market. As a result, even after just 5 days, sprint participants gain validation for their ideas as well as a solid roadmap for the next phases of the project.
But that’s enough theory; it’s time for a real-life example of what this all looks like in practice.
Design sprint – how we tested our solution
We decided on a time period and sent out invitations to everyone who would need to be involved in the process:
- on the client’s side, this included:
– the CEO,
– one marketing specialist,
– one recruitment specialist,
– one team leader,
– one developer;
- on our side:
– two UX experts were responsible for conducting the workshop, doing research and working on the design.
DAY 1 | MONDAY: Understand
Ready, steady, go!
Feeling truly enthusiastic about the project, we met up on Monday and focused on understanding the long-term business goals and defining the scope of work.
We started by analysing how exactly the client’s business works – what their objectives and challenges were at that very moment. There were a lot of details to discuss, one by one, which was tedious but absolutely necessary. As a result, we were able to clarify our long-term goals to guide us through the rest of the work.
We also created a map depicting all current user paths and everything that added up to the user experience, including the paths that they had taken to enter our client’s website. We determined different user types, how they found the company, what they were looking for, how they contacted the company, and how they were served. This provided us a full view into the current situation, so that we could understand key issues and start planning improvements.
One of the most significant parts of the day was when we got to interview the experts who were responsible for the key areas within the client’s company, in order to get their perspectives and opinions on the problem that we were working on. That was a real fountain of knowledge!
We heard different views on the same issues, and were able to discover many problems that had been significantly affecting our project. Without this step, we would have surely overlooked some important issues. From these interviews we were able to pull out a common denominator – the same problems that kept appearing and reappearing in all of our conversations. Of course, we couldn’t take all of the reported issues into account since we had to be careful not to lose sight of our long-term goal.
Plus, since we needed to be ready with everything by Friday, we were forced to keep things simple. We took the map that we had created and – based on the results of our interviews – we identified the most important areas to focus on while working out the solution.
And this is especially worth highlighting – during a process as short as a design sprint, you always have to focus on just one thing, instead of dabbling in all parts of the project at once. Remember that you have to prepare a prototype and conduct user testing within 5 days. However, if you choose your area of focus wisely, it actually works like an acid test – you can find out if your project makes any sense, and if it’s a good idea to proceed with your plan. And you will learn all of this well before anyone actually sits down to write their first line of code.
DAY 2 | TUESDAY: Diverge
On Tuesday, we focused on looking for inspiration and creating a sketch of the final concept.
- Lightning Demos
First, our sprint team ran a brainstorming session, so that everyone could focus on finding inspiration from different areas. All the experts involved had a chance to describe and justify their ideas and suggestions. We were inspiring one another to come up with new and interesting solutions, making this a very effective part of the day. As a result, we collected a lot of sensible options to choose from.
- Split up
Then our team split up and everyone had to create a sketch of the final solution on their own. We were all working on the same problem, regardless of our respective drawing and design skills. After all, a pen and a blank sheet of paper are sufficient enough to express what you have in mind, no matter who you are or what you do.
And it was crucial for all of the team members to not tell one another about their suggested solutions afterwards…
DAY 3 | WEDNESDAY: Converge
On Wednesday morning, we had a board containing 5 different options on how to solve the problem that we were facing. Each consisted of 3 crucial steps and involved new screen designs and user paths within a new website. We just didn’t know who was responsible for which suggestion, in order to remain impartial while deciding and voting.
So, having these 5 options, we started to review them one by one. One team member would describe what was on the board, while the rest of the experts involved would listen and write down questions to ask the creators once the presentation was over, and they could finally reveal themselves.
After the discussion, everyone was allowed to vote for one of the presented solutions (either for the whole sketch or only part of it). We were able to create a heat map that showed how the team members were voting, to produce a final concept that merged all of the best ideas.
This way, we selected a final shape of concept that was ready to be prototyped and then put to the test of an end user. And we only had 2 days left.
DAY 4 | THURSDAY: Prototype
Finally, it was time to create a working prototype – in just 8 hours!
As a designer, I was horrified at first, since we had very little time to prepare something that, in principle, should imitate the finished product as accurately as possible. In our case, the prototype was supposed to look like a real website covering a simple user path – from entering the main site to going through a few subpages. And that was when I learned to truly appreciate our interdisciplinary team.
We divided the tasks among our team in accordance with each of our skill sets. One person covered all of the copywriting tasks, while another prepared the photographs and icons. One UX expert focused on designing the screen views, while the other one added all the interactive features to the views. Everything was moving like clockwork.
In the meantime, the team member responsible for conducting user testing was preparing the test scripts for the next day.
What a day and what teamwork!
DAY 5 | FRIDAY: Test
On Friday morning, having created our prototype, we were ready to test our idea.
The users that we had recruited earlier began to successively join the test sessions, doing tasks and adding comments.
Our team, on the other hand, was monitoring the process and making notes.
As a result, we collected important feedback that showed us what was working well, and what we would have to modify. But the most important thing we learned that day was that (after 5 testing sessions), we were sure that our idea had caught on and we were confident that it would work out really well in the market!
All the necessary modifications were introduced after the design sprint. However, we were extremely satisfied with the effects of our 5-day test run. We created and tested a working prototype that met all user needs and fully supported the client’s business goals.
After this design sprint I became a big fan of this methodology. And I agree that the bigger the challenge, the better the sprint, which was emphasised in the Design Sprint Book.
This method allows us to focus on a small yet significant part of a larger problem and work on it separately to ensure that we are moving in the right direction. Plus, we don’t have to stop at one design sprint – it can always be repeated whenever needed, and even used to create something bigger, more holistic. The result of a design sprint can also be leveraged to continue our work in the form of a Discovery Workshop or Software Product Design.