How We (Almost) Nailed A Design Sprint In ONE-DAY

To clear the clouds, we strongly believe that the best results can be achieved with 5 Days model of the Design Sprint. Lesser the time, harder it is to get the best out of the exercise. But In our case, because of the shortage of time, we decided to become scientists for a while and experiment with One Day Design Sprint session. You know, SOMETHING is always better than NOTHING.

Also, this post is not a propaganda to promote One Day Design Sprint but to share our experience and learnings with fellow developers and design enthusiasts.

For this assignment, Vishvajit who is one of our best Project Managers, flew to Boston, USA all the way from Pune, India to visit a client and conduct one-day Design Sprint session. It was going to be a short and intense session and we were firm on sending the best of our captains. Vishvajit has been experimenting with different Design Sprint models and we knew he was the right candidate.

The idea was to dissect the project from all angles and build a road map for a well-rounded and perfectly structured application to satisfy user expectations as well as business needs.

Following are the key takeaways in his own words -

From the day my plan of meeting Alex and Dylan was fixed, I was super-excited. But I was also a bit nervous as I never dared to conduct a Design Sprint in ONE DAY. Right from the agenda to the the outcome of the session, I envisioned everything and was ready to roll.

Finally, the day arrived. On Wednesday morning, I got on the plane from Mumbai International Airport and was in Boston 20 hours later. I headed straight to the hotel (and then to my bed) to get rid of the Jet Lag.

The next day, I united with the client team and after few Hi’s and Hello’s, we started spinning the wheel. We did most of the planning beforehand to avoid wasting any time and focus purely on the Design Sprint activities. Right from the stationary till primary research and competition analysis, we had our ammo ready and we were ready to fire.

So why ONE DAY Design Sprint ?
Time ! We did not had a liberty of it ! When client approached us, they had strict deadlines for the project and the countdown had already been started. There wasn’t any scope to tweak the deadlines as well. So with little room to breath, we straightaway decided to have a in-person and quick design sprint session to fix on major features of the app and get started with the development.

Warming up —
Before getting started with the session, we needed to DEFINE our objectives and end goals. So we drafted a concrete plan along with the number of hours we will be spending in total. As we had a time limit, we wanted to make sure that we derive the most out of every hour (rather every minute) spent. This planning served as a guideline throughout the session.

We divided the entire day in 3 slots —
> 2 hours for DEFINE and UNDERSTAND phase where we will debate on the idea and app features for the first version
> 3 hours for DIVERGE and DECIDE phase where we will draw rough sketches of the important screens
> 1 hour for concluding the session

Getting Started —

DEFINE (2 Hours) :

As we only had one day, we had to keep plenty of things ready beforehand. There was no scope for committing any error. We also made sure that we had most of the specifications, app features and client expectations ready with us. We just revisited them quickly.

One cannot really DEFINE what needs to be done unless he puts himself in client’s shoe and understand why the client wants to build the application and what problem he is trying to solve. But as we did not had a liberty of time, we had to make it quick. Their expectations, business goals and objectives (even though I studied them prior to the session) became crystal clear to me after we spent 2 hours together.

To give you an idea, the concept of the app revolves around creating trips for user’s air travel and providing more info to the user about the destination city. We had an in-depth discussion to prioritize app features. We decided which features would be built in Version 1 and which ones need to wait for Version 2. Not just the features, but we also defined every small detail about them.

DIVERGE and DECIDE (3 Hours) :

After the initial discussion, we started building a technical story to get a clear picture of how all the pieces will work together technically.

Together, we created hand sketches for the major screens of the app. This stage definitely deserves more than 3 hours (I wish we had 2 more hours).

After brainstorming over ideas from all the participants, we started with mapping the flow of the app and it’s functionalities. The link between features and their use was also established to get an idea of tentative flow.

We had our ‘User Personas’ ready with us and we kept it at the center of everything. A persona is a representation of a type of customer. Personas answer important questions about the user like, “Who are we designing for?” and “What are their characteristics, their goals and pain points?”. Personas help to align strategy and goals and include specific features for specific user groups.

Keeping hand sketches, flow and personas in front of us, participants were asked to explain their sketches one by one. Then we voted for the best sketch features, solutions with most votes were declared as winners. Voting helped get a clearer picture of the most popular solutions.

And that’s how we finally had a feature list and a clear road map for the app.

Conclusion (1 Hour) :
Working with a vague idea from the client, in one afternoon we conceived design flow, and were ready to produce a well-rounded and perfectly structured application to satisfy all user expectations. We tried to do our best in a given time.

The Design Sprint didn’t just help us get the complete idea about the product, it helped the client discover and consider some aspects which were not thought of before.

We now knew what to build, what to eliminate and how all the pieces will work together. Most importantly, it brought the entire team on the same page before getting started with the actual development process.

The biggest achievement was that we eliminated some features which were not adding value to the user and brought down the expected development time by about 20%.

Though we didn’t achieve something extraordinary from One Day Design Sprint, I still believe that for any project to succeed, a good bonding between team members is absolutely essential. And this Design Sprint session served as a platform for us to form that bond. As a result of this session, we got to know each other much better (I now know the name of Alex’s pet dog!) and I formed a special attachment to this project.

Bonus (30 mins):
Finally, we shared notes and had fun activities for about half an hour and said “Adios” on a joyful note.

Here are Few Pro’s and Cons of One Day Design Sprint-

Pros —
1. You can always spare One Day :)
2. It’s suitable for projects with aggressive deadlines or projects which have crossed their deadlines
3. It works as an ice breaker between development team and client team
4. It is more systematic and fruitful than just having a meeting or a presentation session and sharing random ideas without any guidelines
5. Well, and it’s much less stressful on your pocket

Cons —
1. You only have ONE day :)
2. You can not really explore all the features or create hand sketches for all the screens of the app
3. There is a risk of missing out on important functionalities or features
4. Participants don’t have much time to process all the information and come up with creative ideas. On the contrary, 5 Days allow participants enough room to think
5. Participants might not express their opinions freely considering the limitation of time and possibility of getting into long debates

Conclusion —

If you have enough time in hand, always go for 5 Days Design Sprint as it is the most scientific and proven Design Sprint model. If and only if, you have absolute shortage of time, you should consider customizing the process to meet your timeline and in that case, focus on 1–2 core feature of the app rather than trying to dissect an entire app.