Humans have a natural affinity for stories. We know this intuitively. When we’re trying to teach a child important lessons about ethics, caution and quick-thinking, we don’t work them through a series of Powerpoint slides on the subject in the hope that it will get our point across.

Rather, we tell them the story of Hansel and Gretel. Over the course of the narrative – as the siblings walk through the forest, dropping breadcrumbs, as they get taken in by the cannabilistic witch and then delay their transformation from youngster into dinner until they can turn the tables on their would-be murderer – the young audience engages, empathises, and learns.

Adults have a similar experience when it comes to stories. Whether it is the ancient oral tradition of encoding information about hunting or farming into folktales, or contemporary storytelling developments like management case studies, stories have a way of reaching us that mere description can’t match.

This cognitive resonance is what makes design stories a powerful prototyping tool. People can understand complex concepts underpinning a design more easily if they’re embedded in the narrative form. And there are even more reasons to use stories to prototype your design:

• They can be created right at the beginning of the design process, based on concepts and ideas. No coding or process engineering required – only brainstorming and a bit of writing time (although supporting user research efforts can be extremely valuable inputs).
• Used well, they paint a vivid, holistic picture of a future user experience in a way that users and stakeholders can engage with and empathetically critique.
• They provide context – in a story, the focus is not on the solution (eg a website), but on the users and how they go about interacting with it, to their benefit or peril.

And, incredibly importantly:

• Design stories create a mental “scaffold” for their audience. Once people have understood and embedded the user experience story, you can use that mental model to start adding in complexity. Discussions about business processes, technology, user interfaces can be tied back to the story, to help people make consistent sense of it all.

Planning an example speculative design story

Let’s look at how we’d go about using a design story to speculate on the future user experience – say, showing how some of the major technology and social trends we’re seeing today will change the world in the next decade. To plan out our story, we might first consider a few key storytelling elements:

1. Story coverage and size – what should the story cover, and how big should it be?

In terms of coverage, because the story is going to be speculative, I’ve decided to be a bit ambitious throw in a bunch of trends that I think will be influential in how we live our lives in a decade’s time. These are:

• Crowdsourced personal decision-making (asking your online social networks to help you decide on what to do, both in your personal and professional life)
• Social benchmarking (rating yourself against your online social networks)
  Augmented reality, bolstered by ubiquitous GPS usage (technology knowing where you are I a geospatial sense, and being able to “overlay” what you are seeing with additional information)
• Connected home appliances that are actually useful,
• Further convergence of many information devices into a single device (so that your smartphone, iPad, MP3 player, television etc all become functions of a single gizmo),
• Standards unification turning into integrated services across vendor siloes (so that your experience across the online services you use don’t fragment through the need to sign-on multiple times, duplicate information across services, not have access to data from service A while you’re using service B etc).
• Gestural and eye-tracking interfaces displacing (although not replacing) touch and mouse interfaces (getting UI’s off a screen and more integrated with natural interfaces like your hands and your eyeballs).

As for story size, I’m pretty confident that I can show how the world has changed by telling the story of a single, universal experience – waking up in the morning, and going to work.

2. The narrator – Who is telling the story?

Because the story introduces many new societal and lifestyle concepts, it’s important to focus on the protagonist’s thoughts, motivations and feelings, to help the reader quickly make a connection that will ground the speculative future being canvassed. To achieve this, I’ve decided to write in first person.

3. The protagonist – who is the story about?

I want to make the story about someone that the readers can at least somewhat identify with. So I’ve decided on a character who has certain types of common characteristics (25-35 age bracket, professional, urban, cares about health, relationships and appearance, tech-savvy) without making any of those characteristics come across so strongly that people who fall outside of the aggregate demographic will switch off to “owning” the experience that they’re reading about.

4. “Plot-driven” or “slice-of-life” – how is the story structured?

If I were writing a story about a specific service and its value to the protagonist, I might use a traditional plot-driven story with a beginning, a middle and an end, and where the protagonist faces a conflict that the service being designed helps him/her overcome to achieve his/her goal.

