Defining Feature Sets Through Prototyping

by:   |  Posted on
The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members.Over the last couple of years, a standard method for user-centered interaction design has begun to emerge. First, you gather background from the clients and stakeholders, conduct user research, and look at competitive sites. Then you build personas and scenarios, do workshops, and conduct brainstorming sessions. All of that is analyzed down into a grand vision of what should be built.

But what happens after that? Most of the literature in this area assumes that once the designer has a vision in mind, it’s time to move straight into sitemaps and wireframes and the rest of the business of functional design. But I’ve never seen it actually work that way. In my experience, there are always clients who need to approve the vision, scope that needs to be defined, and project managers who want detailed and concrete functional requirements from which to manage. If I’m not involved, they’ll do it without me, often leaving me with a scope and a set of requirements that doesn’t have much to do with the vision with which I started.

To address this issue, over the years I’ve put together a method to translate a conceptual vision into a set of concrete functional requirements, by way of what I call a Vision Prototype. The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members. Because the prototype serves as an explicit visual representation of the project’s needs, it can be easily translated into a set of functional requirements.

What is a vision?
This method assumes that a vision has already been defined in someone’s mind, using one of several user-centered interaction design techniques (see “For More Information” below). The vision doesn’t need to be extremely detailed, but it should answer these basic questions:

  • What’s the purpose of the site?
  • What are the main things the users will do with the site?
  • What’s the general conceptual structure?

Let’s look at an example of a high-level vision. Let’s say I’m building a website that allows Quinn Exhibition, an imaginary trade show company, to sell booth space online. In my—fictitious—user research, I observed that the floor plan for the exhibition was critical in everyone’s thought process in determining everything from number of booths to the position of a competitor’s booth. Typically, sales reps fax annotated floor plans to potential purchasers and buyers show them to their bosses.

Based on this data (and backed up by my fictitious competitor research, personas, scenarios, and workshops), my vision for the website is to use a visual floor plan as a key interface metaphor. Potential clients can see what booths are available and where booths are located by perusing a familiar floor plan format. They should be able to buy straight from the floor plan.

Documenting the vision
It’s not easy to jump from a vision in your head to a list of concrete functional requirements, and it’s not desirable, for a number of reasons. At the most basic level, creating formal documentation of a vision ensures that a vision does in fact exist. While this sounds obvious, it’s a problem that I’ve seen frequently, especially in more traditional software development processes. It’s easy to build a requirements document by piecing together what everyone says they want without any overarching idea of where the system as a whole is going. Needless to say, this often results in sites that are less than cohesive.

A visual representation also makes the vision tangible and understandable to clients, users, and the rest of the project team. This makes it possible to get feedback in this early phase and serves as a touch-point for the rest of the project. When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.

This is where the prototype comes in. I’ve had great success in documenting an ideal vision with a conceptual prototype which, in anywhere from four to ten linked pages, shows the high-level functionality and conceptual structure of the site. I’ve found that this type of Vision Prototype is both easy to create and easy to understand.

The prototype is built not to show the interface, the page flow, or the fields, but to represent an ideal feature set that makes the vision happen. For instance, I’ll often represent site functionality with a number of significantly labeled buttons (i.e., “Add New Location” or “Advanced Search”). These buttons serve as functionality shorthand—there’s no need to show an Advanced Search page in the prototype if the team will understand what a button labeled “Advanced Search” implies.

Because the prototype is primarily documenting an intended (or ideal) feature set, I carefully determine the right level of detail and functional feasibility. I try to represent the site functionality to just the necessary level of detail to allow an engineer to estimate the approximate time and money needed to create each feature. This means representing some specifics (especially for a more unusual feature), but certainly not every field on every page. I also go to some effort to ensure that the prototype feature set is ”blue sky” enough to be inspiring without being completely infeasible for the time and money. I generally think of the prototype as representing the feature set of the site two or three phases down the road.

The illustration shows two pages—a Floor Plan and a Booth Detail page—out of a Vision Prototype for the example website. The pages use both an interface-like structure and suggestive buttons (“Search All Available Booths,” “Split this Booth into Two”) to show the feature set. The prototype would include a few pages in addition to this: an overview or homepage, a static content template (to show that the content links are just pages of text), and perhaps the Buy Booth page itself.

