One day in the early 1980s, the computer scientist Danny Hillis was having lunch with the Nobel-prize winning physicist Richard Feynman. Hillis mentioned that he was going to create a startup, with the goal of building a parallel computer that had a million processors. In typical Feynman fashion, the physicist responded that it was “positively the dopiest idea I ever heard.” But he was intrigued, and by the end of lunch had agreed to spend the summer working at the company.

During the first few months on the job, Feynman worked on the router circuits. These would allow the processors to communicate and were far more complex than the processors themselves. The routers—tasked with ferrying information from point to point—had to find a free path through a 20-dimensional traffic jam between the processors, or hold the message in a buffer until the path was clear. A critical question was whether the design had allowed for enough buffering to operate efficiently.

Feynman began studying the circuit diagrams and was willing to listen to explanations of why things worked. But he far preferred to use pencil and paper to simulate the action of each circuit and figure out things for himself.

‍

Feynman began studying the circuit diagrams and was willing to listen to explanations of why things worked.

Feynman’s work on the routers helped the team discover the potential of the computer—which they had dubbed the Connection Machine—for complex numerical computing and physical simulation. This was useful for modeling things like the behavior of fluids and the simulation of artificial life, programs which other computers of that era were not designed to perform efficiently.

Establishing a ToC framework is an initial step towards ensuring that your corporate giving is outcome-focused, meaning it is centred upon creating impact instead of responding to impulse. Undertaking the ToC process enables your organisation to have crystal clear clarity around:

1. (i) The outcomes desired;
2. (ii) How they will be achieved; and 
3. (iii) Through what level of investment.

The benefits of undertaking the ToC process are wide reaching and are summarised below.

Embarking on a Theory of Change process:

1. (i) Forces an organisation to be disciplined in clarifying the overarching impact it desires and the tangible outcomes it seeks to achieve.
2. (ii) Allows organisations to identify where course corrections in programmes or grant making may be needed. 
3. (iii) Assists with resource allocation and provides a comprehensive picture of the investments needed throughout the giving process, be them financial, human capital, or otherwise.

Historically, the ToC framework was utilised predominantly by organisations that interfaced directly with beneficiaries including non-profits, major donors, and other community or development organisations. The ToC is now more widely adopted by grant-making organisations as a mechanism to provide greater insight into the inputs and outputs of their giving. 

The team had initially assumed that their machine would not be capable of these types of number-crunching calculations, but Feynman argued that the assumption was worth challenging.

To settle the argument and find out how well these computations would work in practice, Feynman had to create a prototype program to run. He was only really familiar with the programming language Basic, so he made up his own version of Basic that would run on the parallel processors. He would write the program, and then simulate it by hand to estimate how fast the Connection Machine could run it.

Feynman treated these challenges like a game, starting with very basic questions like, “What is the simplest example?” He would then continue to ask questions until he had boiled the problem down to something he thought he could solve—which he would attack with pencil on paper.

Feynman’s contributions eventually helped the company become a leader in parallel computing, generating tens of millions of dollars in revenue.

When Hillis reminisced about his work with Feynman, he realized that in almost everything they collaborated on, they were amateurs. From neural networks to parallel computing, they didn’t know what they were doing—but these things were so new that no one else did either.

By distilling complex problems down into simple ones and using prototypes to answer critical questions, they were able to drive innovation that even they themselves didn’t know was possible.

Prototype like a physicist

Although Richard Feynman was a physicist and not a product designer, he intuitively understood the power of prototyping. Prototyping helps us learn, solve disagreements, and test ideas quickly and cheaply. Feynman began the design process with sketches, which helped him understand the problem and identify critical questions that the prototype needed to answer.

Building a prototype gave Feynman a chance to settle the argument he made for the capability of the Connection Machine to solve complex calculations. Without it, he and his colleagues might have sat in front of a chalkboard, endlessly throwing equations at each other and citing research papers.

Finally, instead of taking the time to teach himself a more complex language, he used familiar tools to quickly build a program which simulated the efficiency of the machine. If he had failed at this point, it only would have cost days or weeks instead of months.

Framed in this way, it’s clear why design-driven companies prototype early and often, throughout the design process, to create better products. In the remainder of this article, we’ll look at a case study where Uber prototyped to help them build better products for multilingual use, and we’ll run through some techniques that can help you and your team instill a bias towards prototyping from the beginning of the product design process.

Case study: Uber goes international

The reason that these prototypes are really useful is that when we don’t have a live product built, but we need to get feedback, we can send them to researchers on the ground … it allows us to get feedback not just from drivers in San Francisco, but from all around the world.
— MOLLY NIX, UBER

Uber, the increasingly ubiquitous ride-sharing service, boasts some impressive statistics. As of the writing of this article, 1+ million Uber drivers—or “driver partners,” as Uber prefers to call them—had given more than 2 billion rides to more than 8 million users. No matter what destination you travel to, you’re likely to find an Uber driver—they’re present in more than 400 cities in 70 countries.

Designing Uber’s app to work seamlessly for the drivers and riders in this multitude of countries offered a unique set of challenges. There are differences in language, of course, as well as with symbology and wireless access speeds. All of these variables had to be taken into account as Uber worked on a ground-up redesign of its driver app in 2015.

The team began with lightweight prototypes of the app in English, using Sketch and InVision. As they worked through these flows, the team had to also take into account their global audience, so they would go back into the Sketch files and update the languages to reflect Hindi or Chinese versions of the InVision prototypes.

With prototypes in hand, the team could test with users in each country and begin to answer critical questions about where the app might be confusing or fall short of an excellent user experience for the drivers. They began with the navigational structure. What were the important functions to drivers, and how should they organize the content of the app? In the evaluation phase, they asked whether terms like “earnings” and “ratings” would translate appropriately into the other languages.

