1 Only works if all of you pages are STATIC !

[QUOTE] . . . we can rapidly go through the discovery (a.k.a. scope creep) process, taking successive passes at arriving at a finished prototype—one that looks identical to what the application will look like.
[ EMP. ADDED: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^]
Once we arrive at that point, where both the client and we agree that discovery is complete, we “freeze� the prototype—meaning that no other changes can be made (at least for this version). . . . With these tools and techniques, we know when to start writing markup and code (when the prototype is frozen) and—just as importantly—when to stop (when the prototype “runs�).
[/QUOTE]
Bah! NO, you’ve only captured (at best) the part of the requirements that can be conveyed by the static appearance of prototype. For systems with non-trivial dynamics (i.e. anything more complex than a simple brochure-ware site or anything that looks like an application), you’re missing a whole bunch of ESSENTIAL stuff: – field-level validation – form-level validation – text formats (input and display) – dynamic form behavior (i.e., enabling/disabling other controls depending on, say, a radio button selection). – conditionalization of page-page navigation (go to page X if A is true, else go to page Y) – business rules – animation – dynamic widgets (i.e., sortable table column headers).

Yes, you can end up programming half the eventual application/site if you try to portray too much of this stuff in the prototype, but you do have to document it somewhere, somehow.

As far as knowing when to stop modeling and start coding, a better way to do this is to have your users (or people who look like them) try to perform key Use Cases with the prototype. If they can successfully perform each key Use Case and they (or your subject matter expert) agree the the prototype fully covers the task(s) at hand, then you’re ready to proceed.

posted at 09:25 am on September 20, 2002 by Banned in Boston

2 but clients like to see things

I’ve been making use of Hal’s Wireframe Tool for a little while, and DevNotes for much longer. I have to say, while I find Wireframing useful for me, it’s been a complete bust for using with non-techies. I think for many clients, the abstraction required to visualise your non-existent site as essentially logic gates is too much, They don’t get it. Hell, my project manager on most projects, who’s seen me wireframe at least a dozen projects now, claims to never get a feel for the site from the wireframe. So I use it for myself, mostly to test use-case scenarios, but it’s been no help at all in terms of setting scope to me. Perhaps if my contacts with clients were all CTOs. But they’re not. I think tellingly, the only client I’ve had who found wireframes useful was, like me, in her early 20s and had been using computers since she was wee. The average client, in her late 30s or 40s, who got online since 1996 seems to need to see visuals.
So I’m not at all convinced that wireframing embraces scope creep. Hal seems to be using it as another way to prevent scope creep once the real work has started, by making sure it’s all been accounted for previously. In many ways, embracing scope creep seems a pie-in-the-sky fantasy: by its definition, it is impossible to budget for scope creep in a fixed-fee project.

posted at 09:45 am on September 20, 2002 by Stv.

3 PHP Version

He mentions a PHP version of the Wireframe Builder which I’m having trouble finding and the demo at bjork.net doesn’t seem to be working. Anyone know where to find the PHP version or see a working demo? Thanks.

posted at 10:33 am on September 20, 2002 by Walt

4 Who is the customer?

Hal, great article… I am glad someone finally wrote about this issue. I do, however, have a few problems with this article:

“Scope creep is the pejorative name we give to the natural process by which clients discover what they really want.”

Why is it that the client’s are the ones determining what they want? From my years of experience I would have to say that the developer/designers are responsible for determining what the site or application should entail, the client is the one that brings the goals of the site or application. The actual end result is the “user” defines what is needed by way of use cases, user testing, focus groups and more.

Basically if the client wants a 3D spinning logo with fire on it, fine, but I don’t think the actual user wants to see that (obviously depending on the focus of the site and intended target audience). Don’t design for the client, design for the user but meet the client’s goals.

Also, a word about wireframing: I use them as often as possible, however I would never deliver them to a client. Clients don’t “get” what a wireframe is no matter how many times you explain it to them…. “Is this what it’s going to look like?”, “Will there be lines and boxes like this?”, “Where is all the color?”, “I don’t see the logo”, etc. A wireframe is an internal deliverable. A mockup is an external deliverable.

In addition, I want to mention that while scope creep may not be avidable, it should always come with a cost to the client. Yes, I agree it is good to make changes to the master plan to accomodate the user’s need, but I don’t believe the web designers or developers should be made to take the brunt of tight schedules and projects that are over budget. Kelly Goto has a great book that covers some of these kinds of things… she focuses on workflow so it covers a lot of ground, but scope creep is in there to some extent.

Lastly, if you are developing or designing complex sites or applications the amount of work that goes before a single HTML tag is typed should be approximately 1/3 of the time and costs of the overall schedule and budget. Anything less is cheating the client from what would otherwise be a good web site or application. The code should be “written” (in text) before it is programmed this way it ensures a detailed understanding of how it will function and what it should look like. This is why there are technical specs, functional specs, style guides and IA deliverables.

