User Interface Design

1. User Interface Design

2. Introduction • Overview of guidelines for user interface design • Principles of user interface design • User interface design process.

3. Principles of User Interface Design • Layout • Content Awareness • Aesthetics • User Experience • Consistency • Minimize Effort

4. Layout • The screen should be divided into areas that are used consistently for the same purpose, e.g. top for commands and navigation, middle of the screen for input/output. • The screen should be divided so as to provide natural intuitive flow and minimize the user’s movement.

5. Content Awareness • User must always be aware of where they are in the system with minimum effort. • All interfaces should have titles. • Menus should show you where you are, where you came from and where you can get to. • Field labels should be short and specific. • Field labels should be clear and unambiguous.

6. Aesthetics • The interface must be pleasing to the eye. • All forms and reports must have a minimum amount of white space. • The font size should not be less that 8 point and 10 point is usually preferred. • Different font size should used to distinguish between different types of information, • Underlining and italic makes text harder to read and should thus be avoided. • San-serif fonts, e.g. Arial, Helvetica, are most readable for computer screens.

7. Aesthetics • Capital letters should only be used for titles. • Too many different colours and patterns make for difficult reading and should thus be minimized. • Colours can be used to differentiate between different types of information, e.g. to differentiate headings from regular text. • Different colours tend to provoke emotions in different ways. • Colour blindness

8. User Experience • Novice users vs. experienced users. • The priority of novice users is ease of learning. • The priority of experienced users is ease of use. • Novice users and experienced users have different behaviour patterns. • The user interface must provide a balance between quick access to commonly used functions and guidance through less well-known functions. • Guidance can be possible switched on and off

9. Consistency • Consistency forms the basis of ease of use, ease of learning and aesthetics. • The needs to be consistency in the navigation controls. • There must also be consistency in the terminology used. • Consistency will enable the user to predict the effect of his/her action.

10. Minimize Effort • The minimum amount of effect should be needed by the user to perform tasks. • A minimum amount of mouse clicks or keystrokes should be used to execute actions. • The “three clicks rule” can be used for this purpose. • This rule states that each action should be performed with a minimum of three keystrokes or mouse clicks

11. User Interface Design Process • Use scenario development • Interface design structure • Interface standards design • Interface design prototyping • Interface evaluation • During design one moves back and forth between these steps instead of performing them sequentially.

12. Use Scenario Development • A use scenario lists the steps that must be performed by a user to achieve a particular task. • A use scenario is determined by specifying a path through the use case, i.e. a use scenario is a narrative description of a use case.

13. Use Cases • Use cases are used to depict how a computer system interacts with its environment and thus illustrates the actions performed by the users of the system. • Each use case describes one interaction between the user and the system, however each use case may have many paths. • For example, when searching for a CD in on online CD system the user can search for it via the title or artist. Each path is called scenario.

14. Use Case Descriptions vs. Diagrams • A use case description describes this narratively while a use case diagram depicts this pictorially. • A use case description is usually firstly created and this description is then converted into a use case diagram.

15. Example The customer browses the catalogue and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit and confirms the sale both immediately and with a follow-up E-mail.

16. Use Cases for the Example: Buy Product • Customer browses through catalogue and selects items to buy. • Customer goes to check out • Customer fills in shipping information (address, next day or 3-day delivery) • System presents full pricing information, including shipping • Customer fills in credit card information • System authorizes purchase • System confirms sale immediately • System sends confirming E-mail to customer

17. Buy Product: Alternatives . • Alternative: Authorization fails - At step 6 system fails to authorize credit purchase. Allow customer to re-enter credit card information and re-try • Alternative: Regular customer • 3a. System displays current shipping information, pricing information, and last four digits of credit card information • 3b. Customer may accept or override these defaults • Return to primary scenario at step 6.

18. Interface Design Structure • This phase involves describing the different components of the interface and how the interact. • A window navigation diagram (WND) depicting different screens, forms an reports and the relationship between them is used for this purpose. • A WND is used to illustrate the state of changes in the interface.

