July 30th, 2012
Try and Try Again – Why Prototyping Matters
If there ever was a unicorn in the digital agency world, that mythical beast would undeniably be the practice of prototyping. We talk about it, revere it, but for most, we’ve only ever witnessed it vicariously – gracefully crop-dusting the world with rainbows one retro t-shirt at a time. We try on clothes before we buy them and we test drive cars yet, when it comes to interaction, often a series of static images determines the nuances of what we make. We even expect clients to do the same.
We all communicate in different ways and often domain knowledge drives our default choices. Strategists deliver decks. Designers make atrocious mimes – describing animation sequences through calculated hand gestures augmented with sound effects. Developers love acronyms like a fat kid loves ice cream. And, if it’s not an Excel document, producers long for project GPS. We spend copious amounts of time trying to communicate effectively, yet frequently ignore one of the best ways to do it. We might not understand what you are trying to say, but we all understand something that we can use and experience.
For many, making prototyping an integral part of the project process is painfully new, made only more difficult by how disruptive it is. It forces us to re-evaluate conventional processes and deliverables. Let’s face it – it doesn’t exactly squeeze into the Spanx of line items gracefully like wireframing. Put the word ‘exploratory’ in front of pretty much anything and most people won’t sign up for it. ‘Exploratory’ is too often synonymous with ‘optional’. We’ve come to a point, however, where prototyping is not optional as it is the most effective form of communication in the project process and is too often neither seen nor heard.
The intent of prototyping varies as much as the approach. For some, the focus of prototyping is to mitigate risk – creating a proof of concept to discover limitations and prove possibility. For others, it serves to explore possible interaction models. Some people use prototyping-specific software. Just imagine, the modern digital “Inception” experience is actually within reach – there is a plethora of software available to prototype, well, software. Some people use the software that they know and bastardize it for the cause – Keynote comes to mind because no one willingly admits to intimate knowledge of PowerPoint. Others write code, while some embrace their inner organizational-office-supply-stealing self with the flexible lo-fi nature of the yellow Post-It note. Fact is, there is no standard or best practice, there is only the practice that works.
If action speaks louder than words, then prototyping must be doing the death-metal guttural scream right in speculation’s ear. Instead of spending time discussing possibilities, we can spend time actually making something work. The earlier you get to the trying, the better you can inform the design – from font choices and colors to advanced interaction and mental models.
Convincing someone – or many people (because plurality makes everything better) – that there is value in a process that may have no defined deliverable is no easy task. It becomes especially daunting when a deliverable or output is how we typically define each project phase.
We’ve learned so much from prototyping. People can look at a static design and understand the desired interaction differently. And then, when an actual prototype appears, people can quickly change their minds about previously held notions. Discussions become more focused and valuable because we have the intended context.
At Big Spaceship, prototyping is a fundamental part of our approach. From quick, self-contained one-offs to more complex interactions, we’ve embraced the process, elevating it from what many have considered a nicety to a necessity. A prototype’s value is in communicating the intended idea over code reuse and pixel perfection. Each project is different as are its requirements, and these variances mean we don’t adopt one systematic way to do prototyping. In evaluating the needs of the projects, often we find ourselves prototyping to answer questions that we can’t immediately answer. Can we do this? How would this work? These questions often pop up early in the discussion or creative process – so the need to answer them should be just as timely. Is our basket big enough for all those eggs we want to put in it?
Often, we find ourselves prototyping what we lovingly refer to as the “sauce” of a project. The sauce is that lil’ something that if it walked by on the street, would make you unabashedly look twice. It’s what gives the experience depth. A lot of time is devoted to “the sauce” through an iterative design process where prototyping is used to explore those nuances we love so much. For example, it’s not uncommon to explore the navigation system subtleties by doing several prototypes iterating on the original idea. Prototyping affords the opportunity for accidental discoveries.
Now the pragmatic part of me realizes that there is a deadline, a scope of a work, deliverables and this thing called a schedule. And, more importantly, it all actually exists. Balancing the pragmatic with the utopic requires what I’m told every loving relationship thrives on – compromise. The needs of the project determine the compromise. When a big blue box will suffice in place of the image with a custom-made channel reflection, then why do more? If edge cases don’t have to be accounted for, toss them to the side. If code re-use isn’t important, then there is nothing wrong with programming like no one is watching – just leave the sweatpants in the basement.
Prototyping is like that junker of a car you refuse to admit you once owned. It didn’t have to be pretty, it just had to get you from point A to point B and ideally do so without having a random stranger yell at you to replace the muffler. The same goes for prototypes: they are about getting the job done, and the job is to communicate in ways that words and pictures alone cannot.
Photo Creative Commons Licence courtesy Gordon Ednie.