Fake It Convincingly

Faking it is a very important strategy. It crops up constantly in the form of GUI Prototypes, Look and Feel simulations, part-function simulators and other "the product isn't quite there" strategies which let stakeholders get the feel of what is going on even though the fidelity is not quite 100%.

Some good strategies related to faking it convincingly are ManualAsSpecification (or "manual up front" ) and PaperPrototype. These are essentially communication strategies, not necessarily implementation strategies, although they can operate in both capacities. Also they tend to be scale dependent and become more important as the scale grows larger. --RaySchneider

In a situation where users are deeply concerned with human factors, PaperPrototype can be an excellent way to avoid doing any actual work. GUIs can absorb any amount of effort you throw at them, and the last ones aren't that much better than the first ones.

You can consider ten GUI layouts on cards in the time it takes to prototype one. Good strategy. --RonJeffries

I'm not sure I agree with this, Ron. I expect its largely true if the GUI is simple and static, but any form of detailed clickable graphic, animation or dynamic display makes paper/card GUI layouts impracticable. Recently I was involved in a massive battle about GUI possibilities conducted on whiteboards, paper and OHP slides. It took weeks. Once each combatant spent a day or so putting together a prototype, it was resolved in half an hour at the next meeting.

Consider the very simple case of a four pane display, where each pane can have three different types of content. It should be quite simple to prototype in most prototype systems, but 81 (3^4) almost-but-not-quite identical cards would be tedious and error prone to produce. --FrankCarver

Consider this. Use a simple prototyping system that will give the 3^4 screens (either HTML or Visual C++, don't have to use the final product), then bring up the screens one at a time, and print them to paper. -- NickBishop

Consider this, too: Make 12 cards (3*4) which each bear no resemblance to each other. Switch them around as needed on a table as a demonstration of the intended interface of your system.

Nah, nah, nah. Everybody and his idiot brother has a laptop with a browser on it, right? Use HTML forms and some JavaScript(even though JavaScriptSucks) to put together a GUI demo. It should be pretty easy to do, and it can be modified on the fly pretty quickly, too. That's the great thing about HTML and JavaScript. This stuff is just interpreted text, so it's easy to change right there in a meeting.

The primary applicability of PaperPrototype is in the conceptual phase prior to the project go-ahead. Then you can indeed consider and present a number of ideas to decision makers and get a tentative approval for the project. Since PaperPrototype subsumes interface mockups (i.e. I intend it to cover all the "show slides with buttons" kinds of things) it is often very helpful. If on the other hand you have a InterfaceCzar who is designated to dictate what happens you don't need it. But you better have a czar that knows the mind of the customers. --RaySchneider

I think one of the main problems with implementing GUI prototypes is that they are misleading. People (especially users) who see a GUI prototype tend to start thinking of the system as done because they can see the system "working". That perception can be very hard to change.

In terms of communication - what you have communicated is a false level of doneness. This is one of the reasons for keeping the GUI as simple as possible until the foundation for the system has been completed. The system is not complete and neither is the GUI.

PaperPrototype(s) can help avoid this problem. The PaperPrototype is clearly not the system, but still allows users to give useful feedback. -- AnnAnderson

FakeItConvincingly is absolutely essential when you are using a GUI prototype to do UsabilityTesting. The prototype is not being used as a demo ("what do you think of..."). Instead, you watch users perform tasks to determine whether they can successfully perform their jobs using your software. If you can't FakeItConvincingly, your testing is worthless. In my experience, FakeItConvincingly is the hardest part of GUI prototyping.

My employer brags about how 1500 users gave input on a new product. This "input" was UsabilityTesting on a GUI prototype. (See http://www.medtronic.com/news/298kappa.html) -- SusanJohnson

You don't have to prototype using the same thing as the final product. We prototyped an operator's screen using html, but the final thing will be a Java program (I think ... ?).

Wanna hear a sad story? In a system under development it prints a tree-like structure on the GUI - but the tree is not sorted. When we made up some printed posters of the system, the Marketing Guru told the guy doing the screen shots to graphically edit the picture to shift the entries around until they appeared sorted.

-- Nick Bishop

You are who you pretend to be.

Nice motto for a wannabe "doctor" that will operate your appendix. Lucky software developers don't make life threating software. Or are they?

Is this the same as FakeItUntilYouMakeIt?