Comments on Defining Feature Sets Through Prototyping

Xavier Fan — Tue, 28 Aug 2007 00:30:04 GMT

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.

Laura S. Quinn — Tue, 28 Aug 2007 00:30:04 GMT

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 laura.quinn@intrasphere.com if you want to talk about this more.

marko z muellner — Tue, 28 Aug 2007 00:30:04 GMT

hello everyone,

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.

Laura S. Quinn — Tue, 28 Aug 2007 00:30:04 GMT

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.

David C Dunkle — Tue, 28 Aug 2007 00:30:04 GMT

The art of design is like a cuckoo clock maker who was summoned by the King to create the finest cuckoo clock ever for the Queen’s birthday.

Now, in addition to the obvious artistic carving that goes into cuckoo clock making, there are size calculations, audio ambience design, and a motif, or “metaphor” for the general mood that the clock presents. This includes the color, size, choice and composition of accessories, etc…

After a series of interviews with the King, the clockmaker began a prototype design. This consisted of a somewhat fleshed-out wooden shell, with a bird on a spring, fastened near the top. The King sort of “bought-in” to this vision of the gift, but it was hard to separate his functional preferences from his opinion of the workmanship of the prototype. The King would say, “This wood is too dull and rough”, and the clockmaker would reply, “Try not to focus on the wood, that isn’t the way it will look when it’s done”, or the King would say, “ Can we make the bird more lifelike?” and the clockmaker would say, “Oh yes- that is our intention in the final product.” The King wondered out loud, “What will it be like when the clock wakes the Queen up in the morning?” and the clock maker assured the King that the chime, or “cuckoo” would be most harmonious. In the end, the King agreed that his suggestions were being considered, so he accepted the design progress being made, but something bothered him in the back of his mind. As much as he tried to tie his concerns to an aspect of the prototype, it always seemed that he was criticizing the look-and-feel, and he was sure his concerns went far deeper than that.

On the morning of the Queen’s birthday, the clock was ready, and the King led his Queen into the presentation chamber. With great flourish, he unveiled the clock, and it did look magnificent! But the Queen could only manage a Mona-Lisa-esque smile; she was pleased, but not overwhelmed.

At that moment, a bluebird flew into the chamber, alighted upon the King’s staff, and broke into song. The Queen’s eyes lit up; “Oh my dear husband, what a wonderful sound to wake up to in the morning!” The King, being of quick intelligence, ordered his men to capture and cage both the bird and the clockmaker, but only the bird was housed in the Queen’s chambers from that day forward. You see, a cuckoo clock maker tends to solve all problems with a clock, and unless he is careful to refine his customer’s requirements prior to offering a solution, he might not realize a different alternative is superior to the original prototype.

designjerk — Tue, 28 Aug 2007 00:30:04 GMT

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.)

Horacio Salazar — Fri, 26 Jan 2007 14:50:50 GMT

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.

Ralph Lord — Fri, 26 Jan 2007 14:50:50 GMT

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.

laura s. quinn — Fri, 26 Jan 2007 14:50:50 GMT

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.

David Dunkle — Fri, 26 Jan 2007 14:50:50 GMT

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.