From Facade to Functional: Create your next MVP inside a design sprint
When I’ve facilitated design sprints in the past, I’m usually asked the question: What do we do with the prototype when we’ve finished our Sprint?
Normally, design sprint prototypes are meant to be temporary. They’re facades… created and constructed to gather valuable insights, opinions and perspectives from your target users and customers.
But what if the prototype your team builds… wasn’t temporary?
What if, in the course of doing your design sprint, you create a prototype that you can carry forward into an actual product build? Could your team create something that functions both as a testing prototype and a lightweight MVP in just a single day?
I think you can.
A couple of days ago, I watched a video on Chris Do’s The Futur, where Flux’s Ran Segall described how he used an online program called Webflow to service his clients:
“Webflow (…) was a game changer because it allowed me to build and execute on my own ideas, custom ideas and literally do everything. It’s not a drag and drop tool. You’re actually coding without writing code. You’re working with a UI, but thinking like a developer.”
Here were my main takeaways after watching the whole thing:
- Webflow creates clean code as you’re designing your interfaces.
- Webflow is hyper efficient. What normally takes a week to build can be done in a couple of hours.
- Designers can leverage style guides and integrated templates while developers can integrate exported code into existing legacy setups.
- Webflow drastically cuts down the amount of time spent on back and forth communication, allowing designers, developers and clients to make changes while looking at the same interface in real time.
- You can effectively reverse engineer websites and apps created by other designers in Webflow by opening them in their online editor (if a clone-able version is available).
“You can literally ‘stand on the shoulders of giants’ and learn the techniques of other design professionals. It’s like getting access to the PSD files of the Hollywood studios, or the After Effects files on the motion picture industry.”
Ran likes Webflow, a lot. He’s shown real business results with his own company, worked to secure a partnership to promote the product and recently launched a Masterclass to teach others how to use it for their businesses.
To be fair, the casual observer would argue that he’s incentivized to promote his point of view. There are other options like Wix and Wordpress that could work for different situations. I can appreciate and understand that perspective.
But given my impressions so far, I think the integration of a web-based tool for building responsive websites (like Webflow) into your typical Design Sprint prototyping process could fundamentally change the conversation of how product builds are begun.
While you wouldn’t be ‘faking it’ to establish realism for testing within a design sprint process, you’d effectively transform the value of a design sprint effort by starting the actual build of your concept during prototyping.
It would require a different type of team to support this effort. You couldn’t just take a handful of designers, researchers and representatives from each part of the business to make this happen. You’d need to be deliberate on the process you’d use to get the results you want.
You’d also need to prepare your design sprint efforts in an altogether different manner than you’ve done in the past. You’ll need even greater alignment with both business and development… especially when you’re attempting to integrate new code to an existing environment in a short period of time.
Here’s how I think it could work.
Preparation
The following are essential activities I recommend doing for any Design Sprint you facilitate and manage… whether your prototype becomes an MVP or not:
- Address the ‘why’ of your endeavor
A Design Sprint Charter is a perfect vehicle to have a meaningful conversation with stakeholders and customers. It’s typically a 2–3 page document, outlining the vision, mission, target audience and success criteria of your Sprint. - Align on the problem or idea you’re looking to explore
Alignment can take the form of a simple conversation, several discussions around the aforementioned Design Sprint Charter, or a complete workshop session filled with different processes to get to the root of the problem. New Haircut has a great series on problem framing that I highly recommend if you’re dealing with a complex set of circumstances. - Secure time commitments from the right people
You’ll be organizing a particular group of individuals for your Sprint Team (see “The Sprint Team” below), and you’ll need their full commitment to the effort. Don’t shortcut this one. Get the right people in the room. - Schedule subject matter experts (SME’s) and user test participants as far in advance as humanly possible.
Between cancellations, no-shows and technical difficulties, this is one area of preparation that never fails to be an achilles heel for facilitators and design sprint teams alike. Always prepare with discipline and intent. - Align Design and Development on Webflow’s capabilities
Both Design and Development should be familiar with both the programs’ capabilities and the Webflow editor. They’ll need to examine the design system/components/generated code from the Webflow prototype and its’ integration with the company’s existing codebase. Constraints would also need to be factored into the prototype build for proper handoff of completed code to the Development team.
The Sprint Team
- Senior Designer:
You’d ideally want someone who knows their way around a web-based tool like Webflow AND can flex in either Figma or Sketch. Having front-end coding knowledge helps but it’s not a deal breaker. - Researcher:
Never leave home without a researcher who knows their craft. In Design Sprints, they’re invaluable for testing and knowing the prototype. - Senior Developer (2):
In my experience with tech-centric sprints, having at least 2 developers in any design sprint provides a proper foundation to validate execution and ensure a better handoff. - Decider (2):
I believe it’s better to have two deciders instead of 1. Ideally, they should come from two different parts of the business, and cover for the other if one has a time conflict (which always happens)
The Sprint Team Bench
If you’re unfamiliar with the concept, a ‘Bench’ is a holding area for resources to join your Design Sprint when needed. A DS Bench is usually employed during storyboarding and prototyping, but your needs may vary.
- Junior Designers/Developers
If you have some folks who are looking to learn their craft or get some reps in, Design Sprints are fantastic opportunities to get new blood involved. - Subject Matter Experts (SME’s)
Why restrict their involvement to expert interviews? Sometimes a quick 5–10 minute phone call or Slack chat can clear up confusion or provide direction can save hours of time. - Content Strategists
Nearly always overlooked and undervalued, a good content strategist can really make your copy sing. They can provide a healthy narrative throughout your prototype’s experience, ensuring your message and value proposition is heard loud and clear. - Technical Analysts / System Architects
This role may vary by company, but folks who are familiar with the down-stream data dependencies of your legacy systems and how things interact with one another. Usually great to consult at the very beginning of your prototyping session.
The Week of the Design Sprint
If you’re good to go, here’s a short breakdown of each day. For reference, we’ll be following AJ&Smart’s 2.0 Design Sprint process.
Monday
Per the schedule, you’ll be defining the challenge before lunch. Expert interviews, How Might We’s, Long Term Goal + Sprint Questions, and eventually making the Map. No real fundamental changes here.
In the afternoon, you’ll produce solutions via Lightning Demos and The Four-Step Sketch. Usually if you’re ahead of schedule, you can also start the Sticky Decision, but it’s not a big deal if you don’t.
Tuesday
Tuesday is when things are altered slightly. You’ll have your Sticky Decision session in the morning where your deciders will decide what to storyboard and prototype going forward.
After lunch, you’ll change things up a little. You’ll still be doing a user test flow and a storyboard to go through the experience of what you’re prototyping. But you’ll be adding the following activities to prep for Wednesday:
- Set up the default framework (mobile, tablet, desktop) within Webflow.
- Set up the Webflow CMS (if needed and necessary)
- Create a series of blank pages corresponding to the main storyboard/user test flow that gets generated in the afternoon.
- Plan out your milestones and deadlines for the day; where should the team be by lunchtime on the build? What screens absolutely have to get done for the prototype to reflect the user flow/storyboard?
- Identify potential areas for expansion in case you get way ahead in your prototype build (which does happen).
- Give everyone a job to do for prototyping day.
That last one is important.
A lot of times on prototyping day, you’ll sense that creeping feeling of drift.. Some members of the Sprint Team will start adopting an attitude of “Oh, I’m not a designer or developer. I can shove off and browse Instagram!” or “I’ll just go over here and put in a few waivers for my fantasy football league. They won’t miss me…”. Some of them go for a 3 hour bathroom break.
As the facilitator of the Design Sprint, you’ll need to apply some ‘tough love’ and get people pot-committed to the effort they started. No excuses.
Deciders can work with the Researcher to fine tune the interview scripts and start laying the groundwork for what happens after the Design Sprint ends (presentation, report, continued build activities, etc.) Another team member can manage the Bench. Yet another can reach out to user test participants and set the stage for Thursday’s interviews.
It’s extremely important that each person has a job to do and knows exactly what they’re on the hook for. If you don’t combat laziness and apathy early, you’ll be scrambling to finish the prototype by day’s end.
Wednesday
If you’ve done your due diligence, Wednesday should be all about execution. I’d recommend the following to move things along.
- Timeboxing: Using a Pomodoro technique or other methods to define working and rest periods helps keep the team focused.
- Broadcast Progress: I’d recommend running a Zoom, WebEx or similar group session that broadcasts the designers/developers laptops that are working on the prototype. Restrict visual access to the Webflow Designer, and your stakeholders can see their progress in real-time.
- Library Rules: People who are disengaged from a prototyping process can easily forget that loud talking or regular conversation can disturb designers and developers that are trying to concentrate. Enforce Library Rules to keep work periods focused.
- Kanban Board: I’ve been using Kanban Boards more and more during my own design sprints and prototyping engagements. They’re a great visual for knowing how much work has been done and what’s being worked on. We can also put finished pages through some quality assurance and track that for updates. Digital Kanban boards can be shared with online for checking progress during the day.
- Order lunch delivery: It’s the right thing to do, and it keeps the team focused on the prototype build. Having everyone break for lunch is a recipe for lost time and focus. Herding cats and keeping people after 5:00 pm are never activities you want to manage on prototyping day.
Thursday
If your prototype works as expected, it’s time to see what your customers think. No real changes here. Only difference is… your prototype has real code powering it from the backend.
I’d recommend using a scorecard to keep track of participant reactions to your prototype and how it tests against your long term goal and sprint questions. Voltage Control’s Design Sprint Scorecard is an excellent option.
This is also a day where Developers tend to disappear. They have huge dependencies with other work they need to get done. However, if you have their full commitment for the week, they should take the day to prepare the codebase and/or environment for a planned handoff of the prototype.
Friday
How did it go? What did everyone learn? Hopefully you’re addressing these questions in a nice retrospective over lunch + adult beverages with your Sprint Team.
At this point, your situation will likely fall in one of these scenarios:
- Scenario 1: Your prototype was a huge success
If the majority of your customers liked the core concept of your prototype, you’re in great shape. You can set up an iteration sprint to fix any problems or issues that came up during testing, or start projecting your development cycles based on the work that was done during the design sprint. Either way, you’ve just saved your company a ton of time by building out the beginnings of a viable product. - Scenario 2: Your prototype was a mixed bag
If your customers had mixed reactions to the prototype, it’s a judgement call. Were the issues uncovered during testing functional or foundational? If it’s the former, I’d recommend an iteration sprint to get closer to the ideal. If it’s the latter, your prototype will have to be iced until those higher level alignment conversations can take shape. - Scenario 3: Your prototype was flat out rejected by most participants
Well that sucked! Your prototype may have fallen short with your user test participants, but your team is far better off than they were before. You have informed alignment, learned a ton about the problem space and have a re-usable prototype you can leverage for future design sprints.
But wait, there’s more!
If you’re interested in learning how to integrate Webflow into your next design sprint, here are a few resources I referenced while writing this article:
- Robert Smith:
Webflow for beginners / Introduction to Webflow - Ran Segall and Flux:
Why use Webflow? and What websites can you build with Webflow? - Pablo Stanley / Sketch Together Live Workshop:
Creating a simple landing page with Webflow and InVision Studio
That’s it! Thank you for your time!
I’d love to hear your thoughts and comments on what I’ve presented here. Feel free to leave me a message and challenge me on the ideas I’ve presented, or add to the narrative with your own perspective.
If you’d like to collaborate on design sprints or need some help facilitating them in the future, you can DM me Instagram or Facebook.
Till then, I hope your Design Sprints are successful AND productive!
Shoutout! — My sincere thanks to Tahir Aziz, Chris Sywassink and Alex Ornelas for reviewing the article and giving their perspective and insights.
