Qwinix transitioned from a traditional software development model to using design sprints to better align client needs with end-user demands, resulting in improved user adoption. Key takeaways from facilitating design sprints include the importance of clear role definitions, managing expectations, and maintaining focus on user-centric design throughout the product development lifecycle. The design sprint process has proven invaluable in extracting insights and refining product definitions based on user feedback.

1. Design Sprints
Learnings and Insights from the Trenches
Total UX Meetup November 15th 2016
About a year ago, Qwinix operated as a typical software development company: our clients,
ranging from one person startups all the way to massive enterprises, would approach us to write
software for them. They would tell us what the requirements were, we would take those at face
value, and we would build exactly what was ordered.
But while we were really good at delivering exactly what was asked for, we learned that in many
cases our clients ended up dissatisfied. Disappointing results were typically caused by poor
user adoption. As we took our clients’ requirements at face value, we never questioned whether
or not they had done their due diligence in figuring out fundamental questions like “which
business problem are we trying to solve”, and “who are we building this product for”. In the end,
Qwinix looked bad because we delivered products that failed to meet the end users’ demands.
This realization caused us to fundamentally rethink the way we do business. Rather than taking
our clients’ requirements and building exactly what they envisioned, we started to put the focus
on partnering with our clients to first and foremost validate that they were on the right track with
their product definition. ​Sprint by Jake Knapp had just come out as a new format to apply design
thinking principles to new product development, and we decided that we would insist on having
a 5 day design sprint with each of clients who wanted to embark on a new product development
path.
This new approach has proven to be wildly successful, and has led many of our clients to new
insights that radically changed their envisioned products for the better. After having facilitated
about 12 design sprints at Qwinix, what follows are my ten biggest takeaways.
10. You’re going to need a report
It is not mentioned explicitly in the book as such, but we have delivered a sprint report to all of
our clients, and they absolutely love it. The report contains a concise recap of all the activities
that were done during the sprint. It includes pictures of both participants as well as artefacts
created by the team. This report has served as a summary of what we set out to do, the
activities that helped us get to our prototype, screenshots of the prototype and learnings from
watching testers interact with the prototype. Additionally, we include a high-level product
roadmap; a bulleted list of features that should be the focus of an MVP or first version of the
product, based on prototype testers’ feedback.

2. 9. Lunches are critical
Many times, the audience of our design sprints are cross-functional, and there is a tendency to
have the guards up early on. People who have worked in silos for years are for the first time
forced to collaborate in a highly interactive environment, and for 5 days straight. We have
learned that going out to lunch together and encourage conversations that are not related to the
product or business are of critical importance to instill a sense of cooperation - we now insist
that we walk to an off-site lunch location rather than to order in because of this reason.
8. Don’t underestimate recruiting
Recruitment of your prototype testers is not easy, and timing is tricky. There is the temptation to
get a head start and line up your testers too early (and run the risk of not having the right
people, because not enough thought has gone into who your target audience is yet), and on the
other hand there is the risk of procrastination and ending up with less than 5 solid testers. It is
critical that someone is in charge of lining up 5 solid testers that match the target audience as
defined on Monday.
7. Role definition
We have a number of different configurations we apply at Qwinix as far as facilitation goes, and
two people typically fulfill a number of different roles: there’s the facilitator - the person who
introduces and leads the exercises, keep people on task, etc. Secondly, there is the visual
designer - in all likelihood you will be creating a prototype that consists of a number of screens
that need to look credible. Thirdly, there is someone who needs to play the end user advocate -
in many cases, the team is enamored with a product idea and has been for a while, which
sometimes makes it hard to take a step back and ask “why would I use this” - having someone
in the room to ask these questions is very useful. Lastly, it is very helpful to have someone in
the room who can provide a technical and/or product management perspective - someone who
can provide a technical reality check in case things tend to go off the rails.
6. Ask the Experts. If you must.
The book pays quite a bit of attention to the Ask the Experts sessions. We have had very mixed
success with it. In many cases, the experts who had been lined up basically repeated what the
team had been diligently pulling apart for a number of hours before that, and very rarely have
we come to new insights or surprises while talking with the experts. Part of this has likely to do
with the fact that the experts need to be lined up very early on (on Monday), which is right when
the team is starting to get to really deep insights about their problem space. Most importantly,
we have learned that introducing these experts on Monday afternoon has had a negative impact
on the momentum that had just been built. We advocate that you keep experts ready to be
called up in case there are concrete questions, but leave them out as a default session on
Monday.

3. 5. Keep your eyes on the ball
One of the most challenging aspects of getting 7-10 people in a room and encouraging them to
think creatively is that sometimes you are ​too successful. When you give people free reign on
what can happen with their product, they sometimes start to run wild, and lose track of what we
set out to accomplish. It is very important that you write down what your sprint goals are (which
questions are we trying to answer or what are we trying to validate with our prototype?) Having
these goals posted in a prominent place in the sprint room has proven to be invaluable to point
back to when things tend to go off the rails a bit.
4. Don’t show me the money
One specific distraction that rears its head time and time again is monetization. There is typically
at least one person in the room who has to tie all activities back to “how are we going to make
money with this?” Of course, the majority of the products or services we build are ultimately
aimed at either making or saving money. But for our design sprint, it is completely irrelevant. All
we want to learn from our prototype is whether or not people will use it, and why or why not. If
you have user adoption, monetization will happen one way or another, and exactly how it
happens can be decided by business people at a later time. That discussion is a distraction
during the design sprint, and should be tabled for after we have our confirmation that the
product or service is viable from the end users’ perspective.
3. Who is the client? Who is the end user? Huh? What?
It’s one of the core ideas behind user-centered design, but more often than you may think, our
clients struggle with identifying who they are building a product for. One of our clients had a
fairly defined idea for a product at the beginning of the design sprint: it was supposed to be a
tool for data scientists and would allow them to more quickly calculate ROI on prospects. They
currently are a bottleneck in the sales process. Two days into the sprint, they came to the
conclusion that if they would focus their effort on putting better information in the hands of their
sales force, the quality of their leads would improve significantly. Their end users changed, as
did the complexity of their envisioned product, simply by asking fundamental questions about
who the envisioned product was for. Years of planning had gone into this already, and a mere
two days opened the client’s eyes to an entirely new way of looking at this.
2. The design sprint is only the beginning
The design sprint puts user-centered design principles front and center, and people really like
this week-long exercise. But some of them believe that this is the end of it, and that we can now
start building products based on what we’ve learned. This approach won’t work. The design
sprint sets the direction, validates that the direction is a good one, and that it is fairly safe to
proceed down the path we’ve chosen. But that path still needs to involve all the tenants of
design thinking: user validation needs to happen every step along the way, and the same
mindset that characterizes the design sprint week needs to permeate the remainder of the
product development lifecycle.

4. 1. Expectations
Finally, one of the hardest things to manage is expectations. Design sprints are popular now,
thanks in part to Knapp’s book and lots of exposure at conferences. Many enterprises want
design sprints, and this popularity and desire to jump on the sprint bandwagon often comes with
false expectations. Design sprints are not a substitute for product development best practices. It
is not a shortcut. The hard, difficult work of software development still needs to happen, and all
the common pitfalls still exist. All the design sprint does is to put a working prototype in front of
actual, unbiased users. And their reaction will help you understand whether or not moving
forward is a good idea. The design sprint is nothing but a very, very good reality check before
you head down an expensive product development path.