Slides from a training session introducing UX concepts to Business Analysts. This includes: * An explanation of what User Experience involves * How to include "contextual inquiry" into requirements gathering * What "Information Architecture" is and how to manage findability and discoverability * A brief introduction to Usability Testing

1. User Experience for
Business Analysts

2. Hi
I’m Rick Dzekman
A User Experience Consultant who’s
worked on a wide range of projects from
small apps to enterprise software
2

3. 1.
What is UX?
A brief intro to User Experience
3

4. Source: Morville's Facets of User Experience Refined?
4

5. “ Something is usable if
▸ A person of average (or even below
average) ability and experience
▸ can figure out how to use the thing
▸ to accomplish some desired goal
▸ without it being more trouble than it’s worth
- Steve Krug

6. 6
▸ Findability / Discoverability are about how
users navigate interfaces
▸ Often called “Information Architecture”
▸ Includes navigation & search but also
screen organisation (tabs, toggles, etc.)

7. 7
▸ Ensuring that the most amount of people
can access what we design & build
▸ Includes devices (mobile, desktop),
interface (touch, mouse), connectivity
(online / offline), and more
▸ Making sure that we don’t discriminate
against people with accessible needs

8. 8
The other side of the value chain
▸ UX is not just about design
▸ To make sure our designs bring value
they need to serve a useful purpose
▸ Our target users need to want or need it
▸ The entire solution needs credibility to
give our users confidence

9. Source: Morville's Facets of User Experience Refined?
9

10. 2.
Requirements
Gathering
UX design also involves requirements
10

11. Requirements in UX look a little different
▸ Make sure we are building the right thing
▸ Don't ask users what they want - instead
use “contextual enquiry” to find out what
their goals / problems are
▸ Understand:
▹ Goals, Behaviours, Mental Models, Emotions,
Access Methods, Journeys
11

12. Requirements & Goals
12
Requirement: car must have a speedometer on the dashboard
Goal: get from point A to point B
A self driving car would address the end goal
and may not need this requirement at all
Goal: drive at a safe speed to avoid accidents/speeding fines
What if the car automatically knew the speed
limit and automatically cruised at that speed
unless the brake was applied?

13. Requirements & Behaviours
13
Requirement: alarm must have a snooze option
Behaviour: perpetually hitting snooze till absolute last minute
If we designed an alarm to accommodate this
behaviour, what might it look like?

14. Requirements & Emotion
14
Requirement: show user’s current / active bank balance
Emotion: financial difficulty may cause anxiety about available
funds to pay upcoming bills
We shouldn’t design a banking platform
assuming all users are financially stable. How
might we help people alleviate anxiety about
not knowing where their money is going?

15. Requirements & Mental Models
15
Business process: if a university student wants to take a
semester off they need to apply for a leave of absence; if they
don't enrol in units their enrolment is considered lapsed
Possible mental model: student believes they are enrolled at
the university unless they drop out and that enrolment means
enrolling in subjects. If they want to take a semester off they
simply don't enrol in any classes. What could go wrong?

16. Defining Requirements as a User Journey
Gathering methods
▸ Customer Interviews
▸ Diary study
▸ Observation
Presentation
▸ Personas
▸ Journey Maps
▸ User stories
Aim
▸ Understand goals and behaviours
▸ Empathise with users’ emotions
▸ Understand their mental models
Purpose
▸ Understand different perspectives
▸ Consider more than just function
▸ Go beyond business processes
16

17. Activity #1
Making a persona
17

18. Persona for an eCommerce store
Use someone you know as an example (or yourself)
Situation: Person wants to buy something
▸ Book, item of clothing, gadget, appliance, etc.
Questions:
▸ Do they know exactly what they want?
▸ Why do they want to buy it? (gift, occasion, problem, hobby)
▸ How long can/will they wait for delivery?
▸ What's important? Brand, specific product ID, colour, etc?
▸ How tech savvy are they?
▸ How do they find the site?
18

19. A Simple Persona Template
19
Name
What they are looking for (one line)
A quick profile or
stats, e.g:
“Not tech savvy”
“Cautious”
“Time-poor”
Their story…
● What are they buying?
● Why?
● How did they get to this website?
● What are they thinking about?
● What’s their emotional state?
● How do they expect things to work?
● What matters to them about this particular
purchase? (familiar brand, colour, etc.)
Keep it short (2-3 paragraphs)

20. Persona Reflection
Based on this persona...
▸ How would you design the navigation or
“Information Architecture”
▸ What should the checkout be like?
▸ When listing products what key information would
we need to highlight to them?
20

21. Requirements & UX - Key Takeaways
▸ Requirements you gather impact customers - real
people who sit on the other side of a screen
▸ Using our systems & apps is a small part of end
users’ lives and always a means to an end
▸ Emotions, behaviours, and mental models
influence how people interact with a system
21

22. 3.
Information
Architecture
It’s not about the underlying data
22

23. What is IA?
▸ Information Architecture is not Data Architecture
▸ In the world of UX it is about how our users find the
information they need through what we design
▸ It includes navigation, search, content hierarchy,
page layouts, and anything that impacts wayfinding
23

24. Navigation, menus, and search
▸ Deep navigation vs wide navigation
▹ Depth is how nested nav items are, and how
many nav items you need to go through to get
to the thing you are looking for
▸ In the navigation below, where would you click to
start an application for their services?
▸ Different people will try different menu options for
the same goal; others will go straight to search
24
About us New customers Existing customers How to apply FAQ

25. Taxonomy
▸ Client
▹ Project
▹ Release
▹ Component
▹ Tasks
25
▸ Project
▹ Epic
▹ User Story
▹ Task
▹ Item
Consider the possible taxonomies we might have for a
Project Management tool, e.g.:

26. Relational Architecture
26
Consider how we might organise a media/content hub
▸ Content could be browsed by:
▹ User, tag, category, date, type, search query, etc.
▸ Content may have comments
▹ Users can see all their own comments
▹ Content viewers can see all comments on content
▸ How do we surface new content? “Recommended”
content, “similar” content, same tags?

27. Screen Layout & IA
27
Each of these layout decisions influence wayfinding
Tabs
Progress bars
Some page title
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Vivamus at massa vel diam
eleifend porta quis et nulla. Fusce ultrices
dui nulla, vitae imperdiet nunc viverra sit
amet. Duis sagittis pharetra sapien ut
vulputate. Interdum et malesuada fames ac
ante ipsum primis in faucibus.
Modals / Dialogues x
Buttons >
Options
Information hiding behind
ambiguous icons
Bread > Crumb > Trails
White Space

28. Why Information Architecture Matters
28
▸ Our users have mental models of how information
is organised - these models can change over time
▸ When we design navigation (and other wayfinding)
we assume a particular mental model
▸ Our assumptions about where users will think to
look are very often wrong

29. How to Design Information Architecture
29
▸ Test before we commit to a data model that
constricts our IA (and is expensive to change)
▸ Use research techniques like card sorting to work
out users’ mental models ahead of time
▸ Test assumptions with Usability Tests / Tree Tests

30. 4.
Screen Design
A quick guide to what should be on a screen
30

31. Screen Design: State
31
▸ A screen should show the user the current “state”
of the system
▸ Questions that could be answered with state:
▹ Where Am I?
▹ What actions have been performed so far?
▹ What is the current status? (e.g. of actions)
▸ Imagine the user gets distracted for 10 minutes
and comes back… “what was I doing again?”

32. Screen Design: Options
32
▸ On any single screen the user needs to know what
their options are
▸ What actions are allowed / possible?
▸ Where can I navigate to?
▸ What will happen if I select this option?

33. Screen Design: Feedback
33
▸ If an action is performed the screen should give
instant feedback to acknowledge the action
▸ This is especially important in interactive systems
▸ This feedback is how we tell the user:
▹ “yes, pressing that button did indeed work. Not
only do you not need to press it again but it’s no
longer possible to do so”

34. Screen Design: Response
34
▸ Once the result of an action is (quickly) completed
we need to let the user know the result
▸ What did the action do? What are the
consequences? What does this mean for me?
▸ Were there any problems? Can the action be
undone? Can I go back to the previous state?

35. Screen Design: Heuristic Evaluation
35
▸ A good way to evaluate a screen (or a set of
screens) is to use a heuristic evaluation
▸ Jakob Nielsen has an article called:
▹ “10 Heuristics for User Interface Design”
▸ Use these heuristics to evaluate designs

36. Screen Design as a BA
36
▸ As a BA you often define the requirements for
various screens / interfaces
▸ Sometimes you even wireframes / design them
▸ It’s easy to get lost in business / technical
requirements and forget about end users

37. Activity #2
Heuristic Evaluation
37

38. Heuristic Evaluation Exercise
38
▸ Take an App or Website you are familiar with
▸ Go to a random inner screen / page
▸ Evaluate the screen against the 10 heuristics
▸ How effective would this be for a first time user?
What about a less tech-savvy one?

39. 5.
Usability Testing
A primer on testing usability
39

40. Usability Testing is not like UAT
40
▸ Usability testing is used to see if an end user is
capable of completing some task (or goal)
▸ No instructions are given to the user other than a
specific task
▸ Help is given to users only if they get stuck and
cannot complete the process (obviously this is
considered a bad thing)

41. How Usability Testing Works (1)
41
▸ Give users a specific task which has an end goal
(e.g. find the location of your next exam)
▸ If possible try to find an actual end user, using their
own behaviours and goals
▸ If you can't find actual end users try anyone who
hasn't seen the system, do a “hallway usability test”
where you ask the closest person near you, if you
are really stuck ask a team member on the project

42. How Usability Testing Works (2)
42
▸ Tests can be done on paper prototypes,
wireframes, dev/test releases, or live in production
▸ During the session ask the participant to think out
loud, let you know what's on their mind, ask you any
questions they might have
▸ Try to record the session (screen capture + audio +
(optional) webcam) to review later
▸ Find the biggest difficulties people had and try to
come up with a solution to address them

43. Activity #3
Usability Test
43

44. Usability Testing Exercise - Pair Up!
44
▸ One person will pick an app/site they are familiar
with; give a task to the other person; then observe,
prompt the person to think out loud, take notes
▸ Second person will use the app/site to complete a
specific task on the phone
▸ Where do they go? What do they click? Why? What
are they thinking/feeling? Did they succeed?
▸ Make the task have a specific end goal - “order an
Uber”, “create a shopping list”, “find this video”, etc.

45. Usability Testing Outcomes
45
▸ Who succeeded in their task?
▸ What were the first steps they took?
▸ What was easy?
▸ What was difficult?
▸ What would be one thing you could change to
make this experience better?

46. 6.
Wrap-Up
What to take away from this session
46

47. Key Takeaways
47
▸ When gathering requirements try to get input from
your actual users through “contextual enquiry”
▸ Think about Information Architecture (and test it)
▸ Usability is perfected through testing - don’t just do
UAT but try usability test with real users too

48. Recommended Reading
48
▸ “Don't Make Me Think (Revisited)”
▹ By Steve Krug
▸ “The Design of Everyday Things”
▹ By Don Norman
▸ “The Elements of User Experience”
▹ By Jesse James Garrett
▸ “A Project Guide to UX Design”
▹ By Russ Unger and Carolyn Chandler

49. 49
THANKS!
Any questions?
You can find me at www.rickdzekman.com or on
Twitter, LinkedIn, or SlideShare