However, I am trying to show how life in general has changed as a result of an accumulation of trends. This makes me lean towards writing the story in the “slice-of-life” mode, where I can show a brief snapshot of a person’s life. I don’t need a plot, or too much context, or for the protagonist to develop over the story’s course – I just need people to give people a sense of what life is like in the “new world” I’m speculating on.

An example of a speculative design story:

So, taking all of that into account, here’s the speculative design story. Interestingly, I’ve had two distinct types reactions from people about it, which I’ll summarise with two actual quotes: “I want this now!”, and “Gee. It sounds like…a nightmare.”

This story could be told using many types of experiences as a basis – visiting a doctor, shopping for groceries, going to dinner. As long as the experience is one the audience can relate to and benchmark against their current state , it’s possible to scaffold the complexity and paint a vision that people can thoughtfully consider.

Regardless of the specifics of the story, the freedom that the storytelling form gives you means that you are only limited by your ability to imagine the world in a way where your ideas – as wildly ambitious as they might be – have played out.

Top image: Pawlowski

After over 2 years of extensive research, Todd Zaki Warfel has released the book “Prototyping: A Practitioner’s Guide”. I talked to  Zaki Warfel about his interest in the area, the surprising results of what prototyping methods practitioners actually use , and how he seeing prototyping being used in the future.

VT: What was the inspiration to write about prototyping?

Prototyping: A Practitioner's Guide

At my company, Messagefirst, we had starting doing more and more design of webapps and things that took advantage of modern technologies like AJAX to improve the user experience. We were finding that as detailed as our wireframe documentation was, it was falling flat when trying to show transitions like self heal and progressive reveals. We needed something that could show and tell the story of the experience better—we turned to prototyping.

How clued up is industry right now when it comes to prototyping?

Not very. I’ve seen a high degree of interest, but from practical standpoint, there’s a very small minority of practitioners doing prototyping as a regular part of their design process. I find it’s most common at the most extreme ends of the spectrum. Based on the research I did for my book, it was something that I found to be more likely in Agile-type shops and really large corporations with hefty budgets like Microsoft. That’s not saying that all Agile shops or corporations with hefty budgets are doing it, but those seem to be two environments where it’s more likely to occur.

Todd Zaki Warfel

While there is interest in prototyping, the two main things that prevent people from adopting prototyping into their design process are that they don’t know where to begin and they have a hard time convincing their client or boss that it needs to be.
There’s this misconception that prototyping has a high cost, adding significant time and financial cost to the design and development cycle, when in fact the exact opposite is true. Not that prototyping doesn’t have a cost, it absolutely does. The thing is, just like anything else, you’re going to pay now or later and prototyping has a much lower cost than paying later. Fixing something in the design process is much less expensive than trying to fix it once it’s been launched. Depending on who you ask, fixing a problem once your system has launched will cost 100-1000 times as much as what it would have cost had you fixed it during the design process.

Getting past the “cost” argument can be challenging for people who don’t have experience prototyping and can’t speak to it first hand. Fortunately, I’ve seen the benefits firsthand and have a number of stories I can tell about those lightbulb moments we’ve experienced with customers and clients that we’d never experienced with wireframes. I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done with out prototyping.

People just need to find the comfortable place to jump in and try prototyping, something small with a low initial cost that can provide some value they can show clients in order to make it a regular part of their design process.

One interesting concept in the book was using prototypes for communicating ideas (Robert Hoekman, Jnr. coined it “proto-communicating”).

The standard practice is to either use wireframes with behavior notes and or a spec document. Spec documents are the worst. They’re typically 60-200 pages, mostly text, occasionally include screen shots to illustrate what the text is trying to describe. It’s still a static representation of an interactive and dynamic experience.

Wireframes are a little better for communication, as they rely more on visual representations of the system with behavior notes. But like a spec or requirements document, it’s still a static representation of an interactive and dynamic experience.

Since the dawn of man, we’ve used pictures to communicate. Our first form of written communication was cave paintings—drawings. We are visual thinkers by nature. If I try and describe a system to you, your brain is wired to immediately draft a picture of what the system is, how it might look, the way you move from screen to screen, or state to state. Why not leverage that native visual thinking language?

Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design. That’s kind of ground zero.

