In a 5-day sprint, no one’s job is more stressful and more seemingly impossible than the prototyper. When we run a Sprint, we usually employ a product researcher (before the sprint), an experienced Sprint facilitator who is also an experienced product/UX lead (that’s me usually), and a prototyper – which usually means an experienced visual designer who can work quickly to mock up a digital product, but could sometimes mean someone who is experienced at modeling physical products.
In running sprints, we’ve noticed a clear pattern – the only day where we often go over the usual hours of 10am to 6pm, sometimes by quite a lot, is prototyping day. And the most exhausted member of the team is always the prototyper.
The reason seems clear: the prototyper is the one tasked with delivering on the promise of the previous 4 days. Any gaps in understanding, unmade decisions, lack of focus or clarity – have to be plugged in by the prototyper. Any last minute ideas or changes have to be accepted or rejected at the prototype level. Any copy issues, important branding issues, flow issues, and financial details (for instance pricing on a marketing page) have to be finalized during prototyping. And finally – in any software design that displays fake data (for example a dashboard, or list of items) – prototyping day is when we try to get the fake data as close to reality as possible. (Data that doesn’t feel realistic is highly distracting to users and can derail the user testing on the final day.)
Over time, we’ve developed a fairly good way to mitigate, though not completely do away, with this stress. Here are some of our tips:
1. Prepare some styles ahead of time
When a branding guide or existing software is available and is good enough, we try to prepare elements and components in our design tools ahead of time, so that we can quickly reuse them when it’s crunch time. This helps a lot – especially if multiple people are going to be prototyping.
2. Limit the prototype scope upfront
Scope creep is a problem not only in software development projects – but also in the sprint. We therefore try to limit the scope in advanced. In a software project – we explain upfront that the sprint will tackle the most important 6 screens on a web / desktop / tablet product, or the most important 10 screens of a smartphone app. This provides ample opportunity to test important assumptions and often defines what is essentially a whole product. However in very large or complex projects – it keeps us focused on the few key screens that we can actually prototype in a day.
3. Embrace the good enough
Great visual designers are perfectionists, but pixel-perfect designs are not what the sprint is about – it’s about testing assumptions. It’s about good enough. We prototype our software to be realistic and attractive, but we don’t judge it by the standard of final production designs. Sometimes, a wireframe with just a little bit of color can teach you everything you need to know.
4. Keep less important transitions and steps to the end
Gaps in the user’s flow are not as distracting as you might think. Humans are very adept at filling in the gap. So if a person hits Sign Up and is then taken to a signed-in state – that’s not the end of the world. Not spending enough time on the critical screens that test the core assumptions is much worse – so make sure to prioritize screens and don’t go purely based on logical order.
5. Do as much as possible during Storyboarding
Because we follow the original 5-day model, we usually arrive at the storyboarding phase on Wednesday with plenty of time to spare. But tiredness from the intense week can set in, and doing a rough storyboard then breaking early can feel oh so sweet to everyone. I recommend pushing through it just a little bit further, and make sure that we have a decent sketch for every key step. We still do detailed wireframes of some challenging screens the next day, but there should be plenty of screens the prototyper can jump right into on Thursday morning.
6. Assign important prep work to the rest of the team
Assigning work to people who are your clients or your superiors might feel unnatural for some. (Personally, I love it – but that’s just me.) But there are many important prep tasks that non-designers can do on Prototyping day. We’ve had people write copy in a Google Doc that our designers could use, do pricing / financial research to figure out the right prices to show, even furnish us with fake data, including fake images.
7. Prepare detailed wireframes of challenging parts, but not everything
As I wrote above – we want the storyboarding sketches to be detailed enough that the prototyper can dive in. Very often, however, there are 2-3 especially challenging and important screens that require a little bit more product / UX thought before they’re ready for design. I usually tackle those myself, in wireframe form – after discussing with the prototyper to identify the correct screens for me to tackle. This is not science, but a conversation. The goal is to separate as much as possible product thinking and discover, which should have been largely tackled by now, and pure visual design – which is what the prototyper should be focused on.
8. Bring lunch in, and an endless supply of coffee and snacks
Prototyping day is no day to go out to lunch. There’s no time for that! We usually order sandwiches in, or bring something in from the hotel’s lobby. And we try to make sure there’s an endless supply of coffee and healthy snacks at hand – in keeping with the recommendations in the Sprint book.
9. Protect your prototyper’s time and attention
The absolute worse thing that can happen on prototyping day is to have the rest of the team sit around chatting idly and distracting the poor stressed-out designer. The prototype will not happen if prototypers don’t have the ability to focus for long stretches of time — 3-4 hours at least without a break. In the last sprint, I kicked out the entire team from the room until the next check-in at 4pm. I’m also considering recommending high quality noise-cancelling headphones as required equipment for prototypers. If 6pm has hit and the prototype is still not ready, that’s OK – we consider going back to our separate hotel rooms and keep in touch over chat. This gives the prototypers a chance to breath, stretch their legs, get something to eat – and hammer the final details out without distractions.
10. Not using Figma in sprints? You’re crazy.
I know it’s odd to make such a specific product recommendation when the rest of the tips were so general – but Figma is just a life saver in a Sprint context. Figma, for those who don’t know, is a Sketch-like Visual Design tool that allows complete and total real-time collaboration, Google Docs-style, between designers. In the context of a Sprint, it changes everything. One person is polishing copy? Go into Figma and make the changes yourself. Want to re-use an element from one screen on another – grab it from t he designer who just finished it, then duplicate on your own screen. Need to make quick adjustments to the flow between tests? Everyone has the latest version at all times. Figma has become an essential tool for us, and will likely continue to be so long as other tools don’t allow real-time collaboration.
Hope these tips help! If they do, please let me know in the comments, or drop me a line!
Remake Labs is a Design Sprint agency dedicated to better outcomes and impact through rapid prototyping.
