In an ideal world, we could build and test complete, functional, high-fidelity prototypes for every project, then iterate and test again. But even in the real world, with time and budget constraints, we can use prototyping to answer user-research questions, solve interface problems, prove concepts, test usability, and reduce risks before committing to development.
Prototyping techniques range from rough sketches on paper to hand-coded HTML. Tools like Axure and iRise allow non-programmers to develop interactive HTML prototypes that approximate enough functionality and fidelity to cover most testing requirements.
When planning a prototype, there are two basic questions to answer. First, what level of fidelity and functionality do I want? This will determine which tool or technique you use. Second, how am I going to test the prototype? This can range from showing it to a few stakeholders to setting up full usability lab testing with a group of typical users (which of course costs more).
But before you can answer these questions, there is a more important question – what exactly is the problem you need to solve, the question you need to answer? A clear sense of these priorities is vital to cost-effective prototyping, since you only want to develop enough prototype to solve these problems or answer these questions.
Two examples from recent UX Guys projects:
Online Store
As part of a redesign project for a telecommunications company, we developed an online store environment for ordering complex TV, internet and phone products. We built a series of high-fidelity prototypes in Axure to test two different interface concepts. The prototypes were first created as functional wireframes, then once we finalized the logic and flow, we added content and minimal skinning with graphic elements to create the illusion of a real web site for test users.
The first interface concept was a traditional catalogue in which products were grouped by a hierarchy (e.g. HD vs. non-HD TV service) then a good-better-best order for different products (e.g. numbers of phone features or TV channels in different packages). The second, alternative concept was an “assisted-selling tool” that made product recommendations based on how the user answered questions about their preferences and intended usage needs.
The prototypes we developed included readily available comparison tools and progressive-disclosure techniques such as roll-downs and pop-ups for more detailed information. We added a floating shopping cart showing which items have been selected (though due to Axure limitations we were not able to calculate a running total).
We tested our prototype with two groups of eight users on two different evenings. We gave the users a number of tasks, and divided them equally between interface options. We used feedback from the first session to make iterative changes before the second test, but only to correct minor usability problems that presented consistent roadblocks.
In developing the prototype, we used a new visual design and interaction model but preserved the current product names and organization. One of our goals was to find weaknesses in the way the company’s products were structured, positioned and marketed.
In testing, we had two very different objectives, or basic questions: to see how the prototype interface performed in terms of allowing users to complete tasks, and to see how users responded to the organization of the company’s products. Did the conceptual model – breaking TV into service then channel package, for example – actually work? In other words, could we build an interface that allowed users to complete a complex task successfully, but could we also find ways to reduce the complexity of the task by simplifying the underlying structure?
Based on the testing sessions, we learned that both interface concepts were relatively successful at allowing users to complete all tasks, but that users do in fact struggle with the complexity and ambiguous naming of the client’s products. Users were divided in their preference for the traditional catalogue and the assisted-selling tool, so we proposed including the tool as an optional “help” path for users who needed more hand-holding.
Thanks to the prototypes, we have a well-developed IA for an online store environment that we know will work effectively, thereby reducing risks once we start development. But perhaps more importantly, we found compelling evidence of user confusion that we can take to business stakeholders, in an effort to convince them to reduce product complexity.
Internal Software Application
We were engaged on a small project to solve interface-design and usability problems for an web-based internal software application used by the purchasing department of a global auto manufacturer. The client presented us with rough wireframes showing their first ideas for a solution.
We sketched out a number of possible solution concepts, then drew wireframes of the most promising idea. Without going into great detail describing a complex application, the core problem was to present a list of up to 100 different auto parts, then for each part multiple tabs containing dozens of data fields, while allowing values from certain fields to be copied from one part to one or more other parts (e.g. the right- and left-side versions of a suspension component would both come from the same supplier and have the same price terms and shipping costs, so the user should be able to copy those fields from one to the other rather than enter them twice). Our basic question was simply this: was our interface concept “intuitive” and usable? There was no formal testing beyond presentation to the client.
The client requested a clickable HTML front-end prototype that would show interactive elements on the page, but with no access to data. A developer quickly took the wireframes and built out the pages, but in the process the developer and the UX architect together added a number of dynamic elements that provided the user with clear indications of what steps should be taken next in the process, and clear feedback showing when an operation was successful. (When the user checked a data field to mark it for copying, the paste button appeared above the list of parts, along with check boxes next to each part and a select-all button. When the user clicked on the paste button, selected parts were highlighted in green for a few seconds to indicate a successful copying of data fields.) Hiding controls until they were needed improved usability by reducing interface complexity and making next steps clear.
The lesson from this project is that while dynamic behaviours can be documented in wireframes, it’s hard to think dynamically when you’re drawing statically, and the HTML prototype was critical to developing screen-level interactions that provided a far better solution for the user.