When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.A prototype this early? Are you nuts?
It’s worth pausing here to acknowledge that the idea of building a prototype before even defining scope alarms many reasonable and experienced interaction designers. I’ve heard two different but related arguments as to why it’s a bad idea:

  • Argument 1: Functional requirements by definition should talk about needs and specifically avoid any consideration of design like conceptual structure or specific features. Something as tangible as a prototype should come after the definition of requirements, to ensure that all the issues and parameters are considered before jumping to a design solution.
  • Argument 2: Clients aren’t able to separate a conceptual prototype from an interface design or a live website. They’ll focus on the wrong details (like the page flow or graphic design), fixate on a particular detail that will turn out to be infeasible, or just generally misunderstand the intent of the prototype.

Both of these arguments are rooted in the same premise that it’s preferable to first work at a fairly abstract level to define the scope and needs of the project before looking at a visual representation that might start to limit the field of design possibilities or encourage people to determine how things should be implemented as opposed to solely what the system should do.

While this premise makes sense in an ideal world, I believe that it simply doesn’t work in the vast majority of project situations. Information architects are comfortable working in the realm of abstract functionality (that’s one reason why we’re hired), but clients generally are not. In the same way that we wouldn’t show a user a text list of features and expect to get good data about the usefulness of the system, we can’t expect a client to be able to adequately give feedback on a high-level description of functionality.

By creating a visual representation of the project vision early, we give up a little to get a lot. We give up tight control of precisely what the client will be thinking about at each phase of the project. This can sometimes result in early discussions about things, such as page flow or graphic design, that are unrelated to the decisions at hand (by the way, I’ve seen this type of thing get somewhat irritating on a project, but I’ve never seen it cause any lasting harm). But by giving this up we gain a huge advantage: we gain the active understanding, participation and buy-in of our clients. Ultimately, ensuring our clients can effectively understand, review, and discuss important project concepts will result in better products and fewer problematic misunderstandings down the road.

Does it have to be a prototype?
That being said, a Vision Prototype may not be appropriate for every project. I’ve found that a prototype is particularly good at representing highly complex functional sites. For this type of site, it can represent a lot of complexity in a format that makes it easy to review and understand. In addition, prototypes are familiar to the many companies who already use them as a standard to get buy-in on a project.

For smaller projects, however, I’ve found that it’s difficult to build a conceptual prototype without detailing every field, simply because there’s not that much to say about the site vision. A prototype also may not effectively handle the structural issues of a content intensive site. For this type of site, the prototype can be replaced by anything that’s tangible, non-technical, and fairly comprehensive—perhaps a content map, a comprehensive set of scenarios, or a page flow (when there’s not a lot of complexity in the page flow itself).

Verifying and getting buy-in on the vision
One of the main reasons to create a Vision Prototype is to allow the rest of the project team and the client to understand, review, and provide feedback on the vision. Because the prototype makes the ideas under discussion visible and concrete, it’s common for new needs or concerns to come up at this point—even in areas that might have been completely covered in previous conversations. It’s simply hard for many people to think abstractly about the same things that are made obvious by the prototype.

User focus groups can also be useful at this point. A successful vision will generally get a “Of course, how else would you do it?” response, with some suggestions for minor additional features. Confusion, lots of questions, or lots of suggestions for major new features are all signs that the vision does not correspond with the users’ expectations and model of the system, and needs to be reconsidered.

At this point we resolve any issues, and ensure that the whole team is happy with the prototype before moving forward. In this way, the prototype becomes the documentation of the entire team’s vision.

Creating a functional requirements document
Because the Vision Prototype contains a comprehensive look at ideal functionality, iterated and approved, it is itself a representation of the functional requirements. In order to translate these ideas into a more traditional document, one can simply systematically write down the functionality shown on each page. It’s also important to think through any administrative or tangential features (user administration, for instance).

For instance, looking at the Quinn Exhibition prototype, I can pull the following functional requirements (among others) from the Floor Plan page:

  • The position of each booth is displayed on a visual floor plan.
  • All hall infrastructure is displayed on the floor plan.
  • The status of a booth (occupied or available) is displayed on the floor plan.
  • Booth details, such as the size and the occupant, can be easily seen on or linked to the floor plan.
  • The user can search for a booth based on key booth criteria.
  • An administrator can define the hall infrastructure and initial booth layout for an exhibition.

