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.

For more about how we work and think, try Why consumers are just not that into your brand and How to structure your culture for innovation.

Photo Creative Commons Licence courtesy Gordon Ednie.

  • http://www.ignaciogiri.com Ignacio Giri

    I’m having a problem right now. I’m building this prototype for a website in HTML5/CSS3. Looking good. But the client only have IE8… what’s it’s the best way to approach this?

    • http://twitter.com/StuartKentNZ Stuart Kent

      I’ve played with Balsamiq before, which was good, you just link between mockups. It may not be as involved, but could still do the job.

      Otherwise, if the website you are creating will be using these technologies anyway, this is a good time to find out workarounds and fixes for IE8. A good question to ask is how much Javascript you want to rely on :)

      Hope this helps!

  • http://twitter.com/rosspw Ross Popoff-Walker

    Awesome post, thank you Stacey. Any chance you can share some examples of prototypes BS has done, or admires? Or a generalize approach and process you guys are using?

    • http://twitter.com/bitchwhocodes Stacey Mulcahy

      I think that will be a part two to this post :)

  • ADAM QURESHI

    I love prototyping! i can sit and look at it all day! ;-)

  • Pingback: Flying Magic Unicorn Pony

  • Pingback: Why Prototyping Matters! « Prototype A

  • http://twitter.com/ChrisGriffith Chris Griffith

    From one prototyper to another, great write up! Often my prototypes are a part of usability study, so they tend to be a bit complex to allow proper exploration of the app. But once I client sees the pay-off, they typically are sold on having a prototype as part of the design process.

  • Guest

    I personally have not found an ideal solution for rapid prototyping. With many projects where I developed prototypes using developers rather than software such as balsamiq, Axure, etc – cost is a factor – you do get specific functionality for your tests – so an investment is well spent in these cases. Notwithstanding – these are rare cases – where you may spend a deal on prototyping, and have been larger enterprise level projects, selling an idea, pitches. For rapid, and everyday use, Axure provides a great set of tools and functions but fails in responsive design for tablet and mobile (landscape/portrait). It fails to discern between accurate swipe and scroll (as of 6.5 it’s an undocumented problem – believe me I had to do a major workaround). Balsamiq although cost effective lacks other features, already common in Axure – you get what you pay for. I have been keeping a close eye on Fireworks CS6 as it seems to have some great CSS features and jquery tools natively – I’d love to hear from anyone with practical examples and reviews. As with anything, it depends on your goal. Approach your prototype with the question: what will this accomplish? Sometimes a high def prototype is not needed, if what you’re testing is actually a smaller component. I have had successes with pencil and paper so just focus on what you want and be flexible and nimble enough to use a toolset rather than a tool.

  • Tommy

    I personally have not found an ideal solution for rapid prototyping. With many projects where I developed prototypes using developers rather than software such as balsamiq, Axure, etc – cost is a factor – you do get specific functionality for your tests – so an investment is well spent in these cases. Notwithstanding – these are rare cases – where you may spend a deal on prototyping, and have been larger enterprise level projects, selling an idea, pitches.

    For rapid, and everyday use, Axure provides a great set of tools and functions but fails in responsive design for tablet and mobile (landscape/portrait). It fails to discern between accurate swipe and scroll (as of 6.5 it’s an undocumented problem – believe me I had to do a major workaround).

    Balsamiq although cost effective lacks other features, already common in Axure – you get what you pay for.

    I have been keeping a close eye on Fireworks CS6 as it seems to have some great CSS features and jquery tools natively – I’d love to hear from anyone with practical examples and reviews.

    As with anything, it depends on your goal. Approach your prototype with the question: what will this accomplish? Sometimes a high def prototype is not needed, if what you’re testing is actually a smaller component. I have had successes with pencil and paper so just focus on what you want and be flexible and nimble enough to use a toolset rather than a tool.