You did a lot of research into the prototyping tools interaction designers currently use. Did you have any surprises?

Initially, I was surprised at the number of people using Visio and Excel to prototype. Let’s be honest, as a drawing tool, Visio is mediocre to decent at best, but as a prototyping tool, it’s pretty poor. And then there’s Excel. Who in their right mind would ever prototype in Excel? Turns out, someone who has access to it, knows it, and is comfortable using Excel.

This turned out to be one of the biggest influencers in selecting a prototyping method or tool: use what’s available and what you know. The thing is, that as bad as these tools are for prototyping, the worst tool you can try to prototype with is the one you don’t know, aren’t comfortable with, or don’t have access to.

There are a number of better prototyping tools available: Fireworks, Flash, Axure RP Pro, PowerPoint/Keynote, and HTML just to name a few. And while they might actually be better prototyping tools, if you don’t know them, don’t have have them on your computer, and need to prototyping something quickly and have it ready today, tomorrow, or in a few days, then you use what you know. Learning a new tool does have a cost. You just have to decide when you can afford a little downtime to learn that new tool.

Zaki Warfel's Prototyping Methods Matrix

What are your preferred prototyping tools?

Paper and pencil to begin. Every design I do starts with one of our sketchboard templates, a mechanical pencil and a thin felt tip pen. After sketching through several iterations of the design, I typically move right into the HTML/CSS prototyping framework we’ve built. We’ve plugged several different JavaScript frameworks into it: Prototype, jQuery, and most recently YUI. I’m really impressed with the strength of the YUI 3.0 JavaScript framework for AJAX-style transitions and interactions. jQuery is probably my favorite for doing things quickly, but YUI 3.0 has become really powerful.

I’ve also leveraged Fireworks from time to time. It’s a good tool, but not great yet. There’s some real quirkiness with the application (things like zooming won’t work on the window you have in focus until you click on the actual frame of the page). If they’d fix the buggy quirks, it would become a great tool. But my preferred prototyping tools are paper, pencil, pen and HTML/CSS with JavaScript.

Has doing the book changed how you prototype?

I’m continually evolving the design process we use, so it’s hard to say. It did open the door to some new tools that I was aware of, but hadn’t tried out yet, like Fireworks. In the past, I had only used Fireworks for visual design and production of visual assets, but not for prototyping. The more I learned about it, the more I wanted to try it out for prototyping.

We prototype almost exclusively in hand-coded HTML, CSS, and JavaScript—prototyping something in Fireworks is a significant departure from what we typically do. However, since writing my book, there have been a few opportunities where a Fireworks prototype turned out to be the most appropriate approach.

One of the things that did happen along the way, was that our prototyping process evolved to the point of being more and more comfortable creating production-level prototypes. Most prototypes are built with the intent of being a “throw away”—little if anything from the prototype will actually be recycled for production. Personally, I think that approach gives you a great deal of freedom and flexibility. And honestly, it’s the approach I would advocate for most people. Our situation is a little different. Most of our prototypes are created with the intent that eventually most if not all of it will be repurposed for production.

Since we’re creating prototypes that often make their way into final production, our approach is a little different. We use our own custom HTML/CSS framework to prototype. There’s nothing really proprietary about it—it’s all standards compliant HTML and CSS with Prototype, jQuery, or YUI! thrown in for AJAX effects. However, as part of the ever evolving refinement of our design process, I’ve rewritten this framework three times and am currently working with Jonathan “Yoni” Knoll to rewrite it again to make it even better.

I think the book has encouraged me to explore additional toolsets and continually refine our prototyping process and framework.

Are there many things in the design process you can’t prototype?

Not that I’ve found yet. The nice thing about prototyping is if you can fake it. One of my guiding principles is: If you can’t make it, fake it. So, there really isn’t anything I can think of that can’t be prototyped at some level. Some things are easier than others, but I can’t think of anything I haven’t been able to prototype to date.

