How to improve your design sprints with the working backward-approach
- It´s all about that P.0.
This article is a step-by-step example of how a working backward methodology can be used during a one-week design sprint.
A 5-day sprint to create a food delivery app.
This week we were introduced to the approach in how to “work backward” during our design sprints. We were tutored by amazing Jorge Furuya — currently working at Samsung in Seattle. Jorge gave us a very insightful week. We learned and practiced to apply systematic thinking throughout the week.
In parallel with the project’s methodological approach, a lot of our prototyping skills were stretched, using Sketch + Principle*.
*Before even starting with this particular kind of prototyping, learn to always, always name your layers. This will make your life easier.
- Our team was given a quick but process-based methodology: start with the end goal.
1. Start by writing down a simple fictional press release.
The fictional press release should be describing your product — as if it would already have been released. In a written format, describe the main target user, the main problem it solves, what technology is being used and how it improves the user’s life(s).
2. Gather together in your team (could also be together with the client) and go through the press release.
Decide some main points on how you can work to make the press release a reality.
3. Create value propositions.
In our case, we wanted to make a homesick student feel less lonely in a new place by bringing the essence of a familiar and home-cooked, meal to a food delivery app. Our values became; honest exchange, efficient exploration, community building, and welcoming wellness.
What are the core values your product wants to represent? Is it helping people to overcome anxieties? Is it an app to help dog owners diagnose their pet before seeing the veterinary? Then these values need to be representative of these user groups, and the scope of the problem or how they will represent the experience. These value propositions can be iterated upon, but they are important.
3. Set up a user in mind
Or a few users. Make use-cases describing the emotional background, the journey the user goes through and the main problems for this user. Set up how the product can help the user through a short journey.
4. Based on imagining your story: what will be the features of your product?
Start making P:s. yes, they are called P:s!
P0 — Absolute necessary features. These features are what the product needs to have to even be shipped.
P1 — Very important requirements
P2 — These requirements would be nice to have, but are not that important
P3 — The product can live without these requirements, but are great to add at later stages of the development
An example:
P0 — The app needs a landing page
P0 — The user should be able to connect with peers
P1 — The user should be able to pay as the user pleases
P2 — The app should be able to connect to other organizations and stakeholders
Divide these P:s into a list. Always come back to the list when ideating on for example screens or product components. It is a great way to prioritize and make sure that the whole team is on board on what needs to be done.
5. Create several wireframes and doodles.
Divide the wireframes into sections onboarding, search, browsing, customization, check-out or depending on the story you are trying to create. Decide on a complete or simple journey. They don’t have to be refined yet.
7. Set up mood boards and visuals.
(Can also be created by the lead visual designer within your team). Color schemes, choose your material design language, pictorial representations, and descriptive keywords, etc. In regards to the prototyping flow, it can be easier to make small “sketches” with random objects/layers in principle to practice making transitions/animations you will be using later.
9. Always reflect back and use your value propositions and P:s during iterations.
Is the “swipe away actions” really the most important thing for the user, if the app should be representing community building?
If the app is about community building, then maybe the app instead should lure the user in to explore peoples stories, and linger on people profiles to extend personal relations? These are the kind of thoughts you should be having throughout the design process while working through the priorities and coming back to the values of what you are trying to create.
Reflections
By following this type of process, a very successful and rapid prototyping week came to its end. Using this, it was extremely simple to manage the team - and division of tasks.
We have all experienced that working in a team can sometimes seem very hard, but when we used this method, we actually managed to apply a system on how to work together efficiently like never before.
One thing that was missing for us was the ability to work on the same files inside Principle and Sketch. To conquer this issue, we tried to plan the grids, fonts, visuals as much as possible. We tried to adopt the kind of systematic thinking to be able to make the final app flow as cohesive as possible.
It was very easy to manage the team and division of tasks using this “Working backwards — approach” and the final experience became surprisingly seamless and unified.
Here is an initial screen of the final result rom our new food delivery concept- SNACK in a bowl delivered in the city of Umeå, Sweden.
Working in a team, IXD -19, @ Umeå Institute of Design: thanks to Klio Rapakoulia, Borut Kerzic, Nicole Waniowska, Zhi Wang, and Mehek Sharma.
