- September 27, 2012
One Small Step
On July 20, 1969, Apollo 11 landed on the Moon. A few hours later, Neil Armstrong and Buzz Aldrin stepped onto the lunar surface—the first time humans set foot on another planetary body. The astronauts were explorers. Yet, if they did not share their experiences, their expedition would have provided no meaningful benefits to anyone but themselves. True exploration isn’t just going somewhere or doing something new; it is experiencing something new and communicating that back to those who care.
As designers and developers, we are explorers. We thrive on investigating new ideas, approaches, and processes–whether our focus is an application, website, advertisement, or otherwise. We are the astronauts of our industry. But that means we need to be able to effectively express our experiences to the rest of our team.
The Importance of Sharing
While on the lunar surface, the crew of Apollo 11 set up equipment to collect data about the Moon. But the astronauts were not scientists; they were test pilots. They weren’t the ones who could extract meaning from their data. The people who were most interested in the data were the geologists, biologists, and astrophysicists back on Earth. The information the astronauts collected became useful only once NASA scientists had access to it and could study it.
Sharing your work with the rest of the team, with people who can then turn that knowledge into something productive, is one of the best contributions you can make. But, as we all know, communication can be hard.
During the astronauts’ stay on the Moon, they gave detailed verbal descriptions and collected a ton of data about the surface. When they returned to Earth, they brought with them almost 48 pounds of Moon rocks to give to scientists around the world.
Words alone are not always the most fruitful way to exchange ideas, especially when describing something visual or with complex interactions. Sometimes, the best way to communicate is to hand someone something physical that they can hold, use, and experience. Verbal description can leave a lot up to the imagination of the listener, whereas a hands-on experience can be clearer and more effective.
A proof of concept doesn’t have to incorporate any of your actual work, and it probably won’t be shippable. (In my own proofs, the code is generally quick and cringe-inducing.) Your proof of concept just needs to show that something works as expected or how something could come in handy for your team in the future.
Building is Easy!
I love that proof of concepts let you investigate new ideas in a completely sterile, sandboxed environment. There are no outside factors to distract or screw things up, allowing for deeper and more focused experimentation.
If you want to start building proofs of concept today, it’s easy: just starting coding! There are some awesome tools out there, like CodePen or JsFiddle, that offer fast setup and flexible configurations for building proofs of concept. Or, if it’s something you want to test across multiple devices in a pristine environment, you can host it on your own server (like I do).
Proofs of concept are incredible tools for exploring new ideas and, more importantly, for being able to share those ideas with your team. If a picture is worth a thousand words, a proof of concept is worth a million.
Have you experimented with proofs of concept? How have they improved communication and collaboration within your team?