In nearly every case in the past three years, prototypes have become our documentation. There are a few exceptions, where we need to include some supplemental documentation, say a 10-20 page document to specify some business rules that happen on the backend, which aren’t clear from the prototype. But I’m willing to do a 20 page spec document and a prototype instead of a 200 page spec. It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it. And you still won’t know if it’s going to work or not until the system gets into production. Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.

Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.

Any predictions or hopes as to how prototyping might evolve in the future?

My hope is that it becomes more of a common practice in the design process of anyone making products. I know personally how much making prototyping a core part of our design process has changed the way we approach, design, and validate our assumptions. It’s also made our solutions much more creative at Messagefirst. Once we start to see how the system will work, it begins to inspire new ideas. We can also identify issues much faster and earlier in the design process. Those issues create opportunities for more creative solutions. And the earlier you find problems with the design, the cheaper it is to fix them. Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser. All in all, my hope is that I’ve given the community something they find will help them improve their design process, their designs and make it easier to communicate their designs to clients and colleagues. Less pain, more gain.

Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser.

Any other insights about prototyping that you’d like to mention?

Probably the biggest insight is that making prototyping a core part of our design process has literally changed the way we approach exploring, crafting, and validating our design concepts. Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.

I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.

Example of physical prototyping (taken from Prototyping: A Practitioner's Guide)

One last insight is prototyping has not only given us the ability to test out our designs early and often, quickly uncovering issues with the designs, but has also given us a method to inspire new design solutions. It’s not until you start experiencing and playing with the design that we know whether or not our theory will really work. Once we start playing with it, seeing how it works, experiencing it, we often have those light bulb moments of “Oh, now that I see it does that, imagine if we take it a step further and do this…

Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.

Getting the book

Prototyping: A Practitioners guide is available now in paperback and digital format.
Thanks to Rosenfeld Media, Johnny Holland readers will receive a 20% discount on the book with the code JOHNNYHOLLAND when buying it from the Rosenfeld Media website. It is also available via the UX Bookstore.

———-

Images taken from the Rosenfeld Prototyping: (diagram illustrations) Flickr set. CC BY 2.0

In our previous article, we focused on the first step to developing a User Experience (UX) strategy by presenting how user stories are generated, themed and prioritised, as a means of helping us to understand the shape of the project (what) and its purpose (why).  In this article we focus on the use of scenarios and paper prototypes to support a rapid and collaborative exploration of potential implementation approaches (how).

An Approach to UX Strategy

The goal of the strategy phase is to ensure that all stakeholders are similarly focused and aligned around project goals, i.e there is agreement in principle about the purpose of the project and the priorities for implementation.  A high level agreement to what the project is, why we are doing it, and how it will be achieved reduces the risk of budget blow outs or conflicts in the design phase by ensuring that all project stakeholders have similar expectations. In addition, it is only through an understanding of the scale and complexity of the project that the design team can accurately, or at least confidently produce a budget or estimate for the project.

Our approach to the development of a UX Strategy is motivated by three interrelated, pragmatic and theoretical drivers:

1. Firstly, getting the client team on board and in agreement during the strategy phase relies on these stakeholders having a shared understanding and vocabulary. Tools like scenarios and prototypes help to externalise issues and make them available for shared conversation.
2. Secondly, they also allow the project team to collaboratively and rapidly investigate options and expose constraints. The tangible and visual nature of these tools allows us and the client team to think, explore and discuss the potential project in a more concrete way by grounding conversations about the project in its context of use. This ensures decisions about approaches and priorities contained in the strategy are appropriate to the opportunities, boundaries and constraints of the particular project.
3. Finally, the third and perhaps most important reason is that tools like user stories, scenarios and paper prototypes frame the discussion about the project strategy from the perspective of the user experience. Doing this collaboratively is an opportunity to expose, explore and align the various agendas and perspectives of stakeholders and work through how they might come together in design. As a result clients are better able to understand the implications of project objectives and priorities, and refine them based on the impact this will have on the potential user experience.

From User Stories to Scenarios

Any of the high level user user stories generated as part of the early strategy phase could be implemented in any number of different ways. Different approaches to implementation will require different levels of investment and be more or less appropriate given the project context and constraints. So, once a list of user stories has been developed (as described in the first article) the next step is to identify the key scenarios. The intention is that by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why. In our experience fleshing out 4-6 scenarios will allow us to explore enough of the key aspects of the site/application. If not, then this is a sign that the project may need to be divided into smaller phases.

The intention of doing this work is not to find the solution or define the architecture per se, but rather to explore possible approaches and agree on an appropriate UX Strategy. We also hope to expose risks or contradictions between expectations and constraints (e.g budget).

… by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why… to explore possible approaches and agree on an appropriate UX Strategy.

Selecting Key User Stories

The user stories fall, more or less, into two categories. The first are that those that are simple, familiar or unambiguous enough that we can feel confident about budgeting them and resolving them as part of the design phase. These might include user stories that use common UI patterns that we are familiar with or that we have resolved many times before. The second group are more like ”black holes”. By that we mean ambiguous, complex or particularly unique to the project; if not better understood they will pose a risk to meeting deadlines or timelines in the design phase. Our goal is that by the end of the strategy phase we can a) be sure that they can be implemented and b) put a cost against them.

