 |
|
|
Design Tidbits
Design Tools
- My Design Tools – Part I
- My Design Tools – Part II
- UI Toolbox: Capturing and Editing Screenshots – Part I
- UI Toolbox: Capturing and Editing Screenshots – Part II
Simplification
- What Does "Simple" Mean?
- Anti-Simplification – How to Make Life Harder for Users
- Reducing Complexity
- Error Prevention Comes First
- Don't Let Your Interface Lie
- Don't Let Users Suffer from System Weaknesses
Interaction Design
- Did You Make Your Selection? – Part I
- Did You Make Your Selection? – Part II
- Did You Make Your Selection? – Part III
- Did You Make Your Selection? – Part IV
- The Software Works The Way I Think: Beyond Point and Click
- A Layman's View on Interaction Styles – Part I
- A Layman's View on Interaction Styles – Part II
- Selecting Objects By Attributes – Part I new
- Selecting Objects By Attributes – Part II new
Screen Design
- The Art of Hiding – Part I
- The Art of Hiding – Part II
- Screen Layout – Part I: General Considerations
- Screen Layout – Part II: Layout Hierarchy
- Screen Layout – Part III: Examples
Hierarchies
- Hierarchies - Categories vs. Vectors
- Fighting
(with) Hierarchies –
Part I: Basics - Fighting
(with) Hierarchies –
Part II: Presentation - Appendix: Fighting (with) Hierarchies – Presentation Techniques I
- Appendix: Fighting (with) Hierarchies – Presentation Techniques II
Visual Design
- Some Color Mysteries
- Some Mysteries of Colored Text
- Animation – The Chili Pepper of the Web
- Appendix: Definitions of the Most Common Types of Animation on the Web
Design Process
- The Construction Cycle – Another Way to "Organize" the Design Process
- User Feedback
- What Does User Integration Mean for Software Design?
- Mapping a Conceptual Interface to a Physical Interface
Web, Web Applications, Web Design
- The Web – A Short Introduction
- An Introduction to Designing User Interface Controls at SAP
- From Dropdown Listboxes to Comboboxes
- List Box Tweaks (Part II)
- Concept Statements and Website Messages – Part I
- Concept Statements and Website Messages – Part II
Miscellany
- Adding Value to Your Interface by Using Simple Math and Matching
- How Much Documentation Do Applications Need? – A Simple Example
- Narrative User Interfaces
- Golden Rules
for Bad User Interfaces
- Universal Usability
- User Interface Controls and Interaction Techniques of Horror new
Links & More
 |
Print version |
Related Links |
|
 |
Error Prevention Comes First |
|
Don't Let Users Suffer from System Weaknesses |
Background Links |
|
 |
Simplifying for Usability |
Don't Let Your Interface Lie
By Gerd Waloszek, SAP AG, Product Design Center – 09/15/2000
There are many ways to confuse users. One way is to let your application's interface lie. OK, software cannot lie, but it can mislead users, which is about the same. Your software does not lie? Well, I'll tell you a few examples, and then you might reconsider this issue.
Pretended Freedom
Since the invention of graphical user interfaces, there is the idea that users should be in control: Users should input the data in the sequence they want, select menu items and click buttons whenever they want to, etc. Nothing is wrong with that idea, but sometimes software is designed in a way that clashes with this freedom: There are dependencies between data, views or screens, which have to be observed: For example, if data depend on each other, they have to be entered in a certain order.
Buttons: You have to Click the Way I Want
If an R/3 application has several buttons in the application toolbar, this clearly signals to the users: "You can press these buttons in any sequence you want". I once came across an application in which there were two buttons that brought up dialog boxes for setting program options. However, whenever I clicked the second button after starting the application with new data, it did not show the expected dialog box. Instead it showed the other one – the program required me to process the dialog box of the first button first. You should have seen my face when this happened first. This application not only lies to its users, it also educates them: After a while you will hit the buttons in the order the developer intended it. But the interface still shouts: "You can click the buttons in any order" – the mismatch is still there.
Tabstrips
The same problem may arise with tabstrips: Although the tabs are arranged serially, their message to the users is that they can be clicked in any order (see Figures 1 and 2). I heard developers say "But the tabs are in the correct order; users should proceed through them one after the other". So, there seems to be a difference in the views of developers and users. Developers expect users to recognize their implicit message and process the tabs in the given sequence. But users do "nasty" things like not following such assumptions – and they are right. So, do not expect users to click the tabs in the order of the screen sequence. If there are dependencies between tabs, consider other design options like wizards, but do not use tabstrips or a set of buttons.
Figure 1: No - tabstrips are not for wizards
Figure 2: Yes – use tabstrips for views which can be accessed in any order
Pretended Functionality
Often functionality makes only sense in a certain context. In other contexts these functions are not needed or would even do harm. So, typically these functions are blocked in such situations. On some platforms, however, there are no disabled buttons (or other controls) to indicate that a function is not available – the respective buttons look like any other button. If a user clicks a button with no functionality behind it, different things can happen: (1) nothing, (2) a dialog box or message comes up and tells the user that the respective functionality is not available, (3) an error occurs. None of these possibilities is very user-friendly, and all of them should be avoided. OK, this example may be one of the past, but have a closer look at the Web – here this problem reappears in many disguises.
Conclusion
Obey the interface rules. Most controls have a fixed set of applications and rules for the look. This is good, because users will learn these rules just by using the software. If you break these rules, you will confuse your users and slow them down.
