Slide 1 of 42

1
Designing theUser Interface

• Dick Penn
• Positive Interaction Inc.
• 12 September, 2001
• http//positiveinteraction.com/carleton/2001Design
  .ppt

2
How do you design aUser Interface?

• 1. Identify the information
• 2. Find out how it will be used
• 3. Organize it in a sensible way
• 4. Depict that organization
• 5. Iterate, iterate, iterate
• includes websites, web applications and
  traditional GUIs

Requirements Capture
High Level Design
Low Level Design
3
OrganizingPrinciples

• A structure which
• fits in all the information (input and output)
• makes sense (can be taught) to everyone
• helps people find things
• helps people know where to put things
• More than one is OK

4
Information Design Approaches
Organizing Principles

• Data-centric
• entity-relationship diagram
• Object Oriented
• class hierarchy
• Task Oriented
• hierarchical task analysis

5
The Data-Centric Approach
Organizing Principles gt Data-Centric Approach

• Focuses on the information
• Modeled as a series of tables
• fixed columns or Fields
• indeterminate number of rows or Records
• e.g. e-mail
• each message is a row
• columns are To, Subject, Body etc.
• another table would be the address book
• Fixed set of actions for all products
• Add, Delete, Update, Report, Duplicate

6
Entity-Relationship Diagram
Organizing Principles gt Data-Centric Approach
MessageID To From Subject Body Status Time/Date
Addresse-mail First Name Last Name
N
M
N
M
MsgStatusID Display Name Actions
N
1

• Shows tables, relationships between them

7
Data-Centric Design
Organizing Principles gt Data-Centric Approach

• Application typically built from three screens
• search forms, which query one or more tables
• grids or tables, which list the results of a
  query
• forms, which are used to update a record
• Pros
• Maps directly to implementation, so easy to make
• Works well when user tasks are simple, linear
• Show current data, before making changes
• Cons
• Many screens to perform tasks (multiple tables)
• Not all actions fit the mold (e.g. Send)

8
The Object-Oriented Approach
Organizing Principles gt Object-Oriented Approach

• Focus is still on the information
• Modeled as a series of objects
• combination of data, and actions to be performed
  on each
• Objects are seen in a class hierarchy
• A is a kind of B is a kind of C
• Objects have Properties
• in the same way that tables have fields
• Actions and Properties assigned at any level
• Specific objects inherit them from general ones

9
Class Hierarchy
Organizing Principles gt Object-Oriented Approach
Actions
Classes
Delete
Properties
Object Message Outgoing Message Unsent
Message Sent Message Incoming
Message Unread Message Read Message Address
Read
To, Subject, Body
Compose
Send
Date Sent
From, Date Received

• Actions and Properties assigned at any level

10
Object-Oriented Design
Organizing Principles gt Object-Oriented Approach

• Each object is assigned a number of views
• e.g. icon, list entry, complete form
• Navigation by some relationship
• usually containment
• may be subclass (often confusing)
• Challenge is to depict all relationships
• container - components
• class - subclass
• OO analysis does not lead directly to design
• unless the analysis is simplistic, when the
  design will not work

11
The Task-Oriented Approach
Organizing Principles gt Task Oriented Approach

• Focus is on user actions
• Hierarchical Task Analysis
• Identifying types of user
• Identify user goals
• e.g. Book a flight, Schedule an appointment
• Break each goal down into tasks
• e.g. Find available flights, Identify the user
• Repeatedly break each into sub-tasks
• until desired level of detail is reached

12
Task-Oriented Design
Organizing Principles gt Task Oriented Approach

• Task-Oriented Design
• assumes the user starts by stating their goal
• (typically selecting a goal from a menu, screen
  or tree)
• Leads the user step-wise asking for information
  as needed
• Usually allows back to repeat steps, sometimes
  skip or next to take steps out of order
• Examples installation wizard, bank machine

13
Task-Oriented Design
Organizing Principles gt Task Oriented Approach

• Pros
• intuitive, easy to understand and describe
• starts with an understanding of the user
• Cons
• what if user needs data to decide what to do?
• e.g. dealing with customer help-line inquiry
• may lead users to perform the wrong task
• e.g. add a customer when the customer already
  exists
• system control user - may antagonize experienced
  users, third parties
• leaves user high and dry if task not anticipated

14
Combining Approaches
Organizing Principles

• Consider
• An task-oriented front-end, for some user classes
• focus on discoverability and performance
• supports frequent, simple tasks
• not comprehensive
• consistency less important (users follow prompts)
• An object-oriented (or data-centric) back-end
• focus on understanding underlying structures
• used by technicians, administrators
• comprehensive
• consistency important (may not see all parts
  often)

15
Softening Approaches
Organizing Principles

• Try to combine the best of all methods
• Examples
• OO interface with task-oriented coach
• TO design with macro/learn facility allows
  advanced users to add new tasks
• DC design, with hyperlinks to related objects as
  shown by OO analysis
• Whatever design approach is used, all the
  analysis techniques can contribute
• Examples
• OO design can use task data to exercise the
  model
• or vice versa

16
Dealing with an Existing Design
(Dont use this term with clients)
Is the present design fundamentally flawed?

• ? Deconstruct it
• Mine it for information

? Tweak it Incremental redesign
17
When is existing design Fundamentally Flawed?
Dealing with Existing Designs

• Potential for order of magnitude improvement in
• convenience, clarity, safety, security
• fit to user requirements
• Improvement wont fit the existing structure
• No-one can explain the existing design
• except its always been that way
• or it matches the internal database
• or it conforms to such-and-such standard
• If its a successful product, it probably isnt!

18
Deconstructing Design
Dealing with Existing Designs

• List every item in the current design
• fields, table columns, graphics, etc.
• tagged by which screen they came from
• Talk to users
• find out what parts they use, how often
• identify problems, task information
• classify the users, by how they use the data
• Talk to marketers, support folks
• where is more functionality demanded?
• Turn the sea of data into a new information
  design
• use information design approaches
• dont reproduce the old design (users will want
  you to)

19
More on Deconstruction
Dealing with Existing Designs

• Look for hidden complexity
• command languages
• input syntax
• (example from search engines)
• if found, decide whether its useful
• if so, bring it out where users can see it
• if not, get rid of it

20
Tweaking Existing Designs
Dealing with Existing Designs

• List every item in the current design
• fields, table columns, graphics, etc.
• tagged by which screen they came from
• Talk to users, marketers, support
• same information as before, but
• Generate a list of suggested changes
• within the existing framework
• includes moving items around
• includes adding items, within existing rationale
• Prioritize the changes
• set your own priorities
• discuss with client to accept/reject/defer
• Build a new design based on the changes
• iterate, iterate, iterate

21
DesignProcesses

• 1. Group Design
• 2. Brainstorming
• 3. Bottom up design
• 4. Top-down design
• 5. Iterate, iterate, iterate

22
Group Design
Design Processes

• sucks
• Definition of a camel
• (this is actually a gratuitous insult to camels,
  for which I apologize, but it does illustrate the
  point. A complete understanding of the functional
  requirements for camels would doubtless reveal
  the elegance of their design)
• Group processes can contribute to design
• Actually doing design is at most a 2-person
  process
• examples
• authoring fiction
• painting pictures
• writing music
• driving a bus

23
Brainstorming
Design Processes

• Group processes which contribute to design
• Assemble all the functions/items/tasks
• Evaluate a design
• existing product
• proposed design
• Groups can
• generate ideas, list requirements, discuss pros
  and cons, analyze
• Groups can not
• design, resolve issues, synthesize

24
Bottom-up design
Design Processes

• Books all tell you its the wrong thing to do
• I generally do it anyway
• Good way to assemble functional requirements,
  when fuzzy
• Lets your intuition identify needs
• Treat the resulting design as fundamentally
  flawed and redesign from there
• missing person website example

25
Top-down design
Design Processes

• You have a complete set of functions/ features/
  widgets/ objects/ data tables
• You have an organizing principle with which to
  assemble them
• You can now apply the principle, to generate a
  detailed design
• This will often
• reveal whole classes of objects you have
  forgotten
• reveal fundamental flaws in the information
  architecture

26
Iterate, Iterate, Iterate...
Design Processes

• Instantiate the design
• make it real (fidelity varies with stage)
• Look at it yourself
• stand back, squint, have a beer, have a bath,
  anything to change perspective
• Walk through user tasks
• Show it to someone else
• listen to them, but keep listening to yourself
• in order colleagues, mentors, clients, users
• clients marketing, documentation, implementers
• Use formal testing methods
• CHANGE IT!!!

27
Iterate, Iterate some more
Design Processes

• Dont limit what you hear
• when doing low-level design, listen for new
  requirements, better organization, but...
• Dont accept everything you hear
• filter it by
• what other people have said
• what you have tried
• still listen and record, but dont always change
  the design
• otherwise the design will never reach a
  conclusion
• Dont let inconsistency creep in
• if you hear things which dont fit the organizing
  principle, reconsider the principle or reject the
  changes
• branches may bend in the breeze, but the trunk
  must be strong

28
More Iteration...
Design Processes

• Consider all criteria
• not just your own skill-set
• Brand - doesnt look like our other products
• Image -
• Technology - cant be done, hard to do
• A good design makes sense
• to Users
• to Developers
• to Marketers
• to Authors

29
Low Level Design

• Assign functionality to windows
• Devise navigation scheme
• Design graphic elements
• Assign terminology
• Arrange widgets within windows
• Specify Dynamics
• Ensure Accessibility
• Redo everything
• it doesnt fit!

30
Assign Functions to Windows
Low Level Design

• Apply the organizing principle
• (task or object)
• Identify the actions
• performed locally on each object or screen
• global actions, such as creating new objects
• Look out for special-purpose windows
• login, search, about box
• Look for similar windows
• devise single common template for all
• Compare everything
• look for places to be consistent
• Walk through tasks
• look for ways to save steps

31
Devise Navigation Schemes
Low Level Design

• Once windows are identified, how are they
  accessed?
• What is the windowing model?
• MDI, SDI, frames

32
Alternatives to Trees
Low-Level Design gt Trees

• Everything in the world is not a hierarchy
• Try a schematic or flowchart
• Try a two- or three-dimensional cube
• Try a geographic map

33
If you must use a tree
Low-Level Design gt Trees

• No matter how carefully you classify, many users
  will not expect things where you put them
• (try finding a file on someone elses computer)
• Dont use experts (or yourself) to classify items
  - their view is different from the readers
• use card-sorting techniques
• dont throw away minority data
• Put iffy items in multiple places
• Iterate, iterate
• peoples expectations are based on the total set
  of categories - old test results cant be re-used
• Provide search or goto capability to bypass
  the tree
• consider expanding the tree to show the location
  of the found item

34
Splitting trees
Low-Level Design gt Trees

• If the tree is very deep, consider two trees, or
  a tree and a list
• If the items to be accessed are qualitatively
  different, consider separate mechanisms
• E.g. in a typical company website, use a tree for
  content, but contact address, who are we and
  privacy statements should be in a separate menu
  or bar.
• If the tree is shallow or contains actions,
  consider drop-down menus, or use an indented list
  with no folding
• Dont combine actions and objects into one tree -
  place actions separately, with an overview of the
  object

35
Vast Simplifications
Low-Level design

• Use a number instead of browsing
• from a printed catalog
• from a bus stop
• Get information from the real world
• bar codes and transponders
• GSM in package delivery
• calling number ID (screen pops)
• Bring a variety of objects together
• Use personalized views
• Use an Inbox
• Keep thinking throughout design
• where is the user getting the information?
• can I get it for them?

36
Design Graphic Elements
Low Level Design

• Graphics should
• carry content, convey structure or promote brand
• Graphics should not
• distract from content, interfere with structure
  or dilute the brand
• Graphics which carry content are tough
• drawing must convey the metaphor
• metaphor must convey the concept
• empirical testing very useful (and depressing)
• look at confusion rates, not raw recognition
• Remember dial-up users
• keep graphics small

37
Design the Words
Low Level Design

• Terminology
• Agree customer-focused terms for all objects,
  actions and properties
• Listen to users talking about the task
• Test and adjust for comprehension, confusion
• Design new terms for new concepts
• Translate terms into all target languages
• Make sure graphic metaphors complement terms
• Use one term consistently everywhere
• field labels, window titles, column headers,
  menus, buttons, command line input, dialog
  messages, graphic icons

38
Design the Sentences

• Consistent grammar for dialogs and alert messages
  
• To tell users what to do
• Use second person imperative - Type your name
• To tell users whats happening
• Use third person, avoid passive voice
• File is missing not I cant find the file or
  File cannot be found
• Consistent rules on tone
• Dont blame the user, be respectful but not
  fawning
• Use common contractions, but not slang
• Dont use doom-laden or scary terms
• Fatal error in process. Abort?
• Kill all the children of this node?

39
Arrange Widgets in Windows
Low Level Design

• Some people think this is all of UI design
• Its not!

40
Specify Dynamics
Low Level Design

• Dont assume that software designers know all
  this
• Dont assume that off-the-shelf components get
  it right
• Use the book - theres lots of details
• If its not in the book, copy a model (Office?)
  and document it
• so it gets done the same way everywhere

41
Ensure Accessibility
Low Level Design

• According to section 508 (U.S. legislation)
• Employers must make all reasonable efforts to
  accommodate users with handicaps
• Visual impairment
• Dont use fixed font sizes
• Provide more contrast than typical users need
• Dont rely on graphics to convey any content
• or provide alt tags to explain graphic content
  (web)
• Motion impairment
• Dont rely on pointing devices
• Software must be fully operable by keyboard

42
Agree on a low-end target

• Screen size
• e.g. 640x480, or 800x600
• Browser version
• e.g. 4.0 I.E. and 4.0 Netscape
• Modem speed
• e.g. 28.8 kbps
• May need to be much lower
• e.g. school users, government, third world
• Must test design on target, early and often
• N.B. designer workstations are high-end