The process of fleshing out this latter group in more detail allows the scope and nature of the project to emerge through a focus on user experience. At the same time it exposes and challenges some of the assumptions and expectations held by stakeholders, or embedded in existing documentation.

The following is an example of a key scenario from the redesign of a university website:

As a potential student I can find out about the application process, find an available supervisor and apply.

This scenario is derived from these user stories:

• As a potential student I can find out about the application process
• As a potential student I can find an available supervisor
• As a potential student I can apply to study

The example scenario above was chosen because it represents a complex pathway that would be completed by a potential student over several weeks or months. Walking through such a scenario forces us to explore and confront a number of strategic, political, technical and user experiences issues.

Mapping out scenarios as user pathways

Once the key scenarios have been identified and agreed upon with the client, they are mapped out as user pathways.

Initial pathways are generated using a walkthrough process represented by post-its. We take each scenario and ask ourselves what would we would need to provide in order for that scenario to be achieved. We have to hand personas, business objectives, content examples, accessibility guidelines, and any relevant technical specifications to assist our decision making about how people might proceed and what they might need to do so.

Each step gets a post it/sketch to represent it, as shown in the image below. We aren’t working at the level of pages yet, just creating a trail of things that would need to exist in order for it to be possible to fulfill that particular scenario. This process allows us to think about the experience as a dynamic thing that happens over time.

Mapping Pathways

Analysing pathways

All the scenarios are mapped out in the same physical space and in relation to each other. If there is some cross over between the scenarios then that is shown physically by an intersection in the pathways.  It is likely that the pathways of earlier scenarios may have to be adjusted in response to what emerges out of the later scenarios. It is an iterative process and depending on the scale of the site, might take a few days to complete. In the image below, intersections in pathways were exposed via clusters of different coloured post-it notes.

Identifying Pathways

Rather than exploring or defining the approach to design or user experience from the perspective of features, this process allows the shape of the site to emerge through an exploration of user activities. Particular patterns about potential use can then be identified, which feed back into the strategy development process. For example, we are able to see that particular areas of the site, or pieces of content contain information relevant to most stakeholders, while others have value for only a small number. These patterns can inform decision making about priorities for the site and help clients to come to agreement in principle on approaches to various aspects of the project, including where time and money is best spent in the short term.

Drilling down through prototypes

Visualising the user pathways also reveals underlying technical and content needs and raises questions around feasibility, content and functionality. In some cases the issues and questions raised are better understood at a more granular level, i.e how they impact on specific interactions via the interface. Paper prototypes or mock ups are then used to rapidly drill down into these “high risk” areas. The image below displays an example of a paper mock-up used to explore possible ways of supporting a searchable index of university scholarships.

Sketch Prototypes

Seeing the potential user experience mapped out in this way provides the client with a different perspective on the project and this allows them to discuss the project the different ways. For example, this process will  expose how a scenario or user story, currently prioritised by the client team translates in design into a potentially very complex requirement, or requires the availability of a certain set of content not currently available. It can expose tension or conflict between a priority objective and what it would actual take to make that happen.

