Gui Design Taken from Gui Bloopers by Jeff

Gui Design Taken from “Gui Bloopers” by Jeff Johnson

First Principles • 1. Focus on the users and their tasks, not the technology. • 2. Consider function first, presentation later. • 3. Conform to the users’ view of the task. • 4. Don’t complicate the user’s task. • 5. Promote learning. • 6. Deliver information, not just data. • 7. Design for responsiveness. • 8. Try it out on users, then fix it!

1. Focus on the users Answer the following Questions. • For whom is this product or service being designed? Who are the intended customers? Who are the intended users? Are the customers and the users the same people? • What is the product or service for? What activity is it intended to support? What problems will it help users solve? What value will it provide?

More Questions • What problems do the intended users have now? What do they like and disklike about the way they work now? • What are the skills and knowledge of the intended users? Are they motivated to learn? How? • How do users conceptualize and work with the data in their task domain?

And more • What are the intended users’ preferred ways of working? How will the product or service fit into those ways? How will it change them?

Users • Software should be designed neither FOR users nor BY them, but rather WITH them.

2. Consider Function First • This does NOT mean “Get the functionality designed and implemented first, and worry about the user interface later. ” • It means consider the purpose, structure, and function of the user interface – and of the software as a whole – before considering the presentation – the surface appearance – of the user interface. • The word “function” here does not mean implementation, it means “role” – what does it do?

KISS • Keep It Simple Stupid • Keep it as simple as possible, but no simpler.

3. Conform to the user’s view • Don’t make users commit unnatural acts. – Steps users have to perform to get what they want that have no obvious connection to their goal. – Imposing arbitrary restrictions • • Limiting person’s name to 16 characters Allowing table rows to be sorted by at most three columns Providing undo for only the last three actions Forcing all address book entries to specify a fax number even though some people don’t have fax machines

Cont. • Use the users’ vocabulary, not your own • Keep the program internals inside the program. • Find the correct point on the power/complexity trade-off – – – Sensible defaults Templates or canned solutions Progressive disclosure Generic commands (create, copy, move, …) Task specific design

4. Don’t complicate the users task • Common tasks should be easy. – Support customization – Provide wizzards • Don’t give users extra problems to solve. – Tiff to gif conversion, etc.

5. Promote Learning • Think “outside-in” not “inside-out” – Don’t design like you assume the users will automatically know what the developers intended. • Often the cause of Textual Ambiguity

Textual Ambiguity • • • Crowds Rushing to See Pope Trample 6 to death Drunk Gets Nine Months in Violin Case Vineland Couple to Take on Missionary Position Teacher Strikes Idle Kids British Left Waffles on Falkland Islands Iraqi Head Seeks Arms New Vaccine May Contain Rabies Two Soviet Ships Collide, One Dies The patient was at death’s door, but the doctor pulled him through!

Other Ambiguities • Typographical Ambiguity – DOIT • Graphical Ambiguity – In or out

6. Deliver Information not just data • Design displays carefully; get professional help. – Visual order and user focus – Match the medium – Attention to detail • The screen belongs to the user. – Preserve display inertia • Minimize what changes when responding to an action

7. Design for Responsiveness • Responsive software keeps up with users even if it can’t fulfill every request immediately. • It provides enough feedback for users to see what they are doing. • It lets users know when it’s busy and when it’s not.

Poor Responsiveness • Delayed or nonexistent feedback for user actions. • Time-consuming operations that block other activity and cannot be aborted. • Providing no clue how long lengthy operations will take • Periodically ignoring user input while performing internal “housekeeping” tasks

8. Try it out on users, then fix it! • Test results can surprise even experienced designers. • Schedule time to correct problems found by tests. • Testing has two goals: informational and social – Find aspects of the user interface that cause problems – Convince developers that there are problems