A prototype is worth a thousand words

Leigh shares some thoughts on why a functional prototype is worth a ten thousand word specification.

Steve Job’s once said:

“Design isn’t just how it looks, Design is how it works”

Wireframing is important.  I don’t think I need to labour the point about this, Its something most designer folk involve themselves with at the start of the design process.  If you don’t, you really should.

Most of the effort in wireframing is gathering together the outline of what will be on each page and where it will sit within a page hierarchy, we create a blueprint for our website when we wireframe.  Equally of importance, however, is the interaction design on each page,  between pages and how the site is navigated as a whole.  This is when we start to think beyond isolated wireframes.

Wireframing - the blueprints for your starship

Wireframing vs Prototyping.

When we start to move beyond single page wireframes and begin to demonstrate interaction we start to build low fidelity prototypes.  A prototype reveals how the site will be used, how it will be navigated and how the interaction features assist navigation and the overall experience of the site.

Planning with a prototype

I like to build the main sections of a website as a working prototype near the start of the project.  During this process a lot of thought is put into the whole framework to ensure no stone is left unturned.   The  prototype poses a lot of questions and demands answers. It challenges the designer to get stuck in and problem solve at the planning stage where they belong.  Building a prototype prevents assumptions being made and important decisions being overlooked which will inevitably reveal themselves later on in the process.  Later on it can be too late to make changes, changes which are time consuming, or simply impossible.

Planning with a prototype forces us to think things through from the beginning.  When we start navigating around our embryonic site and setting ourselves tasks, we can quickly begin to see when things are working and what the experience will be like.

The working prototype is the plan and becomes the specification for the site.  It’s a page by page model – a bit like a 3D styrofoam model an architect may build to demonstrate and explore a building from different angles.  The prototype becomes the master plan and the functional design.

Everyone wins

Clients love to see prototypes.  Development teams love to see prototypes.  The prototype acts as a central hub for everyone involved in the project, offering something tangible to explore and consider, and to show to others without getting bogged down in more aesthetic design decisions.   It helps to focus the attention on any problems that need to be solved with the site, and becomes a basis and focal point for discussion.  What’s more, a prototype shows progress, real visual progress – rather than a written document specification which may be hard to digest and visualise.

User testing

A good working prototype is a great tool for testing on real users.  Rather than waiting until more time, love and effort has been invested into aesthetic design,  testing the prototype early on can reveal any shortcomings in the information architecture, navigation, calls to action and interaction design.  The prototype can be tweaked quickly and less painfully at this stage, and this can offer huge rewards.

Showing ‘Flow’

You may think you can just demonstrate how a site is going to work with static wireframes by simply describing how it’s all going to work.  Yes you can.  But it’s really not the same.

You get a far better idea of whether a solution is really working when you can click around as it would actually be used.  Static wireframes, or approximates with notes saying ‘This will slide down’  don’t give such an effective demonstration of the interface, whether it really works and flows or whether sliding down is such a good idea.  The final solution for the site should be fluid, intuitive and logical.   Prototyping helps to demonstrate this flow, and therefore it needs to be able to work as near as is possible to the intended solution in the finished version of the site.

Building your prototype

We need the right tool to build our prototype.  We need a tool which is both fast, for getting our basic wireframing ideas together and powerful enough to add interactivity to our prototype later to create a fully navigable set of pages.

The tool must be easy to use and intelligent in the way it handles repeated elements across multiple pages so we can change things around without pain and maintain consistency.

So just build it in HTML, right?

The most effective option is probably to build it all in html from the beginning, giving us a framework which can be re-used throughout the rest of the project.  Much has been written about this, and I respect the approach.  The trouble is that building our prototype in code becomes slow and clunky (even with my many years of production HTML/CSS experience), and is far from being ‘rapid’ prototyping.  Getting bogged down in HTML and CSS and Javascript can become seriously time consuming if we start moving our page layout around on the fly.  Even though there are huge advantages in taking the HTML approach, it can limit the outlook and we can become lead by code rather than being lead by ideas and the best solution for the site.

Finding the right tool

I’ve tried wireframing in a lot of tools over the last couple of years, including; Balsamiq, Mockingbird, Flash, Flash Catalyst, Fireworks, Powerpoint, Keynote, Sketchflow, Visio, Flairbuilder, HTML, various online solutions and of course pen and Paper.   Yes, pen and paper can be great for getting initial ideas down in some meetings.  However, my experience of flip charts, whiteboards or passing paper around is that things can quickly get messy. Constantly redrawing page ideas from the beginning becomes tedious and often I’ve ended up with a pile of meaningless scribbles at the end of the meeting which can easily be misinterpreted.

Wireframing in software during client meetings can also have huge pitfalls such as; losing data, discovering the client has a lower resolution projector than anticipated, or software/hardware which starts to generally misbehave for no good reason.  All things considered it is still my preferred method and worth the occasional pain.  It allows decisions to be made which all can see and read, keeps everything fluid and gives a realistic idea of how much usable space is available on a page.

Most tools suck

I’ve rebuilt entire prototypes in tool B rather than tool A because tool A was causing so much pain.  But, to be honest they all cause pain sooner or later.

I want a tool that aids creativity and helps to inspire original solutions. I want to be able to create new interaction ideas as well as being given a bunch of preset components. I want to be able to show large hover ‘mega’ menus, I want to show large sliding panels, interface elements with fixed positioning and show how items will open and close and how the rest of the page flows naturally as with any regular HTML page.  But demonstrating all this is quite painful with all the wireframing/prototyping tools I’ve tried to date. Hopefully things will improve in time.

Current tool of choice

I’m currently testing Axure.  It solves the fundamental issues of being both fast for quickly throwing ideas together, but it’s also powerful when needed.  It has some great features for both creating and presenting working prototypes.  As well as all the usual simple drag and drop components, It has really powerful interactions, dynamic panels with multiple states, master elements and a feature I particularly love, a slider control to decide how linear or ‘sketchy’ you want the whole thing to feel.  It will even output a complete specification document from all of your notes and page comments if that’s something you are required to produce.

It’s not perfect though of course. It’s also very expensive compared to some other tools. But building a prototype is important work, and worth investment just as Photoshop is worth the investment for graphical work.

Things to consider

A few of the things I consider when looking at wireframing/prototyping tools:

  • Is it regularly updated and developed?
  • Does it have a development team, rather than being developed by an individual?
  • Does it have a thriving community?
  • Is it stable?  (Some of the tools I’ve used repeatedly fail).
  • Has the community built a downloadable libraries of preset objects if you need them?
  • Does it let you assemble wireframes without fuss – could you use it quickly infront of a room full of people?
  • Does it have a complete site map allowing quick jump from page to page?
  • It is fast and responsive even with large projects?
  • Can you build a working prototype with it in a fraction of the time it would take you to build in HTML?
  • Does it allow the creation of complex interactions when you need them?
  • Does it allow the creation of realistic forms?
  • Does it allow logical operations, ‘if’ statements etc?
  • Does it have templates, or a library function of updatable objects to ripple changes rapidly across your model?
  • Does it have layers, to lock elements down in the background so they don’t get in the way?
  • Does it have a selection of basic design tools in case they are needed?
  • Can you choose if you want it to look ‘sketchy’ which can be distracting – or more ordered and linear?
  • Does it let you collect notes about pages or elements to assemble your thoughts?
  • Is the viewing mechanism easy to distribute to team members or a client?
  • Is the final output built in HTML – therefore pages can be navigated more realistically rather than Flash?
  • Does it allow feedback from these viewers?

Conclusion

Building a good set of wireframes that become a working prototype helps your web project get off to a flying start, it becomes the hub of the design and development project which everyone involved can refer back to.  You need to find the right tool to build your prototype. It must be capable of demonstrating how everything will work, whilst not being a complex or fickle beast you have to battle with. Ultimately you need a tool to help shape your thoughts and create a tangible model which is robust enough to be tested with real users and take you through to the next stages of the design process.

  • http://twitter.com/webcraftsman Jeff Bridgforth

    I think you made an interesting observation. As a student of architecture, I built low-fidelity models all the time. There is only so much a flat 2D drawing can do. I ended up making a lot more design decisions as I built out a 3D version which was more representative of the space of a real building.

    I think the same is true on the Web. Interactivity can only be experienced in a model. I think prototyping is becoming more and more important as we look at adaptive techniques. I agree that we need better tools to help us build these prototypes. I would always use cheaper materials to build more low fidelity models before moving to form core or balsa wood for more refined models of a “finished” project.

  • Michael Ickes

    Excellent article!

  • http://twitter.com/extremejava J4Java

    The best part of prototype is that it gives you clarity about whether you are going in right direction. Most of the best products are built using prototypes only.
    How
    to use value of one variable as name for another variable in
    javascript

  • http://twitter.com/marcus67 Marcus Lillington

    Nice to see these thoughts reach the page here because it will formalise our processes. I’ve built prototypes in the past but, kind of, at random. I need to try Axure :)

  • http://twitter.com/marcus67 Marcus Lillington

    Nice to see these thoughts reach the page here because it will formalise our processes. I’ve built prototypes in the past but, kind of, at random. I need to try Axure :)

  • http://twitter.com/mohsinnazir Mohsin Nazir

    nice article

  • http://twitter.com/mohsinnazir Mohsin Nazir

    nice article

  • http://www.marcpoulin.ca Marc Poulin

    I like your article so much that I will add it as a reference to one of my blog posts on prototyping.

    You mention JavaScript and CSS when doing HTML prototypes. It may be because I do not master these tools but I like very much the idea of low fidelity wireframes that do not require JS or CSS. This is because it forces the stakeholders to concentrate on the essence of the site. 

  • Phil Middlemass

    I’ve been using Protoshare for wire framing and functional mockups for about 1yr now and find it the best of all I have tried previously, it’s a SaaS product through the browser, it’s also got good collaboration tools for discussing designs, allows multiple users to work on a project simultaneously and supports versioning of your pages.

  • Pete Karabetis

    Great observations in this article!

    We’re kind of buddy-buddy with the Axure prototyping software here at Vim Interactive :) We often create static wireframes in Axure then slowly add in the interactions as we solve problems page by page. It is expensive, but you get what you pay for:

    “Nothing good is cheap and nothing cheap is good.”

    From a continuing-ed perspective, you can create almost any interaction you can think of without diving into or learning code. That alone is invaluable because it encourages creativity by letting you brainstorm instead of spending hours learning code to accomplish what’s in your imagination.

  • http://twitter.com/melcabs16 melanie cababat

    awesome article

  • http://cheekymonkeymedia.ca Rick Bjarnason

    We have been using Axure for a few years now, and it is pretty good at getting the job done. One thing that I would love is if they introduce the ability to easily edit the html.
    Honestly, my favorite is still plain old html, css and javascript. If you do enough of them it is relatively easy to keep a few snippets of code around to speed up the process.

  • http://www.facebook.com/people/Mikee-Chavez/1085767972 Mikee Chavez

    Don’t let Adobe see your list of “things to consider”, they’ll fatten up one of their programs with it:P

  • http://profiles.google.com/juls.petersburg Julia Kryuchkova

    Some statements in the article are arguable :) Too much time wasted on creating the interactivity which is not as self-explanatory for developers and customers as it seems. Interactive prototypes are good if you show them personally. And – they are good for not very experienced interaction designers as they help them think in terms of action flow rather than static screens, and push them to answer questions “what happen if I do this or that”. 

    We have to remember that building interactive prototypes can be very time-consuming, so, unless it is absolutely necessary to impress the customer or to figure out difficult interaction case or for usability testing – we have to think twice before decide to do it.

  • Anonymous

    Nice article. I run http://www.mobjectify.com which is a tool specifically for prototyping interactive working HTML designs for mobile devices.
    Would be great to hear your thoughts on it.

  • http://twitter.com/benjudy Ben Judy

    Good article, especially for anyone who is just entering the web / software design field and has never attempted prototyping.

    Axure has been my go-to tool for a few years. As you say, it’s not perfect. But once I mastered it and learned to work within the constraints, I found I really could create interactive mockups more rapidly than any other method I’ve tried.

    One potential problem with prototypes is the issue of fidelity in interaction design. The best way I can summarize this is to say that “the devil is in the details.” That is, while you can use a tool like Axure to simulate common Web interactions, the nuances aren’t always there. I once found myself in trouble with a client who assumed that my Axure prototype — because it included interactivity — was meant to convey *precisely* how the end product would function. Then when I explained it was “just a prototype”, the client was frustrated because they “thought we were further along” in the product development process.

    Of course the real issue there is communication. But my point is that an interactive prototype opens the door to inferences you (as the designer) may not be aware of. Clients may see a clickable prototype and assume that you have created working code, or that you are nearly finished with development — when in fact you are just beginning the collaborative design process!

    Just something to be careful of. With great power comes great responsibility! Powerful prototyping tools do not eliminate the need to communicate with stakeholders about design process and intent. Many times, they heighten the need for this kind of communication.

  • Anonymous

    Really enjoyed your article – especially the list of things to consider – very concise. Commercial disclaimer but you might be interested in http://www.fluidui.com if you are doing some mobile-specific wireframing or prototyping. Thanks again for the article – enjoyable read.

    Ian

  • carlymarr86

    Can I ask which typeface you use for the body text?

  • FluidUI_Team

    Fluid UI is now live and launched https://www.fluidui.com/editor

    We would very much appreciate your feedback!

  • Barry

    Good article. I am using http://www.hotgloo.com and am loving it.

Headscape

Boagworld