Often at this point, project realities begin to sink in and project teams are forced to realistically assess what could be achieved in the allocated time frame and budget. The visual pathways, mock ups and paper prototypes become visual and tangible aids to explain the issues and options, and support discussion, negotiation and resolution about appropriate approaches and priorities. We have found this technique is very effective for generating and supporting constructive discussions with the client when decisions about priorities are needed. The client has the opportunity to understand the impact of various decisions and requirements about technology or content in relation to the user experience. This supports the development of design principles and guidelines, and helps clients come to an agreement on approaches to particular aspects of the site or application. It can also lead to a revision or shift of emphasis for the project objectives.

The process of thinking through actual prototypes provides these stakeholders with a new way of seeing and new language for describing what is most important. As a result the client team is better placed to decide and describe the most valuable outcomes and confidently direct resources towards the most important elements of the project.

Summary

Creating an effective User Experience Strategy requires the alignment of perspectives such as technical, business, content and brand with that of the user experience. In this article we have described how we support clients to develop a User Experience Strategy that takes into account all these perspectives, based on an understanding of how it will translate into design.

We believe that a core part of developing a design or User Experience Strategy is about interpreting how ‘abstract’ business goals are translated into a specific design project. Scenarios and prototypes are light weight, visual tools that can be used to assist clients to rapidly envision the potential experience for users. They bring a tangible quality to conversations that can otherwise be ambiguous, allowing team members to collaboratively think through project goals and approaches to implementation. They force us to deal with the concrete issues of use in situ, provoking and facilitating critical conversations about overall strategy, opportunities and constraints prior to moving into the design phase. Most importantly they frame questions and decisions about functionality, brand, content and technology in relation to the impact this will have on the potential user experience.

As designers, we deal with users perspectives and the concrete situated issues of use as part of our daily practice. These collaborative tools enable the user perspective to sit at the centre of the discussion and decision making for our clients as well.

Acknowledgments
The reflection on methods outlined in this article was largely made possible through project work completed on behalf of Digital Eskimo, a social design agency in Sydney whose Considered Design methodology makes embracing these methods and approaches possible. We would also like to thank our clients UNSW, Melbourne Journal of International Law and Inspire Digital and our project partners Zumio and Redrollers for their generous commitment to sharing the design experience and process, and to all the participants who give time to our projects.

“We won’t be doing any user testing for this project. There’s just no budget for it, and we don’t have time.” Hear this often? We do, particularly since we work in Ireland – a small country with similarly small companies and budgets. However, we believe user research is too important to give up. So instead, we have to run tests quickly and cheaply for our clients to accept the cost – and we have to clearly show how it brings value. Because of this, we’ve developed a toolbox of quick, cheap UX research techniques.

In this article, we’ll talk about one technique known as fast prototyping, and how we effectively used it in a recent project for Vodafone Ireland. We’ll also be talking about this subject at EuroIA 09 in Denmark.

Background: Vodafone Ireland

The Vodafone Ireland webiste

Our task was to redesign the Vodafone Ireland information architecture (IA), which the company had quite simply outgrown. Traditional business areas dominated the website and left little breathing room for new business streams in which the company was investing heavily. Our challenge was to provide Vodafone’s users with a clear map of the site and its products in a quickly shifting market.
We investigated traditional IA user testing tools such as card sorting, but we felt given the complexity of the site, it would give us limited results. A prototyping solution was a much more effective use of resources.

Why Prototype?

Card sorting is great for defining natural associations among a selection of words and objects, and really helpful in deconstructing concepts into logical groupings. But we felt that it often places undue weight on the unusual cases that straddle concept groupings, and not enough on the main paths that most users pursue when navigating a site.

True, prototyping doesn’t provide the volume of statistical data you’d get from a large group of card sorters. You have to invest more time in fewer people, but the qualitative and comparative data can be a really rich resource.

At Vodafone, our focus was on efficient findability – getting users to their destination easily. So we had to test not just our product groupings, but the usability of our principal purchase flows.
A prototype combined with specific use cases or scenarios was perfect for this.

Making the Prototypes

