Skip to content

Prototypes aren’t a deliverable; they’re a communication tool

July 19, 2011

Following up from the idea of a UX as a Facilitator, not just a Designer, one of the key UX tools that makes this possible is Prototyping.

To do this you need to break out of the mindset of UX generated designs being a ‘final deliverable’ and instead view them as a ‘communication tool’, which facilitate a step in the process rather than being an end point.

Prototypes in the world of UX

A prototype is ‘working’ interactive version of a concept that anyone can try, understand, and see how it would work. They provide a proof of concept that can communicate the solution in a concrete and tangible way. A prototype can be anything from a piece of paper folded a particular way, through to a clickable and polished simulation of a product. The most common UX prototypes are a usually series of static pages linked together.

Their key benefit is that they are low-cost to produce (compared to production code) and can be tested with real users to ensure that the concept and value proposition meets the target audiences’ needs. They can be iterated and improved quickly to get the concept right before more costly development begins.

Prototypes are a communication tool

It is important to consider prototypes (especially lo-fi ones) as a way of communicating a concept, not a final deliverable that is handed over. They never showcase the complete working functionality and usually require some form a narrative to be told when testing/presenting them.

Rather than trying to replicate the entire end-end functionality (that would make them the finished product), prototypes focus on demonstrating the key user journeys through the product, telling a narrative of what the user would experience and how the interactions would work.

With this narrative, they can be a very powerful tool, without it they can become confusing. They can’t just be thrown over the wall to a Dev to build. They need to be part of a conversation about what the experience should be. They work at their best in a collaborative environment.

I see them as a key step in moving from a Waterfall to an more Agile UX approach where there isn’t a hard handover point between design and development, but instead an ongoing conversation and collaboration.

Prototypes vs Functioning Code

There is always a healthy tension between how much effort should be put in to producing prototypes in non-production tools as apposed to just jumping in to coding up a real world working version.

I believe that the sooner that you get to code the better. It is after all the actual medium in which the product will live. And you can never truly test the actual real experience until you see how it will work for real. As much as I love playing around with paper and post-it notes, they are only a stepping-stone to get to the real coded version. And once you get to code iterating and refinement becomes far more efficient.

However, more often than not projects jump into code too soon, before they have tested, validated and tweaked the underlying value proposition.  Once code has been written these concepts become far harder and more costly to change.

As soon as code has been written it becomes an asset, making it far harder to throw away. In the early stages of creating a new product concept or just playing around with a new piece of functionality, lo-fi prototyping tools provide a great to play with ideas and explore different approaches, before one gets locked and set in to IT concrete.

Prototypes vs Wireframes

There is a gray area between what is a prototype vs wireframe. Although they are both created using the same tools and can use the same page content, there is an important distinction between the two:

An example of a wireframe describing and annotating what the experience will be. A prototype would demostrate how this would work in interactively which just can't be demostrated on this static page.

  • Wireframes focus on comprehensively capturing the page content and structure.
  • Prototypes aim to demonstrate the interactivity and journey through a product.

Wireframes function more as a requirements document, which can be used for getting stakeholder sign-off and then be passed on to Devs to build from.  Despite being more comprehensive, they are far from the best way to showcase the experience.  Prototypes are able to demonstrate interactively and visually what the experience will be like, whereas wireframes can only describe the experience. This is not to say that wireframes don’t have a place or aren’t required, but they have a different purpose.

  Prototypes Wireframes
Focus Interactions and journey through a product Content, page structure and functionality
Purpose Communicating the vision of what the experience will be like Creating a blueprint of the product for stakeholders to sign-off and developers to build from.
Benefits
  • A powerful communication tool.
  • Interactive and visual
  • Tell a story
  • Can be used for usability testing.
  • Can be produced rapidly.
  • Covers the product more comprehensively.
  • Captures requirements.
  • Provides more formal documentation.
  • Captures content, including copy and images
Primary audience Users, stakeholders and developers Stakeholders and developers

Choosing a tool

Prototypes can be made using many different tools, all of which have their various benefits. These are some of the common tools used for designing user experiences:

Low-fidelity:

Medium-fidelity:

High-fidelity:

The general dilemma when choosing a prototyping tool is which level of fidelity to work in. The general pros/cons are:

  Lo-fi Hi-fi
Time to produce Cheap and quick Time consuming
Look Rough & sketchy Polished & Final
Focus Proposition, Concept & Structure Interaction Design, Appearance & Usability
Usability testing Requires a guided narrative Users can complete tasks by themselves

The choice of prototyping tool selected should be based on the level of user experience that is being addressed.

If the product solution is new and the underlying concept/proposition is still being developed, then a lo-fi option is always best to begin with. The deliberately sketchy nature of lo-fi tools removes any focus on detailed page design and instead puts focus on the value the solution provides to users. It instead focuses on what should we build, not what will it look like.

A lo-fi sketchy styple prototype made in Balsamiq. This was made early in the process to test the concept before much time had been put in to design..

A hi-fi visually poished prototype of the same page, made in Omnigraffle. This was made later in the process after rounds of stakeholder input and usability tesing.

Once the solution has been confirmed as the right idea to progress with, higher-fidelity prototypes will allow for more detailed level testing which can iron out any interaction design and usability issues.

Recommended reading:

Advertisements
13 Comments leave one →
  1. November 23, 2011 1:46 am

    You’re quite right with this piece..

  2. Matt deCourcelle permalink
    December 6, 2011 8:55 pm

    I use gomockingbird.com for low-fi wireframe design, plus its free and available via cloud.

  3. Matt deCourcelle permalink
    December 6, 2011 8:56 pm

    and great blogs BTW!

  4. December 8, 2011 2:24 am

    Thankfully some bloggers can still write. My thanks for this post…

  5. Triz permalink
    March 5, 2012 2:02 pm

    So how often do you work on a project where you start designing in Balsamiq for early concepts then move to Omnigraffle to design in high fidelity?

    I wonder about the efficiency in the time it takes to transfer the design from lo-fi to hi-fi. Any thoughts?

  6. March 9, 2012 2:12 pm

    Rarely. One of the problems with lo-fi tools such as Balasmiq is that you very quickly reach the limitations of what you can design in them. I only try to use them to quickly validate an idea/proposition, and not detailed interactions.

    I’ve always find that if you spend more than a couple of days using them then they start holding you back. After that you’re better off using a heavier weight tool in the long run.

    The only time I’d ever really make a transition from a lo to hi fidelity design tool is if an idea was validated and then we needed to launch in to a more detailed design phase. And even then I’d always be trying to get to working code as quickly as possible so would be aiming not to do that much detailed wireframing anyway.

  7. October 14, 2015 2:53 am

    Reblogged this on HAO UX.

Trackbacks

  1. Ship Better Experiences with a Lightning-Fast UX Workflow
  2. Ship Better Experiences with a Lightning-Fast UX WorkflowFree Internet Tutorials | Free Internet Tutorials
  3. Ship Better Experiences with a Lightning-Fast UX Workflow | MotionBump Reader
  4. Ship Better Experiences with a Lightning-Fast UX Workflow - The Infinite Studio
  5. Ship Better Experiences with a Lightning-Fast UX Workflow | web Design & web Development & web Host
  6. Ship Better Experiences with a Lightning-Fast UX Workflow | Tech Tips

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: