1. USER INTERFACE
DESIGN
Definitions, processes and principles
David Little, User Interface Designer, DDH
MA Digital Humanities: Methods and Techniques

2. OVERVIEW
1. Definitions
2. User-centred design (UCD)
3. Design principles
4. Why you should care
5. Design exercise

3. 1. DEFINITIONS
• What is a user interface?
“That part of a computer system with which a user interacts in
order to undertake her tasks and achieve her goals.”
(Stone, Jarrett et. al., 2001)
• What we interact with when we use any kind of digital
hardware or software.

4. EXAMPLES

7. http://www.flickr.com/photos/purecaffeine/3537809738/

8. http://www.flickr.com/photos/joelanman/4333130522/in/pool-dailyux

9. http://www.flickr.com/photos/macbosse/304314327/

10. WHERE THE UI FITS
• Back-end infrastructure: servers, databases and
programming.
• Content (i.e. words and pictures).
• Information architecture: how the content is organised and
navigated.
• User interface: where the user interacts with the above.

11. USER INTERFACE DESIGN
“[Interaction design] is concerned with describing user
behavior and defining how the system will accommodate and
respond to that behavior"
(Jesse James Garrett, 2011)
• Research into the behaviours and goals of the target
users of a digital product or service.
PLUS
• The design of appropriate tools (interfaces) which enable
users to achieve their goals.

12. !
• Design without research is guesswork.
• Or may result in an interface which reflects the
understanding (mental model) of a product’s programmers
or architects, not its users.
UI design should be thought of as:
• A process integral to the creation of digital products.
• A group of interrelated activities.
• A mindset.

13. THE CONTEXT OF UI DESIGN
• Sits within a larger set of disciplines, all ultimately
concerned with the interaction of people with machines.
• Labels can be confusing and describe overlapping
activities and processes which may be carried out by one
or a number of people.
• Interaction Design (IXD) and UI design: subtle differences
in definition but will be used interchangeably in this
lecture.

14. USER EXPERIENCE (UX) DESIGN
• Commonplace term in software design and beyond.
• A vague term: which part of a digital product isn’t
experienced by users?
• Totality of users’ experiences of a product or service, from
its content, navigation, aesthetics, interactions or even
how quickly it performs or responds to users’ interactions.
• Umbrella term for a number of more defined disciplines.

15. THE UX VENN DIAGRAM
Dan Saffer, 2009

16. HUMAN-COMPUTER INTERACTION
(HCI)
• Academic study of the interaction between humans and
machines.
• Computer science, psychology, linguistics, sociology,
anthropology.
• Popularised in the 1980s but with roots in older fields of
ergonomics and human factors: 1900s and earlier.
• UI design can be thought of as the practical
implementation of HCI research, methods and practices.

17. 2. USER-CENTRED DESIGN (UCD)
• The “U” in UI: USER; the “H” in HCI: HUMAN
“Focus on the user and all else will follow.”
(Google)
• Focus on: people, their motivations, goals and
behaviours.
• Must be aware of technological constraints but UI design
is not a technological process.

18. USER-CENTRED DESIGN (UCD)
• Involve users at all stages of the design process.

19. RESEARCH
• Who are the users?
• How many different types of user are there?
• What do they want to be able to do?
• How do they currently do it?
• Where do they currently do it?
• Where might they want to be able to do it?
• How might they want to be able to do it?

20. USER GOALS, STRATEGIC GOALS
AND CONSTRAINTS
• What are the strategic goals (“business goals”) of the
product you are creating; what were you funded to do?
• Tensions between strategic goals and user goals: how will
this be managed?
• What constraints do you have:
• Financial
• Time
• Technology
• People

21. USER RESEARCH
• How do you find users?
• An existing user base.
• An organisation’s own information (e.g. marketing, focus groups,
audience profiles): what are they willing to share?
• Academic projects: project team contacts and knowledge.
• If you have limited resources?
• Friends, family, colleagues.
• Mailing lists.
• Social media.

22. ENGAGING WITH USERS:
INTERVIEWS
• Need to be pragmatic: what are your constraints (time,
financial). User research takes time and you may need to
recompense people for their time.
• If you have time: face-to-face, one-to-one interviews in user’s
“natural environment”: ethnography or contextual enquiry.
• Observe users: how they work, their behaviours, what other
resources they use.
• What users do and what they say they actually do may well be
different (c.f. Jakob Nielsen’s First Rule of Usability).
• Unstated goals, domain language.

23. ENGAGING WITH USERS: OTHER
METHODS
• Interviews via Skype or Email.
• Online surveys (generally better for quantitative
information).
• Existing published information about user behaviours.

