Frequently asked questions
I understand a "prototype" will be created during the sprint. Will this be production-ready? Can I hand it to developers?
This is the biggest difference between a UX design phase – which, in Agile teams, can take the form of literal one or two-week sprints – and the formal design sprint methodology as pioneered by Google Ventures, on which our methodology is based.
The model we're talking about is an interactive workshop (a Sprint 0, if you will) to help define a new product or improve an existing one. The outcome of this workshop is not a production-ready prototype; rather, it's validation for a proof-of-concept, rapidly designed in a day, and only complex enough to mimic the proposed features or functionality you want to validate with end users. The point is not to rapidly create a final product in a day – which, let's face it, is impossible and risky, since users might not understand or want the features you're proposing – it's to validate the value of that product concept in a day (which, thankfully, IS possible) before you waste time and money on full design and development.
We often use Sketch and Invision to design rapid prototypes, but sometimes they can be created in Keynote or Powerpoint – or, if your project is already committed to a specific platform (e.g. Sharepoint, Salesforce, AWS, Tableau) we can bring a trained front-end developer to the sprint to work with our UX designer in creating a rapid prototype in that native environment. For some clients, we do extend our prototype phase to 3-5 days, allowing us to design a few extra features to test.
Only after user validation do you move into a full design phase, where the prototype is refined and visual styles defined. Technical architecture would also be defined in this subsequent phase. We can run this part for you, or coordinate hand-off of an improved prototype to your design team or preferred agency.
Do I need to know in advance which platform I want to use for my product, before participating in a design sprint?
Not at all! And in fact, design sprints are typically platform agnostic. While this doesn't mean that you're not "allowed" to already be committed to a platform like Tableau or native iOS, we find that a design sprint can be most helpful when the technology isn't yet defined. In these cases, the proof-of-concept prototype we test with users will be generic enough to get useful feedback before a specific platform is selected. The emphasis here is getting clarity on which features and functionality are most essential for your users; selection of technology should follow this determination. If you already have made a commitment, or are improving an existing platform, that's fine too; we take limitations into account during sketching activities, so we won't design solutions that are impossible to put into production.
How will deliverables from the sprint inform my product roadmap?
We work with clients to make sure our deliverables will be suitable for your next phase of work, and any features we design and test during a sprint represent what the group feels will be most important to users, and have the highest ROI for your business. Coming out of a sprint, we summarize which features and functionality tested well, and which might be superfluous or relegated to the backlog. As part of our final report, we often draft user stories – defining the specific tasks users users should be able to accomplish – written in a specific syntax that is helpful to development teams. You will come away with a solid understanding for which features are most important to users; these should make it into your initial release at the determination of your technical lead.
Could this work for service design?
Yes! In fact, the original model by Google Ventures was conceived as a design-thinking approach to unpack ANY problem – whether to determine a strategy, a service design model, or a product.
Are you a sandwich shop having a problem with long queues and frustrated customers? The same methodology we use to understand the customer experience can be applied to this service design challenge, and the solution might be a product (in this example, a kiosk ticket system), a different POS configuration, or a physical reorganization of the shop, changing the way customers wait in line. In these situations, our "prototype" – if no product is involved – can often be the redesign of a physical space, or even a new marketing strategy tested (ideally in situ) with the target market.
Everything sounds very product-focused. Where does human-focused research and planning come in?
This is a real comment we got after explaining design sprints to a client. It took us by surprise, because the design sprint methodology is entirely human-centered. We start the sprint by unpacking and understanding the problem from both the business and the customer/user perspective, and recommend spending a portion of the day interviewing users directly as a group to validate and expand the experience map we've created. If very little is known about user behaviors or preferences in advance, Slalom will do more of this research upfront, in advance of the design sprint. And any solutions the group designs must be validated by 5-7 target users through testing sessions before you can confidently move forward committing them to your product roadmap. Really, all aspects of our process are user-centered; in other words, human-centered – focusing on the humans who will ultimately adopt and evangelize your product.
What usually happens after a design sprint?
We end the sprint by giving you a summary of all material produced, findings from user testing, plus recommended next steps. Sometimes a sprint can be followed by an additional sprint to define a new feature set as needed; sometimes more user research or market research is needed to make sure the problem you're solving for your users is the right one, and with the right approach. Though in our experience it has rarely happened, you might have to completely change your original idea and start over if your solution was invalidated by users. More often, you move into a detailed design phase, during which the rapid prototype produced during the design sprint is improved based on findings from user testing.
At this point, technical feasibility needs to be assessed, and a specific platform or technology is chosen. Prioritized user stories are then finalized in coordination with a technical resource, describing every feature and functionality in the more detailed prototype. We also recommend another round of user testing to validate your changes are approved by users. A visual/UI designer will likely be engaged to help define visual styles, in coordination with technical architects and developers.