We have a small development team of 3 full-time front-end programmers who spend their days (and often nights) writing production-quality code. For us, assigning developers’ time to prototyping is a huge expense. But for our interaction designers – who aren’t all expert coders – creating prototypes in HTML is too time-consuming (even if 37Signals say otherwise). Therefore, we needed a prototyping technique that was simple and didn’t involve a lot of coding.

While there are many methods around, (for example, Phil Frelinger of Xero champions working with Flash, others have even suggested Powerpoint or Keynote), we found that for static pages, image map prototypes worked best, and for forms integrating image map prototypes with HTML.

Static Pages – Image Map Prototypes

Most wireframing tools (Omnigraffle, Axure or Visio) allow you to assign actions to shapes, such as opening a new wireframe or displaying a layer on click. The wireframes can then be exported to HTML, with clickable areas represented by image maps.
We’ve found this is a great way to prototype static web pages and have used them to test:

• Information architecture
• Navigation
• Labeling
• Content

What’s best about them is that they’re fast. A prototype created in HTML takes about 2 days of development and 1 day of interaction design. An equivalent image map prototype, starting from existing wireframes, can be created by an interaction designer in just 3 to 5 hours.

Forms – Image Map + HTML

Unfortunately, image maps can’t be used to test forms. Forms must be filled and submitted. They must validate input. They must provide error and confirmation messages. This means form prototypes must be built in HTML.

To minimise development work, we integrate image map prototypes with forms built in HTML, CSS and JavaScript. (See the below video for how to make one).

In our projects, we use prototypes to test process flows (e.g. online purchases and applications) – from the homepage to the confirmation message. We use image maps for all static pages, and build the forms in HTML, CSS and a JavaScript framework. We then link the image maps and the application forms together, and it works seamlessly.

We can built these prototypes in just one day, with a half-day each of development and interaction design.

Testing With Prototypes

The Vodafone IA project involved 2 rounds of user testing.

• Round 1 was 2 days with a total of 12 people for just under an hour each. We tested 2 low fidelity prototypes against the existing website.
• Round 2 involved just one combined prototype for verification purposes and looked a little harder at some of the decision pages, content and design decisions that needed firming up.

We used scenarios when testing to provide depth of context and richness of content. We inserted live videos and advertisements into the prototypes, and used posters and storytelling to get the user to take on a role and reenact scenarios. It led to very effective, real life, real world conversations.

How prototypes provided context

The Vodafone site had enormous similarities between its product subsections. Mobile phones and home phones all had plans, costs and bundle offers, and could be used to access the internet. Because card sorting approached IA analysis from the bottom up, we would have had to prefix each choice with a content heading like “mobile plans” or “mobile costs” in order to provide context. Using prototyping to test from the top down, we were able to avoid this and base our analysis on the user’s contextual position once they’d clicked on a particular section.

Testing page designs and IA at once

The previous design of the site included a number of decision pages to minimise reliance on an IA. These served a purpose within the site structure, but we found they had usability issues – and analytics confirmed our suspicions.

Still, we saw these pages as an integral element of the IA itself, so making them work was a key objective. Prototyping also allowed us to explore a number of design concepts for these pages. For example, there was discussion in the project team over the best approach to display IA layouts. When we looked at other global Vodafone sites, we saw two distinct approaches:

1. A single top level IA exposed
2. A top level IA with a sub level IA exposed

Prototyping allowed us to feasibly examine both possibilities and unearth the most efficient solution.

Conclusion

In cases such as the Vodafone Ireland project, we found that fast prototyping techniques opened up possibilities for innovative, low-cost and iterative approaches that engaged users in task and scenario-based exercises during the design process.

Fast prototyping gets us close to a real-life scenario of a website, but affords us the flexibility to test different structures and designs very early on in a project – before any costly development work has begun.

For more on other cheap UX tools, see our workshop at EuroIA, “Cheap and efficient tools: how to engage users in IA design when there is no budget and there is no time“.

Acknowledgments

We would like to thank Vodafone Ireland for allowing us to feature their projects.

