System Development Methods: Chapter 8

CIS 251 - System Development Methods

Chapter 8: User Interface Design

Objectives:

This lesson discusses material from chapter 8. Objectives important to this lesson:

Interface design
Interface components
Output design
Input design
Assignments for the week

Concepts:

Chapter eight begins with Tina and David doing a sales pitch about user interfaces.They have always seemed like a couple of users, so this little play seems more natural than the previous ones.

Page 302 begins a discussion of what user interfaces are, have been, and typically look like currently. The text presents a couple of dichotomies that show changes in interface design over time.

process-control systems are characterized as older interfaces that were based on the programs that the user needed to run
The text also portrays this kind of interface as representative of systems in which users had to make requests for simple reports through the IT staff, instead of being able to ask for such reports themselves through a system interface. User interfaces were typically limited to character based screens, and were not major parts of systems.
user-centered systems are described as being used in more modern systems, allowing users to make requests for their desired output without IT staff intervention
User interfaces became more complicated when technology supported it, when systems began having graphics, and processing power supported Graphic User Interfaces (GUIs). This began around the time Windows was available on personal computers. It was at that time that user interfaces became a feature of a system, which naturally caused system developers to be interested in their development.

It is a bit unfair of the authors to characterize the interfaces of the sixties and seventies as less friendly to users, and to imply that those character based systems were designed to be unfriendly. It is more accurate to describe them as being from the days of lower computing power and less capable graphics cards. It is not so much that designers did not think about the users' needs, but that there was not much a designer could do with a system before we had decent graphics and pointing devices (mice). We owe a great deal to the graphics card industry and to Xerox PARC.

The views of IBM are mentioned several times in this section of the text. Their idea seems to be that a system should be as easy to use as possible, and that it should allow users to get what they want rapidly and painlessly. Page 305 presents a series of steps to follow in designing a user interface. These steps echo the analysis methods in the previous chapters. The difference is simply that they focus on interface design.

Understand the business - Determine what the users need to do in the interface, asking questions about their needs and making charts of their intended use of the system.
Maximize graphical effectiveness - The text advises us to use visual elements to help users function and to learn the system. Good use of screen space should be a goal for every system.
Think like a user - This means more than getting the user requirements. It means to understand what the users know, what they are used to in a system, and what will work from their point of view.
Use models and prototypes - This is a reiteration of the idea of making prototypes, showing them to users, and improving the system based on user feedback. An intermediate design step we have not discussed in this context is the use of a storyboard. A storyboard can be as simple as a comic strip, or can be a series of mocked up screen shots.
Focus on usability - The text recommends striking a balance between too much on a screen and too little. Another recommendation from the world wide web is to minimize the number of clicks needed to reach an objective. If a system takes too long to use, it will not be successful.
Invite feedback - The text reminds us to listen to users during development, and to listen to their comments after the system is deployed as well. The testers of your system may not encounter features of the system that the users will come to love or hate.
Document everything - We have seen this advice before. This time the advice is about user interfaces, but the general idea is the same: record your findings, your tests, and your results. You may continue a project or someone else may continue it, but no one can do a good job without the information gathered at each step.

When you get to the actual design stage, you should follow the principles that begin on page 307. Unfortunately, there is a good bit of repetition in this list.