Note that there’s a great deal of work left to do to completely define the functionality. What criteria can be used to perform a booth search? How does the administrator define the original floor plan? The point of this functional requirements document is not to completely design the site or define all business rules, but to establish the functionality to the point that the site can be estimated.

I put each requirement on a separate line in an Excel spreadsheet, and prioritize each based on my user research findings and client priorities. I generally use Core, High, Medium, and Low. Core requirements are ones that the site wouldn’t make any sense without—in the example site, for instance, “The position of each booth is displayed on a visual floor plan” is a core requirement. The technical team also assigns a complexity (High, Medium, and Low) to each requirement.

The actual writing of requirements takes a little practice to ensure they’re at a useful level of detail and are relatively unambiguous.

Defining scope
The last step in defining a feature set is determining what set of the functional requirements can be implemented in the next phase. I start by working with the development team to determine approximately how much time and money will be left over after achieving just the “Core” priority features. If the time and money can’t accommodate even the “Core” requirements then there’s a problem, and we need to revisit the vision. This is why it’s important not to make the original vision too ”blue sky.”

We then spend several hours as a team going through the rest of the requirements and creating a draft scope. Features are quickly reviewed and separated in to those that should obviously be included (such as High Priority/Low Complexity requirements) and those that obviously shouldn’t (Low Priority/High Complexity). Most of the discussion is around the High Priority/High Complexity and Medium Priority/Medium Complexity features and determining what can be included to create the best mix of basic functionality and strategic features. Determining a scope is more of an art than a science, as the features tend to be dependent on each other in complicated ways. Once there is a draft scope, a more detailed estimate can be made. Often there is too much for our schedule and budget and we have to go back to determine what else can be removed.

Unless the client is very detail-oriented and very close to the team, I’ve found it nearly impossible to involve them directly in the creation of the draft scope. There’s simply too much detail and too many time and money sensitivities. Once we’re internally comfortable with the scope, we can summarize it and present it. While the client almost always has changes, it’s fairly straightforward to iterate the scope because the team internally understands the trade-offs and complexities.

All the previous steps set up a framework in which to consider the issues, generally making the actual definition of scope fairly straightforward. The development and iteration of the Vision Prototype allows the whole team—both the internal team and the client—to solidify a team vision and working relationship. Scope definition, which can often be a painful process of wrangling over favorite features, is made much more straightforward by the imposition of a common vision.

Laura S. Quinn is a technology strategy and information architecture consultant for both corporate and nonprofit clients. Her company, Alder Consulting, specializes in helping nonprofits build powerful internet and database systems with the resources they have (learn more about Alder Consulting at In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.

What You Should Know About Prototypes for User Testing

by:   |  Posted on

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity “An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:

  • Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
  • As with any user test, it really helps to ask the respondent to think aloud.
  • If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
  • Use a piece of posterboard as your “screen.”
  • Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
  • Attach the folder tabs that come with hanging files to components so they are easier to grab.
  • Invite users to throw away or cross out components that they don’t think are important.
  • Number the pieces so that you can easily refer to them in your notes and keep them organized.
  • If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:

  • Scissors and tape,
  • Different sizes and varieties of sticky notes (which make great drop-down menus),
  • Markers and pens in various colors and sizes,
  • Paper clips and binder clips for keeping slips of paper organized, and
  • Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

  • Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
  • animation features provide automated interactivity,
  • Static Photoshop prototype pages shown to users on a computer screen, or
  • Same as above, but printed out in color on paper.

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

  • Testing the effectiveness of labels and icons.
  • Finding out the right balance of depth and breadth of a topical hierarchy.
  • Determining the right options to offer for narrowing a search.
  • Choosing the most important metadata elements to show on a search results screen.
  • Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.

For more information

  • Evaluating Information Architecture,” Steve Toub (2000).
  • UPA 2000 Proceedings:
    #28 – “Waving Magic Wands: Interaction Techniques to Improve Usability Testing Low-Fidelity Protoypes,” Barb Datz-Kauffold & Shawn Lawton Henry.
    #32 – “Prototyping for Usability,” Jack Hakim & Tom Spencer.
  • “Prototyping for Tiny Fingers,” Marc Rettig, Communications of the ACM, Vol.37, No.4 (April 1994). (ACM Membership required)
  • Using Paper Prototypes to Manage Risk,” User Interface Engineering.
Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web.