Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
47 lines (24 sloc) 3.92 KB

Prototyping for Speed and Scale

With Carl Sziebert

Prototypes tell stories about the future. By leveraging a prototype we can paint a complete picture about how users engage with product. Prototypes are key when creating things that have never been done before. The reason we prototype is to test assumptions. So what really is a prototype? It's an early sample built to test a concept or process. It’s in a crude in form and should not have all the features of the finished product. Most importantly, it is a thing to be learned from. Prototypes help eliminate the subjectivity of the design review process and we can use them to get design consensus. With prototypes you can build "an enthusiastic compromise". By gathering feedback you can focus on the most important elements of the product and get quantitative data to aid the decision making process. This helps you avoid politics based decisions.

At Google they prototype across a range of modalities: sketches, papers, digital, physical. As UX engineers they're primarily working on native applications, so it’s important for them to choose the right fidelity for the prototype. In prototyping "the journey is the thing" and you learn by doing. To gain knowledge from an experience the learner needs to be actively involved, must be able to reflect, and must have good decision making and problem solving skills. Throwing away your work though can be difficult, but you also need to be able to embrace failure. Throw things away is an essential part of the prototyping process.

You will often want to start projects with low-fi prototypes. Even developers can draw boxes. Low-fi prototypes are great for bridging gaps in knowledge, and design speed dating helps chose from an array of options. Most prototypes however are at the higher fidelity ranges, and are created using tools like FramerJS. In addition to the product itself, you will also want to prototype your engineering tools, e.g. React, Angular, and decide which is best for the project.

The idea of design sprints originated from the agile framework. Sprints are used by large companies like Google and small start ups as a way to focus the group on the project at hand. In your sprint, try to scope your prototype efforts around immediate goals or else there’s a risk that the sprint goals will get out of hand. Ad hoc cafe tests (quick candid feedback from a small but diverse population), and A/B tests can be simple ways to validate prototypes. However, for stakeholder reviews, you’ll want to test the prototype with real data on real devices.

You want to work towards a thoughtful and deliberate design process. In the inspiration phase immerse yourself in the world of your users. In the ideation phase consider all possible solutions. In the implementation phase you’ll want to test them. It’s important to add in checkpoints in these phases to validate thinking.

Beware of common pitfalls when you prototype:

  • fixating on the artifact, not the understanding the problem

  • converging to a solution too soon

  • over engineering prototypes

Advice for would be prototypes:

  • Master your tools, but be a tool polyglot.

  • Keep a record of your progress with source control.

  • Project management tools can be useful for getting feedback

  • You can easily get feedback with ad hoc testing, simply offer someone in line at Starbucks a free coffee to look at an app!

  • Measure success. At Google they use OKRs to capture goals and define success metrics.

  • Keep in mind Brooks' law, "adding resources late to a product life cycle will cause it to be delayed even more".

  • Invest in active listening.

  • Establish context for reviewers.

  • Make room for "palate cleansing" projects to clear the residue of project grind.

  • Have empathy for the user and be technically selflessness.

GOAL: Engineering in support of/to drive great design.