Along the way, they made some interesting discoveries. For example, one of the icons for Earnings was a bar chart, which represented what the Earnings screen looked like when you tapped into it.

However, when they tested the prototype in India, drivers there thought the icon would take them to network settings. High latency and slow speeds kept the network at top-of-mind for Indian drivers—and the Earnings icon closely resembled common signal-strength icons you might see in the status bar of a smartphone.

This discovery allowed Uber designers to alter course and create an icon more representative of cash, which solved the problem before it had a chance to crop up in a live product.

Another discovery, also related to the low speed networks, was the scenario in which a driver was starting their shift and going online to begin accepting trips. At this point, the team had moved from low-fidelity prototypes, through higher-fidelity interactive and animated prototypes, to early functional builds.

In these initial builds, there was no feedback to the driver after tapping the button to go online—just a delay while the app called to the server to verify that the driver could accept trips in their current area.  To the driver, the app appeared frozen.

In this case, adding an animated transition, which normally might be considered non-critical “polish” of the app, was critical to its function. The animation resolved this problem and improved the user experience for drivers.

One important thing the Uber team did throughout the design process was match the fidelity of their prototypes to the questions that they had to answer. Early in the process, low-fidelity prototypes were used to get a better handle on how the product translated into other languages. As the product direction solidified, higher-resolution, functional prototypes ironed out some of the potential user experience roadblocks.

Prototyping earlier

As a designer, you’ve almost certainly built prototypes of a product before releasing it, but you may be looking for ways to insert prototyping earlier in your process. When considering the fidelity of a prototype, it’s always important to consider the kinds of questions that you’re trying to answer and to be cautious about interpreting the results of testing very low-fidelity prototypes with users (see Daniel Burka’s sidebar about prototype fidelity).

That said, if you are working out the flow of a new feature or trying to communicate ideas to team members, sketches and paper prototypes are completely valid ways of moving forward. Here, we’ll outline a number of techniques and ideas for moving prototypes to the beginning of your design process. Some can also be found in the Stanford d.school Bootcamp Bootleg.

The timeboxed prototype

Create a low resolution prototype of a feature that you’d like to test with your team, before investing the time to build a higher-fidelity version to test with users.

Challenge yourself to work quickly. Set aside an hour and create 2–3 variations of the prototype. Screens can be sketched by hand, captured on a smartphone, and brought into InVision to be made interactive. Alternately, you can use the Prototype on Paper (POP) app.

Prototype to decide

Settle an argument amongst your team about what direction to take a product or feature.

Just like Richard Feynman and Danny Hillis, your team might have differing points of view around the direction a product may take. To make a decision, build prototypes of the competing solutions.

If your users are going to judge, try to get to a level of fidelity that will elicit a genuine observable reaction from them—but don’t spend any more time than necessary. Distill the problem down as much as possible and isolate the variable you’re testing.

Wizard of Oz prototyping

Build a prototype faster by using humans on the back-end to save time and resources.

The music-streaming service Pandora has an almost magical ability to create playlists of the songs you like, just by rating a track or two with a thumbs up or down. The company likes to give credit to its Music Genome Project, which attempts to categorize all music by attributes (tempo, vocals, etc.) and then sort them using a complex algorithm.

Early on, however, the company realized it needed a human touch to make the playlists resonate with human ears. Much like the Wizard of Oz, there’s a human behind the curtain, categorizing and describing each song as part of the “algorithm.”

You can take advantage of this technique, too. If you’re building a chat-bot, for example, have a human on the other end supplying the replies until you better understand the needs of the user. Or if you’re trying to build an on-demand service (let’s say Uber for dog walkers), you and your team walk the dogs yourselves before you build out the infrastructure to summon actual dog walkers on demand. Tools like IFTTT and Zapiercan connect the services needed to build prototypes like this—pushing a button can simply send a text right to your product team.

Wizard of Oz prototyping allows you to learn a lot about how your users communicate before the commitment of writing any back-end code.

Related: Prototyping in Sketch with Craft Prototype

Prototype to teach

In 1986, 7 astronauts lost their lives when the space shuttle Challenger broke apart 73 seconds into its flight. In the aftermath of this tragedy, Richard Feynman participated in a Congressional hearing investigating the cause of the disaster.

In what has become a famous anecdote, he sat in front of the congressional panel and demonstrated what happened to the shuttle’s O-rings in the colder-than-normal launch day temperature. Using a glass of water and dropping a clamped O-ring into the glass, he showed how O-rings become brittle and inflexible when exposed to the cold.

Contrast this simple demonstration with the complex charts produced by engineers in an attempt to warn about the dangers of O-ring exposure to cold temperatures

Once again, Feynman’s ability to distill a problem down to its essence, and to create a prototype which tested his hypothesis, was critical to his ability to share this experiment. We prototype to learn—but we can also prototype to teach.

Challenge yourself to find new ways to insert prototyping into your design process—it might teach your team a fresh approach to a challenging idea. Sometimes the act of building is the best way to raise energy and surmount a problem. Just be clear about the questions you’re trying to answer and the level of fidelity you need to do so.

For many hands-on designers, prototyping is where the fun begins. And even though it’s the 4th phase of this Design Thinking framework, it can just as easily be a starting point (remember, the process is not always linear). Sometimes the key to good Empathy is sharing or co-creating a prototype with your users and getting feedback.

In the next chapter, we’ll talk about how to use these prototypes to test your hypotheses so you can channel your inner Feynman to overcome the problem at hand.