Designer on The Sprint. 10 Thoughts
Hello Dear Reader,
I know that many of you have probably read or at some point heard about design sprints for now. It’s no longer any innovation. UX teams have been practicing this pattern for a while now.
Up to this point, been through a few design sprints myself. Some of them were applied to the real projects, some had rather educational goals, some were the workshops I conducted to involve other people in this process and gain more experience myself.
Running sprints is a good way to make sure you give your project a proper launch. This story is not only about that though. Given an interesting nature of the sprint and looking through the prism of being a designer, I decided to distill the most interesting moments and turn them into this article.
But before we get to it, just a quick rundown on what the design sprint is.
Design sprint is a cross-functional, empathetic and human-centered approach to delivering solutions and facing the problem as it is. It’s based on Google Design Sprint which is originally and most fully described by Google Ventures. Shortly and as defined in their book “Sprint” :
Design sprints are a framework for teams of any size to solve and test design problems in 2–5 days.
I’d highly recommend this book for reading. It doesn’t only describe the process stages in detail but very much helps you to get your own sprints running.
The standard design sprint consists of 6 main steps:
- Understanding the problem;
- Defining your methods of solving it and key focus points;
- Diverging from solution to solution to try out as many as possible;
- Selecting the most promising ideas;
- Prototyping it so you can test it with real users;
- Testing the prototyped solution with users, stakeholders and experts.
The sprint team, in turn, has its own roles within. In most cases those roles are assigned according to the participants’ fields of expertise.
Coming from my experience, the “Basic” team set includes:
- Facilitator. The team lead. Facilitator keeps track of time, identifies the challenges and makes the final decision in case the team is uncertain.
- Domain Expert. Representative of a specific area where the challenge is located.
- Tech Expert. Technical feasibility and input. Technical specialist is also often involved in turning ideas into the testable prototypes.
- Design Expert. Usually, the major advocate of the users. Aside from theoretical input and taking an active part in ideas generation (those usually taken down by Techs or Facilitator), often responsible for the visual concept of prototyped solution.
Those roles may also vary based on the ongoing activity. For example, when conducting user interview you need to assign at least the “Interviewer” and the “Note Taker” (it goes without saying you’ll also need to invite the “Interviewee”).
Running design sprints is beneficial when you have cross-functional approach within your UX team. Having a domain expert in the team might help you to filter your ideas from the standpoint of their applicability to certain area, developers would advise on technical feasibility, designers would apply their specific expertise and so on.
Though I tried different roles running different sprint sessions, I’d like to share some thoughts on what a designer might expect from the design sprint.
1.It’s mentally exhausting. Most of the time we ran design sprints that were just two days long. That means we had only two days to find the problem, research it, do/think/feel/look at it from our user’s perspective, try dozens of solutions to test just a few. For a limited amount of time, your team needs to develop this aggregated mental model to be applied to your findings during the sprint and try not to kill each other.
All of that is happening under intense time pressure. Such tense mental activity is hard and sometimes stressful. Starting the sprint at 10 am, I felt like a squeezed lemon by 5 pm.
2. Not all of collective activities are fun. The more sprints I was involved in, the more I realized that even though the collaboration is a key factor you don’t have to like all of it.
It’s all about the collective input when you are inside of that process. A result of literally every activity turns into the achievement of collective effort. The visual stage is not an exception. I don’t know about you but I like putting my pixels together when concentrated, to get the best ones I need to stay undistracted.
Don’t get me wrong, I do think that the collective approach during the sprint is important and leads to more insightful results. Moreover, some of them can even bring some fun to the process. Still, that doesn’t make me like preparing the mock-ups with people distracting and staring over my shoulder any better.
Maybe I’m being too much of a designer here but that part of sprint sucks. Well, that’s the price I guess.
3. It’s amazing to see the results of your work implemented so quickly. It really impresses me to realize that what I visualized (for the most part) an hour ago, I will be able to try out and test with real user in just a few hours or so.
As a designer, love seeing my work in the hands of a real user, especially when we are talking about just a few hours of the time difference!
4. It teaches you to ask before answer. Sprint shows that before designing the solution it’s always a good idea to find out what the problem actually is. It shows the bigger picture.
You can either design a chair right away (and likely redesign it many times afterward) or brainstorm on how to develop a way to sustain a person. The beauty of this approach is that it’s fully applicable to many other areas.
You can always try to look deeper, to ask “Why?” one more time. It’s no longer designing, now it’s problem-solving so don’t design a chair unless there’s no better way to sustain a person.
5. Sprint releases your creativity in the most unexpected way. There is a place for brainstorming within the design sprint. Discussing your ideas out loud with your team allows you to look differently at them when they are no longer just in your head. Your creative thinking is not only improved, it’s encouraged now.
When all think alike, then no one is thinking. — Walter Lippman
If you have some “out of this world” ideas how to, let’s say, improve the shopping experience, that’s exactly the time to express them. That’s when you can say “I want a nice looking female robots to do the shopping for me while I’m playing computer games” and supposedly no one will call you nuts (maybe weird though).
I actually believe that those kinds of insane ideas are pioneers in the way of global innovation. They didn’t invent the electricity by constantly improving the candles.
6. It broadens your horizon. During the sprint, you deal directly with people from different areas of expertise. Sometimes you pick up things you may not have even expected you would.
Working together on the same problem makes people discuss and look at it from very different yet related fields. Understanding the implementation restrictions for IOS today may save you quite a time tomorrow.
And that’s still an easy part, how about business analysis or strategic marketing?
7.Design sprint shows you rather the importance of the process than its result.
While running the sprint, don’t try to find the solution too early otherwise you limit your potential of achieving it.
Defining it shortly, design sprint is the sequence of steps with an outcome at the end. We can jump over those steps straight to the conclusion, but what kind of conclusion that would be?
Your outcome of the process is what you put into it. Design sprint taught me that the more thoroughly (and patiently) I try to solve the problem the more insight I can put into the solution. It makes me think less of implementing features (the result) and more of gradually researching the need (the process).
A human brain is always trying to answer all the questions in the shortest amount of time. Greeks believed in Zeus explaining the lightning but that doesn’t make myths historical facts.
8. It kills your internal perfectionist. I remember what a perfectionist I used to be a couple years ago. I’d just be sitting and polishing that dribbble shot for hours, gathering those pixels into neat little icons. No blurred edges, pixel-perfect only.
Point is, it’s pretty opposite to what happens during the sprint. When you have a couple of hours to design a bunch of screens of the system you first heard of yesterday, best case scenario — you cover it with “Font Awesome”.
Time restriction helps, especially in the design sprint. The lesson I learned from it: There’s something more valuable than a “perfection”, this is an education and learning at every step taken.
9. I love sketching now more than ever. During the design sprint, especially throughout certain activities (e.g. crazy 8s), every team member needs to put as many ideas on paper as limited time allows. Paper sketches are used because it’s accessible, easy and fast.
Such approach has many advantages, and there was a time when I just didn’t believe it does. I remember my thinking a few years back: “Why to spend time on paper, I have all the ideas in my head and I can just quickly photoshop them”. The truth is, while spending time on digitizing that one idea, I could have visually memorized dozens of them using a pen and piece of paper.
It doesn’t have to be a full flow or much itemized, just accent the details that represent that specific idea. During the sprint, the rough sketch is the best teacher because it’s the fastest one.
10. The rules are different if you are in a team. You need to know how to sell now.
It’s one case when you have your design task and need to pitch the result to the client after you are done, another — when you first need to pitch it to your team.
As was mentioned earlier, the design sprint is all about a collective effort and the outcomes are considered a collective achievement. Which is why you might have the best idea ever, you can be thousand percent sure that’s the one but if you cannot properly present all its benefits, it will just stay in your head or the best case — on paper.
In conclusion, can say that I consider running design sprints highly effective. Not only for the project but for my personal development as well. Aside from what has already been said, applying collective insight to find and research the problem brings an added value to the time spent on it by me and other people. It increases the time value for myself, consequently leading to spending it more sparingly and so efficiently.
So stay productive and have insightful design sprints.
Hope you’ve enjoyed this article. Is there anything you’d like to add? What is your experience of going through the design sprints? Feel free to drop a few lines within the comment section.