19. A WND is Composed of: . • Each box represents a user interface component, e.g. a menu or a form. • Transitions between the components are illustrated by a double or single arrow. • A single arrow indicates that a return to the calling state is not needed. • A double arrow indicates that a return to the calling state is needed. • Each component is described as a stereotype, e.g. <<form>>, <<menu>>. • Each component is also given a label, e.g. Menu A, Form J.

20. Interface Design Standards . • This refers to the standards that are applied to components of the interface. • There generally standards for the following components: • interface metaphors, • interface objects, • interface actions, • interface icons and • interface templates.

21. Interface Metaphors . • These are basically concepts from the real world that used to model a computer system. • For example, an online CD sales system may use a music store as a metaphor, with a shopping cart, etc. • The metaphor is meant to help the user to conceptualise the system and to predict certain actions. • A system can have an overall metaphor or different parts of a system can use different metaphors.

22. Interface Objects . • This refers to specifying the names of the objects that will make up the interface. • The usually correspond to class names. For examples an online CD sales system the shopping cart will be called the “shopping cart”, CDs maybe called CDs or albums. • Both the software developer and user must agree on the names used.

23. Interface Actions . • This involves defining the navigation and command language. • There must be consensus between users and developers uses of terminology, e.g. “buy” vs. “purchase”.

24. Interface Icons . • Icons are defined for specific actions, e.g. a disk can represent the action of saving. • Use icons that are used in commonly-used software packages and will be known by the users of the system. • Sometimes icons can cause some confusion so use icons that are not ambiguous.

25. Interface Templates . • These templates defines the appearance of each screen. • The layout is described in terms of the position of the navigation area, status bar, form, reports and the colour schemes that will be applied. • It will also describe the view types, e.g. cascading windows and where standard interface operations such as “File”, “View” and “Edit”.

26. Interface Design Prototyping . • One of the following techniques is used for prototyping: storyboarding, HTML prototyping or language prototyping. • All three techniques maybe used at different stages of the project. • Storyboarding is the fastest, with language prototyping being the slowest and HTML prototyping falling in between. • Similarly, storyboarding is the least expensive, HTML of medium cost, and language prototyping the most expensive.

27. Storyboarding . • This is usually done on a paper and consists of hand-drawn pictures as to what the user-interfaces will look like and the flow from one screen to the next. • This is the simplest of all three techniques. • Storyboarding is generally used for well understood parts of the system

28. HTML Prototyping . • The designer uses HTML to create the prototype. • This technique has the advantage of the users being able to use the prototype and hence provide feedback on the ease of use, etc. • The disadvantage of this approach is that screens will not appear in exactly the same format as they will in the final product.

29. Language Prototype . • This involves creating a prototype of the interfaces in the same language that the system will be coded in. • The advantage of this approach is that the users will be able to see exactly what the screens look like. • The disadvantage is that it takes longer to build prototypes using this approach than the other to techniques. • Is used for parts of the system that are not well-defined.

30. Interface Evaluation . • Interface evaluation is performed to identify areas of improvement for of the interfaces and hence is performed more than once during the software design process. • This is often left to the end and is the last step in the overall process. • Four techniques that are commonly user for interface evaluation are: • heuristic evaluation, • walk-through evaluation, • interactive evaluation, and • formal usability testing.

31. Heuristic Evaluation . • A checklist of the different design principles that the and interface navigation, input, and output principles (will be discussed later) is constructed. • A minimum of three project team members test the interface using the checklist individually and meet and discuss their findings.

32. Walk-Through Evaluation . • The project team walks the users through the interface. • The users are required to suggest changes to the interfaces.

33. Interactive Evaluation . • Instead of the team members walking the users through the interface, the users interact with the interface on a one-on-one basis. • The users then inform the project team of what they like and do not like about the interfaces. • The project team also makes note of any confusion and misinterpretations of the interface by the a number of users.

34. Formal Usability Testing . • This form of testing can only be applied to language prototypes. • As with interactive evaluation a single users tests the software on a one-on-one basis. • The evaluation is conducted in a lab equipped with video cameras to capture the users response to the interface. • Each user is given a specific set of tasks. • There is no interaction between the users and the project team and the user is not given any assistance. • The drawback of this method is that it is expensive.