Design a transparent interface - this means to make the interface support the application and the user; don't make it stand out so much that it gets in the way
Make it easy to learn and use - this makes perfect sense, but it is puzzling that this is a separate point, since it was covered in the text's expansion of the point above
Enhance productivity - A good interface makes a user more productive, and a bad one makes a mess of an otherwise good application. The text advises us to place commonly used options near the top of menus, lists, and screen sequences. Shortcut keyboard sequences are recommended, but they can also be problematic. Make sure that users want your shortcuts, and that they do not get in the way. Let me tell you about the keyboard shortcuts in 3DS Max.
Two concepts: Make it easy to get help, Make it easy to correct errors
Both concepts have to do with something going wrong. Typically, help systems address user training that has not taken place, while error correction addresses mistakes on the part of the user, the data provided, or the system itself. The point is that it should be easy to find out how to do something and how to change data that should not be in the system. The interface should not be so automatic that the user can't back away from a wrong choice.
Minimize data input problems - the most common advice is to make data input screens mimic the forms or screens that users gather their data from; the text advises that you should build data entry rules in the system so that only acceptable data may be entered in any field
Provide feedback to users - the suggestion should have said "meaningful feedback"; many systems provide error messages that are uninformative, which lowers productivity; avoid this problem by giving users helpful prompts and error messages
This item relates directly to the previous item. They could have been combined into one.
Create an attractive layout - the advice in this section is about functionality as well as aesthetics; go over all the suggestions in this list
Use familiar terms and images - this one relates to the advice to know the users and how they think; it's a waste of your time and the user's time to explain things in terms that are unfamiliar to the user

The text continues with a list of control features to consider including in your interfaces. The list is about control in the sense of operational control, not security. This is really a list of commonly found objects in a GUI, specifically features found in Windows interfaces. The features apply to iOS, Android, and other operating systems as well.

The chapter turns to Output design on page 320. It begins with standard questions that should be asked about the reports any system should produce.

What is the report for?
Who gets the report? What security restrictions apply?
What information will be in the report?
Is the report to go to a screen, a file, a printer, or elsewhere?
Is the report to be run on a schedule, or on demand?

The text discusses report types and components for several pages. You should have encountered these concepts in programming and database classes. Review these concepts starting on page 322:

detail reports
exception reports
summary reports
report features starting on page 323

Output is not limited to what most people would consider a report. Other output types are listed on pages 326 and 327. Remember that a system may output credentials, receipts, purchased tickets and coupons, and other documents and objects not listed in the chapter.

On page 328, the text turns to Input design, which may seem backwards to you. This is a common technique: decide what the system must produce first, then use that information to decide what must be put into it to make that production possible.

The text refers to the classic warning about input: garbage in, garbage out. When you enter bad data, the system can only produce bad output. In a way, it is comforting to see this familiar advice. It reminds us that we know what to do, we just have to make sure we are doing it.

The text discusses source documents, back on page 319, in terms of proper design of forms. A form can be a piece of paper or an input screen for a system. It doesn't matter if it is a paper or electronic form: proper design says to make it easier to use than the last tool. The text offers some advice on good form design. Consider some of these points:

make the form flow left to right and top to bottom: this leads to less scrolling, and fewer items being missed
make the instructions easy to see: consider instructions for each part of the form, or mouseover help on fields that need examples
validate data as it is input instead of waiting for the user to reach the end of the form
if using paper forms whose data must be transferred to an IT system, make the paper form and the data entry screens as much alike as possible

A previous version of the text discussed the opinion of Dr. Jakob Nielsen, who says that users do not read web pages, they only scan them. I would agree, up to a point. I encountered a particularly bad case of this behavior not long ago. A student told me he could not follow my notes, and that he needed to see how something is done to learn it. (Despite the fact that I had just demonstrated how to do it it. I have doubts about his chances of success in life.) I hope he is not typical of students or workers, but Dr. Nielsen seems to believe that many people have learned that they do not have to pay attention to something on a web page. I am sure the phishing scammers love this idea. We can hope that students and workers are motivated enough to notice what is in front of them. Apparently, we cannot expect a customer to meet any standard of attentiveness.

Make each screen short and pleasant.
Keep to the point.
Don't ask for things you don't need.

Review the points that begin on page 331 about screen elements that help users input data (formatting, examples, error trapping). If you are an analyst, but not a programmer, it may not have occurred to you that a system can impose the kinds of error checks presented. A well designed system should include all of these where needed. (If you are a programmer, but not an analyst, you may be shocked to learn that a user will enter unformatted or inappropriate data in a field. Welcome to the real world.)