Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UX for Business Analysts

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

  • Be the first to comment

UX for Business Analysts

  1. 1. User Experience for Business Analysts
  2. 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. 3. 1. What is UX? A brief intro to User Experience 3
  4. 4. Source: Morville's Facets of User Experience Refined? 4
  5. 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. 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. 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. 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. 9. Source: Morville's Facets of User Experience Refined? 9
  10. 10. 2. Requirements Gathering UX design also involves requirements 10
  11. 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. 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. 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. 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. 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. 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. 17. Activity #1 Making a persona 17
  18. 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. 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. 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. 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. 22. 3. Information Architecture It’s not about the underlying data 22
  23. 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. 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. 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. 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. 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. 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. 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. 30. 4. Screen Design A quick guide to what should be on a screen 30
  31. 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. 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. 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. 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. 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. 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. 37. Activity #2 Heuristic Evaluation 37
  38. 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. 39. 5. Usability Testing A primer on testing usability 39
  40. 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. 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. 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. 43. Activity #3 Usability Test 43
  44. 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. 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. 46. 6. Wrap-Up What to take away from this session 46
  47. 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. 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. 49 THANKS! Any questions? You can find me at www.rickdzekman.com or on Twitter, LinkedIn, or SlideShare

×