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.
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.
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.
- Beyer, H., & Holtzblatt, K. (1998). Contextual Design. California: Morgan Kaufmann Publishers.
- Cooper, A. (1999). The Inmates are Running the Asylum. Indiana: Macmillan Computer Publishing.
- Gause, D., & Weinberg, G. (1989). Exploring Requirements: Quality Before Design. New York: Dorset House Publishing.
- Kovitz, B. (1998). Practical Software Requirements: A Manual of Content and Style. New York: Manning Publications Company.
I agree with you, Horacio — part of the problem is that many people tend to think of software prototypes as “the real thing, just not done yet.” (This is a problem when it’s the business people thinking that; it can be a disaster when the engineers do, then go off and start coding from the prototype.)
But your analogy of concept cars doesn’t quite work. Many concept cars are purely style exercises intended to display the creative prowess of the company’s designers and engineers, to unveil a new design direction, what have you. Most of the time, the vehicles don’t run at all, or have a simple stock motor in them to power them up the ramp to the stage. A stylish, but non-functional, presentation seems exactly the thing Ms. Quinn is trying to avoid with her technique.
A better analogy, I think, is the foamcore scale models architects (the building kind, not IAs) create to illustrate the physical and spatial aspects of their designs. These mock-ups are impossible to confuse as the real thing (unless you’re Zoolander), and they can be very effective at communicating the concept of the design, while hinting at the execution of it (“brown construction paper means stucco”).
Granted, a foamcore model benefits from a size that is drastically different from the real thing — something an interface mock-up doesn’t usually have. But what about using “model” instead of “prototype?” (Yes, “model” is a loaded term too, but I thought I’d throw that out there.)
I completely agree with you guys about the name “prototype.” Beyond everything you’ve said, I also have trouble with my corporate clients who tend to think of a prototype as a coded, very functional, often mostly done thing. It’s just hard to come up with something that gives the right connotation without (a big consideration with my clients) sounding too fuzzy and “internet-y”. I feel like “model” implies a diagram rather than something interactive (vision model?)…. And “shell” is perhaps a little too conceptual? Maybe “site conceptual structure”? I don’t know, it’s hard—which is why I always end up back with prototype.
David, I’m sorry, I don’t understand your example. All I see in this is that the clock designer is a poor designer—he apparently built a prototype without even talking to anyone, without trying to ascertain anything about what his users wanted or needed. I’m certainly not advocating that. The prototype certainly doesn’t substitute for data gathering in any way—it only provides a format for documenting the same things that a requirements document does, in a way that I’ve found to be more useful to both the client and users.
it’s seems to have been a while since the last note in this thread, oh well.
i find myself in an odd position, i’m an internet producer for a large corporation, i am the client yet i’m doing the work you all are discussing.
i have found iterative vision prototyping to be the best way for me to explore solutions. most of my prototypes never make it to the agency but they all form the foundation of my requirements documents. luckily, the agency has never confused my prototypes as final…
i provide working flows and schematics to the agency at kick-off and have found that while they have helped clarify a bit, they have not solved all the problems of articulating site information architecture and page content/messaging hierarchies for example. maybe it’s because my audience is ultimately designers and engineers and these documents must get through a layer of account and project management, or maybe i’m not finding the “art” of too much vs. not enough detail…either way, as always, my requirements packet is a constant work in progress.
i wonder if you all have any ideas about how clients could better present our/their requirements and solutions so that you all can take the project to where it needs to go.
thanks for your wisdom, it’s great fun.
This is a really interesting question. Strangely, the idea of clients doing useful requirements is so far outside my realm of day-to-day work that I had an immediate gut reaction to the question. It’s as if you asked how we could get users to better define their requirements—my gut says that it’s not the job of either or users or clients to figure out their needs or how to present it, it’s the job of the consultant to define it. But that’s certainly too many years of consulting talking.
While I’ve specialized over the years in doing high level definition for people who didn’t have any idea what they wanted—and thus got a lot of quite technically un-savvy clients, certainly that’s not the only workable model. It makes a lot of sense to me to say that one should have an in-house expert on feature definition and high level design who can be counted on to figure out the right system for the organization, and then guide the consulting team.
Which is what it sounds like you’re doing– essentially doing high-level design (i.e. not just feature definition but also basic ia structure and functional design—through schematics and process flows), and then handing it off to someone else to do the detailed design or even just build. That’s always a hard thing to do (as there’s just a substantial amount of stuff in your head at that point that’s hard to convey).
I’m not sure exactly what you’re documenting, but it seems to me that it would be useful to do full IA documentation for whatever work you’re doing. Feature definition documentation through user profiles, as-is scenarios, interview notes, prototype, text requirements document… And then sitemaps to represent IA…process flows, page flows, use cases to represent functionality….detailed wireframes of every page, if you’re doing that level of work.
It’s hard to know what might work without knowing more about your projects and you’re responsibilities compared to the agency’s….
I think this is a pretty dead board… email me at email@example.com if you want to talk about this more.
How can clients convey useful requirements – a very interesting question.
I think it depends to a great extent on your audience (the members of the agency team you’re handing off to). Different team roles require different aspects of the documentation that Laura listed out. Visual designers might focus a bit more on any basic page layout you have, java/back-end developers might focus on the data model or specific interaction behaviours, etc.
The more you can structure your information so that your users (the agency) gains maximum use out of it, the more successful the handoff process will be. (Sorry for stating the obvious). I think having you walk through your prototype and thought processes with the consultants would be very useful, along with the other documents (site maps, etc.) for reference.
The reason is that the nature of a prototype makes it a gestalt combination of requirements and mental models and design makes it difficult to document; it really is more than the sum of its parts. There is always a leap to make when translating requirements into a prototype, or decomposing the insights from the prototype into requirements documents. Thus, having the actual prototype can really give some insight as to which path was chosen from the multiple paths available as specified by the requirements.
Laura, great article by the way. I’m a big fan as well of iterative prototyping. I’d be happy to discuss this further as well.
Vision prototyping is great (when it works). No one can argue that hitting the nail on the head from the start, with a truly representative prototype, is a great jump-start into product development. The article suggests that prototyping prior to defining requirements is more “real-world” and practical than the pie-in-the-sky approach of functional analysis followed by prototyping. I would suggest the opposite.
Pre-requirement prototyping can be dangerous in three major ways. (1) It can perpetuate existing and ineffective visual metaphors, (2) Establishing a visual prototype early inevitably shuts down further innovation in screen design, and (3) It creates a “wag-the-dog” process where requirements are justified on their ability to conform to the visual aspects of the prototype.
It seems to me that the vision prototyping process is more reliant on an ideal world than the traditional methods of requirement definition.
David, let me go through your points.
(1) It can perpetuate existing and ineffective visual metaphors and (3) requirements are justified on their ability to conform to the visual aspects of the prototype.
I’m just not sure what you mean by this first one. Presumably you’re not perpetuating bad things unless your prototype itself uses an ineffective visual metaphor, so I would guess you’re saying that it’s more difficult to define an effective metaphor before finalized requirement than after. I’m not sure why this would be. Although I’m not sure I would use a “metaphor” as all, if I wanted to, it seems to me the right time to define it is when you have a strong idea of the user needs and stakeholder priorities (i.e. you’ve just finished your research phase), but before you nail down all the detailed explicit functionalities for the site. And then to me it’s a good thing that you’re justifying requirements based on that—as otherwise you’re trying to determine what conceptual model you can glom together based on the hodge-podge of features you’ve got left after scope was defined, as opposed to ensuring that your features will all hang together to create something meaningful for the user.
(2) Establishing a visual prototype early inevitably shuts down further innovation in screen design
I guess this would depend on how detailed your prototype is compared to the size of the site, but I’ve never found it to be the case. I’ve in fact defined vision prototypes that really had no relation at all with the final page flow, let alone screen design. And since you may well be cutting scope between the vision and the wire frames, there may obvious reasons to change things up substantially. As I mention in the article, this may be more of a issue for a small site. If you’re representing a 20 page site with a 6 page prototype, I would be concerned about exactly this as well. But representing a 100 or 200 page site, it’s going to be obvious that the prototype isn’t screen design.
As to your point in regard to ideal world and practical approaches, I think you’re measuring a different dimension that I was in the article. What I intended to say is that the vision prototype is more *tangible* to a client than a requirements document—that it’s easier for a client to understand and relate to something that’s visual than something that’s just a list of terms. I believe you’re referring to the methodology as a whole as opposed to the deliverable itself. I certainly agree that the methodology I outline as a whole is more conceptual (and perhaps more “pie-in-the-sky”) than a requirements analysis based on the traditional techniques of essentially asking users and stakeholders what they want. Certainly this is a more straightforward approach, but I would argue that it’s by definition not user-centered, as it depends on users translating their own needs into requirements. My methodology puts more responsibility on the designer to actually *design* (as opposed to analyze)—which, yes, makes it more conceptual.
I find that clients can almost never make as much sense of a traditional requirements doc (think RUP or your own version) as they can of a visual representation. Even then they need walking thru the prototype, asking questions along the way to both understand the idea fully and exposing issues we didn’t think of/realize before.
I also have found the visual prototype useful in setting the right expectations for the level of detail a discussion should have. When the prototype looks “sketchy”, it sends the message that “this discussion should stay at a high level”. Text documents in a meeting(especially Excel pages) almost always tend to sink towards too much detail early on. On the other hand, a really high-fidelity prototype also gets mired/involved in lots of detail.
In fact, I have found with client teams that one of the key issues is dealing with the need to stay at the “right” level of detail during various stages of the research/design activity.
Since our craft has a lot to do with labeling, I’d like to point out that part of the problem, conceptually speaking, is the traditional definition of a protoype: think about concept cars: even though they’re “prototypes”, they are quite functional.
What I usually do in this regard is to call the damn things “shells” (think “turtles”). If I offer a shell, nobody’s going to confuse the thing with a final product, and in fact I can be as high-level or as specific as I want.
Hope this helps.
Comments are closed.