Interactions > Images > Words
There is a natural progression in making software. You start with an idea and that imagined future, keystroke by keystroke, becomes something a machine can understand, and hopefully, something a human can understand as well.
If you’re working on your own, this process is freedom itself. You decide what to build, how it will look, and the steps to make it happen. If you’re unhappy with the result, you dive into your editor again, removing an incantation here, and adding another there, bringing your vision in line with reality, line by line, pixel by pixel.
When you work on a team, decisions become shared. Everyone has a role to play. One person owns the requirements, another the design, and yet another the job of bringing it to life through code.
With division comes a need for communication, and soon, artifacts to codify the decision, approach, and even how success will be measured. But I wondered, why all these steps? Why so much process? Somewhere along the way, the joy of creation is snuffed out under the weight of Google docs and Jira tickets.
“As far as the customer is concerned, the interface is the product.” - Jef Raskin
While we need a way to share a vision of where we’re headed, the traditional ‘requirements’ doc fails miserably as it doesn’t really communicate much of anything. The illusion of consent is worse than the truth of confusion.
Take, for example, the menu at the well-known restaurant, The French Laundry. Here is this weeks dessert selection:
If you handed these requirements to 10 chefs, what are the chances they each deliver what you have in your head? Is this what you imagined?
The issue with requirements documents is that they are disconnected from the reality we hope to deliver. They are words and we are delivering experiences. It stands to reason, that we should understand, as closely as possible, the desired experience before we code.
"Weeks of coding can save you hours of planning." - Unknown
This means striving to move up the hierarchy of understanding from words, to pixels, to prototyping as fast as possible. Of course, there are many reasons we skip this step and move to creation without clarity. For some it’s a mindset, others lack skills or resources, and yet more are managing looming deadlines (ie. it takes time)
The faster a team moves from words to a living prototype, the better the resulting product will be. This is one of the reasons we see a rise in the popularity of tools like Invision and Figma.
“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.” - Tom and David Kelley
Of course, there is a cost to this approach and not everything can or should be brought to life before being built ‘for real’. Nothing comes for free, but for most teams, the balance is wildly off.
The winning plan is to figure out the areas of your product that matter most - what is the core that demands an outsized effort. Once you know that, you have the areas you should over-invest in understanding the experience.
Focus there, build something interactive, share it for feedback, iterate, and do it all again - when it’s ready, you’ll know.
After all, what’s the use of shipping something no one will want?