Build Design Systems With Penpot Components
Penpot's new component system for building scalable design systems, emphasizing designer-developer collaboration.

Giant Robots Smashing Into Other Giant Robots | Kyle Fiedler
Design Sprints,
a five-phase process pioneered by
Jake Knapp
and Google Ventures,
are a great way to get a team working together
with a shared understanding of a problem,
coming up with potential solutions,
and quickly testing those ideas.
We’ve found the process great for products
or features that haven’t been validated.
Because of the amount of new knowledge
and thinking that goes into the sprint,
they are draining for the entire team.
As an introvert,
I find these days working in the same room
as 3–6 other people especially draining.
Yet, I’ve found them to be the best tool
for getting a base level of knowledge for the team,
getting the client to think about problems
and not solutions,
getting a diverse set of minds ideating on one problem,
and testing risks in a business.
Since my first few sprints,
I’ve been working to make them more
sustainable for my team and me.
We should never be following any process blindly,
and every sprint should be different.
We should be adapting the process to
fit the needs of our team, our clients,
and the problem that we’re trying to solve.
That even means during the sprint.
If we’re halfway through the sprint
and we think that we don’t need to do more,
we shouldn’t.
Here’s a short list of things I’ve done
to make sure the sprint is sustainable
for me while I facilitate
and for everyone participating in the sprint:
Sprints should be 7 hours max.
Since I’m more of a morning person,
I like starting around 9 and ending between 3 – 4 pm.
This includes the prototype and test days.
I’ll let the client know before the sprint
that these are intense days
and that they’ll be tired as well.
I set their expectations that
while we’re not working a typical 8-hour day,
they’re getting higher quality because of it.
One of the ways I would dig myself into a hole
was planning on prototyping something
more than I can handle in those 7 hours.
But the scope creep has a broader impact than that.
It means we’re talking about more possible ideas
during the sprint and we’re learning
and trying to understand more.
A prototype shouldn’t have to be more
than a handful of screens.
I use the problem statement to curate the conversation
so that we never grow the solution
to more than I can prototype in a day.
If they are looking for a prototype to take to get funding,
I’ll skip bringing in people to
run interviews on the last day
and spend two days prototyping.
If they’re fuzzy on what they’re trying to solve for,
I’ll conduct more interviews
and focus more on testing our collective assumptions.
The best way to figure this out is to ask.
I start each sprint by asking what success
looks like to everyone in the room.
These usually take the form of
Jobs-to-be-done switch style interviews.
These give me some time to learn about the problem space,
the context people are in,
and helps me understand the desired outcome
before we head into the sprint.
I’ll have the entire team join me in these
to start to build a collective knowledge base.
Similar to the interviews at the end of the sprint,
seeing them firsthand has a bigger impact
than reading summary or watching a recording.
The seemingly small task of note-taking
turns into a much larger task
while facilitating the sprint.
I’ll ask someone in the sprint to
document our process for me while I’m facilitating.
This person not only records notes and photos during the sprint
but also is in charge of adding them to
our Trello board after our days are done.
My participation isn’t nearly as meaningful as
making sure I’m facilitating as well as I can.
If the design sprint doesn’t have the strong opinions of a designer,
I’m ok with that.
I’m seen sprints fail because
the facilitator wasn’t focused on
leading the team through the sprint.
Conversations get drawn out,
exercises aren’t fully explained,
people are confused about next steps,
and the goals of the sprint were’t clearly defined.
I try to have a 30 minute break in the morning,
hour break for lunch and 30 minute walk in the afternoon.
Breaks should be a quiet time
for people to catch up on other work or go off
and reenergize.
Breaks are not meant for more talking about the sprint.
I’ve prepped enough times to cut down on the time I need to get ready.
But I do admit that this has
come with running more than a handful of sprints.
After your first sprint,
try to see what you could do better up front
to set expectations and prepare yourself.
Instead of reading through all of Sprint again,
just use the schedule they have in the back of the book
or our guide
to refresh your memory.
Use tools like our Trello board
during the sprint and don’t be afraid if
you need to take a minute to re-read instructions
during the sprint to get the exercise right.
No matter how tired I am,
I force myself to exercise at the end of the day,
this could be something as simple as a long walk with my dog.
After sitting in a room all day you need the exercise.
I find that this minor thing helps me recharge
mentally for the next day.
During the sprint,
I try to drink a lot of water.
It’s easy to focus so much on the sprint that I forget to drink.
I keep a pitcher of water in the middle of the table
with a few extra cups to make sure everyone else is doing the same.
The caveat with experimenting with the sprint process
is that they depend on all the variables that go into the sprint.
What is the problem, who is the team, what time do you have together.
Some of these experiments, like hydrating, are really low risk
but others could have a bigger impact on the results of the sprint.
Be intentional about how you experiment
with the format and how you implement the changes
and be aware of any negative impact that
experiments might have on the success of the sprint.
Have you experimented with different ways
to make sprints more sustainable for you?
Let us know on Twitter
what you’ve found successful!
–
Want to learn more about the way we run design sprints at thoughtbot?
We’re running a workshop in Raleigh-Durham
in conjunction with American Underground on November 9th.
Join us!
AI-driven updates, curated by humans and hand-edited for the Prototypr community