From the course: Learning Design Thinking: Lead Change in Your Organization

Prototyping fast and often

From the course: Learning Design Thinking: Lead Change in Your Organization

Start my 1-month free trial

Prototyping fast and often

- Experiences are experienced. Designing an experience in words, on post-it notes, on a whiteboard or in wire frames will never explain the experience as well as an experience of it. Prototyping is in essence sketching an idea in time and form, both physical and digital. Like a sketch on a whiteboard, they are disposable and changeable, but nothing puts your ideas to the test faster than making them experienceable. What prototyping will mean for your industry can vary widely. A prototype for an app might be a strip of paper with screens on it encased in a mock-up of a phone to get quick feedback. While for an oil and gas product, it might mean modeling a substation in Legos to facilitate a conversation between potential partners. For something as abstract as insurance products, prototyping might mean trialing a new underwriting approach with 10 brokers using just a storyboard. Even those these examples are very different, the common goals are to swiftly learn from interacting with the prototype, to share it within the team and with real people, and to be able to quickly adapt it with what you've learned. Similarly, what prototyping means throughout your iterations will change as you refine the concept towards a market launch. For example, that prototype app might first be paper screens, but as the concept is refined further, it might become simple wire frames that let people explore the interactivity more. Effective prototyping is about selecting the information you need to learn about right now, in this iteration, and creating an expression of that at only the level of fidelity needed to get you enough information to inform your next iteration. Because of this focus on what we need to know now, prototyping comes in many forms, from paper and performance to highly refined experiences. Prototypes generally go from open to specific. Teams iterate quickly through prototypes and each iteration tends to bring greater specificity to the work as the concept moves from an early exploratory stage to deeper conceptual modeling and eventually onto the highest levels of specification before the go to market realization begins. At Frog, we generally look at prototypes as serving three purposes. The first is framing the iteration. The need to decide which question to prototype is core to the process of aligning the team to what's important in this iteration in order to best advance the design. The second is learning from others. Prototypes enable us to engage people and stakeholders in the experience to give us immediate feedback on the ideas. The third is refine and make. Defining what we learn from making the prototype and sharing it with others helps us be clear about the decisions we've made and to be able to communicate the evolution of the idea within the team and with our stakeholders. Getting good at prototyping requires a clear eye for what is just enough for the prototype to explore. Often, teams are tempted to put everything into a prototype, believing that the stakeholders and people won't be able to see past the gaps into the core experience. The very sketch nature of prototyping helps this. You'll find that someone in your foam core mock-up of a retail environment will easily accept the pretend environment and imagine themselves in a store and focus on the elements you have mocked up with greater fidelity. If your mock-up is a hand-drawn interface with a marker beside it, you'll find people are often very willing to make their own thoughts tangible for you. If your team gives into the temptation to take just another two weeks to get everything in, you'll find the process of quickly iterating ideas slows back down to a business as usual pace. If you take little else from this course, I hope that you take the intention to make light, fast prototypes and share them with others as fast as you can. I'd urge you to reduce your presentation decks in favor of walking your stakeholders through these experiences. Put them in the user's shoes and let them experience your ideas. Your stakeholders will understand the ideas better. Your team will be better aligned on what you're making if you do this. You'll tend to make products and services that are more meaningful and desirable.

Contents