Wilbur and Orville Wright based their designs of the first airplane from countless hours studying birds in flight. They scrutinized the air patterns surrounding their wings as they flew and analyzed how they were able to keep control. They also gathered as many books as possible on the topic of birds – they even wrote to the Smithsonian Institution to borrow from their collection.
From the results of their findings, they then built kites and gliders to methodically test their learned assumptions regarding a bird’s flight. While testing the gliders, they photographed the flight to create a reference for their next prototype. One glider in particular preformed terribly and was considered a huge failure by both brothers. Through this failure, the brothers questioned some of their basic assumptions, namely The Lift Equation. Their findings from this particular prototype proved to be a big step towards building an airplane that was capable of safely carrying passengers.
Throughout their process, the Wright brothers were continuously learning what they were doing correctly as well as improving from their failures. Each subsequent prototype reflected this knowledge, proving better than the last. Even with competition from Samuel Langley, who had a larger budget and increased resources, the Wright brothers were still able to build and launch the world’s first airplane.
I enjoy the Wright brothers’ process because it can be adapted so well to the way we work at thoughtbot and is a great lesson on iteration. Conducting design research by studying birds helped the Wright brothers create a more complete understanding of the problem. Their methods and process, which resulted in an eventual working airplane, enforce the need for having a continual feedback loop.
Just like the Wright brothers, we need to have a continual feedback loop throughout the design and development process. This allows us to continually test our designs to validate new features and ideas. We learn valuable information from our failures as well as successes.
When discussing the prototyping stage for design sprints, we tend to focus more on the artifact, whether it is HTML or Invision, than we do on how the prototype should be used. It’s easy to miss the idea that the prototype is simply a talking point for testing in a user interview at the end of the sprint. The purpose of the prototype is to put users in front of the features we think solve the problem that we think they have and learn from the interaction they have with it. The real value isn’t built up in the artifact, it’s in the information we get after watching people use the artifact. We get to see if users accomplish the job-to-be-done better, faster, or easier than what they are currently using. If they can’t, we dig deeper to find out why is this. Do we have the wrong context and motivation? Or maybe the wrong pain point?
Even if we find out through testing that the prototype is a failure, our overall direction isn’t compromised. The Wright brothers proved that there is a lot of value in learning what will not be successful. It’s better to find out quickly that you are going in the wrong direction and learn why. It’s that learning that we get from the prototype that is of real importance.
