Remote Design Sprints
Making meaningful progress with distributed stakeholders
Imagine your team has a big problem to solve and a brand new product to be built from scratch. The expectations are high, there are diverging opinions among stakeholders and you don’t have much margin to make risky assumptions. Besides that, your team and stakeholders are continents apart from each other.
In our case, Porto Alegre (Brazil), Austin and New York. The client is a SaaS startup that is disrupting the real estate industry in the United States. So our job was to make real estate agent’s life easier when it comes to selling or buying a property.
If we started building the MVP without getting enough feedback in the early stages, there was a high probability that the product wouldn't solve the real problems (the classic scenario).
Failure is expected and healthy for every product. The problem is failing too late.
At Ambush, we implemented Design Sprints at the start of any project. We are constantly tweaking and tuning it. Having a structured step-by-step process, to validate and test ideas, ensures that we have design thinking present in the product development process.
In the case I'm sharing here, we built the product MVP from scratch in 3 months using Design Sprint as a game changer in the kickoff phase.
As usual, I learned so much during the process:
The Challenge
Brokerages have tremendous costs to create and print marketing materials to publicize properties. The workflow is slow and they are dependent on middlemans to get marketing pieces ready. It was a nightmare for real estate agents to come up with great layouts of marketing pieces (online and offline) that could possibly help them selling properties.
They needed a tool to make the process of designing and printing marketing collateral effortless for real estate agents. Giving the ability of an advanced design tool to both novice and expert users.
How to get client buy-in?
It’s crucial to create a good relationship and build rapport with clients, especially if it’s the first time they’re in contact with design sprints. Remember that outside of our design/product bubble, most of people are not aware of the hype around processes and tools.
Avoid the curse of knowledge assuming that everybody knows what design sprints are.
Show the power of design sprint. It can possibly save months of development into an idea that just doesn't work. Also, it's a great alignment tool to get things on track since the kickoff of the project.
Setting the right expectations
Here's a quick checklist, to help you to set the right expectations before start sprinting:
- Explain every little detail of the agenda
- Explain what do you expect from them (their roles)
- Reinforce that the prototype is a facade of the product
- You won't solve the entire problem in one week
- The prototype can fail in many levels, and it's a good thing to do it fast
Most importantly, explain the relationship mindset: You'll work with the client, not for the client. Collaboration is all about combining everything they know on their domain with our expertise to solve problems and build great products.
Crafting the process
It might sound controversial, but I don't believe in design methods that are done by the book. Projects are different by nature. Different users, businesses, needs and contexts. Therefore, we cannot expect that applying the exact same process for all the problems is going to be effective.
First understand the user & business and then craft the process for this specific need. We need always to adapt it to attend all variables.
Before start sprinting, we had 3 calls with the client to understand their need. This way we were able to craft the process based on how deep they knew the problem and what was the business motivation behind it.
Design sprint was surely the best fit to kickoff the project. We did a quick start explaining how the whole process would work.
The Team
Here’s where the magic is: The more diverse the better.
For this design sprint we gathered:
- A frontend developer (Porto Alegre, BR)
- A backend developer (Porto Alegre, BR)
- Two Designers (Porto Alegre, BR)
- V.P. of Product (New York, NY)
- Real Estate Agent (San Antonio, TX)
The Agenda
We did a design sprint of 6 days. Here's why:
We had the problem of different time zones (we were 4 hours ahead of the client). To optimize the sprint week, we decided to kickoff the design sprint on Friday.
Understand
The client (VP of product) recorded a 30 min video showing how was their current system to help real estate agents. Also, he shared three similar solutions that they like/dislike in the market. It helped a lot to put the team into the context of their problem.
Lightning Talks:
We sent the client a script with questions to guide them during the exercise. Both (agent and VP of product) gave us 30 minutes talk about the short/long term goal, key functionalities, competitive landscape, and described in details three personas (based on real users).
During this process the team was fully committed taking How might we notes to build the foundation of the Design Sprint.
Ideate
Comparable problem (Homework):
Each team member brought ideas from industries related to our project, and gave a tour of their solutions.
Boot Up Note Taking:
We gave the team 8 minutes of silence to review and take notes about what’s been collected, based on the shared knowledge generated in the Understand phase.
Crazy 8's:
We started then the fast sketching exercise. Eight distinct ideas in eight minutes. The main goal here is to push beyond the first idea and generate the most different ideas possible.
Team members without a design background may be intimidated at this point. As a facilitator, pay attention to emphasize that the focus is on the ideas and not how perfect it's drawn.
After creating 8 ideas each, we shared and voted on the ideas that we most believed in.
Solution Sketch:
Each team member had 30 minutes to create a detailed solution sketch. At this stage it's great to combine your and other people's ideas into a new one. The goal was to create the best solution to be shared and voted one more time.
It's great to see the patterns taking shape, and what the team thinks are worth prototyping.
Prototype
Storyboard: To unify and consolidate the entire ideation phase into one concept. It helps to save valuable time of the team that can now concentrate only on executing the the prototype.
High fidelity prototype:
It was three intensive days of prototyping. Over 30 screens designed to make sure the main flow could be tested and validated by the client and final users.
To streamline and pair design the prototype, we used sketch + abstract for version control and invision to make the interactive prototype.
We were lucky to have, from the client side, a representant of the users and a product person within the sprint process. It was great to see their reactions throughout the entire week and specially with the prototype.
User Testing
On friday we presented the results and walked the client through the prototype.
As they the client had great knowledge product wise, they opted to be responsible to test the solution with end users in the following week.
After doing that, they sent us tons of feedback to be implemented into the solution to reiterate.
And what happens after the sprint?
By the end of the Design Sprint we got:
- A functioning prototype that validated the overall concept of the product.
- A ton of feedback from the users and a lot of learnings
- A clear path to follow
In the second week after the Design Sprint we evaluated and incorporated most of the feedback from users to reiterate with them. We call it the Iteration Week.
After that we got into the product development phase. Starting to actually design the UI, creating the design system, defining backlog and priorities and started the 2-week iterations.
This is how we married the design sprint with the product development process:
The results and learnings
The client is extremely happy with the results and how fast we moved. At this stage (3 months after the kickoff), we’re already testing the MVP in staging with more confidence that we're in the right path.
Besides that, I'm stoked about the relationship of trust that we created with the client. All the way through 3 months of development, the whole team was perfectly aligned with well defined priorities and crystal clear roadmap.
What would we do differently?
Surely the user testing could be done more carefully. Without our team participating actively in the user testing sessions, lots of subjective signals can be lost along the way.
Thanks a lot for reading!
Let me know your thoughts in the comments.
Cheers.
Special thanks to this awesome team:
Eduardo Javier, Daniel Antoniazzi Amarante, Gabriel Alves, Renan Vaz, David, Brian, Leo Sansonovicz & Diego Hainzenreder