I think that it would be a good thing to have a part 2 to this article that addresses effective methodologies for avoiding scope creep (not that it’s really avoidable).

- Nick

posted at 12:01 pm on September 20, 2002 by Nick Finck

5 Scope Creep Is Consultant Failure

When engaging a client in a project, I always develop a specification. The larger the project, the more detailed the spec. The spec is the reference for the project. It is the beginning and the end. All development is done according to the spec, as well as progress evaluations. When anyone proposes a new feature or questions the design, I refer them to the spec. Sometimes the spec can be tweaked, and sometimes the customer request threatens the projects foundation.

Every time I’ve had a problem with feature creep, it’s because the spec wasn’t detailed enough or non-existent. True enough, customers hate ccollaborating on specs—-they don’t know what they want and don’t want to waste time and money talking about it.

Write better specs and this problem will cease to exist.

posted at 03:00 pm on September 20, 2002 by Robby Slaughter

6 RE: Scope Creep is Consultant Failure

Robby: I would strongly disagree with the statement that pre-build specs are the answer to getting through a project without scope-creep. In the hundreds of projects I’ve worked on, the most satisfying for me and my clients have always been the ones with a short, focused, feature-driven development cycle.

Extensive scoping with Specs is great for me as a person with a background in web development, but for most of my clients (Marketing, sales, and managers) the specs are just words on paper, and they often have little correlation to what they actually want. Let me rephrase that: “The specs have little correlation to what the clients FIND OUT they want.”

This comes back to reducing scope creep (which I think this article didn’t actually covered) by reducing the size of the development cycle. The longer the loop that the designers and developers have to go through before the client sees the results, the more likely that there will be changes to original specs, and the more likely that the end work of a loop will miss the mark of what the client actually wants.

Right now I’m trying to move a client into a more ‘agile’ development cycle: results of small changes in weeks vs large changes in months. So far, the weekly cycle has been more effective for the client, their users and the support staff.

Specs (IMHO) are a wonderful thing in theory, but Nature abhors a Detailed Spec. They rarely exist in Nature.

posted at 03:47 pm on September 20, 2002 by Ross Olson

7 RE: Scope Creep is Consultant Failure

Ross:

Clents seem to always want features or changes we didn’t discuss originally. Specs just form a record of that original conversation, so that there can be no basis for argument.

It sounds like we typically work with different kinds of clients. Most of the clients I work with expect to be able to rattle off their needs and meet up with me after a few weeks or months to see the (practically) finished project. I very rarely find that my clients willing discuss continued progress at each step of the way.

Would I rather have a shorter, more “agile” development cycle as you describe? You bet. And it would reduce the amount of time and energy spent in building specs—-a sort of eXtreme Programming model for project execution. I’ve just not found clients willing to do that (perhaps I lack your expert negotiating skills), so the spec model works best for me.

And most importantly, all of my experiences with scope creep come from ill-defined specs. Many consultants I know don’t develop good specs and just overbudget and overprice themselves to compensate for “slack time”. I think this is unfair to client and consultant. My advice to peers who complain about scope creep is to spec heavily——from now on I will also propose shorter development cycles based on your recommendations and experience.

posted at 05:58 pm on September 21, 2002 by Robby Slaughter

8 RE: Scope Creep is Consultant Failure

Robby:

I completely agree with the idea that you and I may have different sets of clients. And I would add that perhaps different methodologies should be followed for different situations: I can say that an Agile cycle only works once you’ve reached a point where there’s a usable project. A Deep cycle would be a good name for the first release of the site I’m working on now. It took 11 months to develop the first release. It was certainly a Deep cycle. The first time the client really had some hands on with the final piece was 4 weeks before launch, far too late to make some changes they wanted.

I guess it’s a bit like bridge construction vs building construction. You can build a building 1 floor at a time if you have too. Each floor can be a success unto itself and each floor can build upon the others. But a bridge has to be built all the way before it’s usable. Deep cycle = Bridges. Agile cycles = Floor by Floor buildings.

You and I seem to agree on the idea of getting as close to reality as possible. I hope other project managers/creative directors/producers share that.

posted at 11:52 am on September 22, 2002 by Ross Olson

9 so far i love it

just read the article last night, showed it to my back end girl,
she installed it, and we set up a project i hope to sign tomorrow.

so far its great for the two of us collaborating, we work remotely,
and it really beats a huge thread of emails which never really present a
final and collected project.

i do have my reservations on how the client would feel, and i probably will not show it this time around. I think some very basic CSS positioning such as MENU: is aligned on the left and a HEADER bar would really help the client to visualize the project. oh, and REALLY large disclaimer stating “Design has not been addressed in these Wireframes”
;)

posted at 02:31 pm on September 22, 2002 by rob rhyne

10 related joke seen on newstoday

how many designers does it take to change a light bulb?

f*(& you, im not changing anything!

posted at 02:32 pm on September 22, 2002 by rob rhyne

Discussion Closed

New comments are not being accepted, but you are welcome to explore what people said before we closed the door.

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)