24. WHAT TO ASK
• What kind of information: qualitative or quantitative
information? At initial stages of research qualitative
information may be more useful.
• Ask non-judgmental and non-leading questions.
• Don’t ask questions that are too open-ended (what is of
relevance to the project given its constraints?)
• For more information:
• Box and Bowles, Undercover User Experience Design (2010)
• Kuniavsky, Observing the User Experience: A Practitioner's Guide
to User Research (2003).

25. ANALYSIS AND CONCEPTUAL
DESIGN
• Analysis will probably take a lot of time!
• Identify trends: what are user goals and how can these be
supported—identify by analysing interests and behaviours,
stated and unstated goals.
• Use information to create high-level documentation to guide the
design, e.g. user stories (statement of user goals by user
group) or personas (more in-depth descriptions of “typical”
users).
• Conceptual design documentation—wireframes.

26. DELIVERABLES
• User stories: simple statements of overall user goals.
• As a <type of user> I want <a goal> so that <some
reason>:
• As an academic historian I want to be able to track ownership and
descent of manorial properties (to support my research).
• As a genealogist I want to be able to be able to establish family
relationships of the families I am researching so that I can use the
information to construct a family history.
• Sketches and wireframes: at this stage a point of
discussion with other stakeholders.

29. PROTOTYPING AND TESTING
• Prototyping: creation of artefacts for testing with users:
can be low-fidelity (e.g. paper-based), medium fidelity
(e.g. wireframes, static coded web pages) or high fidelity
(e.g. functional web pages).
• Feedback from testing the prototypes can be fed back into
further iterations of the design.
• Resource intensive but much easier (and cheaper) to
address issues and fix usability problems early in the
process than later.

30. COST BENEFIT
“The rule of thumb in many usability-aware organizations is
that the cost-benefit ratio for usability is $1:$10-$100. Once a
system is in development, correcting a problem costs 10
times as much as fixing the same problem in design. If the
system has been released, it costs 100 times as much relative
to fixing in design.”
T. Gilb (1998) quoted on the Usability Professionals
Association (UPA) website.

31. USABILITY TESTING
• Usability
“The extent to which a product can be used by specified users to
achieve specified goals with effectiveness, efficiency and satisfaction
in a specified context of use.”
International Organization for Standardization (ISO): ISO 9241-11
• Doesn’t require a lab or expensive equipment.
• One-to-one testing of a prototype with a user. A facilitator gives a
participant a number of tasks to work through on the interface and asks
them to “think aloud” their decisions.
• Make notes on the user’s behaviour and, if possible, use screen
recording software to record the user’s decisions, voice and facial
expression.

32. ITERATIVE DESIGN
• Analyse results of testing and feed back into design
• Don’t need many participants to identify main usability problems
(around four should be fine).
• Steve Krug: short, accessible books on running usability testing: Don’t
Make Me Think! and Rocket Surgery Made Easy.
• How many tests should you run? It depends. Usually defined by
project constraints (unless you’re Google who once famously tested
41 shades of blue to see which performed better!).
• Remote usability testing software: an alternative to running face-to-
face tests, but usually better for gathering quantitative information.

33. UCD: SUMMARY
• A mindset: gives a voice to the user throughout the design
and build process.
• Iterative: design, test, design, test etc.
• Be pragmatic. You will always have constraints.
• One round of testing is better than none.
• Testing one user is 100% better than testing none (but
more is better!).

34. 3. DESIGN PRINCIPLES
3.1 Simplicity
3.2 Structure
3.3 Visibility
3.4 Consistency
3.5 Tolerance
3.6 Feedback

35. 3.1 SIMPLICITY
• A user interface should be kept as simple as possible for
users in order that they can achieve their goals.
• What is simplicity? The simplest interface for the job, but
no simpler!
• Which is simpler?

38. SIMPLICITY
• Depends on context of use.
• What is the purpose of your product?
• What do your users want to do?
• Keep to your core functionality

39. 3.2. STRUCTURE
• Ensure that the interface is clearly laid out, well organised
and controls are easily identifiable.
• “Gestalt laws of perception”:
• Proximity. When elements are grouped together, people perceive
them as being related.
• Similarity. Elements that look similar are perceived as being
related.
• Closure. As humans we are generally quite good at filling in
missing information and this is certainly the case in perception. We
fill in the blanks with “incomplete” images. Commonly used in logo
design etc.

40. Proximity: the layout of a
navigation menu

41. Proximity and similarity: Flickr’s top menu bar
Similarity: Icons for Adobe Dreamweaver
and Fireworks

42. Closure: Apple’s logo

43. Grids: an established tool from graphic design
for imposing order on information

45. 3.3. VISIBILITY
• Visibility can be thought as ensuring that interface controls
that need to be accessed by the user are as visible as
possible.
• It ties in with the idea of “affordance”, popularised by the
design thinker and writer Don Norman:
“The perceived and actual properties of the thing, primarily
those fundamental properties that determine just how the thing
could possibly be used.”
(Don Norman, 1988)

46. • Affordance: “this is for doing that”.
Underlined text on a web page is for clicking

47. The “home” button on an iPhone is for pressing

48. • Conform to established rules.
• Use of appropriate metaphors can also promote visibility.
Sometimes metaphors come from a pre-existing technology,
e.g.:
• At its most extreme this can result in “skeuomorphism”:
incorporating elements in the UI from a previous technology
that serve no purpose other than being decorative.
The Gmail icon: resembles a “traditional” envelope

49. Apple’s Podcast app: features an emulated
tape mechanism.
“Real-world” UI metaphors most successful
when they allow users to easily form
connections between the interface and
existing technologies.
What does a tape mechanism mean for
younger users?

50. 3.4. CONSISTENCY
• “People see what they expect to see.”
• Recognition over recall.
• Consistency across a product or set of products.

51. 3.5. TOLERANCE
• Well designed software should try to prevent users from
making errors in the first place but is inevitable that
mistakes will happen. A tolerant UI is a forgiving UI and
lets users recover from mistakes they have made.
• Mistakes may take many forms, e.g. an accidentally
discarded email draft, a formatting mistake in a Word
processor or an incorrectly filled form field.

52. Tolerant: the colour picker in Photoshop: only allows me to enter six digits for a
hex colour code (red, green and blue number pairs).

53. Intolerant: the colour picker in Illustrator: allows me to enter more
than six digits and then presents me with an annoying error
message (also note the inconsistency across products).

54. 3.6. FEEDBACK
• How the UI communicates with the user after she has
carried out an interaction.
• Feedback may be visual, auditory or even haptic (that is
communicated via touch):
• The success message that appears after a web form has been
submitted.
• The whooshing sounds as an SMS is sent from an iPhone.
• The sense of a Wii controller vibrating when simulating a machine
gun being fired on Call of Duty.

55. NIELSEN’S HEURISTICS
• Jakob Nielsen’s ten heuristics (guidelines!) for creating usable
interfaces (1999):
• Visibility of system status
• Match between system and the real world
• User control and freedom
• Consistency and standards
• Error prevention
• Recognition rather than recall
• Flexibility and efficiency of use
• Aesthetic and minimalist design
• Help users recognise, diagnose and recover from errors
• Help and documentation
http://www.useit.com/papers/heuristic/heuristic_list.html

56. 4. WHY YOU SHOULD CARE
4.1 Finance
4.2 Impact
4.3 Ethics

57. 4.1 FINANCE
• Cost savings of usability testing.
• For commercial organisations, greater usability leads to
increased sales and greater competitive advantage.
• For non-profits, “conversion rates” (e.g. transforming a
casual user to a signed-up and engaged user) are still
important: a resource that addresses the needs of its
users is more likely to lead to greater use and (repeated)
engagement.
• Justify the use of limited funds.
• Reduce support costs.

58. 4.2 IMPACT
• Increased user engagement in design can lead to more
user-focused resources which in turn can increase a
resource’s impact.
• Old Bailey Online:
• JISC funded user engagement exercise: resource was not being
well-used by academic community.
• Study resulted in creation of sets of tools aimed at teachers and
researchers.
• Impact important consideration when creating funding
applications.
• Toolkits for measuring impact of digital resources, e.g.
TIDSR: Toolkit for the Impact of Digitised Scholarly
Resources (Oxford Internet Institute).

59. 4.3 ETHICS
• All resources have users or potential users.
• Users may battle with a difficult UI if your resource is
unique enough but why should they?
• Jef Raskin, The Humane Interface (2000): laws of
interface design:
• A computer shall not harm your work or, through inactivity, allow
your work to come to harm.
• A computer shall not waste your time or require you to do more
work than is strictly necessary.

60. FINALLY
• There are plenty of terrible user experiences already,
don’t add to them.
• Engage with users and follow established design
processes and principles.
• Start noticing the good and bad user experiences you
encounter every day.

65. David Little
david.little@kcl.ac.uk
http://dilbert.com/strips/comic/2009-03-21/

66. DESIGN EXERCISE
• Suggest up to three changes to the CCED search screen
which would assist amateur local historians.
• 5-10 minutes: familiarise yourself with the brief.
• Maximum 25 minutes on the design: sketch!
• 5 minutes: prepare to present.
• 2-3 minutes per group: present your ideas.
• No right or wrong answers.