Ch16: User Interface Design Users often judge a system by its interface rather than its functionality Poorly designed interfaces can cause users to make catastrophic errors Poor interface design keeps many systems from being used Graphics versus text: • most business users interact with systems through GUIs • some legacy systems still use text-based interfaces This chapter: • key issues underlying user interface design, not implementation What makes a good UI? Examples of good and bad? How do users differ?
Human factors in interface design Limited short-term memory • people can remember about 7 items of information • if you present more than this, they are more liable to make mistakes. People make mistakes • mistakes can increase stress and the likelihood of more mistakes People are different • people have a wide range of physical capabilities • designers should not design for their own capabilities People have different interaction preferences • pictures/text • mouse/keyboard/voice
16.1.1 User-system interaction Two issues: • providing information from the user to the computer system • providing information from the computer system to the user Interaction styles • direct manipulation • menu selection • form fill-in • command language • natural language Give an example of each, strengths, weaknesses
16.3 Information presentation Note separation of information from presentation sw
1 4 2 3 Information display factors Is the user interested in precise information or in data relationships? How quickly do information values change? Must the change be indicated immediately? Must the user respond to a change? Is there a direct manipulation interface? Is the information textual or numeric? Are relative values important? 0 1 0 2 0
16.3.1 Color Color can • help the user understand complex information • highlight exceptional events Guidelines • design for monochrome then add color • don't use too many colors • use color consistently • avoid color pairings which clash • change color to show status change • be aware that color displays are usually lower resolution • remember that some users are colorblind
16.4 User support E.g.: on-line help, error messages, manuals etc. Integrated with the user interface to help users when they need information or make an error
16.4.1 Error messages Poor error messages can mean that a user rejects a system Messages should be polite, concise, consistent, constructive The background and experience of users should determine message design Design factors context: be aware of where the user is in the program experience: beginners need more help,others may get annoyed skill level style: positive, not funny or demeaning culture: reflect the country where the system is sold
Please type the patient name in the box then click ok Bates , J . OK Cancel Nurse input of a patient’s name User-oriented error message System-oriented error message ? Err or #27 P atient J . Bates is not registered Clic k on P atients f or a list of registered patients In v alid patient id entered Clic k on Retr y to re-input a patient name mation or more inf or Clic k on Help f OK Cancel P atients Help Retr y
16.4.2 Help system design What do you look for? Help? means • I want information • I'm in trouble Take both requirements into account Guidelines • multiple entry points so the user can get into help from different places • allow the user to navigate and traverse the help system • others?
16.4.3 User documentation Supply paper documentation as well as on-line information Design for inexperienced and experienced users Provide other help such as a quick reference card Are 1 and 3 being phased out? What documents might you provide with your system?
Attribute Description Learnability How long does it take a new user to become productive with the system? Speed of operation How well does the system response match the user’s work practice? Robustness How tolerant is the system of user error? Recoverability How good is the system at recovering from user errors? Adaptability How closely is the system tied to a single model of work? 16.5 User interface evaluation The user interface design needs some evaluation, but full scale evaluation is expensive Do these belong in requirements?
Simple evaluation techniques Questionnaires Video recording of system use Instrument the code to collect information about use patterns and user errors A button for on-line user feedback Assignment wrt your project add user interface requirements (if any) to your chapter 3 design the user interface (include in a separate chapter or subsection) add help requirements to your spec describe help facilities (include in a separate chapter or appendix)