Pop some popcorn, recline in your favorite recliner and rest your laptop. In five articles I will share with you some of the more interesting user experience videos on the web. They represent the importance of video as a tool for any designer working with new behaviors, emerging technologies and complex systems that unfold over time. From low-res, techfree prototypes to science-fiction-like future scenarios, this collection of videos will survey the various ways that designers are using this linear medium to explore possible functions, experiences, contexts and values afforded by new technology driven products and services. And we begin with: prototyping.

Video Prototypes

Video prototypes are used for the same reasons any prototypes are – testing, evaluating, iterating, communicating, etc. But video is an especially useful tool for designers who have to quickly represent design concepts that often involve complex relationships or require a high level of technology. It’s fast, cheap, easy to share and allows lots of space for faking it.

The Economizer

The Economizer is a three part video scenario created by Cooper, a design consulting firm in the US. This series is a great example of low-fi prototyping with video. In fact, it’s not even video, it’s still frames with a voice over. You have to love the hand drawn interfaces.

KeyLess

At the Copenhagen Institute of Interaction Design, one of the fist workshops the students take is on the subject of video prototyping. Over the course of a week, students had to represent a concept as a low fidelity, low resolution prototype and then represent the same concept as a high fidelity, high resolution prototype in an empathetic scenario. Each student was given the concept for a service called KeyLess which would replace lost keys anywhere in the city in under 30 minutes. You can watch all the videos here.

Sketch-a-move

Sketch-a-move is the concepts for a toy car by Anab Jain and Louise Klinker. While the concept for the car is technically feasible, this video prototype allowed the designers to answer the most important question – is it fun? – without having to worry about building a functional prototype. This prototype is a great example of how video opens up new possibilities for smoke-and-mirrors techniques. In this case, one can presume, someone behind the camera is controlling the cars with a remote control.

The RaMo System

The RaMo System is a network of portable devices for elderly homes. This video prototype, also made at CIID, explores the interface of these devices, how they work together, and how they work in the context of elderly homes. It even goes as far to explore how it can be a tool to involve family in the everyday lives of elderly people in the home. For a course about GUI, it was a great decision to use video and capture everything happening around the devices.

Next time: concepting

Prototyping in the early phase of a project is the ideal way to see if (and how) a concept will work. But often enough it’s not being done because design teams fear it will cost them all of their available hours. I think this is a big misconception, since there are many different ways you can prototype… And even the fastest way, sketching, is more valuable then doing no prototype at all.

It makes you tell stories

There are many reasons why you should start prototyping… but for now I want to focus on just a couple of reasons. The first being: it makes you tell stories. When you force yourself to make a lo-fi prototype (e.g. sketching) you suddenly have to go through the scenarios/use cases. You have to design the interface and in your head interact with it. It’s not just wireframes in Visio anymore, but it comes alive. And this forces you as a designer to start telling the story of the interface. See it as a person, talking to the user… And like a storyteller you should define the character of the product. Is it agressive? Your friend? Your tutor or advisor? Will it talk to you as a restless child or be like Buddha himself? And what does it tell you? When? How?

The exercise of making a prototype brings this alive. It forces you to imagine how somebody will play around with it. I acknowledge that you should also do this when drawing wireframes, but there you’ll easily enough lose yourself in the details. It’s also a process where you approach each screen as an individual, trying to get the balance on the screen right. Maybe that’s not the correct way, but it is how it works. While making a prototype and playing around with it makes you feel close to the user.

It let’s you explain your concept

Personally I’m not always a big fan of wireframes. When I create them I already know that they will limit me in some way. Clients have a problem looking through the wires and seeing the interactive concept… And I have to split up an interactive concept in different pages and screens, while any interactive part can only be described in text. A prototype helps me explain what I have in mind (even to myself). It’s an easy way to start bringing the concept alive and seeing how it interacts with people. I can make sounds, move things around, let things disappear… everything that I need to bring it alive. And before I dive into the details I can easily change stuff. While others (and me) play around with the prototype, it evolves. Making the prototype isn’t a one-step proces. The creation and adaptation of it is the actual development of the concept.

So let’s start prototyping. And as a proof that anybody can prototype and bring an idea to live… Look at this video: