02. Interface Design

Design -> Implementation -> Evaluation -> Design -> …

Design Process

Saul Greenberg

Articulate

Articulate:

• Who the users are
• Their key tasks

Then design:

• Task-centred system design
• Participatory design
• User-centred design

This should lead to user and task descriptions.

Then, evaluate the tasks and repeat the process, refining goals.

Brainstorm Designs

When designing, consider:

• The psychology of everyday thing
• User involvement
• Representation and metaphors

Create low-fidelity prototyping methods.

Then, create throw-away paper prototypes.

NB: ‘prototype’ has multiple meanings, one of which implies executability.

Evaluate the designs:

• With respect to the tasks identified
• Participant interaction: get users involved
• Task scenario walk-through: in order to do X, Mary will press this button …

Repeat steps if required, further brainstorming more designs.

A reviewer should be able to unambiguously understand how the interface operates and works.

Refined Designs

Create:

• Graphical screen design
• Interface guidelines
• Style guides

Then use high-fidelity prototype methods and create testable prototypes.

Use usability testing and heuristic evaluation to further refine design if required.

Completed designs

Create alpha/beta systems or complete specifications. Do field testing if necessary.

Iterative Design

Iteratively refine design based on evaluative feedback.

A common mistake is to get an idea and hill climb on that single idea. Leads to:

• Tunnel vision
• Premature commitment
• Local maxima
• Stops early bad decisions from being fixed

Elaborative/Reduction Tension

Elaboration: get the Right Design; explore the full space of possible designs.

Reduction: get the Design Right; polish the solution. This may be done on the best solutions simultaneously.

The Design Funnel

                                          _______
                                   ------/
-----                   /---------/    Sales
---\ \___|--------------------\
    ---   Management/Marketing ----------\_______
       \_________________________________________
Design         ----------------------------------
       /------/                 |----------------
    --- /|              --------|
---/  -- | Engineering /
-----/   |----/-------/

Supporting Rapid Iterations

Fudd’s first law of creativity: to get a good idea, get lots of ideas.

Lots of ideas take lots of time to build/test, so we need rapid creation, evaluation and prototyping.

Prototyping

After user/task identification, prototyping can occur.

Low-fidelity paper prototypes (elaboration):

• Brainstorm different representations
• Choose a presentation
• Rough out interface style
• Task-centred walk-through and redesign

Medium-fidelity prototypes (reduction):

• Fine-tune interface, screen design
• Heuristic evaluation and redesign

High-fidelity prototypes/restricted systems:

• Usability testing and redesign

Working systems:

• Limited field testing
• Alpha/beta testing

Low-Fidelity Prototypes: Sketches

Outward appearance and structure of intended design.

Necessarily crude and scruffy:

• Focus on high-level concepts
• Fast to develop
• Fast to change
• Low change resistance; you only put in a few minutes of effort
• Delays commitment

Use annotations/sequences to show UI progression.

Cross reference with other zoomed in/out sketches.

Sequential sketches: show state transitions; what interaction causes the state change?

Focus on the main transactions (Zipf’s law) - clearly convey how the user achieves the 20% of the most frequent interactions.

Medium-Fidelity Prototypes: Wizard of Oz

Have a person emulate the functionality.

IBM speech editor (1984): user would give audible commands to edit a text document, which the wizard implement. This gave IBM a good understanding of the user experience, allowing them to see if the idea was any good without investing a large amount of effort into actually implementing it.

Walk-through evaluation:

• Facilitator gives the user tasks and prompts them for their thoughts
• User looks at current system state
• Component updates system state following some pre-determined algorithm
  • All UI states/components must be sketched/printed out
• Observer takes notes

Refinement (e.g. PowerPoint):

• Facilitates motion paths
• Links between states etc.
• Many wireframing tools available (eg. moqups, blsamiq, axure)

Precise medium-fidelity prototypes:

• For very small but important portions of the UI
  • e.g. slide to unlock animations etc.

Photo traces:

• If you suck at sketching
• Take a photo, trace it out; captures the essence of the interaction without the exact representation

Simulations and animations:

• Works well for second round evaluation
• Horizontal prototype: surface-layer/sketch prototype of entire range of functionality
• Vertical prototype: much of the functionality for a small set of features
• Scenario: intersection of horizontal and vertical prototypes
• Beware of:
  • Inflated expectations - perception of it being ‘nearly completed’
  • Reluctance to change - the more it looks finished, the less willing stakeholders may be to recommend changes
  • Excessive focus on presentation rather than approach

Task-Centered System Design (TCSD)

TCSD is the HCI equivalent of requirements analysis/use cases.

It asks exactly and specifically who are the users and what will they use the system for? There is a critical difference between:

• The User - a pretend person who will adapt to the system and go on a two week training session to live with the designer’s pet system
• A real, busy person doing their job

TCSD acts as a reality-based sanity check for designers.

Good book on system design: Task-Centered User Interface Design by Clayton Lewis and John Rieman.

How NOT to approach design:

• Focus on system and designer needs
• Ask what can we easily build
• Ask what is possible/easy with the tools we know/have?
• Ask the programmer what they find interesting?

UC SMS

UC’s student management system (from the mid 2000s) was a multi-million dollar, unusable disaster.

Example task: Andy is teaching COSC225 next semester; he wants to know how many students are enrolled to see how many printouts he needs. To achieve this:

• Click on ‘Navigate’ button in the toolbar; opens ‘System Navigator’ window
• Expand ‘Searches’ menu (hierarchical menu system)
• Click on ‘Course Occurrence Search’; opens new window
• Enter course code, hit return
• Select the right occurrence
• A window with a huge mess of text fields (mostly disabled) and 13 tabs opens
• …

The company that delivered it had a system that was similar to what UC needed; they did what was easy, not what the end user needed.

TCSD Phase 1: User Identification

Identify categories of end-users with specific exemplars - typical and extremes.

Talk to them!

• If they won’t give you the time to talk to you, they probably won’t use your system either
• If they really don’t exist (no existing system):
  • Worry
  • Describe your assumed users and tasks
• Learn about people in the task chain: who do inputs come from, where do outputs go?
  • Why does the user need to do this? What do they do with the information?

TCSD Phase 2: Task Identification

1. Record what the user wants to do, minimizing the description of how they do it
   • No interface assumptions; tasks are independent of the interface they will use to complete it
   • Can be used to compare alternative designs
   • Don’t write ‘display ${something} to the user’, write ‘do ${something}’: the user wants to get information about something; the system displaying it is just a way they can do it
2. Record the complete task: input source, output identification
3. Identify users
   • Design success depends on what users know
   • Test against specific individuals; name names
4. Uniquely enumerate tasks for identification
   • Giving tasks a unique identifier helps with communicating problematic tasks with the team
5. Identified tasks can be circulated for validations
   • Interview the users with the tasks you identified; they can help spot omissions, corrections, clarifications and unrealistic tasks
6. Identify broad coverage of users and tasks
   • Create matrix with the axes of unimportant/important and infrequent/frequent tasks/users

Example: John Smith arrives at student services trying to enrol in a course online, but refused as he lacked a pre-requisite course. He has a letter from the HoD allowing him to enrol. He has forgotten his ID card and cannot remember his student ID or user code (<- this is an interface assumption; does the system have IDs or user codes?).

TCSD Phase 1/2 Outcomes

A report should state:

1. User categories (and their priorities)
2. Specific personas exemplifying each category
3. Task categories and priorities
4. Concrete representative task scenarios (with name of the owner)
   • Enumerated with unique identifiers for use in UI validation
5. Explicit identification of groups/tasks that will not be supported and reasons for this

TCSD Phase 3: Design

Use task categories/scenarios to generate and evaluate designs.

Strive to make the workflow natural to the user. For each design and task scenario ask how the user would complete the task.

TCSD Phase 4: Walk-through Evaluation

Interface design debugging: select a task scenario and for each step:

• Ask what the user would do given what they know
• Ask if the task is believable
• If not, it is an interface bug. Record it and assume it is fixed when going through the next steps

Cautions on TCSD

• It is hard to record and identify task scenarios that are independent of the interface
• The more the interface and task are interlinked, the more difficult it is to identify alternative/better ways of achieving the task
• It can be hard to find people ‘responsible’ for new tasks in a system: who do you interview, how do you validate the interface?

User-Centred System Design

Know the user: design should be based around user needs, abilities, context, tasks etc. and should be involved in all stages of design: requirements, analysis, storyboards, prototypes etc.

UCSD/Participative Design: Involving the User

Talk to users:

• Interview them about culture, requirements, expectations
• Contextual inquiry: observe them doing their job; a few hours of observations can give a lot of insight
• Explain designs: get input at all stages, show visual prototypes and demos
• Walk-throughs: the user knows what they will do the best

UCSD: Participatory Design

Problem:

• Designers’ intuitions can be wrong
• Interviews lack precision/context and can mislead
• Designers cannot know user needs well enough to answer all questions that are likely to arise during design

Solution:

• Designers having access to a pool of representative end users: not management; real users
• These users are full members of the design process

The users:

• Are excellent at responding to suggested designs (they must be concrete and visible)
• Bring in important knowledge of work context that only someone that has lived in the role can learn
• Will often have greater buy-in into the system

However:

• It is difficult (and expensive) to get a good pool of representative end users - you are taking people out of their regular jobs
• They are not expert designers - they probably won’t be able to come up with design ideas from scratch with an understanding of the constraints of the technology, budget, time etc.
• The user is not always right - they may not know what they want

Erskine: member of Math/COSC departments became members of the design and judging team, gave suggestions to architects etc. (e.g. less glass - too much glare). When finished the staff had buy-in into the building; it was their building, not one built by management.

Usability Heuristics

AKA User-Interface Guidelines, Style Guides.

Usability heuristics:

• Encapsulates best practices and ‘rules of thumb’
• Identify common pitfalls
• Define simple ‘thinking hats’ - specific areas (e.g. memory load) to evaluate the interface

Formative heuristics guide design decisions while summative heuristics evaluate existing systems.

Advantages:

• Minimalist: easy remembered and applied, with just a few guidelines covering most problems
• Cost: cheap and fast, and can be done by novices (e.g. end users)

Disadvantages:

• Heuristics can be broad, redundant and obvious
• Some subtleties in their application

Nielsen’s Ten

The original set defined Jakob Nielsen’s Usability Engineering:

01. Simple and Natural Dialogue

Manage complexity: make it as simple as possible, but no simpler (match the complexity of the domain).

Organization of the interface: make the presentation (appearance of each state) and navigation (between states) simple and natural.

Graphic design: organize, economize, communicate.

Use windows frugally - fewer windows are almost invariably better.

See: Google vs Yahoo search page, iPhone vs feature phones

02. Speak the User’s Language

Affordances, mappings and metaphors.

Terminology (words, colors, graphics, animations etc.) should be based on the user’s task language (and not based on system internals).

e.g. error messages should be useful to the user, not just the programmer/designer.

‘Language’ is textual and iconic (e.g. ‘Save’ (natural language) can be Ctrl-S , floppy disk icon).

03. Minimize The User’s Memory Load

Recall is slow and fragile; use recognition wherever possible:

• In font menus, show the font name using that font
• Show input formats and provide defaults
  • e.g. date inputs with defaults tell you the format the date should be in
• Support reuse and re-visitation
  • e.g. browsers show commonly visited pages in omni-bar
• Support exchange of units - don’t force the user to do unit conversion themselves
• Support generalization techniques:
  • The same command should be able to be applied to all objects (e.g. cut/copy/paste on characters, text boxes)
  • The same method/modifier being generalized (e.g. circles are constrained ellipses, squares constrained rectangles)

04. Consistency

Consistency everywhere:

• Graphic design
• Command structure (e.g. always select object then command to act on it)
• Internally (within the application)
• Externally (within the platform)
• Beyond computing (e.g. red for stop, green for go)

05. Feedback

Continually inform the user about what the system is doing and the system’s interpretation of their input.

e.g. in PS, cursor icon matches selected tool

The feedback should:

• Be specific (e.g. name of file being opened/saved)
• Consider the context of the action - only disrupt the user when necessary
  • e.g. save progress bar at the bottom of the window
• Consider feed-forward: show the effect of the action before they commit to it
  • e.g. in Word, on hover over font, update selected text with that font (although this particular case was distracting)
• Offer choices based on partial task completion
  • e.g. autocomplete
  • This should be relatively stable and predictable, allowing the user to act on muscle memory rather than reading

Response times:

• < 0.1s: perceived as instantaneous
• < 1s: delay noticed, flow of thought uninterrupted
• 10s: limit for keeping attention on the dialogue
  • 1-5s: e.g. spinning cursor
  • > 5s: percentage
    • If just guessing progress, prefer speed up near the end rather than a slow down
  • ‘Working’ dialogues for unknown delays (e.g. throbbers)
• > 10s: user will want to perform other tasks and may have lost their train of thought

Consider feedback persistence: how heavy/disruptive and enduring should it be?

06. Clearly Marked Exits

Avoid trapping the user; offer a way out whenever possible:

• Cancel button
• Universal undo (return to previous state)
• Interrupt (mostly for longer operations)
• Higher precedence for more recent actions - if user does one action then another action that overrides the previous one, fulfil the latter action
• Quit
• Defaults (e.g. losing form data after submitting with one bad field)

e.g. ‘Do you want to save the changes made to ${}’: Don’t Save, Cancel, Save (don’t just use ‘yes’/‘no’/‘cancel’)

Windows 10 volume control: area around the volume bar is untouchable for a few seconds Also placed in the top left corner where a lot of important user elements are.

07. Shortcuts

Enable high performance for experienced users:

• Keyboard accelerators
• Command completion
• Function keys
• Double clicking (shortcut for some menu item)
• Type-ahead (offer most likely prediction)
• Gestures
• History (repeat actions done by the user previously)
• Customizable toolbars

08. Prevent Errors and Avoid Modes

People will make errors:

• Mistakes: conscious deliberation leading to incorrect action (bad mental model)
• Slips: unconscious behavior that gets misdirected (or mis-click/typo)

General rules:

• Prevent slips before they occur (e.g. syntactic correctness, disable items that can’t currently be used)
• Feedback: allow slips to be detected when they occur
• Support easy correction (e.g. universal undo)
• Commensurate effort: difficult states (e.g. document with of unsaved work) should be hard to irreversibly leave (e.g. warning dialog box)

Forcing functions (syntactic correctness):

• Prevent continuation of a wrong action

Warnings:

• Can be irritating when overused
• Can be ‘heavy’ (e.g. alert box)
• Make them subtle unless there is a really good reason for it to be heavy

Ignore illegal actions:

• Not great as user must infer what happened
• e.g. typing alphabetical character in number input

Mode errors:

• Have as few modes as possible
  • Distinct states of the system where the commands available to the user are different or where the commands produce different results
• Allow user to easily determine current mode
• Spring-loaded modes: ongoing action maintains mode
  • e.g. user must hold down control key to stay in a mode
  • Good solution to people forgetting they are not in the default mode

Bad behavior:

• UCSMS Web student search has radio buttons for search via username and student number - two different modes because there is clearly no way for the program to determine the input is a 8 digit student number or a username beginning with alphabetical characters.

Good example:

• World used to ‘unnatural’ scrolling direction, iPhone’s rubber-banding acted as feedback when the user accidentally scrolled down from the top of a list
• User can swipe between photos and also drag when zoomed into a photo - what should the behavior be when swiping to the edge of a photo when zoomed in?

Possible solutions:

• Self-correct/auto-correct
  • Requires trust in the system
  • Negativity bias - incorrectly correcting correct input is far worse than not correcting incorrect input
• Auto-suggest
  • Dialog that allows the user to fix an issue
  • e.g. Squiggly line under mis-spelt text
• User instructs system
  • System asks if the input was intended
  • e.g. add to dictionary
• System instructs user
  • System guesses user intentions and instructs user on the proper way to achieve it
  • e.g. Clippy! - condescending, wrong, tedious, boring

09. Deal with Errors in a Positive and Helpful Manner

Error messages should:

• Use clear language, not codes
• Be precise - rephrase user input (e.g. cannot open ${document name} because ${it is not a supported file})
• Be constructive - suggest and offer solutions where possible

10. Help and Documentation

Documentation and manuals:

• Documentation is no excuse for interface hacks
• Write the manual before the system
• Task-centred manuals (especially for beginners)
• Quick reference cards as a reference to aid novice to expert transition

Tutorials:

• Short introductory guides and overviews
• Video walk-throughs
• Simple task walk-throughs

Reminders:

• Tooltips
• Short reference cards

Wizards:

• Walk user through typical tasks
• Don’t overuse - system in control
• Dangerous if the user gets stuck

Māori Issues and User Interface Design

Te Taka Keegan - University of Waikato

Usability principles

Shneiderman, Nielson have a few relevant usability principles:

• Strive for universal usability
• Match between system and the real world
• Recognition, not recall

Know your audience:

• Ethnicity: group people who identify with each other by genealogy, language/dialect, history, society, culture etc.
• How is the Māori world view different from the Pākehā perspective? A few important values:
  • Manaakitanga: showing respect, care for others
  • Whanaungatanga: building up relationships/kinship/closeness (e.g. introductions include mountain/rivers as a point of similarity and a way to bond with each other)
  • Tiakitanga: looking after the world and each other
  • Rangatiratanga: acknowledging/respecting chieftainship
  • Aroha: love
• Language:
  • ‘Soft’ - every syllable ends with vowel
  • 10 vowels: a/e/i/o/u/ā/ē/ī/ō/ū (short and long/accented with macron)
    • ‘au’ sounds more like an ‘o’
  • 10 consonants: h/k/m/n/ng/p/r/t/w/wh (wh sound differs with dialect)
• Vowel length important for pronunciation and meaning

Something is usable if person of average ability and experience accomplish the task without more trouble than it’s worth.

• Default languages are important
• Interface language affects software usage patterns
• Lack of vocabulary is barrier to using Māori interfaces
• Māori has long words which can cause UI issues
• When using Māori imagery, get feedback and ensure it is appropriate

Inspection Methods

Systematic inspection of a user interface. It:

• Attempts to find usability methods
• Works at any stage in the design process
• Most commonly heuristic evaluation, where 3-5 evaluators inspect the system

Heuristic Evaluation

Each inspector initially works alone. They traverse the interface several times with a specific scenario/task in mind and:

• Inspect UI components and workflow
  • Flow between UI states
• Compare them with heuristics
  • Find non-compliance/problems
• Add notes, magnitude of problems, frequency

It often uses a two pass approach, focusing on specific UI elements/states in the first pass while the second focuses on integration and flows between states.

Results Synthesis

After each inspector does their individual evaluation, the inspectors come together and assess the overlap in problems they found.

Severity rankings can be reviewed and compared, and problems ranked in order of importance.

Severity: (small impact on those encountering it, few users) = low severity. (large impact, many users) = high severity.

Inspectors

Different perspectives will catch different problems so the inspector team should be diverse.

Example:

• Developer
• Designer
  • Beware of vested interest in their design
• Usability expert
• Domain expert
• User

All inspectors should be trained in Nielson’s heuristics.

Nielson claims 3 inspectors should be able to find ~60% of problems, 5 ~70%.

Graphical Screen Design

Gestlat Laws of Perceptual Organization

How humans detect visual groups/relationships/patterns:

• Proximity
• Similarity
  • In shape, color etc.
• Continuity
  • Dots placed along a curve: brain sees the curve as a object
• Symmetry
  • Objects seen as closed when placed in symmetric boundaries
• Closure
  • Brains automatically attempt to ‘close’ objects e.g. semi-circle

Smooth continuity (e.g. smooth curves vs straight lines with right angles) easier to perceive, but less ‘neat’.

PARC Principles

From The Non-Designer’s Design Book by Robin Williams.

PARC:

• Proximity
  • Group related elements
  • Separate unrelated elements
    • Instead of putting ugly borders around two groups, separate them!
• Alignment
  • Visually connect elements to create a visual flow
    • This is why grids are useful
  • And mis-align unconnected elements (use with caution)
• Repetition
  • Repeat design aspects (e.g. font, color, shape) throughout the interface for unity/consistency
• Contrast
  • Different things should look different
  • Bring out dominant elements, mute lesser ones

Misc

Grids:

• Use horizontal and vertical alignment to group related components
• Make minimal use of explicit structure (i.e. borders and boxes)

Navigational Cues:

• Provide an initial focus (top left for western cultures)
• Group related items
• Visual flow should follow logical flow

Economy of visual elements:

• Minimize the number of controls
  • Include only those necessary and relegate others
• Minimize clutter
• Experiment with whitespace
  • e.g. headings/labels above or to the left