Skip to main content

Cognition

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.

Most of the time, believe it or not, the person on your team who cares most about your recent work is not you. If you’re a designer and you mock up a new form control or if you’re a developer and you build a new JavaScript plugin, your work does not become useful until you’ve communicated what you’ve built to your team. Developers need to know about that new form control you’ve designed in order to figure out how to make it function. Designers need to know how your new JavaScript plugin works so they can design a look that suits its functionality.

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.

Getting Hands-on

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.

Instead of explaining that new form control or JavaScript plugin to your team, build a proof of concept and show them. Don’t confuse a proof of concept with a prototype. A prototype is an early, working version of a product, typically used in its planning stages. A proof of concept is a standalone, one-off demonstration of a technology, technique, or implementation.

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.

I recently built a proof of concept for a JavaScript plugin that would create a sliding navigation panel on small screens. I built it to explore possible implementations, to see if it would be something worth putting time and effort into creating, to communicate its interactions to our designers, and to show our developers how it would work from a technical perspective. Being able to hand my phone to someone and show them what I had been working on rather than trying to describe it was incredibly valuable and helped to quickly validate (or invalidate) my ideas.

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?

Back to Top

comments powered by Disqus