The overall outline of this page and the basic points that are made have been taken from the video made by Tandy Trower of Microsoft entitled: Creating a Well Designed User Interface. Commentary has been added (shown emphasized) to the basic points.Developing a user centered design philosophy.
- UI design is hard work. You will never get it right the first time and often it is never gotten right at all.
- No Magic formulas.
- UI design is an evolutionary process. Hardware and software technologies drive UI design. Not too long ago we were all using crt based text interfaces. Where are we heading in the future?
- Focus on users and their tasks. An interactive system is meant to support users and their tasks. This should be the the guiding point in designing and developing a UI.
Cognitive issues: How are people wired.
- People like to feel in control.
- People are better at recognition than recall. Recall the discussion of problem isomorphs. People solve tasks better when they recognize (experience) rather than recall (reflect).
- Remember grouped things better.
- Learn by doing. There is an old saying that goes something like: I hear and I forget. I see and I remember. I do and I learn.
- Rely on previous experiences. We all have a conceptual mental model of the world that we have learned and that has evolved over time. When confronted with new situations and new tasks we use this mental model so that we do not have to re-learn and understand every new situation.
- People differ in how they learn. Remember you are (perhaps very) different from the users of the systems you develop. You have to try to think about the users' knowledge and perspectives.
Seven deadly temptations.
- Design for technology rather than for the user. We as computer scientists tend to become enamored of the technology. We think that technology is good for its own sake. Your users might not share this opinion.
- Cool or sexy design. Focus on what is important for the task - not on what impresses your office mates.
- Logical vs. visual design.
- User input as right or wrong.
- Featurism and over-extended basics. Beware of creeping featurism. Again, we as computer scientists become enamored of technology and more and more functionality. A bloated system might lose its effectiveness.
- Fix problems in the documentation. Ouch, who wants to read documentation???
- Fix problems in the next release. The users of your system will learn from it - they will fit this learning into their mental model. Next time around your fixes better not clash with what your users have already learned.
Basic design principles.
User control.
- All actions initiated by the user.
- Minimize modal interaction. In general the UI community is biased against modal interactions. However, sometimes for some tasks modal interaction is fitting.
- Support personalization/customization.
Directness.
- Support direct manipulation.
- Make representations visible.
- Use familiar metaphors. Metaphors allow your users to bridge the gap from their mental model to your system.
Consistency.
- Internal.
- External. A UI should be consistent with its overall environment. For example, applications that run on Macs are very consistent with their style of interaction (e.g., using menu bar, cut/copy/paste, etc.).
- Consistency with metaphors and the users' conceptual model.
Simplicity
- KISS - Keep it simple stupid. As Thoreau once said "Simplify, simplify". A simple and effective tool is a much bigger win (and is much harder to realize) than a complex tool.
- Simple things simple. Alan Kay's dictum of make simple things simple and make complex things as simple as possible (or at least possible).
- Progressive disclosure. Hide functionality from the user until they require it. For example, pull down and pull right menus can hold a huge number of commands but only show (hopefully) what the user needs.
Forgiveness.
- Support discovery. Humans are very good at finding out how things work through exploration and discovery. For example, consider how people learn how to work the controls of an unfamiliar automobile. They explore the interface and are generally unafraid to try out things. UIs of computers need to support that type of exploration and discovery.
- Warn about potential data loss. e.g., allowing rm -r -f * in Unix might be considered bad user interface design.
- Make actions reversible or recoverable. Undo/redo facilities are wonderful for the user but a major pain (sometimes) to implement. You need to balance this trade-off.
Feedback.
- Immediate cues. Acknowledge to the user what they have done when they have done something. If performance is a problem in your system than the immediacy is sometimes lost - fix the performance or change the type of feedback (e.g., moving graphical objects in a drawing package often moves an outline of the object, not the object itself.)
- Visual and auditory. Feedback can be of the form of changing the state of the application (e.g., showing new text in a text editor when a key is pressed), a beep, changing the cursor, a dialog box, etc. Be careful of auditory cues - they can be quite annoying over time,
- Appropriate to the task. Be careful about giving too much or inappropriate feedback to the user. There is nothing worse than having a dialog box popup every-time you try to do something.
Visual integrity.
- Visual cues.
- The function of graphic elements should be intuitive to the user. Now just what does this icon mean???
- Use an expert. Graphic designers know alot about communicating effectively. Don't be afraid to use them.
Design Methodology
Design Team.
- Development, visual design, writers, human factors. Effective UI design and development requires a variety of skills.
Design Cycle
- Design
- Know your users.
- Define conceptual model and metaphors.
- Write up the design.
- Prototype
- Pencil and paper. Storyboards. Operational software. Pencil and paper are fast and easy to use tools. Paper based designs implicitly do not convey the concreteness of a computer based design. You can focus on the meaningful and high level aspects of your system. Don't sweat the details at the early stages of UI development.
- Communicates the design.
- Provides for early, low-cost user input.
- Test.
- Use representative users. If you have defined representative tasks you can first try out your design with those tasks and with yourself or your co-workers as users. However, remember that you are inherently biased. You might not be the same kind of person as your users and you have a mass of knowledge of the system and how it works.
- Focus on the tasks not the features. Focus on the what not the how.
- Iterate. And iterate and iterate and iterate...