Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
EAN: 2147483647
Year: 2005
Pages: 334
Pages: 334
Authors: Everett N McKay
Unfortunately, the reality of prototyping is a bit more complicated. There are several traps with functional prototypes that a hapless software developer can easily fall into. The problem is that effective prototyping isn't as easy as it appears. Some of the myths about functional prototyping that help explain why include:
Let's look at each of these problems in detail. Note that in this discussion I'm referring primarily to functional prototypes (again, prototypes consisting of functional, working code). Later in this chapter, I'll discuss other forms of prototypes, which do not involve functional code. The following problems do not necessarily apply to nonfunctional prototypes.
Functional user interface prototypes are often justified because they are easy to create and change. Easier to create and change than what? Than fully functional production code? Perhaps, but they are not easier to create or change than paper designs. You can sketch out a window design on paper in seconds. To create the equivalent functional window design with your favorite prototyping tool will take minutes, if not hours. Of course, the more detail in the prototype, the longer it takes. I have seen people spend several months to create a prototype.
Try the following experiment: Draw a complete dialog box design on a sheet of paper. Now throw it away and do a completely different design. How do you feel? Not too bad, I assume. Now create the same dialog box using your favorite programming tool. Write whatever code it takes to make it functional. Now throw that away and implement a completely different design. Be sure to make that design functional as well. How do you feel now? Undoubtedly, you feel like you have wasted a great deal of time and effort. The extra time and effort required to program creates a sense of commitment to the design and a resistance to change. Try asking someone to completely redo a prototype that they have spent a couple weeks on and see how they react. It won't be with enthusiasm—unless they are paid by the hour.
TIP
The more time and effort you spend creating a prototype, the harder it is to change—defeating the very purpose of the prototype.
Functional prototyping promises to be a low-risk activity because the prototype code is going to be thrown away. Its disposability allows you to cut many corners and adapt the shortest of short-term thinking. You can easily justify skipping most of the normal design process and developing horrible code for a prototype, safe in the knowledge that all that rubbish is going to be thrown away. Why spend valuable time doing things right when the prototype is headed for the trash heap anyway?
After you have made all the changes and everyone is satisfied with the results, you throw away the prototype and completely redesign and implement real production code. Well, that's the theory, but the reality is usually different. If the prototype is successful and everyone is happy, everything changes. Instead of throwing it away, why not "evolve" it into commercial code? You don't really have to start completely over, do you? After all, the project is behind schedule, and the code "almost" works. Why not fix what is wrong and move on? Whatever problems the prototype has can be fixed with a few tweaks here and there, and everything will be fine.
In marketing, the tactic of advertising one thing and selling another is known as bait and switch, an illegal practice that leads to criminal penalties and fines. In software development, this tactic is often known as rapid development, because it gives the illusion of quick progress. At least initially. When a project is under schedule pressure (and what project isn't?), the temptation to "evolve" the prototype into the end product becomes irresistible. As a result, functional prototypes are rarely thrown away.
Once this fateful decision is made, the situation don't seem so bad at first. After all, the project seems to be progressing nicely. There is plenty of software to show. But over time, you begin to discover why careful design is important. You discover that adding minor features that should be simple are in fact quite difficult. In fact, any change becomes very difficult and the initial rapid progress comes to a screeching halt. A single word describes code that was evolved from a rapidly developed prototype. That word is dreck. In programming, few tasks are more tedious and time-consuming than maintaining poorly designed, poorly implemented code. Ironically, this situation often happens as the result of misguided effort to achieve "rapid development."
TIP
If you don't throw it away, it isn't a prototype.
Some programmers like to design, but others are uncomfortable with it. They feel more comfortable holding a keyboard and mouse than a blank sheet of paper and a pencil. But all programmers like to program—that's why they are programmers. If they really liked to design, perhaps they would be designers instead. If you give a programmer a programming tool and ask him to design a user interface, the programmer is totally happy. While you might call this process designing, in reality it's programming.
Why? Because the focus is on writing code. When you are implementing code, the decisions you make are implementation decisions, not design decisions. The issues considered don't include whether the dialog box is necessary or whether the navigation to and from the dialog box works well. Rather, the issues considered are more along the lines of how to use the programming tool and how to implement the dialog box functions. The issues considered aren't what the behavior of the dialog box should be, but how to implement it. This leads us to a general conclusion: the more programlike a design is, the less effective it is as a design.
When someone presents a functional prototype to me, I too look primarily at such implementation issues. Although I should know better, the fact is that when you're looking at a functional prototype, it's difficult to consider anything other than implementation. For example, when someone asks me to check out a dialog box they've designed, I look at things like command button placement or the labels on the controls. While I would like to examine the larger design issues, often I can't. What are the user's goals in using the program? What are the goals of the program's design? What task is this dialog box for? How does the user get to the dialog box? Is using this dialog box the best way to perform that task? Who knows? I can't tell just by looking at the dialog box—I need to understand the task at hand and the program's design. If a programmer asks your opinion about a dialog box and instead you ask him all these questions, don't expect him to ask for your advice in the future. His goal is to get help implementing that dialog box, not to get a lecture about user interface design principles.
Focus on design-related issues during the design process. Design, and then implement. Don't implement, and then implement again.
TIP
Programming is programming, not matter what you call it.
While one of the most important objectives in prototyping is to get good user feedback, the fact is that getting user feedback can be difficult to do and the results are often difficult to evaluate. There are several reasons for this. The first is that prototypes are mock-ups that must have significant functionality missing. As a result, users adjust their expectations and react to prototypes differently than to real programs. It's hard to use a mock-up exactly the same way as a real program. It's also hard to be critical of a user interface that you know is a mock-up. A user can easily explain away all minor shortcomings by thinking, "Well, this is just the prototype. All these minor problems will be fixed in the real interface." Furthermore, users don't use prototypes for long, and, because of their lack of experience, users often blame themselves for errors, instead of the prototype.
TIP
Users know that a prototype user interface isn't a real user interface, so they use it and evaluate it differently. It is harder for a user to be critical of a prototype user interface than of a real user interface.
The user needs to be able to communicate any problems or concerns that he has with the prototype. But if an interface is bad, don't expect the user to understand why or how to fix it. In fact, the user might feel embarrassed to say anything at all. I have seen prototypes that were just horrible, yet they received what could be interpreted as positive feedback. (Part of the reason this occurred was that the entire program was prototyped and evaluated as a whole. Had the prototype focused on individual tasks, its failure would have been much more obvious.) The effectiveness of prototype evaluation cannot be taken for granted. To find many types of problems, you need to test real software with real data on real tasks with real problems. I discussed these prototyping problems in detail in Chapter 8, "Users Aren't Designers"
Suppose up to now that you have done everything right. You have created a real functional prototype that you are actually going to throw away. During the process, you focused on design issues, not implementation issues. You developed it quickly, and you were able to get excellent user feedback and make appropriate changes to satisfy everyone. Now what? You now have to turn the prototype into a software design. But you can't just hand a prototype to a team of programmers (often referred to as throwing it over the wall) and say, "Here, implement this, only do it the right way—with plenty of design and all that." You need to provide much more information than just the prototype.
Again, the problem is that prototypes are mock-up user interfaces with significant functionality missing. You need to interpret the prototype. You need to indicate which parts of the prototype are intentional and which parts are arbitrary. You need to specify which parts need to be changed and which parts are missing. In fact, what you really need to do is create a complete design document. The prototype itself is not a good specification.
TIP
You need to interpret a prototype by creating a design document.