Design sprints dovetail with engineering sprints so that designers are always working one sprint ahead and have new designs ready to hand off to engineers at the beginning of each engineering sprint. Some design sprints, like engineering sprints, require a longer timeframe – especially during the early stages of researching and ideating the application.
What it is
Design sprints are the same length as an engineering sprint, and they work in tandem with the engineering sprints. They include a kick-off meeting where design tasks are planned and end with a design review where work is presented to the stakeholders, PMs and Engs before it is handed off for coding.
How its used
The point of the design sprint is to ensure that designers have the time to work on features and assets, implementing the design process and ensuring that the best solution is the one that gets built.
There’s a common mistake both young professionals and expert contributors fall victim to when coming up with ideas. It’s known as the Einstellung effect — when a person defaults to a known solution rather than a novel or optimal way of solving a problem.
Often designers will find themselves at the beck and call of PMs or engineers, having to rapidly create design solutions the night before an engineering sprint kicks off (or in some cases, mid sprint).
I’m sure this has never happened to you.
It is both exhausting for the designers, and bad for the product to work in this half-assed, unplanned way, and yet, many companies consider this the normal way of working with designers. Unfortunately, a constant barrage of last minute design requests with extremely short turnaround times leads to a revolving door of burned-out designers who want nothing more than to get away from that disfunctional process.
It also pretty much guarrantees the Einstellung bias. That’s the belief that whatever first came to mind as a solution is the best solution. Because time is working against the designer–there’s no time to implement any good design process like research, ideating, or validating the designs–he is forced to use the first solution that comes to mind.
It’s easy to spot products that use the “hair on fire” design process.
The design sprint allows the team the breathing room to get past their first ideas and onto the real innovations. It consists of four parts:
Design planning meeting
This is the kick-off meeting where the PM and other stakeholders meet with the designer or the design team to plan out what will get done in the next sprint. Since a sprint is generally 2 weeks (to keep it in sync with the engineering sprint) this planning meeting is where designers can estimate how much effort each design task will take. Then they can make a realistic estimate of how much they can get done during the sprint.
I like to estimate effort the way the engineers estimate their coding effort, using a Fibonacci numeric system that works like this:
- 1 – less than an hour
- 2 – a couple of hours
- 3 – a day
- 5 – a few days
- 8 – a week
- 13 – two weeks or more
Just like engineering teams, it takes a bit of time to accurately estimate effort and get an idea of the team’s velocity.
The majority of the sprint should be uninterrupted design time when the design team can put the process into play: research, ideate and validate
Design review and sign-off
At this meeting, designers show the work they’ve completed for the sprint. The attendees will most definitely include the product manager, but may also include engineers, project manager and other stakeholders. This is where designers will walk everyone through the problem, the solution and field questions.
This meeting should come a day or two before the end of the sprint because at this meeting, the team must decide whether:
- The feature is ready to be pushed into development
- It needs quick changes before it’s ready (e.g. changes that can be done before the end of the design sprint so it’s ready for the engineers)
- Or it needs to be pushed into the next sprint for more substantial changes
Having some way to track design sprints, features, scoping and signing off is really important. I use an Airtable to make sure everyone has clarity on where we are and what we’ve agreed to.
If the team feels like a design is almost there, but small clarifications or revisions are required, then the last day or two of the sprint is when those changes happen. Ideally, these are small enough so that they won’t require a second review with anyone.
Design changes that are too involved to be completed in a day should be pushed into the next design sprint. It doesn’t make sense to set aside time to work on finding the right solution to a problem using good design process, only to throw that out at the end because you’ve run out of time in the sprint. Don’t be afraid to push back under these circumstances.
File prep and hand off
Also remember to save enough time at the end of the sprint to prepare the files for handoff to engineers.
For some teams this might include detailed annotations and prep-work for the visual assets. If you’re annotating along the way (which I recommend, since it not only makes your life easier but helps when you’re doing the design review with the team) and using a tool like Sketch and Zeplin, then you probably don’t have much work to do when pushing the designs to the engineering team.