Using Design Sprints To Hack Your Design Process
It makes no difference whether you are a member of a large design team or a “lonely ipsum” single-handedly fulfilling all the design needs of the company. The pressures to satisfy both users' needs and business goals, deliver quickly and align everyone are always on. Most of the time the process is a bit of a mess. Some of the common time-consumers include going back and forth, finding missing documentation and updating outdated libraries. These might look like minor termites, but slowly and surely they will chew away your days and double the overall development effort.
Luckily for us, there is still a lot that can be done to make our lives easier. It requires some effort put into planning but will make all the difference in the long run.
So, What Is A Design Sprint
A 3-5 day process involving around 7 diverse roles coming together to quickly solve a specific problem in the following order:
- Understand — Make sure you understand the problem on day one and decide what you want to tackle.
- Diverge — Sketch many potential solutions.
- Decide — Decide on the best one and refine it.
- Prototype — a quick and dirty one.
- Validate — Test the life out of it with real users and gather feedback.
Basically 5 days for a solution — except allocating the time of these people for many companies can be quite literally impossible. You will run into a lot of walls when trying to set this up and it might not even be absolutely necessary. The problem with design sprints at the moment is that they are being used as snake oil — expected to fix every design issue. This makes it hard for the sprint to fail as a consequence. Stakeholders need to justify all those resources, which in turn nullifies the sprint because you are not solving the problem, you are just producing false results.
The limited timeframe of this approach points out practical approaches which if implemented in the daily routine can slowly improve our efficiency and give a bit of time for experimentation.
Problem 1: Finding the Actual Users to Interview/Test is hard
We use so many products on a daily basis that not finding someone who would be in the target audience close to you is highly unlikely. You can gather colleagues on a company Slack, send out a Google form, or even go to your friends and acquaintances. Start by asking a couple of questions and making notes — what are their “go to” products and how do they use them? You just need an opinion and a reaction, based on this you create focus points for later. Getting out of your head and putting your solutions to the test with the actual users are some of the main reasons these methodologies work. Having outside input throughout the creation process is crucial to producing a usable product. This way you are able to save time on discovering issues sooner rather than later. Just a simple 5-minute interview can totally change your perspective and provide valuable insight. Do not overdo it though. To paraphrase Steve Krug, 3 to 5 people are perfect, you do not need a division.
Problem 2: The solution is technically impossible to make
Many a time you will have that one person go “This cannot be done!“ even though everyone has already signed off on it weeks ago. There is one sure way to try and avoid this from happening. UX designer can set up a discussion with the whole team on that project way early in the design phase. This way you have all the questions asked before any actual effort happens. Also, this makes sure unrealistic approaches are eliminated from the start. Especially if you are working as part of a team with outsourced members, you need to be involved even more because a large number of conversations just does not happen due to their physical absence. The case of somebody just passing by your monitor and pointing out that something is overly complex to make, is not possible.
Encouraging an environment in which everyone is active makes it more engaging because every voice is heard. The meeting evolves from a monologue to a discussion on the best solution.
Problem 3: Saving time by copying
No, just…no.
When you are given a problem to solve, research should be your primary concern. This includes interviews, looking at similar products, competition, trying to understand their choices and see the pros and cons of every solution. It is very rare to find this kind of information on showcasing platforms or completely 100% made as you need them to be. Most of the people who post regularly to social media are posting solutions that will never be implemented into a product and were probably made just for the sake of practice — not for an actual feature on a real-life product. On another hand a competitor will never have the same use cases, audiences nor business goals as you do so there is no point in just copying. This “strategy” is equal to shooting yourself in the foot as it neither saves time nor it makes the product better.
Problem 4: Never Enough Time
We all have the same 24 hours or rather 8 at the office. Understanding time constraints makes you very aware of distractions and over-thinking. Keeping things simple in order not to get lost in the details and on a schedule is key. So, next time you want to try something new (that sparkly piece of software you got early access to…) or play around with a solution time-box it to an hour or two. If it works, awesome — you have something fresh to bring to the table at the next design update meeting, if it does not — no harm done. I do not see anyone getting upset over a few hours of experimentation. Doing this helps you diversify your activities, if you are on the same project for a long while — you will need a breath of fresh air now and then. Making it a habit should keep the spark of constant curiosity going, something that I value immensely.
Rule: Step away from the distraction and the solution
Unless needed for research at that particular moment, you should consider moving away from your email and smartphone. If you haven’t already tried this, please do. Focusing is a lot easier when you are not distracted every so often. The benefits might sound ridiculous but try testing it out for a day or two and see for yourself.
Presumptions crumble with data and if your idea was not that great, just keep swimming to another one. Designers especially can be very clingy to our creation, if the discussion or data shows a different approach is needed we might even get a bit defensive. Sometimes it helps actually walking away from the computer and asking yourself does this solution fit the actual use case upon return. Cut the unnecessary discussions short and save time, if something is not working out that is just it.
At the end of the day we are not designing for ourselves but for our audience — remember that at all times. You are not the user.
Conclusion: Iterate Faster
If there is one major thing design sprints teach us it is to fail faster, the sooner you find that the solution is wrong the closer you are to the right answer. Most will have a problem with this, it is not easy sometimes admitting failure but a few falls on a small scale can save you from a disaster on the large one. Constantly having a dialogue about your solution with various roles keeps the creative juices flowing. Do not be afraid to scratch a feature or a workflow if it ends up having no sense, even if all the competitors’ products are doing it. Making a bulletproof product means bullets need to be fired in-house first to make sure it survives.
