Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
EAN: 2147483647
Year: 2005
Pages: 334
Pages: 334
Authors: Everett N McKay
In the following sections, I'll describe the roles of your nonprogramming team members in the user interface development process.
Management and marketing's biggest contribution to user interface design is to make sure that the product includes the necessary features required for it to sell (which is the ultimate business goal of commercial software products) or to satisfy the customer (which is the ultimate business goal for contract work or in-house development). They are your connection to the marketplace and the customer, so their input is critical to the success of the project.
The biggest problem I have experienced with managers and marketers is their fascination with vaporware. They seem to be enthralled with the concept of being able to tell their customers that they can completely satisfy all their needs without knowing whether the software they're promising can actually be developed. Consequently, the biggest challenge with working with management and marketing is to make sure that they are not creating unrealistic customer expectations and that they are countering unrealistic expectations that do exist with honest facts. With so much vapor, sometime you need to nail their feet to the floor to keep them from floating off into space.
You should take advantage of the talents of a good graphic designer whenever possible. At the very least, you should have a graphic designer create the program bitmaps, icons, and animations and review user interface designs. In some cases, you might want a graphic designer to create the entire look of the program. Since the amount of time required to do these designs is small compared to the time it will take you to implement them, graphic designers can make a significant contribution to the overall product without significantly affecting its cost.
The first time I worked on a project with graphic designers, I was certain a graphic designer wasn't necessary since the task didn't involve anything even remotely graphic. In fact, the program worked entirely with text and very simple text at that. However, I found working with graphic designers to be an enlightening experience. Their contribution added a certain snap to the product that it never would have had without their help.
Of course, everyone has their strengths and weaknesses, and graphic designers are no exception. Good graphic designers focus on visual communication (especially visual affordance, through which a user can determine how an object is used just by looking at its visual clues), whereas not-so-good graphic designers focus on visual decoration. The not-so-good graphic designers are under the impression that if each visual element of the user interface uses a metaphor, has a textured background, is in 3-D, and has an icon associated with it, then for sure the user interface is a good one. While it's possible that this approach will result in a good-looking user interface, a program's visual appearance is only a small part of its overall usability. A lot of cheesy CD-ROMs and Internet sites are like this. They look great, but their functionality and usability are poor. By contrast, the visibility of the program's functionality—the degree to which the user can figure out how to use it just by looking at it—is a significant part of the overall usability. Work with graphic designers to increase your program's visibility—visibility rather than pure aesthetics is what you really want from graphic designers.
TIP
Use graphic designers to improve your program's functional visibility and its visual appeal.
Technical writers are in a unique position: their job is to describe in a reasonably concise and coherent way what your program does. If a user interface feature doesn't make sense or is difficult to use, your tech writer will surely know it. Technical writers are especially good at recognizing nonstandard user interface designs, overly complex user interfaces, inconsistencies in the user interface or the terminology, commands that are missing or hard to find, and poor or misleading error messages. I find the feedback from good technical writers to be extremely valuable in discovering user interface problems.
TIP
Technical writers are in a unique position to find user interface problems.
Of course, the interesting question is what should you do when a technical writer discovers an interface problem. Should you fix the problem or only document it? Unless you are dealing with extraordinary circumstances, you should always prefer to fix the bug. To make this policy practical, make sure that the technical writing process starts early enough so that there is time to respond to such problems. You also need to make this policy clear so that your technical writer will know to report bugs instead of documenting them.
TIP
Don't document problems; fix them.
The QA team needs to be involved early in the design process to review the design and make sure that the project is on track. After all, there is no point in implementing a user interface if the design isn't any good. Members of the QA team might also be part of the user interface design team. At a minimum, they need to review the design documents and evaluate any demos and prototypes.
It's important to make sure that QA testers check for usability problems. Often testers tend to focus on objective issues, such as missing features, incorrect or inconsistent behavior, and crashes, and not on subjective issues such as usability and performance. If a tester has trouble figuring out how to perform a command or if the tester finds a dialog box poorly laid out or confusing, the problem should result in a bug report. In fact, it usually makes more sense to focus on usability issues first and then look for more objective bugs. If a dialog box is hopelessly confusing and needs to be completely redone, I would rather receive that as the first bug report for that dialog box rather than the last. There is no point in fixing a bunch of details if the dialog box needs to be completely reworked anyway.
As far as usability testing is concerned, more information is almost always better than less. Testers should feel free to submit bug reports on all usability and performance issues, even those concerning the smallest details. On several occasions when I've found a usability problem with a program I was working on, I've said to a tester, "I just found a silly bug that has apparently been in the program for quite a while." Very often the response is, "Oh, I've seen that. I thought it was weird, but I assumed that it was supposed to be like that." By encouraging bug reports on all usability issues, you, not the testers, can be the judge of what is important.
Your technical support team will have many concerns that you as a programmer rarely think about. You need to understand that developing software for technical support is different from developing quality software. You can create a program that is "bug-free" but that is still difficult to support because it is difficult to install or configure. Discuss with your technical support team what the biggest technical support problems are now and in the past and see if there are ways to avoid them in the future.
Your technical support team will likely be concerned about the following issues:
Using a good, well-tested setup program is the single most important step in reducing technical support calls. This is not an exaggeration. The reason is simple. While your program's advanced features might be its selling point and what gets all the attention, if a user has a problem with an advanced feature, maybe you'll get a technical support call and maybe you won't. But if the user cannot install your program, you will get a support call. Guaranteed. And if technical support isn't able to solve the problem, most likely you will get a product return. What good is a program that you can't install?
If the program is an upgrade to a previous release, you also need to address upgrade issues. Does the upgrade install over and replace the existing version or can the user run old and new versions of the program simultaneously? For example, note that you can install Microsoft Visual C++ 6.0 while keeping Visual C++ 5.0 on your system. This is made possible by maintaining completely different sets of configuration information in the registry that is keyed on the version number, as recommended by Designing for the User Experience. It is made practical by having the setup program automatically use all applicable user settings from the previous version so that the user doesn't have to input all of these settings manually.
Lastly, you should encourage your technical support team to review all of your program's error messages to make sure that they are clear, concise, consistent, and informative. Imagine what it would be like if someone you didn't know called you up, read you the error message, and asked you what to do. This is what your technical support staff faces every day. They need to understand the error messages and their significance well before the program ships, not after.
The Designed for Microsoft Windows logo requirements include many useful items to check to make sure that your program installs, uninstalls, and upgrades well.