UX Requirements Made Simple: My proven method for smarter, UX-focused product requirements | Joe Natoli | Skillshare

UX Requirements Made Simple: My proven method for smarter, UX-focused product requirements

Joe Natoli, Coaching & Training for UX Designers & Developers

UX Requirements Made Simple: My proven method for smarter, UX-focused product requirements

Joe Natoli, Coaching & Training for UX Designers & Developers

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
21 Lessons (3h 19m)
    • 1. Introduction: What We'll Be Learning (and Doing)

      6:35
    • 2. Why Traditional Requirements Produce Mediocre Products

      9:16
    • 3. Poor Methods of Requirements Generation

      18:40
    • 4. Assumptions and Misunderstandings: What Requirements Really Are

      9:44
    • 5. Poor Tools for Requirements Generation

      18:25
    • 6. The 1st Kind of Requirements: What People Say They Need

      8:27
    • 7. The 2nd Kind of Requirements: What People Actually Need

      11:16
    • 8. The 3rd Kind of Requirements: What People Don't Know They Need

      13:12
    • 9. Empathy Mapping: Uncovering User Needs

      2:53
    • 10. EXERCISE: Create an Empathy Map

      2:02
    • 11. Sample Answers: Empathy Map Exercise

      9:31
    • 12. Situational Mapping: Uncovering Context of Use

      1:43
    • 13. EXERCISE: Create a Situational Map

      1:27
    • 14. Sample Answers: Situational Mapping Exercise

      8:04
    • 15. Wrap Up: Empathy & Situation Mapping

      6:09
    • 16. The UX SIlver Bullet: Context (and Contextual Use Scenarios)

      14:35
    • 17. Communicating Use: Creating Visual Workflow Scenarios

      12:09
    • 18. Generating Functional Requirements from Use Scenarios

      10:38
    • 19. 18 EXERCISE: Generating Functional Requirements

      1:51
    • 20. Sample Answers: Generating Functional Requirements

      23:28
    • 21. Takeaways: Things to Remember

      8:50
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

249

Students

--

Projects

About This Class

What UX struggles would you love to end?

  • Do you want to stop the endless cycle of rework to satisfy stakeholders’ moving targets?
  • Would you like to play a role in creating requirements instead of having them handed to you like written law?
  • Are you tired of delivering products with UX defects you know could have been avoided?
  • Do you wish there was a way to get managers to agree to UX work at the start of the project, instead of tacking it on at the end, when it’s too late?

If you answered YES to any of those questions, you’re in the right place. I created this course specifically to end the vicious cycle too many developers and product teams are trapped in: vague requirements they had no hand in creating, constant rework and a never-ending stream of new (and changing) requirements. 

See, I’ve been there myself. In nearly 30 years of working with organizations of all sizes in nearly every industry, I know that cycle all too well. I know what it’s like to try and roll the “UX rock” up that hill only to have your stakeholders or managers or clients roll it back down.

No more debate about when UX work should happen.

I know the pain of fighting to get UX included at the start of a project all too well. And I also know that it’s entirely possible to put an end to it.

UX Requirements Made Simple will show you how to get a seat at the requirements table, open the minds and ears of your managers or clients, and see a massive change in both the quality of requirements and the success of the delivered product. In the time it takes to watch a great movie, you‘ll learn to:

  • Use faster, simpler methods to generate, validate and prioritize requirements, resulting in an MVP that clearly demonstrates the power of good UX — from the very first sprint onward.  
  • Integrate user research and validation into an existing requirements process — without a fight!
  • Get a clear, solid sense of what users really need — even if you have no budget to do user research.
  • Easily identify the "sweet spots" where features and functionality deliver maximum value, great UX for users and ROI to the business.
  • Learn a simple way to get managers and clients to listen to your UX recommendations — and act on them.
  • Replace cumbersome, formal tools with clear, simple exercises that uncover true UX needs and get everyone on the same page, sharing the same UX goals and understanding their importance.

You’ll see how easy it is to quickly integrate strategic UX validation into an existing requirements process — without the need for additional time, money or resources. Here’s just some of what you’ll learn:

  • Poor methods for requirements that rely on a broken engineering process — and a better, simpler set of methods that get to clarity and value quickly.
  • Why what users say they need isn’t what they actually need (and how to tell the difference).
  • Poor requirements tools that address task completion instead of success — and a smarter set of tools that focus your work squarely on desired outcomes.
  • How to get managers or clients (or your team) to ask the right questions, instead of solution jumping.
  • How to create contextual use scenarios that tell the real story of the user’s journey from start to finish — and extract relevant functional needs and elements that make up valuable requirements.

It’s simple, it’s straightforward, and it works.

Not because I say it does — but because the Enterprise teams I’ve taught to use these methods have gotten the results I’m talking about. It works because more than 140,000 students (yes, that’s a real number) tell me that my courses have changed the work they do for the better.

Why? Because I deal in software development reality instead of UX fantasy. Perfect situations where we can do these well-funded deep dives into UX research don’t exist for a vast majority of development teams, and I’m really tired of hearing everyone pretend otherwise. So everything I deliver is based in reality, in the less-than perfect world most of us live in.

Meet Your Teacher

Teacher Profile Image

Joe Natoli

Coaching & Training for UX Designers & Developers

Teacher

I've been helping Fortune 500 & 100 organizations train Product Design, Development and UX Teams from the ground up for 29+ years.

I've shown them how to incorporate real-world UX and design best practices into their work, without reinventing or disrupting what they do every day.

I speak at conferences, delivering keynotes, lectures and workshops, all over the world.

I've launched seven successful online courses, with more than 140,000 students (yes, that’s a real number).

My students tell me those courses and workshops are valuable because I deal with the reality of working in the messy corporate world — instead of the UX fantasy land far too many authors and so-called "experts" describe in their speeches, articles and courses.

I have... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. Introduction: What We'll Be Learning (and Doing): ask any group of people what they want or what they need, and you'll get no shortage of opinions or answers. Clients and stakeholders will always have a voluminous laundry list of features and functions, all of which they insist are equally important. Be that as it may, your clients, your employers, your project stakeholders and your users all share something very important in common. And that's the fact that they're all human beings. And we human beings, by turn, also share a very fundamental flaw. We often make very confident but equally false predictions about our future behavior. So the requirements that will actually be most useful, most valuable with ones that will increase user adoption or drive sales with ones that at the end of the day will either save US money or make us money are almost never surfaced in traditional requirements sessions. The purpose of this course is to show you how to change that, something I'd like to point out before we get too deep into. This is the fact that you actually your experience is about much more than users. I always say it's unfortunate that that term exists in the in the term It's really about the intersection of user needs and business schools. The things that live in the middle of those two sets of requirements of needs are the sweet spots, those air things where when you make improvements to use your experience, value gets delivered to both of those groups on user side, You're making life or tasks simpler or easier for people, which makes them feel confident, competent in control. That ensures that they have an easy time using what it is you've created. And it also ensures that some sort of loyalty develops between them and the product On the business side. When that value happens with users, it also usually results in the business making or saving money in some way. Okay, you were increasing our market share. We're getting more people to try or by or download our products. Or we're saving money through some efficiency That's gained because the system is easier to use, were keeping our existing customers were making sure that they know jumped ship to competitors or, of course, we're gaining new ones. Meaningful relevant requirements have to address both sides of this equation, focusing all of our efforts on a single question what will deliver value? So here are our core topics for the course. First, I'm gonna talked about why the requirements process to traditional way this is done, Why? It's broken, and I'm also gonna explain how to fix it. From there we will talk about why traditional requirements fail, why they produce mediocre products, why they produce poor products. We're going to talk about the three reasons this happens, and we're going to explore solutions to each problem. Next, we're going to get into the three kinds of US requirements that have to be addressed if you're gonna produce anything of value. And those are what people say they need, what they actually need and what they don't know they need. From there we will explore what is known as empathy and situation mapping. And that means turning user needs, behaviour, motivation, situational factors into functional needs and requirements. Taking all the things that influence user motivation, behavior and action, and extracting really valuable meaningful requirements from those situations will take that one step further. In talking about context of use, I am going to show you the power of what's called a contextual use scenarios, which is a heck of a lot simpler than it sounds, but it has massive power to uncover riel again meaningful requirements simply by telling a story. And finally, I will give you a set of mantra is which, if you forget everything else that is said during the course of our time together. I hope you remember these things. Finally, I want to give you a quick overview of what will be learning and what we'll be doing. In a little more detail. You'll learn why traditional requirements gathering Onley creates scope, creep stress and a final product that is mediocre at best will clearly illustrate the difference between traditional and you X focused product requirements and why the latter US focused requirements is so important. I'll show you the poor methods that are used for requirements generation that rely on a broken engineering process and confuse solutions with needs. We'll dig into the assumptions and misunderstandings about what requirements really are that in all honesty, the majority of people share. I'm gonna tell you why they're wrong. I'm gonna tell you how they impact the work that you do, and I'm gonna tell you how to get around them. We'll uncover why What people say they need isn't often what they actually need. And I'm gonna show you how to tell the difference between those two things. You'll also learn how to uncover things people don't know they need, but absolutely dio. And I'm also going to show you how to ensure that those things make it to your requirements list. I'm gonna give you examples of the poor tools that are commonly used for requirements generation that address task completion instead of success. I'm gonna give you a smarter, simpler set of tools that focuses your work squarely on what matters most desired outcomes . You're also going to learn how to create more useful, valuable functional needs and requirements based on the concepts of user empathy and context of use. You will see how it's possible to get stakeholders along with your team members toe ask the right questions. Instead of jumping to solutions right from the word go, you'll learn how to create contextual use scenarios that tell the real story of the users journey from start to finish and at the same time provides the functional needs and elements that makes up meaningful requirements. You'll discover a simpler, more efficient way to uncover, invalidate interaction. Work flows by diagramming them visually and no, This ain't UML. For those of you that may be familiar with it, it's over complicated. It's too rigid. It's too formal. It is needlessly complex. I'm gonna show you something that is much, much simpler. Finally, I'm gonna give you exercises where you'll do the work and you'll learn how to leverage these methods in these tools. And I'm giving you in your own work. You'll be able to take everything that you learned in this course and apply it to anything you are either currently doing or will do in the future. 2. Why Traditional Requirements Produce Mediocre Products: I want to talk for a minute about traditional requirements, gathering sessions, and I want you to pay particular attention to the fact that the word gathering is in parentheses. It's a very loaded word, and you'll see why. Have you ever participated in what was called a requirements gathering session that anyone around you use that term, whether it was a client team or your internal stakeholders were people on your team during or after that session? Did you feel confident that you, your team and or your client understood how requirements would meet user needs? Was there clear connection between the two things? Did you all understand how requirements would ensure products success? Did you even understand what constituted success from that session? Did you get an understanding off what the measurement would be of whether this thing that we've done has succeeded or failed, get everybody in the room agree on what constituted success? Okay, so think about the last time you were in one of these sessions and think about whether any of those things were clear to you. My bet is that they weren't how many of those sessions provided clues. Valuable clues as to what the ideal user experience should be like. How many of them provided clues as to who you're designing and building for beginners, intermediates experts? At what level of proficiency were the people using this thing at? Did you understand what the users journey might eat from start to finish? Or how many of those journeys there might be? Did you understand how users might move through work flows or screens? And finally, did you understand how simple or how complex the you I should possibly be? This idea of gathering requirements on Lee creates products that people either don't want or can't use, which results in zero our ally for the business. Why? Because all those things I just mentioned are typically never surfaced, never discussed, never explored and what is considered a gathering session. So what are you X focused requirements? I'm harping about the fact that traditional requirements don't account for user experience . So what I mean by that? Well, UX focus requirements don't assume that anyone truly knows beyond it out. What actually needs to be designed or built. Your ex requirements generate ideas, not features, not specifications. Ideas to be explored, qualified and validated Well before they make it to a requirements list. UX requirements are born from iterative activity, user and stakeholder research, interviews, observation, prototype creation, evaluation and testing. We are not sitting in a room talking about what we think are the right things to do. This is not opinion. It's born out of observation. In fact, U S requirements focus squarely on desired outcomes, not features and not functionality. The core questions are what the users expect and need to be able to do. What does the business need them to do? Let's the desired outcome of product use. Our focus is on outcomes, not features, not functions. Now let's compare typical requirements versus UX folks requirements. OK, I want to give you an example of the difference. Typical requirements are very different from their U X focused counterparts. Typical requirements Look something like this. Implement 1/3 party human slash machine readable knowledge base, Zendesk confluence, etcetera that stores help documents, manuals, troubleshooting information and FAA cues. Allow support engineers to create articles based on pre defined templates and allows users toe opt in to technical alerts. So we've got a list of facts great, but there are a lot of questions that are unasked, that should be asked. And those look like this. How do we know we need 1/3 party vendor requirement that automatically names a specific platform of specific languages? Specific solution assumes that we know exactly what the solution of this problem is, and by my eye that is usually extremely premature. You don't know enough at this point in the game to make that decision. How do we know that this is what people want to see or use? Typically, requirements are the very first thing that happened during a software development cycle, and at that point there's usually no user input or research, and they're normally has not been any observation in terms of what people's behaviors are. We may have done some surveys. Okay, we may be getting executive opinion about what people care about what they want. Um, but it's nothing more than that. It's usually just opinion or its knee jerk reaction to a problem that's happening, which means, OK, the software isn't selling, and we got to do something. Either way, you're not basing your requirement lists on known elements. You're guessing. How do we know this feature is even necessary. Just because we say it out loud just because we think it's important, How do we really know? How do we know that users want to do this or we'll do this, even if there is a sound reason to do these things? What we don't see in any of these statements are the reasons that these things exist. Therefore, nobody on the team has a full understanding of why any of these things are important. No understanding of how important they are, no understanding of which requirements are most critical to the product's success because we all know that going down a project path, time, money, budget and resources are finite. There is only so much we can do in a given period of time, and we may not be able to do it all. So how do we make decisions as to what matters most? How do we figure out what the sacrifice? If we don't know the answers to these questions? We don't know what can be sacrificed, so we make arbitrary decisions at the danger of a traditional requirements list. So now let's look at a similar set of requirements that are you X focused develop a seamless self service experience that reduces user frustration by presenting help topics in simple terms. People can understand, gives administrators the ability to accept and manage inbound ticket requests from any channel, email, web, social phone or chat. And that reduces our current support request volume. I am minimum of 43%. Now look down this list and compared to the long left, first and foremost, it does not make assumptions about what the right solution is. It simply says, develop a seamless self service experience, meaning something that allows people to help themselves, something that reduces user frustration that presents help topics in simple terms that is a UX focus requirement. Let's pay attention. Toe language. Let's pay attention to how this stuff is displayed when we're evaluating possible solutions . Were probably therefore looking for something that is easy to customize. That is simple. That is flexible. The second bullet says give admin, is the ability to accept and manage inbound ticket requests. Important part here from any channel. Give people flexibility If I want email, great. If I wanted the website great. If I want to contact you via social media, phone chat, whatever it is. That's as far as the requirement goes, says this is our end goal. This is what we're after. We don't know what's gonna fulfill it. We don't even know if it's possible, but this is what we're after. The third bullet, especially speaks to a measure of success, reduces our current support request volume. I am minimum of 43%. With that goal in mind, you evaluate potential solutions very differently because in your head you are thinking, Is this something that legitimately is going to allow us to put enough out there to really reduce the amount of phone calls that we get? Are people gonna be able to use this in a way that's keeps them from picking up the phone and calling us those air user experience? Focus requirements there no assumptions as to what's gonna work? And we're trying to make statements about what the end goals are, as opposed to how the features or functions. Work requirements is a big word with even bigger baggage. Immense time and effort has often spent developing requirements, and the result is often mediocre products that fail. Okay, they feel users, they fail the business there are three culprits for this failure. We're gonna talk about each of them 1st 4 requirements. Generation methods. The methods traditionally used to illicit requirements are faulty, their backwards there mired in a process that Onley uncovers about an eighth of what really needs to be discussed. The second culprit is assumptions and misunderstandings about what requirements really are . And finally, four requirements. Generation tools. The tools that are typically used in these quote unquote gathering sessions aren't really equipped to do the job. They're not really built to address the messy human components of what is really needed. You know what people are going to use, what they're be willing to use, what they'll expect, what they'll understand. The methods currently used focus on identifying features and functions, and they rarely go beyond. 3. Poor Methods of Requirements Generation: So let's talk about the first culprit for poor requirements, and that is poor requirements. Generation methods tell you a quick story. By way of example, I worked with health care organization recently, facing several issues with their accreditation reporting system. They were in accreditation organization, which means that it is their job to certify healthcare organizations and say, yes, they're legitimate. They meet thes certain standards and therefore they get, you know, sort of gold seal of approval from us. They had completion and accuracy issues. 37% of all their audits were not submitted by deadline or they were submitted with incorrect data which resulted in having to resubmit. And also they had to pay very hefty penalty fees for submitting late. They were also experiencing a great deal of customer frustration. There were penalties for customers as well. Because of the audit, reports weren't being submitted on time, which results in a lot of frustration right there, saying I'm being hit with a fine. I did everything I gave you all the stuff by the deadline. You didn't turn it in late, and somehow this is my fault. All right, So what happens? Customers trust in this organization begins to road, and it's very difficult once that happens to regain that trust. Finally, they were dealing with market share loss. Customers were jumping ship to competitive organisations at the rate of 8% monthly and growing. Now, at this point in time, there weren't that many other organizations who could do what they did. But there were some upstarts that were doing things in a different way that were operating in a cheaper price point, and it was attractive for people who are frustrated. If it's easy for them to switch, you better believe they're gonna be looking to do it. So by the time I get called in, I saw a list of agreed upon requirements for a system redesign. Okay, this was done before I came in. I saw features. I saw functions I saw use cases and user stories. This was all laid out. It was all done. This was about $1.8 million in estimated work. After I reviewed all of it, I asked a very simple question. What evidence do you have that thes requirements are going to solve your problems? After a very uncomfortable discussion, we eventually got to the truth. There was no such evidence. Nobody in that room had any confidence that this list was going to alleviate the pain points that they were currently having. Now think about that for a second. You're gonna spend $1.8 million. You're going to spend probably at least 12 to 18 months of work of man hours of internal costs, and you don't know whether what you're doing is actually going toe work. This is the definition of insanity, and enterprise organizations do this every day to give you some context. Here are some of the sample requirements that I saw when I first came in the door. The first was, We need to develop an auto assignment logic in some functionality so that news submissions air automatically assigned to one or more reviewers and that review system. That's the status that goes along with it. And everything else has to integrate with our current project and resource management system, which is an enterprise application, a big beast. Here's the problem with this. It assumes that the problem is that submissions aren't being assigned quickly enough right that we just can't get work in people's hands fast enough, which, as you'll see in a moment, is absolutely not true. That is not the problem. The other issue with this requirement is that the cost of integration, the cost of building this new piece and integrating it with this massive project and resource management system equals 38% off the entire budget. 38%. Is that really worth doing? Is that really solving the problem? And if you spend that much money, are you certain that it's going to solve the problem? Another requirement specified that we needed to add performance metric definitions, descriptions and requirements to each category. Subcategory, item detailed was on screen. In other words, reviewers air looking down the list of requirements that the organization has to meet. This says, Look, there isn't enough information there. People don't know what they're looking at. They don't know what this stuff means. They don't know what the actual requirements specify, etcetera, etcetera. So the assumption here is that the problem is that reviewers don't have enough information on screen to do their work. Here's the real problem with this requirement, adding this content represents an additional 3200 words on screen for each of up to 120 plus categories, which includes 300 plus sub categories and 500 plus individual items per submission. This is a massive increase in cognitive and physical workload. There is a tremendous amount of new content being added to the screen that has nothing to do with the actual actions the user needs to take so that we're adding a bunch of stuff that they now have to contend with. In addition to trying to do their jobs again, you're going to see shortly why this has nothing to do with what was happening. Another requirement specified that we needed to indicate status and submission deadlines more clearly in multiple areas that daily reminders should be triggered starting 90 days prior to the deadline. So things should pop up on screen and say, your deadline is looming. Here's where you are in the process, you know, move faster, get more done that also included email triggers. So these folks are getting constant email reminders. Hey, here's the deadline you're behind. This requirement assumes that the problem is that project status isn't visually obvious enough, right? Reviewers don't know when things are do the problem with this is that it's non specific. They're not saying how that status gets indicated. We're not saying where it gets indicated. We're not saying in how many places it gets indicated this is how vague the requirement was . So you're inviting a tremendous amount of design guesswork. You, I guess, work development guesswork as to how it gets implemented and how it works. You are increasing the reviewers workload, and you're taking them away from their task constantly, both cognitively and physically. If I'm trying to do something and I've got constant reminders flashing in my face, if I'm getting emails constantly from getting notifications while I'm trying to do my work , that's taking my brain off the task at hand. It's not helping me be more efficient. It's distracting. Another requirement said create a separate document library separate system to serve as the single sole repository for all customer documentation. When an organization submits their application in their qualifications, there is a tremendous amount of documentation that goes along with it, okay to prove that their organization meets these requirements. Here's the problem with this particular requirement. It assumes that the problem is finding documentation that the reviewers can't find these documents. So they're saying Take him all, put them all in one place and that with the new everything is here's the problem with that Those documents in and of themselves are meaningless if they're not viewed in context with the requirement. The requirement that each document serves defines its meaning and gives it value. If you look at the document without also seeing the required attributes, you won't know what you're looking at. You have no way to evaluate it. You don't even know what it means. You don't know whether it does or does not meet the standards. So what we're doing here is we're increasing reviewer workload. They've got to go to a different place to get a document. Then they've gotta go back and look at other screens to see if it meets the requirements. There's a lot of bouncing back and forth, so this is cognitive workload. It's physical workload. In either case, we are making mawr work for these people, not less if you're already behind. If things are already being turned in late, if you're paying a hefty price for that happening, adding more workload either cognitive or physical is not the way to solve this problem. So I called a time out. I don't like to guess, and I especially don't like to guess with other people's money. So they agreed to the idea of shadowing users for two weeks to find out what was actually happening. What was the rial underlying cause of late submissions? That's what I wanted to know. That's what we wanted to find out. Why is this happening in the first place? Let's back up and figure out what the underlying problem is. We know the symptoms. We do not know the cause. On day one of doing this user observation, we got a very big clue. Users, offices and desks looks something like this. Stacks of paper everywhere to degree where every square inch of someone's office, every horizontal surface had a stack of paper on it, at least three feet high. In addition, each person had to monitors looking at two different systems of input. In addition to that, they had paper in front of them spread open, sort of like taking an open book tests. So these evaluators, as they were reviewing the company's submissions and going through them much like a teacher would grade a test. They had toe have all this reference around them accessible all the time. But there was a ton of it, right to monitors stuff in front of you stuff around you that at any moment you have to dig through and find a piece of relevant information. So the real problems that were happening were that multiple sources were needed for input desktop machine, laptop for two other systems, multiple windows open on each device, by the way, plus stacks of printed paper from the third system, there was a massive amount of switching time moving back and forth between these three input sources in an eight hour workday. Accounted for a whopping four and 38 hours of time, more than half of their work. Tae was simply spent switching back and forth between sources. That doesn't leave a whole lot of time for actually doing work. We didn't even count the additional time that was spent gathering all this stuff before they could even get started. God only knows how many hours that Waas So right from the get go, we saw something that no one had ever thought about. Discussed talked about ever, but it was staring us right in the face. So the solution we came up with based on that and based on walking through the scenarios with these folks was an open book. You I we knew we needed integration across systems. We discovered it was fairly straightforward to stand up that information from three specific databases in one you i you I needed to be flexible. We needed split screen views. We needed some sort of show and hide a court in functionality to quickly show and hide relevant data as it's needed, while the input feels that the stuff that they were working on remain persistent remained in front of them. And finally we knew we needed emphasis on relational data and mid two, your logic. We wanted to whatever degree possible, make the system do the work of identifying all data related to that particular customer. That particular case, the submission at hand. So again, when you read those three bullets, you're not seeing specific feature specific functionality specific platforms. You're not seeing any specs for how this is gonna work didn't matter yet. The most important thing we had to do at that point with relation to requirements was identify what the heck was wrong in the first place and what needed to be done to solve it . We didn't assume we knew how this is gonna happen. We didn't even assume that was all possible, but we had to start in the right place. And that's what you X focused requirements do. Ideas, not facts, not known answers. Here's a conversation that I know by heart, and this is me asking a client. Okay, usually when I come into a situation like the one I just described to you, so tell me, how did you determine requirements? Well, we gathered them from the existing system what customers said they wanted and from meetings with our marketing executive and I T teams. All too often, requirements are based on false clues. They're based on executive opinion. They're based on development, or I t technology preferences there, based on what customers say they want, which is a dangerous minefield. And they're based on what someone in the room thinks customers want, which is an even more dangerous minefield. If you have a bad process, the outcome is a bad product. In the absence of good practices, endless debates, arguments, Political compromises essentially rule the day, and that makes any final requirements that land on that list a matter of opinion. At best, the requirements process takes a lot longer than it should. Okay, a wire frame could have been designed and built to get the development team rolling. We could have been iterating are ready to figure out what's needed and pulling requirements from that prototype. At worst, we go through this entire process and the product fails, which causes great pain to every person involved in a project and in particular the people who built it. Requirements cannot be gathered. Strike that word from your vocabulary. Digital product design expert Kim Goodwin says. Requirements have to be generated. They cannot be gathered. There is no requirements tree out in the backyard as you see here that we can just go pick off requirements. All I need one of these and I need one of those and I need one of these. That's the idea behind gathering, and it's bullshit. It doesn't work. Requirements have to be idee ated. Okay, they have to be iterated. They have to be worked through in an active process requirements have to be uncovered. You don't know what you don't know at this point and requires the most often negotiated between product managers between the i t team between developers, designers. If you're working for an external client, there's other layers of politics, right? It's a negotiation. Otherwise, what stays and goes is usually just a matter of popular opinion and political compromise. And neither of those things lead to a product that delivers value either to customers who need to use it or back to the business that created. The other problem I have with the idea of requirements gathering is that it reduces every person in the room to the role of an order taker, and that decreases your ability to really help them get to the right solution. It decreases your value to that client or to that employer. It decreases what they're willing to pay you, quite frankly, if you don't have anything to contribute strategically, if you can't help them move the needle in some way, remember making money saving money, then you're just another pair of hands, and your value as such is greatly diminished. Here's the take away in all this requirements absolutely cannot be gathered. It is not possible there generated and their negotiated. If you use that word. If people you work with use that term, I want you to strike it from your vocabulary. And I want you to tell the story. I just told you to. Every single person that you worked with requirements cannot be gathered. They're not waiting for us to pluck them out of the sky or off a tree in the backyard. The next problem is that the engineering method that is usually used for generating requirements is broken. The traditional engineering method looks like this. First we define the problem. Then we do background research, OK, and there may be a little back and forth there. Then we specify requirements. Then we brainstorm, evaluate and we choose a solution. Then we develop in prototype that solution. Then we build and test that solution. Based on our prototype, there are two possible outcomes here. Either the test solution meets requirements or it doesn't meet requirements. If it doesn't meet requirements based on results data, we make design changes. We prototype again. We launch and test again, and we reviewed the new data which lands us back at brainstorm of value and shoes solution . And we go through this entire process again. Okay, so that's a traditional engineering method. Now, all that will seem perfectly logical as we look at it. Okay? We look down the list and we go, Yeah, that makes sense. I don't see any problems with that. The problem is this This step is in the wrong place. It's premature. We don't know enough yet at that point in this process to specify requirements. Why? Because we haven't done anything. We haven't done any work. Okay, we've talked about We think the problem is we've probably done a little bit of research, but we haven't done anything. We haven't explored any examples. We haven't done any prototyping. We're guessing everything that we're doing right now is guessing. And that's because these four elements are completely out of order. If we take this method and change it with aux focused approach, it looks like this. First we to find the problem. Then we do background research, right? 1st 2 steps the same. No problem. Then we brainstorm, evaluate and choose potential solutions, which means were trying to gear up to create a prototype of some sort. Low fidelity, low costs, you know, Basic wire frame, html CSS. No real fonts, no real colors, no real images, no riel functionality, right? Just were just mimicking work flows in html and moving really, really quickly just to get ideas out that goes through several cycles. Okay, this looks like a waterfall type process, but really, what's happening is it's a constant process of build review change, revised review, change, revised review, etcetera, etcetera. It goes over and over and over again. Once we've done that, once we've kicked out all the things that don't make any sense. Once we've gotten our prototype in front of people, too may be tested right and gotten some riel time user reactions. We've watched people use it and seen where they struggled. Then we start specifying requirements. Why? Because now we've got fact, we got something we can really hang our hat on. We've got things that we know to some reasonable degree are gonna be usable, are gonna be useful, are gonna be valuable. Then we developing prototype the solution in some real form. Now we're integrating riel functionality. Okay? We're cycling. And then what? We build either meets. The requirements are it doesn't meet the requirements. If it does, then we build and test the final solution. Do you see the difference up to now? We've considered the fact that nothing we've done is Esten Stone because we really don't know. We don't know what we're trying to get closer to certainty as we go along. If it doesn't meet requirements, we go back to the brainstorming phase. But we're doing it in a way that we're able to move quickly. We're not wasting any time on endless debate and discussion. We're building. We're iterating. Does it work? Yes. Does work no. Very, very big difference between these two methods. 4. Assumptions and Misunderstandings: What Requirements Really Are: The second reason traditional requirements processes often fail is because there are assumptions and misunderstandings about what requirements really are. So that is our next topic. First and foremost, all requirements are not created equal, meaning that everything on that list is not of equal importance. Here's an example from an actual product requirements document or what's commonly referred to as a P R D. The following information should be available for any single unit VIN number, tracking number, chassis number and serial number. This is for an automotive manufacturer sales order number, customers, batch number, make model type and model color and option information if available. Most recent location and date that this vehicle was tracked. Status and condition date. State has changed. Final destination and dealer is specified. Okay, so this is verbatim. What was in this product requirements document? Here's the problem with all this. Why do we need each of these data points? Is there anything here that explains why this is important? Is there anything here that tells us how that information is gonna be used? Who's going to use it, why they're going to use it? What do we need to be able to do with this data. OK, great. We're gonna service it on the screen. What needs to happen with it? What is the person going to do that? Where is it gonna go? Who else is gonna consume it? And how do we or users benefit from having it in the first place? There's nothing about these statements that tells us the why that tells us the how that tells us the value of these things. Because, as I said earlier, you are not going to be able to do everything. It is never possible. In 26 years, I've never seen one project where everything on the requirements list got implemented. Never know. Once you have to make choices, you cannot make good choices. Good compromises, good trade offs unless you know why this stuff is important unless you know how it's gonna be used unless you know if it's going to be used. Here's what the desired outcomes related to that project actually were. Reduced. Time lost in planning quicker identification of actual and potential operational problems. Reduced time and vehicle tracking for customers and internal purposes. Better matching of operational costs and effort to sales contracts. Better information for future contract negotiations and renegotiations. Unless this information makes it to that document, we have no way of qualifying the value, the importance or the relevance of each one of those requirements, which means that we essentially have no proof that the requirement is necessary. So requirements statements like this should also have detail. If something makes it to that list, there has to be an extremely good reason why it's there and unless that is explicitly listed or labeled, are discussed in some way, no one knows what's important and what isn't. So they will be bound to make arbitrary decisions about what stays and what goes. One of the biggest misunderstandings about requirements is that they are features. Requirements are not features. Features are solutions. Requirements are all about identifying needs. Asking questions. Okay, these aren't answers. Their questions. Here's something I hear all the time. It has to be responsive, and I say, Well, what will making it responsive solved well so people can use it on their smartphone. And then I say, What are they really willing to do on a five inch screen or six inch screen? What I get When I asked that question is typically a blank stare. No one has thought past the knee jerk reaction that this has to be responsive enterprise systems in particular, that are mostly data input intensive. No one is gonna do all this work on a tiny screen. Responsive is the knee jerk. Well, yeah, everybody responsive. So we have to be to. It doesn't necessarily mean that the requirement is appropriate, because your users may never, ever use any of these features on a smartphone. And that has been the case with several my clients. You cannot make assumptions without understanding why they do or don't matter. Here's the take away when the need is grossly undefined. It has no business being a requirement, especially when it's not really a need in the first place. Like the response of peace. I just talked about if you don't have enough information, if you're a member of the team and you don't understand why this matters, it shouldn't be on the list, either. Someone hasn't taken the time to tell you, or it's really not important. Either way, you have to define what matters. Requirements are also not specifications. In far too many organizations requirements still means a novel length document. I'm sure some of you have experienced this. It's generated by product managers. It's handed down like written law. Here's what we're doing. Go do it, you know, go forth and code right. It's not worth a fraction of the time or effort or resource that are put into creating, updating and maintaining it. I worked on a 12 month project once. Where to project managers there. Onley task. All they did for 12 months was update this gigantic gargantuan requirements document. That's all they did. So you paid to people a salary for 12 months toe update, a piece of paper or a stack of paper that no one ever writ. They're too long there, too dense, and they're too linguistically complex for anyone to decipher. I don't know where this got started, but I wish it would die a slow actually a fast, horrible death, right? This idea that we have to write things that are so dense and so complex and so technical that normal people can't make sense of what they read when you write something down, I don't care what it is. Every single person at any level in the organisation should be able to read it and understand what the hell it means if it only makes sense to an engineer for only makes sense to a developer. If it only makes sense to a designer, rewrite it right things so that other people can read and understand them. Forget trying to impress people with these big words and technical terms. Just communicate. The take away is this. You cannot generate consensus on a document that no one can understand or is willing to read. It's too big. It's too daunting. It's immediately like Oh, God, are you kidding me? I have to read all this. I gotta paid through all this and figure out what my part of it is. Come on, look, even if people say Yeah, I read the document they didn't read, I promise you. All right, Nobody read it. They took a glance at the table of contents and said Nope, not happening. Novel length requirement specifications are of no use to anybody. Another thing about specifications documents is that they start wars between project managers and designers and developers and a project manager side. They want a limit or eliminate unknowns of exploration and iteration. Those terms make them nervous, right? Because they're on the hook for budget. They're on the hook for schedule and their next round of chopping blocks. To some degree, they can't manage two unknowns. It makes them nervous. So they're playing cover your ass. Essentially, they're trying to hold designers, developers, engineers accountable for vague things like it must be easy to use. And, yes, that phrase has often made it into requirement specs that I've seen on the designer and developer side. They think everything in this 200 page document is way beyond vague, so they pushed for formal, structured use cases. Diagrams give me something that I can use. How can I code to this list of stuff? It doesn't make any sense to me, and they're usually on the side of saying, Look, the only way to know is to build. So let's it hurry. Project managers are partly right there. Need for specificity, visibility into the process and accountability is not only legitimate, it's necessary. OK, it's what they're hired to do. Um, and there they have a great degree of responsibility and they're responding to that. But handing a text document to a design development team is kind of like giving an architect a few pictures of rooms and saying, I need a house, Okay? The end result will not be what you wanted. It'll take five times longer than you hope it will, and it'll cost 10 times what you expected doesn't work. Designers and developers air partly right as well. The text document will never provide a complete or accurate picture of the product. Stakeholders will never agree on what the product is and what it should do until they have something to look at. That's human nature, alright, especially for people who are non technical until they see something this is all very abstracted them. It's very hard for him to make sense of what they read and hear. It's very hard for them to visualize, but you do not have to start building something immediately. In order to get that agreement, you don't have to start coding. You don't have to start dealing with functionality. Both parties are very wrong about something, and that is that neither approached addresses One true metric of success and you'll remember this from the beginning. The user experience value loop. Neither approach creates a full set of meaningful requirements that meet user needs and expectations that serve the business goals of the organization and its stakeholders. Neither approach speaks to three very different kinds of requirements. There are things people say they need. There are things people actually need and finally there things that people do not know they need. In the next section of this course, we're going to dig in tow all three of those. 5. Poor Tools for Requirements Generation: Let's talk about the third culprit for poor requirements, which is poor tools used to generate those requirements. The first of these tools is typically use cases. A lot of organizations use use cases that look very similar to the example I have here on the right Use cases described the interaction between what's called an actor and a system. Now you would assume that maybe that actor is a user, but that's not entirely true. And actor may very well be a person. But it may also be another system. It could be a database that provides information to a mobile app, for example. So we're not explicitly talking about human beings here and human use and human needs. While use cases can describe end goals they typically on, Lee described tasks like you see her on the right. Edit profile, delete profile, managed profile edit posting, upload, posting Billy Posting two words very quick. No sense of why that's happening or why it needs to happen. Use cases. Don't consider how people feel about an interaction or why a particular requirement delivers value to them. Just because we have all these actions, and just because we can make them. Reality through design and development and programming does not necessarily mean that they deliver any value, either to people who use the system or back to the organization. As we said, most enterprise development teams make use of some form of user stories. Now. This was born out of the agile movement and was a core component of sort of getting to the reality of why people use certain things and why those features and functions are important . However, they fall far short of truly addressing human motivation. And I'm gonna explain. User stories were typically no more than a couple sentences. Like the examples you see here as the admin. I want to be able to log in so I can add men the site as the admin. I want to be able to delete author accounts so I can maintain control. Those certainly explain how the feature in the function is supposed to work. It also explains what the person is going to do with that feature. However, it gives us no clue as to why that is important either to users or to the business user stories. Unlike use in areas, which is something I advocate don't describe a user's entire journey from start to finish. They focus on a narrow, disparate piece of interaction as opposed to all the things they do in Siris, in a workflow. And like a lot of things in life, you can't take one piece out of context and expect it to fully address the rest of the situation. Okay, there's a piece of the picture that's missing here, and the pieces that are missing are extremely valuable. User stories also don't consider how users think and how they feel. A big part of positive user experience is meeting human expectation. And that expectation is also driven by emotions is driven by this sort of inherent messiness that is, human beings. Okay, The cognitive reasons why we interpret things the way we do, the reasons we get hung up, the reasons we get stopped, the reasons we get confused. It doesn't address any of that. Finally, user stories focused squarely on task completion. Now again, if we're talking about getting from point A to point B, that's fine. But here's the thing. I may be able to complete a task that does not make that activity a success. It doesn't mean I've accomplished anything that meets my needs or my goals. Requirements have to address success, and I'm gonna give you some examples. The ability to view a data chart on screen is a completed task. Cool. I saw the date. I can look at it awesome, being able to make sense of what you see and then act on it. That's success. I have to be able to understand what I see. I have to be able to interpret it and act on it in some way, right? Make a decision based on it. Those are measures of success. Sharing undeliverable file with a colleague is a completed task. Awesome. I can share this latest mock up of the user interface with everyone else in the development team and with stakeholders tracking its version and ensuring that there are no duplicate files, that someone else is working on the same thing. If I have some degree of version control, and I can make sure that there aren't multiple iterations of this floating around that may contradict each other, that's success because it eliminates extra work and eliminates rework and eliminates redundancy, it eliminates confusion. Those are measures of success and again. These are the kinds of things that requirements must address if they are to create positive UX meaning value, the ability to file a tax return in line is a completed task. Confidence that nothing has been missed, that the math is right in that there's no chance in hell I'm gonna get audited. That's success. Okay, so hopefully you see the difference. User stories typically focus on the stuff in the left column. Very rarely do they address the stuff on the right. So I want to show you how to change the user story format very slightly so that it addresses success. The kind of change I'm advocating here happens when user stories air being written. So I'm not suggesting that we add a new process all the stuff we're currently doing. I'm not talking about adding effort, adding work. I'm talking about changing the way we think about stuff we're already doing. If you're the author, you're gonna change the way you write them. That's it. If you're the recipient of a user story, then you're gonna rewrite them in this form, and you're gonna send him back to the Creator and you're going to share them with the team . You have a voice. Don't ever forget that you are in the room because you have strategic value to contribute. You are not just another pair of hands taking orders. So even if user stories air handed down to you like they're written law, you can and should tweak them using the formula I'm gonna show you and send them back to everybody and say, Hey, we need to organize and prioritize these. We need to make sure that we're addressing issues of value here, and this is just my two cents. If you do something differently in this moment, you are instantly in a position to sell the value of U X. You have receptive ears, even the most stubborn and resistant of folks that you may be working with on a management level on a stakeholder level on a team member level, I promise you, when they read this revised user story statement, it will instantly change the way that they look at that statement and its value and what it means and whether or not it matters. Everyone who sees them will be automatically evaluating them through the lens of good UX they won't realize that they won't be thinking about it as such. Don't be saying hope. I am now thinking about user experience. What a miracle. It won't happen that way, but their perspective will change dramatically. A promise You all right? And you'll change those perspectives without hardly trying. So again, my issue with user stories isn't what they say. It's what they don't say. It's what they should say. I'm gonna show you what that is. A typical user story reads like this. As a user, I want this function so that whatever action it is I need to take all right, that's the typical format. There are certainly variations, but that is essentially it. Now here's what I'm advocating. An improved user story looks like this. The user wants a specific function to achieve the goal of whatever the user goal is small modification. Now we're gonna add two sentences. The current inability to do this is causing whatever the adverse effect is for the organization. Do you see what happened there in a single sentence? You have now framed this. Here's why it's important that we do this because it's hurting us in this way. It's preventing us from doing this. Taking this one step further, enabling users to do this would deliver whatever the specific, measurable value is to the organization to see what happened there. We've got to qualifying statements, and here's the deal. If you cannot complete either of those qualifying statements, it means that there is a good chance that that requirement is arbitrary. If you cannot connect it either to solving an existing problem or delivering riel measurable keyword value back to the organization, there's a good chance no one knows why that item is on the requirements list, and it probably doesn't belong there. At the very least, it suggests that you probably need to have some more conversation to do a little more digging to make sure that this is really worth doing. I'm gonna give you an example of an improved user story. The user wants to register using a social media log in to achieve the goal of quickly trying to demo with little effort. The current inability to do this is causing potential customers to abandon the registration page. Enabling users to do this would increase the number of prospective customer registrations and potentially increase sales So we start with the statement. Here's what the user wants to do. Here's what their goal is. It's hash to that. They want to get in. They want to try the demo with little effort. A lot of times what you see in on boarding processes in particular for demos, fried butter or to use the software free for 30 days is organizations ask for 45 different pieces of information right down to what did you have for breakfast last Tuesday? It's unnecessary, and we, as users know it's unnecessary. OK, it's kind of like asking for a kiss on your first date when you show up to the door. Three other person has no idea whether this is going to go well or whether it's gonna be a complete waste of time and you're already asking for something. So we're saying, Look, you just want to get in there willing to try it. They're interested, but this is a barrier. You solidify that statement in the next sentence. The current inability to do this is causing potential customers to abandon the registration page. Let's say in this example, we've got analytics that show 78% of people who come to the registration page fill out the first field, and then they bail already. They just come to the page in bail. We've got some evidence that says this is a problem, Then you connected to value. Enabling users to do this would increase the number of prospective customer registrations. Hey, we can get more prospective customers if we get rid of this barrier to entry. And the last three words are what Get everybody's attention, especially the folks who were saying, We don't have time for this user research stuff. Are you X stuff for whatever it is? Magic words. Three magic words potentially increase sales. I promise you the minute you start talking about money instead of design or you X or, you know, making people happy, you've got people's ears. You are also forcing them to think about whether or not this matters in the first place. Because if there's no connected, measurable value, if you don't say, here's what's going to happen as a result of, here's what could happen in a positive way. As a result, your words are gonna fall on deaf ears, changing the way you write user stories as I've shown you here makes a tremendous difference in how the work you do is perceived. It makes a tremendous difference in how people look at that requirement. It causes them to question whether it's important, because if you have 12 statements that have these conditions attached to him and then you have another 12 that's have nothing in those two sentences. OK, we don't know what the problem is here or how it's hurting us or even if it's hurting us. And we also don't know how that's gonna possibly affect the business that automatically makes those requirements suspect. It makes it much easier to draw lines and say This stuff is priority and this stuff has to wait. If you're doing Sprint planning this simplifies your job Thousandfold in these last two cents is the requirements. Value is exposed. Is this important enough for us to solve this sprint next print backlog? You know what you're doing. You know what you're doing right now and you know what has toe? Wait. You also know what is a total question mark and probably just belongs on the backlog if not eradicated altogether. Small change, simple change, huge dividends. I strongly encourage you to try this out in your own work. I think you will see a massive difference. So obviously user stories aren't enough. I think we prove that point. But personas aren't enough, either. There are plenty of prescriptions for persona creation, but they're essentially all the same there. Laundry lists. That suggests it's possible to understand someone's motivation by simply checking boxes and asking questions. Just because you make up a fictitious identity and a story behind it and attach some demographics to it doesn't necessarily tell us the details of someone's behavior. Why? Because there's no context. There's no sense of how they're using something where they're using it. What things are influencing that use while it's happening. So what I'm about to show you is not that. Why? Because typical personas lack proper context. We want to create a contextual persona, something that takes into account the actual context of use, what's influencing them, what's motivating them, what factors are maybe even changing the way that they use something depending on where they are, what they're surrounded by and what they're doing. Context is the difference between designing for Jane, the 23 year old bank teller, and Jane, the 23 year old bank teller who always has 10 angry people waiting in line because her colleagues call of work constantly and she can't process all these transactions fast enough . Take a look at that second description. That's context. Those are all the things that affect how Jame does her job, how efficiently, How fast, How easily, how well this work has to start early, which is why we're talking about it. In the context of requirements, you have to create contextual personas twice what I'm going to show you. Here is the first of those instances you want to explore empathy and situation before any face time with users. You want to do it before you read any usage data analytics. Whatever that decline has for you, you want to do it before you hear from stakeholders what people are having trouble with or complaining about. Now some of that inevitably comes out in conversation, right? You have some initial conversations with stakeholders and they say, Well, you know, people complaining about this, whatever that anecdotal stuff is fine. What I'm saying is, you do not want to dig into any research before you do this work and there's a take away such that the minute you have user data, you are absolutely no longer objective, and that makes your persona work a lot less valuable. Anything that you know is going to sway. Your judgement is gonna taint your opinion. It is going to influence the conclusions you come to. That is not always obvious, but it is most definitely true. So again, we're starting early. The only things I know if I'm doing this work at this point are the person's job title, particularly in B two B situations. Their day to day responsibilities also typically a B two B thing. How they use the product right now, what other products they may use to do the same thing. How the client thinks they used the product and what features the client thinks are important to them. Again, this is all anecdotal, and it's very surface level. These are the types of things that typically come out in conversation, whether you ask or not. Okay, so again, those things were fine, but we're sort of putting them aside right now. It's basic information. It's enough to get started, but we're not making any big bets on any of these data points. What we're trying to do here is create context. There are two key parts to creating contextual personas. The first is to develop empathy. You have to understand the emotional drivers that affect that person's behavior. The reason. Emotion will trump intellect in almost every situation. Emotional influence cannot be overstated no matter what the best practices are, no matter what the common procedures are, no matter what the rules are, people's emotions will always, always, always win out. You have to be cognizant of that. Next. You wanna uncover behavioral attributes, what people are doing in the context of multiple situations. What are they doing right now? What have they just done? What are they thinking? What are they feeling and how do those things affect what they do next? There are three tools that we use to create context, and I am going toe, walk you through each one of them in detail, and then you are going to do some exercises where you will learn to create them and use them yourself. The first is empathy. Mapping. This uncovers users perceptions, influences and goals. Next is situational mapping. This is used uncover situational factors that affect context of use along with needs and desired outcomes. Finally, we use contextual use scenarios to expose issues that are related to flow constraints, task sequences and related artifacts. Data in data out documentation, all that kind of stuff. We use all these tools to uncover and validate the relevance and value of our requirements . It's one thing just to come up with functional needs and features. It's quite another thing to know that those are the right functional elements and needs and features. These tools allow us number one to extract those things from riel user behavior, and then they give us a filter by which to look at them and say, OK, do these things really matter? And are they really important it? 6. The 1st Kind of Requirements: What People Say They Need: So let's start with things people say they need. Most U. S consultants and practitioners like myself are very fund of saying that what people say they do is not necessarily what they actually do. And by the same token, what people say they need is quite often not what they actually need. And I'm gonna show you why that is the case. Would you like your favorite department store's aisles and shelves to be less cluttered, Right? Would you like to be able to move around easier? You know, not have toe sort of squish your body to get between display racks? Does that sound like something that's good? That would make you happy? Would make your shopping experience better? Easier for most people, the answer to that is yes. In 2009 Walmart surveyed its customers Okay, they sent out a survey, and they asked this question. Would you like Walmarts aisles and shelves to be less cluttered? Customers unequivocally said Yes, OK, people just unanimously said, Absolutely. I'm tired of all the stuff you guys have everywhere. So Walmart cleared space, reduced inventory by 15% customer satisfaction via another survey shot up. They sent in another survey said, Hey, we did what you asked, What do you think? People said? Yeah, it's great. Fantastic. Love it. At the same time, sales plummeted by $1.85 billion. That's 1,000,000,000 with a B. So here's what I want you to think about. Why did that happen? People said this is what they wanted. Wal Mart did what people said they wanted, and then they asked him again, Is that what you wanted? And they said yes. So how did they lose so much money? Why did this consequence occur? Can I think about that? Tell me, if this has ever happened to you, have you ever shown a prototype or working billed to customers or stakeholders? And it was met with, like, near zero excitement? Did you ask them what would make it better? Did they list features that would turn them in the passionate users that they say? Well, if it only did this, and if it did this and if we had the opportunity to do this, then yeah, I would definitely definitely use this and that would be a huge improvement. Did you implement those features that they suggested, and then did you share it again with them? Were they thrilled at that point? Have you ever experienced a difference between your own predictions and reactions? Were you absolutely sure that an event would make you really happy or unhappy? And then it turned out differently than you imagined. Or your reaction was different than you expect it to be. Did that new car a new bike or new house or new golf clubs? New job? Change your life the way you thought it would? Really? No, it probably didn't. And here's the reason why. Let's do a little thought Experiment. I want you to rate how happy you are right now. On a scale of 1 to 10. 10 being I'm extraordinarily happy and one being life sucks. I'm totally unhappy. Hate all this. Imagine that today you win the lottery. You now have more money than you ever imagined. Millions and millions of dollars. Okay, billions at the end of today. What do you think your happiness rating would be again on a scale of 1 to 10? Right? That number. Now what about two years from now? How happy would you be? Write that number down the truth is you won't be any happier than you are today. There's a tremendous amount of research on this. And Dr Susan one check did a great job of sort of explaining it, summarizing it in her book. It's called 100 Things Designers need to know about people well worth picking up. Okay, but here, the psychological fax, we are all poor predictors. We greatly overestimate our reactions to both pleasant and unpleasant events. Second, the brain has a built in regulator, and its job is to keep you on an even keel, no matter what happens to you. And finally, our preference doesn't equal reality. What we say and what we do are often very different things, and they're a number reasons for that. Because of this, surveys and focus groups do not work, and they're still used to a great degree. But they really don't work. Motivations for participation are not equal. Some people who fill out a survey are attend a focus group. I just want to be hurt. Some people come for the money, and some essentially just want some intel. They're spies for the competition. Most participants in surveys or focus groups lie not on purpose, but they do it because they confuse what they actually do with what they wish they did. That's human nature, and the brain does that unconsciously, without us really understanding that that's what we're doing. We often confuse the two. Finally, ego distorts reality. Okay, we have a natural tendency to work to enhance our own self image. To gain Pierre approved. You want other people to think highly of, You know, people walk around all the time. It's I don't care what anybody thinks of me that is absolutely false. There are reams of psychological studies that say otherwise. It's simply not true. The thoughts and feelings that influence our behaviors are unconscious, and you cannot uncover that in the space of a 10 or 15 minutes service. It's simply not possible. The focus group setting in and of itself, eyes a natural. You got a bunch of strangers let in discussion by another stranger. It's very, very hard to instill the kind of trust that's necessary for people to give open and honest answers. And finally, people are asked to judge things that they haven't used. Imagining. Using something is absolutely unequivocally not the same as actually using it. This is why a lot of you X folks like myself insists on user observation as opposed to surveys as opposed to focus groups. And we wanna watch people do something. I don't want to hear them describe how they would do it and take that to the bank. I may want to hear it, but I don't trust it. I want to see behavior whenever possible. Next, our preferences are subject to our emotions, which makes them both unstable and unreliable. If we're having a lousy day, it's gonna color everything that we do. It's gonna color. Our response is gonna colored. Agreed? To which we say, Yeah, this is the most amazing thing I've ever used. And this is the worst product I've ever seen in my life. I hate this thing without experience. Okay, We're essentially asking people to either remember past use of something or were asking them to speculate on future use. Either one of those two things is a guess. Past use in particular is a false clue, because the brain actually has to reconstruct memories. We don't just call it up out of a file. The brain actually has to put the pieces back together. And what any ah psychologist or neurologist will tell you is that the pieces don't always get put back together in their original order. There's always a component of that story that simply didn't happen or isn't true. Could be minor stuff, but in our case it's usually important. So the take away is this. Focus groups and surveys really fulfill the psychological needs of sellers instead of the psychological needs of users. So leaning on those tools to create a set of requirements or to figure out what people want , what they need, what they would be willing to use is a dangerous proposition because you are very likely to wind up with a bunch of things that don't really solve your problem. So remember our folks at Wal Mart? They asked a question. Would you like WalMart tiles and shelves to be less cluttered? People unanimously said yes. They cleared space reduced inventory. They asked them again, Is that what you wanted? People said, Yep, absolutely customer satisfaction reading through the roof. Sales plummeted by $1.5 billion. So I ask again, Why did this happen Now? Here's why it happened, Wal Mart essentially came up with the answer first and then ask customers to agree to it. The way they asked the question was a leading question. It was phrased in a way that essentially says, Hey, wouldn't this be better? Wouldn't you like this more and psychologically were inclined to agree, because we automatically assume that this is a good thing. So while people enjoyed the increase in negative space inside the stores, what mattered more to them was a vast selection of cheap items. And when that vast selection was taken away, they got mad. So did they, like the less clutter? Sure, but there was a bigger need and that bigger need was not addressed in that very narrow question. Big selection is the same strategy that Sam Walton pioneered, and that's what the company is now scrambling to return to because it took such a big hit. This illustrates the peril of listeningto what customers say, instead of what they actually do 7. The 2nd Kind of Requirements: What People Actually Need: So now I want to talk about the second type of requirement, and that is things that people actually need right now, what they say, but what they really, really need in the first place. This is often a matter of requirements addressing symptoms instead of problems. When we discuss user problems or business problems, it's effortless to imagine a solution that will solve the problem. OK, human beings were good at it. Weaken jump to imagining ways that we would solve any particular problem rather quickly. But that solution will almost always address a symptom instead of the underlying problem. That symptom is certainly the right place to start. But we have to uncover the other actions, the other processes in the other motivations that are attached to it. OK, just being able to brainstorm solutions is not enough to say, Yeah, that should be a requirement. One of the questions that never gets asked is okay, what is success? What dictates or constitutes success? Before you can write a requirement, you need measurable goals and desired outcomes from your stakeholders, for example, what needs to happen once we launch or relaunch this and people actually use it. What's gonna happen. What's the outcome? How does each stakeholder answer that question? If you have a room where there are four or five different department heads, different stakeholders, they're all gonna have a slightly different answer. That question, because the part of that that affects their particular corner of the world is gonna be different from their counterparts. And unless you hear it from everybody, you're only getting part of the picture. How will each stakeholder and their relative department measure that success? How are we gonna know what we get there? How are we going to know that this is working? How are we gonna know that? Okay, problem solved. What do we expect? Will a block help increase awareness of or confidence in our expertise? Will that communicate that we know what we're doing and that people should trust us, Will monetizing the site with ads offset our production costs? Will that deliver income to us? Will these new features and functions convince people to purchase? Right? All these people who download the demo did the 30 day trial on and then sort of were never heard from again with all this new stuff that it does is that gonna convince them to pull the trick? Will a self service knowledge based prevent customers from switching to a competitive er well, that ease the frustration? Will they feel like we're responsive and listening to them will not at least buy us some time to improve this thing? Part of creating valuable requirements is forcibly separating us from our users and to explain that I want to give you a quote by Don Norman that I think illustrates this problem perfectly well. Engineers and designers explain that being people themselves, they understand people. But this argument is flawed. Engineers and designers simultaneously know too much and too little. They know too much about the technology and too little about how other people live their lives and do their activities. In addition, anyone involved with a product is so close to technical details, design difficulties and project issues that they're unable to view the product the way an unattached person can is very difficult to be objective. When you our need deep in the middle of something, it is very difficult to step back and remove all your inherent biases and ideas about what's right and what's wrong. It's difficult not because you have some flaw or I have some flaws because we're human beings. This is how we're built. Subjectivity is something that we're all wired to have. Objectivity, therefore, is very difficult. I'm sure you've all experienced some variation of this conversation where you is a team lead or designer or developer says Okay, look which requirements are most important from the mobile app and the product measure? The client says all of them Okay, we know full well that's not possible. But that's always the answer, right? How can we prioritize this list? You know what's most important everything. I'll give you a little example that illustrates this. Further organizations often want to jump to mobile with every feature that's currently in their product. They want all that stuff on the requirements list. Okay, what is the mobile version of this? Have to do? Well, everything that the desktop version does to them. It's a 1 to 1 correlation. Reality is that people will not use all those features on a tiny screen, especially if doing so requires data input or screen re sizing its tiny. And even if your eyes are fantastic, it's mechanically difficult. So in terms of requirements. It's a lot like moving from a big spacious house to a studio permit, because you're forced to prioritize what you really need to take with you. That's an analogy that I use often with clients, because it helps them understand that not everything matters and you simply can't have it all. When it comes to separating us from the people that we're building this for, we have to ask some very important questions. Who are we designed this for first fall? Is that a mass audience across multiple levels of competency? Or is it a you know, a niche set of power users in one very single, very specific job role? What's their reality? What's their point of view? What's their understanding of complexity? One of the dilemmas they face, where their fears, where they've desires, what do they expect, what they need to happen, what's gonna make this meaningful for them? Have we assigned requirements without context in a lot of cases? The answer to that is yes. If you give a subjective tool an objective definition, you're turning gold into lead. Subjectivity is a part of the human experience. We're wired for it another way to explain that is context. Anything that we're ever gonna use Onley matters to us in the context in which we're using it. If you remove the contacts, remove the situation, remove what's driving us to use in the first place, then you don't really know enough to decide what a particular feature or function should be . So the way to design something properly is to design it for what's called a mental model, which is our understanding of the way things work. A mental model comes from all the things that we use on a regular basis and all the things we ever have used. If I pick up a smartphone tomorrow, okay, no matter what brand it is, I use an iPhone. But if I pick up an android phone tomorrow, I can probably immediately start using. It starts thumbing through things, figure out how to get to certain features and functions because I have a model in my head about how it works. And what I see on the screen is reasonably close to the iPhone that I have. Okay, that's a mental model. I have expectations about how this thing works. Therefore, I can just sort of pick it up and get going. If you buy a new car tomorrow, it's a pretty safe bet you can get in and start driving it. Why? Because you've been driving for a while and most cars typically work the same. That's a mental model. Here's what typically happens with software products. There are different models at play when something gets built. The first of those is an implementation model, okay, and that reflects technology, which means what winds up being built. What's on the screen directly reflects features, functions okay, the things on that technology list. At the other end of the scale, we have a mental model, which is all about the users understanding of what this should be, how it should work or how it might work. Between those two models. There is what's called a represented model. That is what we designers and developers on product managers actually create. The closer that what we build is to the mental model, the better it works for people, the more people like it, the more people are comfortable with it. The more people feel like they're able to use it, the more value they ascribe to it. When we build something that is in line with people's expectations, preconceptions, our chances for success are much higher. Here's a question related to that. How many of you care what users think about your creation when you build something? Put it out there in the world. Do you care what people think of it? If you do stop that, here's why. Care about this instead? Okay? Care about what your users think of themselves as a result of interacting with your creation because that's more powerful. We're human beings, and we are focused, mostly undesired outcomes. How something makes us look to our boss can be infinitely more important than whether the feature the function of the product actually works. Does its intend to job how that makes us feel how it makes us look to other people? Those things are almost always more important to us than the actual mechanical task at hand . So think about what people think of themselves as a result of using what you built. That's one of the ways you get two more meaningful requirements. Ask yourself, Does use help them get more done? Does it help them save time? Doesn't make them look good to their boss. And I tell you something about that. That's something that probably should be on every requirements list but never makes it there. Just like I want to make my boss look good. That should also make it to requirements documents. But very rarely does it thes air. Important motivations. Does it help them maintain control over a situation? Does it help them protect your family? Does it make them? Richard doesn't make them taller. Does it make them better looking? Okay, whatever it is, you have to have an understanding of those motivations. Your requirements have to address the things that matter to people. And if they don't, the chances are they're not something that's going to directly contribute to positive user experience. And therefore they're not something that's going to contribute directly to products success , which again, as I've said before, at the end of the day, is about making money, we're saving money. So here's your take away. Your software is on Lee as good as the people who use it. If nobody cares about a feature, it doesn't exist. You understand what I mean. Here, you can build something that's functionally complex on does the most amazing things that anyone could ever possibly imagine. Right? People have an unprecedented opportunity to do things I could never do before. If it doesn't matter to anybody, it doesn't matter. Okay? You're not gonna have any success. You're not gonna make money. You're not going to save money. No one's gonna care about it. No one's gonna download it. No one's gonna tell their friends about it. And all that effort in time and money goes right down to drink. So anything that makes it to a requirements list has to be something someone cares about. It has to matter to them now, As clear as I make all this sound, the truth is that that process is not short and it's not simple. Separating actual need from opinion and hearsay takes a lot of time and a lot of effort. You have to get enough information to either confirm that the approach you're taking is appropriate signal that you're on the wrong path or suggest that additional digging is necessary before you'll know for sure. Again, the path is not simple. It's not straightforward. And in a lot of cases, it takes more time than anyone would like, but it is absolutely worth doing on. I could tell you that some of the failures I've seen over the past nearly three decades confirmed that that's the case. Okay, you skipped the stuff at your peril, and you skip it at your client's peril, you skip it at your organization's peril. 8. The 3rd Kind of Requirements: What People Don't Know They Need: Finally, we get the things that people don't know they need, and I'm going to illustrate this by way of a story tied had a problem. If you're familiar with Tide detergent, that has been around, probably since the 19 fifties, I believe in the eighties the team at Procter and Gamble was the company that produced Time was assigned to improve it in order to stay ahead of competition. Other detergents were now on the market, and they said, Look, we've got a introduce something that will differentiate us in the minds of consumers. So they're in a bunch of surveys. They interviewed customers one on one, and the response was that everyone loved the product. Okay, the performance, the packaging, the smell, everything people essentially said, Look is great. I I can't tell you any any negatives, because I I love everything about it. There were no negatives, no dislikes and therefore no clues for improvement. The team that essentially hit a dead end. So put yourself in Procter and Gamble's place. What would you do? You went out. You talked to a bunch of people. You re in surveys and everybody said No, love it, nothing that could be improved. So you've hit the wall, but you need to come up with something. So what do you do? Well, if you're Procter and Gamble, you observe, use The team, decided to go into customers homes and actually watch them do their laundry and one woman's home. They saw something that was pretty unusual. First he put in the powder. She let the machine fill up with water and then added the clothes. Just before she closed the lid, she reached for a broomstick, poked it in the machine and started swirling the water with it. Why? Why did she do that right? Because the powder was not fully mixing with the water. So she took this additional step to make sure that it mixed before she closed the lid. The team's solution to that unarticulated need is now known as liquid tide. So you see what happened. This is why I harped on the fact earlier that what people say they do is not the same as what they actually do. That's why observing use is infinitely more important than conducting a survey or focus group running those things. If you don't see it, you'll never get to those things that are actually happening, but that people aren't telling you about. Here's a quote I love. People don't want quarter inch drills. They want quarter inch holes. That's from Ted. Love it. Who's a Harvard marketing professor? Do you understand what he means by that? What he's essentially talking about is the fact that there's a difference between outcomes and tools when problems arise as human beings. We look for convenience first, and convenience almost always trumps best practice. What's easy for us and what's right in front of us is always the path we're gonna take, as opposed to doing the right thing. That's because the desired outcome is infinitely more important to us than the chosen tool . I give an example if I'm hanging a towel rack in my bathroom, okay, the walls are drywall. They're hollow, so I need to put a hole in the wall, drill a hole in the wall to put ah, an anchor in the wall and improve. Screw into the anchor. Now I'm in the bathroom. I've got the towel rack. I don't have my drill. I do, however, have a Phillips screwdriver in my pocket. And guess what? it just happens to be about 1/4 of an inch in diameter, which is the same diameter as the whole needed to install this anchor. So what do I do? I take the screwdriver and punch a hole in the wall. Why? Because it got the job done and it was convenient. It was right next to me. I didn't want to go to the garage and get the drill, because then I'd have to find the drill bits, which I never put back in the same place, because, believe it or not, I am fairly disorganized about certain things. Um, and I just didn't want to go through all that hassle. OK, it's easier just to take the screwdriver in my pocket, punch a hole in the wall and I'm done. Alright. Desired outcome. That's all that matters to me in that moment. If your requirements conversations air specifically about the tool being used about its features about its functions about its content, you're having the wrong conversation. Instead of features and functions, you should be focusing on the problem that people are facing. You should be focusing on what the desired outcome is for them. You should be focusing on what they are most likely to do to solve that problem with or without your product. And this is the important part. I cannot tell you in my career how many times requirements important requirements have come from watching somebody construct a ridiculously complex work around to something they didn't want to use the software to do. And if you don't observe somebody's behavior, they'll never tell you about, you have to see it. Conversations about expected outcomes produce relevant requirements. So how do we find these quarter inch holes? There's a great article in fast company that talked a lot about this, and essentially, what you're trying to do is you're trying to get to context. OK, take the amount of time that you typically spend with users or key stakeholders and triple it. You want to fully understand the context of use. What are they doing? What are the pressures that are on them while they're doing it? We're watching for workarounds that people create to make up for the limitations of existing solutions. The picture on the right hand side is, you know, a typical check out credit card machine, and somebody has a fixed a sticker to it that says, Press cancel for credit, which to me is the dumbest thing ever. It's two opposing forces Cancel your transaction in order to use a credit card. It makes no sense. But people devise workarounds like this because the process itself is confusing or broken or difficult. Finally, you want to look past current users. Teoh anyone who's facing some constraint that keeps them from solving a pressing problem. Typically, what happens is war designing or developing a certain type of product for a certain type of client. In a certain type of industry, we look immediately in her own backyard. We look at products and solutions that do exactly the same thing for exactly the same industry for exactly the same types of users. And that's limiting. You can look to any type of product development or design to find good examples where people stepped outside the boundaries to solve problems. Okay, so anywhere somebody is struggling with something is food for thought for you, that's valuable information that you may be able to put to use. Here's another great quote to help you think a little differently about requirements the customer rarely buys what the company thinks it sells him. Nobody pays for a product. What is paid for is satisfaction. That's Peter Drucker was a very famous management consultant, and for my money, that quote alone qualifies him. Has an expert because that's the truth. We care a lot less about the tool about the product than we do about the desired outcome. Satisfaction. Are we happy at the end of this experience? Do we feel like we got what we paid for It? Did we give it We need. Doesn't make us happy is to make us remember Richard Taller, Better looking right. What came out of it? That's what matters. I want to tell you a story that comes from Laura Klein's excellent book called You X for Lean Startups and you know, just like Susan White textbook. I strongly strongly recommend that you go out and get this book. If you don't have it already, it's it's pure excellence all the way through. In this book, she tells a great story about misdiagnosing what's actually needed. Okay, I'm adapting it here with her gracious permission. Consider the case of a large equipment and contract services provider. Okay? Their products are as expensive as they are complex. This is everything from the cell phone tower equipment that you see along the road to all the relays and signals and dishes and everything else that goes along with transmitting wireless network signals. Month after month, they found that their current and prospective customers weren't willing to either recommit to an existing contract agreement or make a new purchase. In either case, people were hesitating big time. When they asked these folks what the hesitation was about. They were repeatedly asking the sales people for detailed case studies. We need to see case days. I need to see case studies of how this has helped other people. You need to show me something to give me some evidence. We need case studies. That was that was the buzzword. Case study case study, case study, case study. So the company says okay. The company spends six figures on two dozen 30 page case studies. It explains why other customers purchased these packages, what the specific implementation and customization processes were for each what the results were. Okay, 30 pages of detail. All the things that people were saying, I need to know about this. I need to know about this. Okay, so they ended up and they did it. The case studies air, then posted the website and links directly to the case studies air used in an extensive email marketing campaign. Nearly 1200 current clients and 300 prospects have full access. What was the result? Three case studies air downloaded per month, on average across a period of nine months. Three. We have a horde of people saying I need case that is any cases, any case studies, and we put him out there and nobody cares. So why? Why is this happening? Well, in Laura's book, she goes back to the customers with a single question. Why do you want to see case studies? A question that was never originally asked. Remember, the company jumped. We need case days. Okay, good. Yes, we're doing it. No problem. Here's what she found. The people that were asking for case studies were all trying to solve three entirely different problems. Problem one. Here's what the customer originally said. I want to know what other companies similar to mine are doing, so that I have a good idea of what I should buy the real story after asking Why? Why do you need to see that? Why do you want to know that? The answer is, I don't know how to pick the right collection of products for my company. So what was asked for what was needed are two different things. This is a choice problem, because this person needs to make interrelated decisions about very expensive items that they don't know very much about. There's fear here. So here are the possible solutions that could have been undertaken that aren't case studies . You could have a recommendation engine built into the website that asks questions about use , how they use certain things, what they provide, what they need to do. You could have a selection of preset packages that are lowest common denominator. Okay, but the majority of our clients use one of these three things, and here's why problem two. Here's what the customer originally said. I want to know what sorts of benefits other companies got from the purchase so I can tell whether it's worth buying. Here's the real story. After asking why I want to make sure I'm getting a good value for my money that's a metrics problem. That means they're trying to away in balance cost versus benefit. OK, it's one of the oldest conundrums in the world to any type of business. So possible solutions to this, as opposed to case studies, could have been a price benefits matrix. What do I get for different levels of service for different contract levels For different spends across packages, you could give these folks the most pertinent part of the case study. For example, if you say customers saw an average of 35% increase in revenue six months after installing this product, you've got someone's attention. Now, if they have to read 30 pages to try and figure out that that happened, you've lost the battle. Okay, Now have you lost the battle? But you've also lost the war because no one is gonna dig through all that to ascertain this coming out and saying it in a very obvious way would be more valuable. These are requirements, folks. I realized they don't sound like technical or functional requirements, but they are requirements, understand? You gotta dig into what really needs to happen, what needs to be addressed. Here's problem. Three. Customer originally said. I want to see what other sorts of companies you worked with. So I can decide whether you're reputable. Here's what that really means. It means I've never heard of your company or your products. I have total unfamiliarity here. Again, there's fear. This is a social proof problem. This person is looking for evidence that other people endorse the product. Okay, no one wants to be first in line ever. Here's some possible solutions to solve that problem. Possible requirements. You could have a carousel of short client testimonials, or you could have a section for client testimonials. You could show the logos of biggest clients prominently on the very first home page. Okay, if I come to your site and I see that you serve Google, you've got instant credibility. The person thinks to themselves, Wolf. Okay, If Google is paying these guys, then they must know what they're doing. At least that may not convince someone toe by, but it certainly convinces them to stick around long enough to learn a little bit more as opposed to losing them. Because you've said you've got to read all this stuff to understand anything. These air all better solutions than the 30 page case study that got produced. What's more important is that they are more appropriate solutions. They are contextual solutions. They speak to the need. They speak to the desired outcome. So here's the take away don't write requirements until you know what people really need. Getting it wrong is expensive, and it's often very painful. 9. Empathy Mapping: Uncovering User Needs: the first of our persona tools is called Empathy Mapping. This comes from Amazing article. I Read A Ways Back by Nicky Knocks called How to Use Persona, Empathy Mapping. It was US Magazine 2014. Your task in empathy mapping is to establish empathy for the user, and you're trying to map their perceptions there pressures, their influences, their beliefs and their goals. The tool that you used to do this is called an empathy mapping template, and that looks like this. You will find this empathy mapping template in the course guidebook that you download it when you started the course where you use it is you think about the sensory experiences of the person across the six areas of the template and your write down whatever comes to your mind as you do again. This is wide open. It's a brave, stormy exercise. Your goal is to generate volume and then whittle it down to the things that are most likely . You want to take a step back from user behavior what they're doing, and you want to focus on the person's emotions and their experiences instead, thoughts and emotions, the person's environment, their social influences their behavior, their pain and their gain. What you do is across these six areas of attributes you try to describe in as much detail as possible. It's kind like a brainstorming exercise. What this person likely is feeling is influenced by what's bothering thoughts, emotions, beliefs, convictions, motivations, worries, goals, their environment. You know, how is that person affected by their workplace by their social settings by similar products and services? Okay, what's their context? That they're operating in social influence is hugely important. Who does this person listen to most? Who has influence? Do they listen to the ideas and opinions and recommendations of friends? Are they beholden to whatever the boss wants? Co workers outside influences, Right? Who has their ear behavior? How does that person act? How does that person want to be seen and thought of not just in the workplace but in public as well? Okay, people's perceptions of themselves and how they want other people to see them is a big driver of what they want to accomplish and why they want to accomplish it. Understanding that is key to getting down to motivation. They're pain. What are their fears, their frustrations, their perceived obstacles. They obviously have something they want to accomplish. What did they feel is in their way and finally gained? All right, What do they want? What they need? What did they believe constitutes success? Remember what we said before the task? Completion is not the same. A success. Just because someone is able to get through an eight hour day doesn't mean that they feel they've succeeded. It also doesn't mean that the work that they have done has contributed to the success off their work or the organization's work as a whole. You need to know how that person sees that success. 10. EXERCISE: Create an Empathy Map: So let's create an empathy map. I'm gonna give you some guidance here, and then I want you to stop the video and actually fill out an empathy map for this user scenario I'm gonna give you. Here's your background. Assume you're designing a call scripting application for emergency response operators. The software's job is to provide scripted responses for multiple types of emergency situations. Okay, meaning a caller calls them with an emergency. And the system says, if the situation is this, you say this. If the person on the phone does this, your response should be that kind of thing. Your primary persona is Jane Holden. She's 51 years old, she is an emergency operator. And here's what she says about her job. Emergency calls could be pretty intense, and I need all the help I can get to stay calm and focused in order to get information and act quickly. Here's some things I want you to consider as you try to dig into Jane's motivations and emotions and thoughts. What does she likely believe about the work she does? Where does she interact with the product? And how might that environment influence decisions were constrained her ability toe act from a social perspective. Who influences how she thinks or what she does. Bosses, co workers, friends, family. How does she want to be thought of and seen both at work or out in public? What does she want people to think of her? Or about her? What fears and frustrations does she likely have and what obstacles to success might be present? What does she want? Or a need in order to be successful? And finally, how does she define that success? What constitutes success for her at the end of her work day when she walks out of that office? What makes her feel like today was success or no, This particular call was a success. So think about all those things. Stop the video, fill out the empathy map to the best your ability. Do not worry about getting it right. Just do it and come back. Leave comments and let me know how you did 11. Sample Answers: Empathy Map Exercise: So now that you've done the empathy mapping exercise, I would like to compliment that and maybe give you some additional clarity by walking through some sample answers with you to either confirm that what you've done is sort of putting you on the right path or just to give you some alternate things that you may not have thought about. Here we go first. Thoughts and emotions, beliefs, worries, motivations, convictions. Jane may very well believe that the work she does is important. She may be proud that she's able to save lives right. There's a lot of pride that goes along with the job. She's doing good things that actually help people. She may wrestle with the fact that she can't save everyone. Think about that from There's a lot of stress involved. These calls, a lot of them are life threatening. The volume of calls quite possibly make her feel depressed and hopeless. They're gonna be people she can't help. You have to think about how that weighs on her conscience. She may lack confidence. She may lack control. She may be worried she won't know what to say in critical situations. She may also wish that she had someone or something to fall back on. She may be the Onley operator working in that room. She's on her own. It's it's sort of stand or fall on your own merit. You know, they're stressed. They're she probably wants to help as many people as she can as quickly as she can. She may also have an imposed quota to meet an average of successful outcomes. OK, her performance may be evaluated in any number of ways. The funding that gets attached to her department, for example, may very well depend on the volume of calls they can get through in 24 hours. Next, her environment. How does this affect ER? How she affected by a workplace by social things by any other similar proxy issues. Her workplace is likely loud and chaotic. There may be other operators taking other calls. A lot of people talking at the same time. There's also probably, ah, high volume of task switching, meaning she's talking to a caller. She's also searching for available help. She's trying to coordinate with dispatch and first responders so speed and focus is critical. She has to switch focus from one task to another repeatedly throughout the cycle of a single call. It is quite possible that she is likely understaffed due to budget cuts. These are usually local or state government funded entities, and as such, they normals never have the tools of the budget that they really need to do the jobs efficiently. So she may very well be doing the work of two or more people. She may be pulling double shifts, her fatigue and her stress may be very high. As a result, she also probably has pressure from multiple bosses of sorts, right? Not just her regular boss, her supervisor. But there are a lot of people sort of dictating what she does right there. Callers dispatch response teams. Everybody wants something and needs something from her. Right now, she is serving all those masters. At any given time, she's being pulled in a lot of directions. Social influence, who influences her Callers obviously have the most influence. Their unpredictable emotional state and situations absolutely demand the most attention. You never know what's coming next. You don't know what the person is going to say next. You don't know how they're gonna react to the coaching you're trying to give them. She may very well lean on fellow operators for support for advice and just commiseration, right? Just to talk about got my This has been a really stressful day. I can I don't know how much longer I can do this right or things love of that nature. She may very well want impress her supervisor, who has the ability to limit her career path. She may be really emotionally finished with this job. She wants to rise up and out of it into a more management level where she's not dealing with this day to day chaos. Okay, maybe wearing on her and she wants to rise above. But the only way she can do that is if she's doing an amazing job on her. Supervisor feels that she is worthy, you know of something bigger. Her dispatchers and her first responders also affect her sense of competence, confidence and self worth. This is the human need to look good to others. A lot of people walk around and say, I don't care what anyone thinks of me. This patently false human psychology at its core dictates that we always want people to think well of us unless we have some sort of literal neurological disorder where you know we're sociopathic and way have a delusional idea about who we are and what we're capable of , okay? But otherwise, we always want people to think highly of us. Her behavior, how she acts. She probably has to put our emotions aside in order to deal with difficult situations, just like doctors and nurses, people who deal with trauma every day, especially in emergency rooms. They learned to compartmentalize their emotional reactions so that they can focus on the task to be done. Thes operators air probably no different. She probably has a desire to be calm, cool and collected to execute with speed and efficiency. She probably wants to be seen this way as well that she's ableto handle even the toughest, craziest situation. No matter what life throws at Jane, no matter what comes down the pike in the next call, she is always on top of it. She always handles it, and she always gets the job done. She probably wants callers and Piri influencer groups to feel like they can rely on her that they get put instantly at ease when she is the person on the other end of the line. She also likely wants others to see the work that she does as important. It likely means a great deal to her. If people say, Wow, I can't believe you do that every day I could never do that. There's probably a strong sense of pride attached to that. Like, Yeah, I handle it and I handle it well, What her pains, her fears or frustrations. First and foremost, she's likely afraid that she'll be the cause of someone's death if she's too slow to respond, if she gives the wrong advice or makes the wrong decision, or she's completely just outnumbered by call volume and she can't get to them all in time, she's probably frustrated and she's probably fatigued. Thes things are almost inevitable in a high stress job like this one. The people she can't help may very well hunter and cause me to doubt herself. The high workload, the amazing, incredibly harsh emotional demands bring exhaustion. Nobody is superhuman. Hey, we're not made of steel. So even in your down moments, thes things probably certainly get to her. She probably doesn't feel like she has the tools she needs. She's probably working on outdated equipment. Ah, with inefficient processes in an understaffed office again, anything that's publicly funded generally suffers, and the tools and equipment that they have to use is usually more than a few generations behind whatever's current. As a result, all of these things affect her ability to do her job. Finally, we look at gain. What does she need? What does she want? She wants to feel like what she does matters more than likely that it has value that it has meaning. She wants confirmation that this work is important. Everybody needs validation. Everybody needs a pat on the back and reassurance that, yeah, this does matter. You're doing a great job. You're doing something that most people couldn't handle on a daily basis. Be proud of that. She probably feels most successful when she knows that disaster has been averted. Life has been saved when she's able to handle the majority of calls on a given day quickly , efficiently, and the volume in chaos doesn't get her. That's probably her definition of success. She likely feels validated if a supervisor or appears, recognize and praise her efforts back to the first part she may not know the outcome of each situation, and she may want to know whether the work she does matters if it's worth the stress and strain. It's entirely possible that once she hangs up with dispatch or with the first responders, she doesn't know how it works at. She doesn't know what happens to that person, whether the outcome is good, bad or otherwise. And that wondering is also something that can weigh on a person not getting confirmation that something worked. You know that something went the way it should have leave some ambiguity that can sort of way on a person's conscience. It's information that sort of gets sucked into the brain and never leaves. So it's in the way all of these things. All of these attributes that we just went through are meant to give you an empathetic view of who she is, what is driving her behavior. Remember what I said about emotion? Emotion trumps intellect in almost every circumstance. So when you are designing, when we're trying to come up with lists of UX focused requirements, we need to make sure that those features and functions that we are suggesting that we're exploring address these emotional drivers. It's not enough just to give somebody the physical tools that they need to be able to do the job. You also have to present that stuff in a way on the screen that complements and works with and supports and in some cases influences their emotional state. You have to be cognizant of the amount of stress that they're dealing with. You have to be cognizant of the fact that all of these things dictate whether someone can or cannot make sense of what they see on screen. 12. Situational Mapping: Uncovering Context of Use: The second tool that we use to create contextual personas is called situational mapping in situational mapping. Your task is to get closer to the specific situations that this user will find himself or herself in. You're trying to map connections between situational factors and needs that arise as a result of those factors. Okay, so what happens has an impact in every event that takes place inside. A particular scenario affects the outcome and effects the actions that the user mayor may not take. The tool that you use is called a situation mapping template, and it looks like this. In this case, we've got two areas up top that describe the situation. Whatever it may be. The second box to the right describes the action step or steps related to that particular situation, right? What needs to happen down below? What you're trying to do is focus on the user and write down all the things that she may be thinking the things that she may be feeling, things that she sees in her environment on the screen, in her office, whatever her environment happens to be, and then the things that she may be doing as a result of all those things. The way you use this is that you develop a hypothetical situation for your user. You want to notice the stress and the possible outcomes, which means the best and worst case of the situation. What happens, what's the best that could happen? What's the worst that could happen? You want to consider and note what the user may be thinking, what they're seeing, what they're feeling, what they're doing as a result of this situation and just like empathy mapping, I'm going to give you an exercise to do to help. You better understand how this works. 13. EXERCISE: Create a Situational Map: So in this exercise, I'm gonna have you create a situational map. And again you're going to use the downloaded form from the guidebook. I'm gonna give you a sample scenario using our same persona, which is Jane, our emergency operator. Jane has just taken a call from a woman who is crying hysterically and possibly hyperventilating. Jane cannot understand a word she's saying, and the caller is not listening to or answering the questions that Jane is asking about her situation and her location. The first thing Jane is required to do is ascertain the collar situation and location. She cannot dispatch any help to this woman until she gets this information. Here's some things to consider. What does she need to do in this situation? What does she need to do first when she need to do next? How does that sequence likely unfold? What does she need to see in order to do those things? What you need to be able to see on the screen in her environment? What is she likely thinking both at the outset of this situation? And it critical points throughout what's going through her head. As this situation progresses, what is she likely feeling both at the outset of the situation and at critical points throughout. Consider those things. Fill out the situation, mapping template to the best of your ability, and then again download the completed situation mapping template and compare your answers. 14. Sample Answers: Situational Mapping Exercise: So now that you've gone through the situational map, I want to give you some sample answers to that exercise to compare with what you came up with. The first order of business is our situation in action. Step Well, we already know our situation, and that is, we've got a woman on the phone who is completely panicked, confused, irrational. She's ignoring requests for situation, details, name, location, etcetera. All the stuff that Jane needs to ascertain in order to get this woman help her action step . Jane's first action step is to calm this woman down. If she cannot get her to be calm, then there's no way she's going to get the information she needs in order to dispatch help . And she understands that every second Lost is a second that this could turn out badly. Her next step is to get the woman situation location. What's going on? Where are you from? There we moved to what Jane is thinking while this is happening. First of foremost, he's probably thinking, whatever this is, it must be really serious. If this woman is this upset, I got to get her to calm down. I've got to move this forward time is running out. She's probably wondering what the heck happened again because of the callers. Extreme agitation. She's probably trying to compensate Arrows in the mind of what could have happened, trying to anticipate on, maybe react quicker. She's reminding yourself that she's got to stay calm. I gotta keep my voice even. I need to stay in control of this situation. Otherwise, again, this turns out badly. She may be guessing at what the situation is. As I said, she maybe also thinking forward to okay, what kinds of help could be needed? She may be multitasking and saying, OK, what? Police cruisers are nearby? What fire or ambulance? Air paramedics like. Who's closest to where I think this is happening. She may also be losing confidence and thinking to herself, Nothing is working. I've tried every single thing that I know. What do I do now? I don't know what to do from there. We dig into what she's feeling. She's probably frustrated that she can't get through this caller, and she can't calm her down. She's probably also struggling to remain calm herself. She's increasingly anxious and concerned because again she knows that every minute lost decreases the chances of a positive outcome here. She may be very afraid you won't be able to get control of the situation. She may also be ready to give up. I can't take this anymore. Why did I ever take this job? You know, stress and frustration can easily reach an apex, Uh, at a point like this. So just real quickly before we go on, The reason we're digging into all this is because it speaks to the urgency of what needs to be shown on the screen. What functionality needs to be baked into the solution in order to address the urgency here . Her attention has already split. She's got a very extreme situation, is demanding every ounce of patients and thought that she has. She cannot expend a great deal of brainpower trying to figure out how to use what's in front of her. At the same time, these were the things that directly inform design, development requirements, user experience, all those things. It's also worth noting that she may be unable to switch off and focus on the next call after a high stress situation like this. If she's doing this for eight hours or, God forbid, you know, 12 hours or a double shift 16 hours. There's only so much that the brain can compartmentalize and deal with. So if she has a call like this where everything's goes completely crazy and she is struggling to get control of situation, it's highly likely that she'll sort of still be there in her mind for the next call. So again, how does this affect our system? Well, it speaks to the fact that the guidance or help that appears to her via the system has to be really simple. Has to be really relevant. Has to go really fast. Ah, and she needs to be able to access and use it very easily and very quickly. So what does she need to see on the screen? Well, she definitely needs to see the caller's phone number. She probably also needs some sense of geographical location of the call to the level of detail where if we can get a street address happening, you know, via GPS or something else that is probably hugely beneficial. That's one less question that she has to ask this caller. So if the system could do something for her that lesson, Her workload. That's ideal. And that's good, You X, because the solution here the product is supposed to provide scripts for her, that coach her responses, the various situations. She probably definitely need to see that, and a very easy way to get to the right one. Something that's relevant. Toe what's going on right now. So she needs control mechanism of some sort. Teoh navigate these things she made likely need an event history for the woman's location. Okay, prior instances. If, God forbid, it's a situation where there's domestic abuse. If there have been a series of 12 calls right for that particular situation, that's again, let's work that she has to do. She may be able to make an inference and say, It's probably happening again. I know at the very least, I got to get the police there right away again. This allows her to act quicker, other recent or current calls referencing the same location. If she works with four other operators and they have all gotten calls, let's say in the last six hours seeing that information again would help her ascertain what may be going on there. If there was a prior instance. She definitely needs data entry screens to enter the collar situation. Information that goes out to dispatchers first responders, etcetera, etcetera. She may also certainly benefit from a map showing the first responders that are available close to her locations. If she looks at a map and says, Okay, there's police patrol less than one mile from her location. I'm gonna ping them right now. There is ah, ambulance, you know, two miles away. Whatever it is, this all helps her act more quickly. What does she need to dio? As we've said previously, she needs to calm the collar down in order to get the information she needs to analyze the risk and the level of that risk and the immediacy of danger. She got to get a quick handle on How fast do I need to respond to this? She also may need to be able to quickly request colleague help if needed. For instance, if the person on the phone doesn't speak English and Jane doesn't know any foreign languages, she may need foreign language. Helps. You may need a translator. She may need somebody to jump on line with her and tell her what this collar is saying. She also needs to decide what assistance, what course of action is necessary and which is most likely to result. Positive outcome. Based on what she knows right now, she needs to easily identify the appropriate quickest responders and dispatch them quickly . And finally, if all this wasn't enough, she needs to do all of the above before the collar hangs up the phone, right? God forbid the person justice so distressed that they just hang up and give up a run away. Or, you know, God only knows what and then she's stuck, so she's gotta act quickly. Time is definitely of the essence. So I hope you see the connection between someone's emotional state, their situational factors, the scenario and the context in which they have to use something effects how the product should be designed. You know what features what functionality is relevant? What's aspects of user experience are at play here? Are we talking about speed, responsiveness, ease of use? There's probably a strong need for clear labeling. There's, ah, huge, huge information architecture challenge here, where we've got all these scripts they handle, handle different situations, and she's an urgent sometimes panic situation where she has to be able to dig through all those things really quickly and where to find the right one. That certainly can't be a drop down menu that's 8000 miles long. It probably also can't just be a Boolean search where she type something in right, and then she's gonna wait and we'd through responses. She needs some sort of browsing mechanism that gets her to the relevant situation really quickly. That's a wicked challenge, but it's the kind that attention to these details tends to solve. If you're thinking with the mindset of the person that is using the product in the situation that they find themselves in and you're considering their emotional drivers, you are much more likely to come up with potential solutions that fit the problem at hand that solve the need 15. Wrap Up: Empathy & Situation Mapping: after you've done your empathy and situational mapping, it's a good idea to get into the habit of asking some additional questions. None of this stuff takes a lot of time, and the clarity that comes from it is infinitely valuable. First, what attributes or situational factors surprised you the most? For example, the impact of stress and anxiety on the operator's ability to succeed. You know, maybe you wouldn't have thought otherwise about the immense level of stress and pressure that these folks are under. And also stress level isn't usually considered during requirements. This is certainly an extreme example. OK, but some level of stress is president every kind of activity or interaction. It may be good stress, and it may be bad stress, but either way, there is motivation that is pushing the person's actions. And you have to be cognizant of that in order to develop requirements that really deliver value. What aspects of your persona do you need to learn more about? Okay, we know some things, but where are are black holes? What don't we know that we think we do need to know about what's the typical call volume per hour per day What's the volume of stuff that they're dealing with and how many people are there to take those calls? How many points of reference data inputs and outputs So they have to deal with. We skim the surface of this, all right, they've got to deal with the color. They got to get the information. They probably have to enter it somewhere. They have to record it and get it to a dispatcher or communicate directly with first responders. How many places does that information need to be shared with? How many people is she coordinating with at one time and how many systems are in use right at one time? Maybe she's working on one computer, but maybe she has to do stuff on paper or by hand or on the phone as well. Okay, you need to know the volume there. What level of data detail do all those people need from the caller and how much of that needs to be related to dispatcher first responders? It's typical in a requirements process to say Okay, here's the data that gets input into the system. What often isn't discussed to the degree necessary is how many other people need that data . What did they do with it? How did they act on it, how they manipulate it, and who else do they send it to or share it with? There's a chain there, and that chain has to be explored to some reasonable degree. What situational factors most affect your products potential to deliver real value. The unpredictability of these collar situations is probably first and foremost. How could we possibly categorize scripts in a way that their access quickly? There's hundreds of potential situations? And there's probably lots of wrinkles, lots of variations in what happens and how it happens. So we've already established that Jane, the operator here, is multitasking on a vicious level, and she's not really multitasking. She's task switching very fast in the midst of everything else she's doing. How can we categorize this high volume of stuff and wait? Allows her to get to it quickly, right, without creating a drop down list that's 80 miles long or creating 1000 categories and sub categories that she has to browse during scroll through in order to get to it quickly. What mechanism could we possibly use that gets her to this stuff really quickly. That's a wicked problem to solve. But it's what creates a great, useful user experience focused requirement. What about the speed at which information needs to be surfaced? Input shared and acted upon again, Just like the previous example with categorizing all this stuff. Everything has to happen fast, right? This is fast. Fast, fast, fast, fast. Gotta move. Gotta move, gun move. Gotta move when you're talking High volume and high speed It's quite a challenge for everything from information architecture to underlying structure to mid tier logic to back end database work. Ah, to the U. Y. Itself. There's a lot of complexity there that needs to be dealt with in order to enable the type of speed and responsiveness that the situation demands. And finally, the operator's ability to stay calm and focused certainly effects the price potential, deliver real value. Anything we can do for them. That sort of keeps them in control, right? That allows them to remain focused, remain calm and execute faster, more efficiently. Right? Some support there. Those are big wins. What situational factor has the most impact on your feature set? What has the most influence on what does ER doesn't make it to that. Requirements list speed and agility is probably the first. The operator absolutely has to have quick access to a massive volume of information. As we said and she has to do it, it has to be shown to her presented to her without obscuring her, interfering with the other work she has to do. This is not a simple thing, and it's not something that you were just gonna uncover in a one hour requirement session. There are a lot of questions to be asked, and you have to do enough digging to figure out whether you are on the right track or whether this may not be a problem you can actually solve. Accuracy is probably next, the ability to find relevant applicability information pertaining to this exact situation before you lose control of the call again. As we said, all this complexity and the stress involved certainly makes this a tough problem solved. So the take away here is this. This work that you're doing well often raise more questions than answers, and that's normal. That's as it should be. Requirements are not, as I said, features. They're not solutions. They're not answers. The point is to uncover what you don't know but need to know. You explore and validate those things later on. In prototype development cycles with minimum viable products with Alfa and Beta releases, you can validate as you go. But right now we're not definitively solving any problems. We're making sure that we ask the right questions so that we know what the right problems to solve are in the first place. 16. The UX SIlver Bullet: Context (and Contextual Use Scenarios): So let's move to the third tool. I would like you to put in your U ex Arsenal, and that is contextual use scenarios. We're gonna start by talking a little bit about context. I'm very fond of saying to anyone who will listen. That context is everything. You cannot design or build anything that is a value without addressing context, without addressing the situation in which people will use it without addressing the things that influence that use, the things that dictate how and when and why somebody uses something that's context, and it must be explored. So what I'm saying is that you can't design well for people unless you fully understand their intentions, their motivations and their desires first and foremost, and there are plenty of products that are designed with these things in mind. If I go to Netflix and I am binge watching House of cards, Netflix knows that I am binge watching. How do they know that? Because at the end of each episode, I see a little interstitial pop up that says, next episode is gonna play automatically in nine seconds. You don't have to do anything. We know you're probably watching these all at once, so we got it relaxed. That is anticipatory design. That is the type of requirement that delivers user value. We love the fact that we don't have to work to find the next episode and started. We love the fact that the system says No, got it on it. We realized what you're doing here. That's a big win that's designing for context. Great you X gives users what they need when they need it, without there having to find it or ask for it. That's context of use. That's what we're talking about here. Good requirements. Compliment that context instead of complicating it just like the necklace example. If we have an understanding of what users typical behavior is, we can design the system to accommodate it, to anticipate it, to plan for it. Designing for context is absolutely the key to getting product acceptance to getting people to use what you have built, even if they're compelled to do so. All right, even if folks who work in in a company have no choice but to use the project management system that's in place there, if they hate it, they're going to find workarounds that allow them to not use the system. They're gonna create extra paperwork. They're going to create extra checklist. They're gonna create extra work for themselves and for other people. I've seen this happen countless Lee over the last three decades. Okay, So designing appropriately for the context in which people use things ensures that the gains in productivity or the money that needs to be made actually happens. This context of used that we're talking about spans four areas. The first is flow. And that means how people communicate, how they coordinates between themselves in order to accomplish work. This means individuals. It means groups. It means the communication patterns that they use. It means their roles and responsibilities. It's a thorough understanding of all those things and how they operated on the day to day basis. The next thing is culture accepted practices, policies in place that essentially shape and effect and dictate how work currently gets done. We want to know what constraints exists, and we want to know how people work around them. As I said a minute ago, just because the rule says you have to do this This and this doesn't always mean that people who use the system to do that. Okay, so we want to know what the rules are. We want to know what they're supposed to do first. And then we want to know what they're actually doing next to sequence the actual detailed steps that are performed to accomplish his task. The strategies that people use along with their intentions, their goals and the obstacles that get in their way. Where do they get stuck? Where do they get hung up? Where does the process suddenly drag? Where people waiting for something from somebody else or another department or the system. And finally, we look at artifacts. Those are documents and those air data points that are created that air used. Ah, and these things reveal how people make sense of their work through the ways that they're created through the way that they're organized through the ways that they're prioritized through the labels that people give them. How much stuff is created, manipulated, accessed, interacted with. Now there are any number of formal methods that are used to investigate, socialize and validate context. All the four years we just talked about, none of this is new and there are plenty of prescriptions for looking into it. The problem with all of them is that they're needlessly complex. They sacrifice clarity and simplicity for formality, just like the use cases and user stories that I showed you previously or UML diagramming, which I have referenced. They emphasize protocol without really stopping to consider whether anyone can actually use this stuff or understand it or make sense of it. All right. They also take a great deal of time and effort to absorb, interpret and understand. And I'm gonna show you some examples, and you'll see why this is true. Anyone who isn't familiar with human computer interaction H. C I or the principles of contextual design or even U X will have no idea what you're talking about On a project team of any kind, you were dealing with lots of people who are not. You exercise. You're dealing with people who are not developers. You're dealing with people who are not designers, your stakeholders, your clients, your users. A lot of these folks don't understand all this stuff. If you're sitting in a room with department heads from an organization, a lot of times, the technical jargon that gets thrown back and forth is done so with the assumption that everyone in the room knows what the hell we're talking about. And the truth is, they usually don't and they're reluctant to admit it because it's embarrassing. So we've got lots of protocol. We've got lots of formality, but we have no clarity. We have no understanding. So what happens? We entered diagram. Hell, we see things that look like this core. This a lot of stuff. It looks good. It's impressive. We got lots of arrows and circles and stuff and, you know, hear all the details of this transaction. But look at all the text there. I promise you, no one's reading that. The same goes for things that look like this. This looks a lot simpler, right? But it is still hard to track. It's still demands that we stop what we're doing and read all this and try to make sense of it. It just goes on and on and on. Okay. These types of diagrams are very commonplace. Their established practice. You will find no shortage of people in my side of the fence on you. Excited the fencer of design side of the fence that love this stuff. Affinity diagrams right are really popular. People love affinity diagrams like Look, it tells us everything about the context of the shopping experience. No one is reading all this. The look at it. They'll be impressed by how cool it looks. They'll be impressed by the level or volume of work done, and that will be it. You are not communicating anything, I promise you. No one has the time to deal with this stuff. So I am proposing to you a better way, a better way that I have used for the majority of my career. There's a cleaner, simpler way toe uncover flow, culture sequence and artifact issues that everyone in the room will understand. You tell a story which is otherwise known as a contextual use scenario. It's a short, simple narrative that describes how someone might go about trying to perform a task or fulfill a specific need. Here are some examples You start with what the user wants to accomplish. Sarah wants to save products to different gift lists for different family members, and she wants to able to share them with her husband. Bob needs to be able to compare service rates and support contract terms from a minimum of three suppliers. Dr. Reynolds needs to update patient status in the 3 to 5 minutes that he has between appointments walking down the hall, the's air, simple short introductions that set the stage for understanding what these people need to do and how they go about doing it. Here's why contextual use in areas work so well. They focused squarely on context on riel world situations on how things actually get used, as opposed to how we imagine they might get used. That means we focus on sequences of related events and actions. We don't narrow down like, uh, user stories or use cases in tow. One piece and focus on that. We want to know from start to finish. What does the person do from the moment they log in to the moment they log outs? What happens not just with the system but outside the system as well. What other people are involved? What other processes are involved, what things influence what happens? Contextual use areas provide a concrete way to think about human behavior and needs because they illustrated and finally, maybe most importantly, they remind us that we're designing for human beings. We're not just talking about some abstract collection of features and functionality. We're dealing with people, people who have to use what we're creating, contextual use scenarios, address functional needs and elements. They absolutely correlate to formal requirements. And I'm going to show you how very shortly they deal with content and data. What should the user be able to see these air? Your noun is right with typically described as Okay, What did announce that we have to deal with? They address action and interaction. What should the user be able to do these air your verbs. Many of you have probably heard these terms before. They also address outcomes, what outcomes are desired and what makes them easier to realize. Right? What can we do to make sure that those things happen? In addition, we use use scenarios because they don't solution jump, which is the difference between saying user needs to be able to download MP three files versus they need to be able to download digital media. Do you see the difference between those two things? The first assumes that we already know what format the user wants and is capable of using. We're also assuming that audio is the only media that's relevant. Well, what about video generating? Meaningful requirements is all about remaining open to possibilities. It's about remaining open to what could be appropriate if you take a look at this picture on the right. When the smartphone was first invented up until that point, no one really considered the concept that you would really be taking good photos with your phone phones at that point had some photo capability that was really poor. Okay, you could look at it on the little tiny screen, but you really couldn't do much else with because the quality was so bad. But once that idea came about, it became a product requirement. Now, every smartphone, every tablet, every portable digital device has a set of requirements relating to allowing the user to take photos. Not only good photos OK, but photos that are portable that can be shared in any number of ways that can be easily posted on social media, all these different things. So if you're not considering the context of use, things like that never come about. This is an example of a contextual use scenario, and this is adapted from Kim Goodwin's incredible book Designing for the Digital Age. Let's assume that you're designing an appointment. Scheduling system for dentists is used by the receptionist to schedule appointments and procedures. Your primary persona, the person that we're gonna deal with in this exercise is Kia Bhandari. She's a receptionist at the dentist office. I want you to notice two things about what I just showed you. Number one noticed that the photo is not a typical, perfectly polished model. She is ethnic. She has very distinguishing facial features, and her name is also ethnic to make her more real to you to make her seem more like an actual person. If this, said Jane Smith, or, you know it was a guy Bob Jones, it was a picture of this typical model smiling into the camera. Hi, I'm Bob Jones. It's artificial. It does not put your mind in that place where you're thinking of this person as an actual person. So the more riel you can make the person's name them or riel and less stock like you can make the photograph, the better off you're gonna be. Here's what Kia has to say about the work she does. Managing and scheduling patients while keeping them happy at the same time can be a very tall order. And when I can help them quickly calls back up fast. Here's the use scenario. Example. Key. It takes a call from Mr Wilson, who needs to make an appointment for his son to have a tooth capped key, looks him up and sees that he has two sons, Gym and Jason. Now Jason is flagged for a follow up. So she confirms what Mr Wilson that the procedure is. In fact, for Jason. She selects that name and chooses the procedure type. The system shows the next several non urgent appointments for Dr Davis, who is Jason's usual dentists. Along with when the room and equipment required for that procedure are available, She suggests the first few dates to Mr Wilson, who says he was hoping to take care of it. Soon she can see that another dentist, Dr Adams, has an opening sooner. But Mr Wilson says not. I prefer Dr Davis. She can also see that Dr Davis has two slots that air close to the required parameters, but don't quite fit them she looks at the calendar to see what appointments are on either side of those slots. One is just Dr Davis's administrative time, so she moves that toe later in the day and offers it to Mr Wilson, who accepts. Kiah tells him he'll get a confirmation in the mail. The postcard immediately gets sent to the printer on her desk. Kia hangs up the phone and greets a client at the desk who's ready to check out. This is the end of our scenario. I've told you a great amount of detail about what she is doing. What's happening, What the other actor, as it were in this scenario, eyes doing in response. All of this detail, as you will see in the next video, allows us to begin constructing rial world functional requirements about what key and needs to be able to do with the system that she's using, what she needs to be able to see and what winds up manifesting itself on the screen. As a result, 17. Communicating Use: Creating Visual Workflow Scenarios: Now I want to talk to you about taking this a step further, and that is making it visual. Talk about creating visual workflow scenarios that increase everybody's understanding of what's taking place here. One thing that I found to be true is that when you're having a conversation, you'll certainly get the impression that everybody knows you're talking about When you draw that scenario on a white board and everybody in the room is looking at the same visual representation, you know, people are understanding. So making it visible in some way goes a long way in communicating to people who otherwise are in the dark and probably will not admit that there in the dark here's out of his works . You take a story like the one we just showed, and you make it visual. OK, you ask how a user would accomplish a particular task first and foremost So, for example, when I'm in a room with a client or in a room with stakeholders, I'm asking questions. I'm saying Walk me through how this person does their job. In the case of ah, an internal B two b app, for example, they'll tell me a story as they tell me. The story I'm drawing is essentially boxes and arrows. First this happens. Then this happens. Then there are some choices have you made? If you look at what's on the screen, you'll see that there's a ah question mark in step two. Is this Ellen past? If yes, this thing happens. If know this thing happens, that's really all it is. I don't adhere to any formal way of doing this because I don't care about the protocol. I just want to make sure that we capture it. And I want to make sure that we can ask questions about whether I have captured it accurately or not. And then I want to and identify where the sticking points are as you'll see. So first we ask, How would someone do this? And then you're drawing as they're talking. So we're diagramming the core work flows here. This is typically how this works. After we've got that down. The next thing you do is you ask questions. I know it works this way now, but does it work well? Where do people get stuck? What part of this takes the longest? What part of this causes you the most pain. What part of this usually takes, you know, three weeks to complete versus the one day that it tastes to do everything else. So you ask questions, and then you note the answers, the questions that arise as a result of those discussions and any comments in a different color altogether, which looks like this now. I often get funny looks when I go into a room because I always carry my own white board markers, and I need to have at least 3 to 4 colors for this reason, so that when everybody looks the screen later and there's all this stuff up there, I want everyone to be able to tell clearly what is the sort of core path that we started with and what are questions. What are issues? What are problems? If you look at this example, you'll see that I've made notes all over this. Okay. When I asked a question about the second step in the process, for example, we found out that there's no link directly to get here. The person has to go back all the way to the beginning of the menu and start over again. So you can see that, I asked a question below it. Why not just go right there? And that's what all this red stuff is. It's going back and questioning and saying, OK, what about this works? What doesn't work? What's a problem? Described the problem to me. And if you happen, have an idea for fixing it. You noted. Here, this is all food for discussion. We're not trying to get to done here. We're trying to make sure that we exhaust Oh, possible questions, and we want to make sure that we identify all possible issues. Here are a few more examples of what those look like again you'll notice the presence of different colors here. The black stuff is here is typically how this goes. K team kick off meeting content kickoff meeting. There's an agenda. There's a word document that gets produced along with an audio recording. Then we go to some sort of vetting process. You can see that below that there's my little person icon who is a collaborator who may be involved in that process. And again you'll notice that not everything about this interaction is noted here. I'm just trying to make sure that we capture all the salient points. What's happening, who's involved, how many people are involved, how many processes are related to this one. And I'm just walking it forward. I don't care what it looks like. And in the example that you see here anything that I've sort of circled in orange, those of the problem spots, what I did is and went back to the same group in the room. There were six people in a room and I said, Where do you get hung up where the problem spots, Where are the places? Progress grinds to a halt because you're waiting and these were there. Is they identified? We did that so that we could have longer, more detailed discussions about those items later. And you'll also see that in those situations, if any particular issues were voiced, such as on the one left, it says additional faculty needed, there is a timeline issue. In other words, somebody had said, Look, if we had three more people involved and we weren't just dependent on this one person who's schedule is completely full and we have to wait until they have a moment. Ah, it would be much easier, so we made sure that we noted that you don't know that that's a real solution. You just know that. OK, well, here's something that everybody feels would help. I say again, this is not a formal process. I am not talking about UML diagramming, which certainly serves a purpose, is very relevant. In some cases, it is not what we're trying to get to here. I am not of the mind that it helps us create the kinds of requirements that deliver positive user experience. It's excellent at identifying, uh, technical needs, functional needs and things like that. But it is not the right tool for what we're trying to accomplish here. UML diagrams typically only capture a very small, very specific part of an interaction. This is not a user journey from start to finish, which, as you heard from me already, is the more valuable part of user experience. UML diagrams also typically include the system which at this point in our work, we don't care about yet. UML diagrams also quite honestly are hard to decipher for non technical people whose understanding you absolutely must have. If I had a dime for every time I have been in a room with a large group of people where engineers were sharing UML diagrams and everybody is nodding their head and going Yep. Got it. Yep. Got it. Yep. Got it. And then you come to find out 34 weeks later that at least half of those people didn't get that No idea what they're looking at. They had no idea what it meant, and they also had no idea what they were agreeing to. This is dangerous. You have got to do this stuff very early on in the process in a way that is very simple, very straightforward and is done in common English. Okay, if it's done in a way where only a select group of people will understand it, it's probably the wrong tool. So here's an exercise for you. I want you to create a visual workflow scenario. I want you to create it based on everything you know so far about Kia's scenario. What we just described what we walked through in identifying functional needs and elements . I want you to take that and try and make it visual, which means you're going to diagram the sequence of actions and events, you're going to include decision points, our actions with multiple outcomes. And then I want you to add questions for the things that you are either unsure of or are undefined at this point. Things you don't know things that you feel like you need more information on. Okay, again, Don't worry about the format. It doesn't have to be anything specific. It just needs to be something that makes sense to you. So I want you to stop the video and give this a shot and then come back and I'm gonna show you an example of how I would diagram this area we just walked through. Okay, so hopefully you've found that interesting, if nothing else. And hopefully a little bit challenging, right? Made you think a little bit. Here's my version. The place that we start is with the players. Okay. We know that we have the admin who is Kia. We know that there's a phone call taking place, and we know that there's a patient on the other end of the line who in this case is Mr Wilson. So the first thing the admin does is she looks up the patient, the first decision point or the first question in the process is, Are there Children? If yes, then we go forward. Okay, If there aren't any Children, then we're dealing just with the patient. But if there are, we go to view those Children's records. The next question, according to our story is, is either one of those Children flagged in any way for a procedure? If no, then we have to select a specific procedure based on the conversation that Key is having with Mr Wilson. If yes, then the procedure is automatically selected. Right? Remember we said that Jason, Mr Wilson's son, was already flagged for an appointment. So the system says, Yep, we're ready to do this. And I've got everything all together for you already. The next question is, is there a dentist assigned in this case? Mr. Wilson was clear, you know about which doctor he wanted. So if that's the case, then you can see the yes path is We go all the way to view that dentists schedule. If there is no dentists assigned, then chaos a select one. Either way, both of those paths lead to viewing the dentist's schedule. Once that happens, the very next question is, is the requested dentist or the requested date available? If it is, then obviously we move forward. But if it isn't, we need the ability to view alternate deaths, alternate dates. Who's available on when? The next question, if that happens, is OK. Do those work? Is the dentist available on the right date? Is the patient available on any of those dates? If they work, okay, we go forward. If they don't then Kia again, as in our story, needs the ability to either move appointments or change dentists altogether. Right? She suggested another dentist. Both of those paths again lead us to the same place, which is okay. Everything is in place, and she has to select that date. Confirmed that Yep, this is when it's happening. The very next decision point, at least where the system is concerned, is. Does the patient have email? If not, then the postcard gets printed automatically, as in our story, and it gets mailed. If yes, an email is automatically triggered and sent to their email account. So all roads lead back to the patient, and at this point, the next step in their path is to show up for the appointment and, uh, have some procedure done, which hopefully is a good thing. So that's how this works. You can see that nothing here is very complicated. Does it account for every possible scenario? No. Does it account for every single technical piece of functionality of the system needs toe have? Does it describe what platform we're gonna use or what databases we have to interface with or how those databases they're gonna be designed or any of those things? No, but none of that matters yet. What we're trying to get to right now is what workflow? What scenario makes sense what has to happen at very high level in order for what we're designing and building here to be valuable both to our core user, who is Kia and also, by extension, our customers or patients. In this case, Mr Wilson, we are focused, in other words, on user experience. 18. Generating Functional Requirements from Use Scenarios: So now that you know what a contextual use scenario is, I want to show you how you extract functional needs and elements from that use an area from that story. These are essentially the building blocks of what you will most certainly recognize as requirements. So here's our Houston. Your example. Okay, this is the story I told you about Mr Wilson and Key other receptionist. I won't walk you through it all again, but I want to show it to you now so that you can see what we're working from. What we're gonna do is walk through this one sentence at a time, and I'm gonna show you how you extract information from every sentence. All right, this is the value of storytelling. So are you. Scenario in essence, provides clues that form the basis for our requirements, and they're sort of two flavors at work here. These are the two things that you do with Houston area to start to start the ball rolling. The first is a functional need, and that is what Kia in this case needs to be able to do with the system. What does she need to be able to accomplish given the statements that we've made, given the story that we've told what things that she need the system to be able to help her do in order to fulfill her goals in order to deliver a positive not only user experience for her but customer experience for Mr Wilson. Next are functional elements, and those are the things that the system needs to present Takia to enable her to do those things. Okay, so we're asking two questions here. What does she need to be able to do? And what does she need to see and be able to interact with in order to do it? So start the first sentence key looks him up and sees that he has two sons, Gym and Jason. So she looks up Mr Wilson and she sees. Okay, he's got two cents. So what requirements come from this? In terms of functional needs, we know that she needs to be able to look up callers among all existing patients. Okay, so she needs a way to sort maybe or filter or sneeze the ability to comb through list quickly and find a single person. We also know that she probably needs to see overview information about each patient and Children who are patients in the associations between the two. Because the story says that when she looks him up, she also sees that he has two sons now on the other side, in terms of functional elements. What does she need to see? Well, she definitely needs an area on the screen that shows her the patient list on that probably has controls that allow her to search or sort or filter or any number of things. She also needs a display of some sort of overview information for the patient. So instead of just seeing a list that says, you know Mr Jim Wilson, she also sees in that same listing before she has to click anything that he has two sons who also happened to be patients of this particular dentist. So again, notice how the sentences written. It doesn't say she digs around for 1/2 hour and finally gets to a screen that tells her, Hey, his two kids go here is well, no, it's all one sentence that suggests that she should be able to get this information quickly immediately. It also suggests that we need a display of over your information for his Children as well, because we don't necessarily care about the fact that Mr Wilson has two sons. What we do care about is the fact that those two sons are patients of this particular desks . Here's the next sentence. Jason is flagged for a follow up, so she confirms with Mr Wilson that the procedure is for Jason. She selects his name and chooses the procedure type. What does that tell us? The functional need that this suggests, is that she needs to be able to see what Children need, some kind of follow up without digging into detail again The minute she sees Jason's name, she needs to know right then and there that he's flagged for Fall up. She shouldn't have toe work for it Now. The functional element that that suggests is some sort of visual feedback on the child's name, indicating follow up right, a little badge or a banner on icon next to his name that communicates. Something needs to happen relevant to this listing. Okay, some sort of visual feedback that says you need to look at this. She also needs an area to set employment parameters in the statement above It says she confirms Mr Wilson's procedures for Jason. She selects his name and chooses the procedure type. So she needs some way on that same screen, if possible, to set employment parameters. Here's where the patient is. Here's the procedure type. Next, the system shows the next several non urgent appointments for Dr Davis, Jason's usual dentist, along with when the room and equipment required for the procedure are available. What functional needs is this imply? Well, it says that she shouldn't have to know how much staff, time facilities or equipment are required for procedures because, as the statement says, the system shows when the room and equipment required for the procedure available. Those associations. If it's this procedure, this equipment is needed and this type of room is required. The system does not work. She doesn't have to do that work. Okay, this is why these statements in the way that they're written, are extremely important and also extremely revealing. It also suggests that she needs to see appointment times when all of the required re sources are available, excluding urgent appointments. Notice that the term non urgent is used in that sense the system shows the next several non urgent appointments. That's a clue. Every word is a clue. So any time ah, client or a stakeholder or anyone walks you through a scenario was, someone has to do something. These are the kinds of things you're listening for. You may think that some of these words are irrelevant. You may only capture some of what is being said to you, but I think you should be able to see already that every word matters we can make inferences on, and we can brainstorm to some reasonable degree from these stories what really needs to happen. So the related functional elements here are some sort of edible default settings that automatically allocate staff time and resource is to procedures. Right? So we know we need some kind of admin interface where all these parameters can be set up. If it's this type of procedure, it requires these particular staff members. It requires this type of equipment and requires this particular room or rooms in our office that all has to be set up at some point. Those associations have to be made by somebody. It also needs to display the best appointment times again, there's logic at work here. The system has to be able to take in all that information and find a place, a dates and a time where all those things come inside. That is an interface need, of course, but it is also a middle tier logic need. So now we get into a little more complexity. She suggests the first couple of days to Mr Wilson, who says he was hoping to take care of it sooner. Another dentist, Dr Adams, has an opening sooner, but Mr Wilson prefers Dr Davis. She can see that Dr Davis has two slots that air close to the required parameters but don't quite fit them. She looks at the calendar to see what appointments are on either side of those slots. One is just Dr Davis's administrative time, so she moves that toe later in the day and offers it to Mr Wilson, who accepts. So what functional needs can we infer from this? Well, she needs to see other times that almost work so that she could make a judgment call based on you know, what might work. So the system said there are two slots that air close to what you're after, but it's not really that. And then it allows her to say, Well, I know what that is, and that's not important. I can probably move it If that doesn't happen. If the system doesn't show the almost matches, she can't do that. All right, So in other words, it hampers her ability to serve her customer, her patient, the functional elements related. There is a display of appointment times that might work if the calendars modified. In other words, there may be some sort of interstitial state where if you make a change but don't commit to it, the system shows you what happens as a result. So if I move this appointment hey, I could get a slot in here, Okay, so some way to actually do that work before you can commit to it. Some way to see that if I move this over here now, it works. She also obviously needs a calendar display for all appointments, and that display should probably be by specific dentist. If you notice the story, says that she sees that another dentist, Dr Adams, has an opening sooner that allows her to offer it to him and say, Look, Dr Davis is busy, but this guy could probably do it. She can't make that recommendation unless the system shows her other dentists aside from the one that she is looking for. So then we get to the end of the story. Kiah tells him he'll get a confirmation in the mail. The postcard immediately gets sent to the printer on her desk. She hangs up the phone and greets, Acclimate! The desk was ready to check out. There's more here than meets the eye, and I'm interested to see if any of you caught it on the functional needs side. She needs a way to automatically print reminders for patients who don't have email. There are plenty of older people who are still kicking around this planet who aren't familiar or wannabe familiar. Quite frankly, with email, they look forward to that postcard in the mail. They depend on it, okay, so that is part of the process. The reason that's in there is because it forces you to look outside your own preconceptions and expectations. The functional meant there is some kind of practice wide default for printing an email reminders. So once again, we have an admin interface that when we enter a new patient, we can say this person gets a postcard instead of email because they either don't have an email address or won't check it. Either way, it gives you the opportunity to customize your service to the patients that come to the office. And once again, that is a seemingly tiny detail that actually goes a long way in providing great customer experiences great patient experiences in this case. 19. 18 EXERCISE: Generating Functional Requirements: So now that we've walked through a couple of these things together, it is entirely your turn. In this exercise. I want you to experience this sort of path of generating requirements from personas and use scenarios. I want you to assume that you are designing an account investment portal for retirees, older people who are already retired and want to be able to manage their investments. It's used to access retirement accounts and change investments. Your primary persona is Bob Davison. He is 68 years old and he is a retired mechanical engineer. And here's what he has to say about his scenario. I'd like to make some changes to my portfolio, but it's impossible to get a person on the phone. They wanted to use the website, but I hate all this new fangled stuff. It's confusing. Here are your tasks related to Bob. I want you to create an empathy map for Bob. I want you to create a situational map for Bob. Next, I want you to write and contextual use scenario, a story where Bob is using the website for the very first time to try and change an investment fund. I also want you to generate a set of functional needs and elements based on your use scenario. Okay, so go back. And if you need to watch the videos for how to do each of these things and then I want you to give it a shot using the templates that I've provided, I want you to just dive in and give this a shot. I don't want you to worry about getting it right. I don't want you to worry about getting it perfect. Don't think about right or wrong answers. Just do it. Okay? Go forward, generates them stuff and keep generating some stuff and feel free to share your answers with me here. 20. Sample Answers: Generating Functional Requirements: Okay, so I hope you went through his exercises. And I hope you're not just skipping ahead to the answers. If you are stopped the video and go to your word before you watch the rest of us. Seriously, it's good for you to experience it yourself, toe work through those processes and sort of get used to doing it. But for those of you who have done your due diligence and done the work, I would like toa walk you through some sample answers. Which, by the way, don't make any of your answers wrong or incorrect. These air just examples to give you an idea of how to answer this stuff and how to do this work in the event that you got hung up somewhere. Or maybe just to give you some alternate possibilities. So again, the person that we dealt with was Bob Davison, who is 60 years old, is a retired mechanical engineer, and what he said was, I'd like to make some changes to my portfolio, but it's impossible to get a person on the phone. They wanted to use the website, but I hate all this new fangled stuff. It's confusing, right? So We know a few things about Bob from that statement, and those are the things that, as you're going to see, manifest themselves in our answers. So let's start with his thoughts and emotions. His beliefs, his worries. He probably doesn't see himself is capable of using technology. He's intimidated. Based on that statement, all this new fangled stuff is confusing, right? So we know he's technology adverse to begin with. That suggests that he's going to need a lot more hand holding than most people. He also believes due to this statement that he should just be able to talk to a person like the old days. You know, why can't I just get someone in the phone? Why do I have to do all this work? And part of that is because he's worried that he might lose a lot of money if he messes something up, which is certainly a realistic concern If all this stuff is new to you, he's worried that anything he does online isn't private. It isn't secure. He's also likely putting off this task for all of these reasons. Let's talk about Bob's environment. How does that affect him? Well, let's say for example, is just him and his wife. At home. His kids are grown, so essentially, there's no one there to step in and walk him through it. He's likely using older hardware and older operating system in an older browser that hasn't been updated for quite a while. Those of you who have parents of an older generation, I am, for example, 47 gonna be 48 my parents for a long time. You know, technology was like this alien land to them when they finally did get a computer. And even to this day, you know, when a new OS comes out or a new browser new software, they don't automatically update anything. They're cautious, like Wait a minute. I know how to use all this stuff right now. What if it all changes? Okay, so most folks in this guy's age range who are, you know, in their late sixties at this point are likely intimidate by that as well. They don't like change that just they know how to do what they know how to do, and they don't want that to change. So Bob doesn't do anything on a computer except email and heap copy does that reluctantly, right? Maybe so. He can talk to his kids or his grandkids or something like that. But to him, the phone is the primary means of communication. That's what he's used to. It's what he's done for the majority of his life. And those habits and those reflexes have a profound influence on what we're willing to do. How about social influence? Who influences Bob? Well, his wife is probably the person he spends the most time with. But maybe she isn't much help. You know, she's never worked, For example, a lot of folks in that generation There were a lot of women who were staying home moms, which is a tremendous job in and of itself. OK, but they didn't have office jobs, and the says say they were never exposed to maybe computers, for example, in that way, so she doesn't really understand this stuff. She's not much help him, either. She's they're both in the same boat, okay, Their skill levels is about the same. Bob's best friend, Henry, is the person he confides in and goes to for advice. They're the same age they've known each other since high school so for the same reason, they may very well be at the same technical level. Also, however, Henry doesn't have any investments like Bob does other than a pension from the automotive factory that they both worked at, and that provides a fixed interest rate and regular distribution. In other words, there's very little that Henry has to do to manage any of this. So he's not much help to Bob because he doesn't have to make these decisions, and he certainly doesn't have to do any of it on a computer. What he's got is sort of a set it and forget it type situation. So you get the picture here. We're trying to paint a picture of what situation is this guy find himself in and what dictates why or why not? He's able to use what's in front of him. How about his behavior? How does he act? Well, he probably prides himself on being a self starter. He can fix just about anything, and he's often too proud to admit when he doesn't know how to do something right. He's used to being fully capable in always. Something breaks in the house. He fixes it. If something's wrong with the car. He fixes it. When something comes about that he has no frame of reference for, he probably gets a little bit afraid, and his pride probably gets in the way of him asking for help. He wants his wife, for example, to see him as the provider, the protector, the person who has everything taken care of so their future is safe and secure. Now. Whether that's true or not is irrelevant. A lot of men in particular, quite honestly, myself included, Um, we want to be seen as that capable person. You know, I am the head of this family here, whatever that is, and that comes from upbringing, right. But it's there. So anything that sort of challenges, that idea, that you are competent enough, you know, to take care of everyone is can be kind of a scary thing. So he's afraid that she'll see him differently. She'll see him as less capable, less reliable. If he can't figure this out. These are all the things that may very well be swimming through his head. What about his pain, his fears, his frustrations? He's probably worried again. Like we said before that he might lose a lot of money if he screws up, and that's a very real fear. He's probably very reluctant to enter sensitive private information like a Social Security number, bank account number, things of that nature. He's probably very worried about identity theft because of the frightening stories he's heard in the media about people his age being targeted. You can't go 10 seconds in this day and age without hearing about identity theft or online hacking or, you know, some really scary stuff that says your information is not safe anywhere. So with older generations in particular, this is a frightening concept. So as I said a minute ago, everything he sees on screen seems completely foreign to him. He has no frame of reference for any of it, since he doesn't really use it, right? Doesn't use the Internet, doesn't use computer that off. Where is gains? What does he need? What does he want and what does he really think? Successes. Well, he wants to make the right decisions to secure his finances. Obviously, he probably lives on a fixed income. He's getting a retirement check, so he's got to be careful about how you manage is his money. He probably wants to be 100% sure that he's doing the right thing. And he would probably stop worrying if he had some kind of understandable proof of that. If what he sees on the screen reassures him that he's doing the right thing, if it guides him and speaks to him and communicates to him in a way that he understands some of the stress would probably go away, he wants to feel as confident and as competent and as in control as he does when he's fixing his car. When he's fixing something in the house that's broken, okay, that is his comfort zone. That's where he feels like. Okay, I can do this. So from there we moved to a situational map where we get a little more specific about Bob situation. We know the basic situation, and that is Bob's confused. He's very nervous before he's even attempted to set up an online account. He has his account information, but he doesn't know how to take the first step. He's afraid of entering any data, any sensitive data because there's just too much uncertainty there for him, so he feels stuck his actions. Step is twofold. First, he needs to get help. He needs to get guidance, and he needs to get reassurance that a he can do this and be it will all be OK. Next. He needs to create an online account, actually get started, right? Take the mechanical steps to actually establish an account. So what might he be thinking? Well, there's no way I'm gonna be able to do this. I don't know what any of this stuff means. Why did they have to use all these complicated, big words? And why is there so much to read? If you've ever looked at an investment site or an insurance site or anything of that nature , once you get into the meat of actually doing something that's transactional, the value of information in some cases is massive, and it's written this obtuse language purposely by lawyers to prevent the company from being sued. So it's obtuse on purpose. A good friend of mine who's a business lawyer talks about this all the time all rights, but it's intimidating to someone who doesn't understand. It's intimidating to someone from a different generation who is used to things just being a lot simpler and taking place between people as opposed to having to read all this stuff. He's thinking, Why can't I just talk to a person or have someone do this for me? What the heck happened? That idea of customer service, that's his idea of of how the world works to us. We're used to self service online. Okay, partly because we're most of us were a lot younger when it was introduced, and we've started grown up with it. It's normal for people of the generation before. This is a new concept. To them, it feels like something is being taken away. People used to help me, and now they're basically saying a You're on your own. Go figure it out. Who else could see my information would have some hackers watching me. What if I do something wrong? Is there a way to fix it? Is their way to undo it? Can I call someone if I get stuck or get myself in trouble? How long is this gonna take? I don't want to be here all day If he logs in and sees this massive volume of text and fields and everything else on the screen he's going on. My God, this is gonna take eight hours. What's he feeling? At the same time, he's frustrated that he can understand language on the screen. He's frustrated that he can't figure out what he's supposed to do first, what to click on, Uh, etcetera. He's increasingly anxious and concerned. The more he reads and nor he looks at, the more he feels like he will never be able to understand the this or be able to use it. He's probably angry that doesn't see any information to call someone to get help. Let's face it, that's one thing that's gone away on a lot of websites, contact information. It's purposely hidden because these organizations don't want you to call them because it costs them money. He's also likely embarrassed that he can't figure it out, and he's probably ready to give up. So what does he see on screen? He probably sees a high volume of dense, complex, legal sounding text that uses big words and acronyms that he can't make sense of. And all this exists beneath a banner that says it's easier than ever to manage your money online. He probably sees field to enter his user name and password, which he doesn't think he has, and he probably don't know how to get one, either. He probably sees a bevy of images of happy seniors enjoying picnics in the park and riding bikes and looking like they don't have a care in the world, right. Those marketing pictures that we see on websites Ah, look how happy everyone is because they're using our products and logging in online to manage their finances. There's probably plenty of that. He probably also sees navigation filled with generic or obtuse terms like wealth management , intelligent portfolios and my favorite insights. Those air, all common terms. But they don't mean anything. They don't tell him anything specific about what he's going to find if he clicks on any of them. What is Bob do in this situation? He probably clicks a few random links in a navigation, hoping that will find some clear instruction. But he doesn't just more text. He can't make sense of and stupid pictures of happy people his age, which he doesn't understand why they're happy, because he is absolutely not happy at this point. He finally locates and clicks a link labeled contact, but he doesn't see any phone numbers just links that say knowledge base. And he thinks, What the heck does that mean? Or forums or other forms of support? In other words, more places we can send you off to to prevent you from calling us. So he probably gives up, and he starts reading through his account paperwork in the hopes of finding a phone number to call someone right so we can finally get the help that he needs. All of this tells us a great deal about what he might need to see on screen what things will actually help him. All this information should be painting a picture for you about what may work for Bob and what may not. So to really solidify those things, we moved to a contextual use scenario. We make up a story about Bob using this website, and I'll share my version with you. It's pretty simple. Bob opens Internet Explorer and opens his Google bookmark. He enters the girl in the search field and then selects the website from the results on a pause there for a second. This isn't necessarily requirement, but the behavior is really important. The behavior does influence requirements in this way. For a lot of people, Google is the Internet. Google is the way you use the Internet. You don't enter your URL in the browser bar above. You go to Google, you search for what you're looking for, and then you click on Understanding how people perceive the way a tool is supposed to be used is extremely important in generating the type of requirement that is going to make sense to them. OK, so this doesn't translate to a requirement in this sense. But I wanted to call it out because it's an important thing. It illustrates how human behavior isn't always what we expected to be. So again, I want you to abandon your preconceptions in your expectations about how people do things. Don't assume that, you know, on the home page window opens up that gives Bob the option to log in if he has an account or create a new account. If he doesn't, he's never done this before. So Bob Clicks create new account. On the very next screen, he sees two fields, one for his email address and one for his chosen password, as he wonders where he adds the rest of his information. He sees a sentence next to the fields that says, Don't worry, we'll get the rest of your information after you create your account. So Bob fills out the fields. He clicks the big blue create new account button below them. On the next screen, he sees a big message saying, Congratulations, you just created your account. Underneath this, he sees text that says, Now we'll need more personal information like your Social Security and account numbers. This information is 100% secure. No one can see it, except you notice how that last sentence is worded. No one can see it except you. That can't be any clearer. That's reassurance that safety that's addressing the users concern to the right of this text. He sees a box tiled next steps. It offers two options reading. If you're comfortable doing this yourself, click the get started button to start filling in your information or the second option, which says, if you're nervous about doing this, enter your phone number in the field below and click the Help Me button. One of our representatives will call you and walk you through every step of the process. So remember that we can extract functional needs and elements from stories like this, and that's what we're gonna do. So use in areas we said before provides clues that form the basis for requirements. We have functional needs, which are what Bob needs to be able to do with the system. And we have functional elements, which are what the system needs to present to Bob to enable him to do those things. And these are very simple starts, okay, but they form the basis for walking down the path of requirements that are meaningful. So let's walk through a couple of these based on the story I just told you, I'm just going to take a couple extracts. Andi, show you what could possibly be extracted here. So what requirements can we infer? Let's take the first point of action on the home page. A window opens up that gives Bob the option to log in if he has an account or create a new account. If he doesn't, he's never done this before. So Bob clicks create new account. What functional needs exist here? First, we know that we need some sort of logic that tells the browser that the user has a never logged in before or B is a new user entirely. We also know that we probably need some kind of script to trigger that motile window and that that is a single instance for first time User. If I've already logged enough of already visited this page, I don't see that pop up. The functional elements that could be attached to this are motile window, with two options, as described here, clear, visually prominent action buttons, a landing page that's attached to ease option again. These are very simple things, but they start you down the path to doing a couple things. Not only you defining some of the stuff that needs to happen technically, but you're also doing some very preliminary you. I work some information architecture, work, some navigation work. You're laying down some things that give you enough to go on to get started on a prototype , and that prototype is what will inform the rest of your requirements. Let's take another part of this. On the very next screen, he sees two fields, one for his email address, one first chosen password as he wonders where he has the rest of his information. He sees a sentence next to the fields that says, Don't worry, we'll get the rest of your information After you create your account, Bob fills out the fields and clicks the Big Blue create new account button. So where the functional needs here? Well, first, the system needs to allow the email address to be used as a user name for the sake of simplicity. We don't need all three things and a lot of instances where you were asking people for user name, password and an email address. You would be surprised how often that third piece information sort of tips them over the edge. It's also become accepted practice that we can use our email address as our user 80. So if you don't need both, you don't ask for both. Anything more than what the person is willing to deal with is a possible barrier to entry, something that prevents them from taking the next step. We're going to allow the creation of an account with Onley, these two data points. We also probably an automatic prompt after logging happens for that person to enter their additional information before they could do anything else. We're putting it off right because a lot of times organizations ask for this massive volume of information before you can log in and get started that to can be a buried entry, ask for the minimum once they get in, then prompt them to enter the rest. That's what we're doing here. Functional elements related to that. We need foreign fields, and we probably need some in line validation, you know, to validate that. That's an actual email address. We probably need a password strength indicator of some sort. We probably need password requirements, texts that tell them you must include one special character, one number one Capital letter, etcetera. Whatever the case may be, we also obviously need clear, visually prominent action buttons and some text. Let's look at another piece of this to the right of this tax. He sees a box titled Next Steps. It offers two options reading First. If you're comfortable doing this yourself, click the get started button to start feeling in your information. Two. If you're nervous about doing this, enter your phone number in the field below and click the Help Me button one of our representatives will call you and walk you through every step of the process. It's that second part we're gonna focus on here. The functional needs they're attached to this are we know we need some sort of automatic prompts, right? Some logic that the person has to fill in the remaining customer data once they create their account. We also know that we need some sort of Web callback module, right that's possibly integrated with chat or help desk or something else for this call back feature where enter in my phone number and then I get a phone call. There are any number of third party modules that do that. There are, ah, lots of solutions for, but the point is, we know we want that feature. It doesn't matter right now what we're going to use to do it. It's simply matters that we know we need it. We know it's valuable. We know it's important, and we know why. It's important. We also probably need some sort of real time progress or status indication for the callback option. Once he clicks, the button enters this phone number. Click the button. There probably needs to be status. Okay, we're gonna call you in the next 60 seconds or processing your information. Expect to call within this time frame. Whatever it is, there has to be some resulting feedback that tells the user what's happening. So here the function elements that support that we need form fields. Obviously we have some in line validation that has to happen. An error feedback. We wanna make sure that that phone number is not malformed, that it's exactly 10 characters or whatever it needs to be. Well, Sezam air feedback When something is wrong, we also need some interstitial progress page or a status indication of some kind for that callback option that maybe baked into the model we're using. Or we may need to create it. Either way, we've captured it. We know it exists. We know we need it. So this story is dead simple. There's a lot of past that you could certainly go down that are much more complex. I wanted to keep it light, keep it simple and just give you a basic idea of what's possible here. But what I hope you see in doing all these exercises is that the more you know about this person, and by doing these kinds of exercises and digging into who they are and what their emotional state is and what their situation is and what their context of use is, you get a very clear picture of what requirements actually are valuable and again not just to that person, but to us, to our business, whether it's us as a creator or whether it's the folks that we worked for that are creating this system. In either case, the only way it's worth doing as if people actually use it can use it, and therefore either by what we're selling or are more efficient and we save money or whatever the case may be. The other thing I want to say about this stuff that hopefully you experienced is that it doesn't take any time. We hear the argument constantly. There's no time for user research. There's no time for additional requirements. Validation. Here's Here's the feature set, like just go do it right wouldn't have time for this. Every one of these exercises is done in much less than a day and a lot of cases. Each one takes about 15 minutes to think through and in every case, you're going to come out of that 15 minutes or 20 minutes, even if it's 1/2 hour, I don't care. You're gonna come out of it with things that are valuable. You come out of it. In the case of ah, you scenario with requirements that are grounded in what actually constitutes value, what actually move the needle in some way, both for the person and for the organization. You don't have tohave extra budget or time or people allocated to do this work. You confined 15 minutes to just dig through it and try to validate what's in front of you. That's all it takes. If nothing else, it may make some of the holes in your current requirements list obvious and gives you a leg to stand on to go back and say, Look, there's only so much we can do in this next sprint and I think the history things have toe weight and here's why. Okay allows you to make your case. So I hope you see the value in this, and I hope that you put it to use and whatever you're working on now or whatever you work on in the future 21. Takeaways: Things to Remember: So at this point, I think congratulations are in order. You've absorbed an awful lot of information. Ah, and you have actually done the work of generating the foundation of solid UX focused requirements. I hope that you've gotten an idea why it's important to approach traditional requirements from this perspective. And as a final refresher, I want to take you through the things that I absolutely want you to remember. If you forget some of the details, you know, as you have some distance from this course, that's OK, but these are the things the core axioms that I really want you to take with you as you go back out into the world and you go back to work first. Requirements absolutely cannot be gathered right. There's no requirements tree out back. We're not just wandering out to pick things that already exists. What's really happening is that we're generating requirements, and in most cases we are negotiating because not everything that is suggested is possible. Not only is it not possible, it's also often not feasible, and in some cases it's simply not the right solution. To begin with, when a need is grossly undefined, it has no business being a requirement, especially when it's not really in need in the first place. Remember how we talked about the fact that at the beginning of any project, no matter what it is, you don't know what you don't know? You have to hold firm to the idea that there are no hard known answers at this point and that everyone's job is to ask questions. Remember that you can't generate consensus on a document that no one can understand or is willing to read. For that matter, every single thing that you commit to paper, to email to a white board, even out loud when you are speaking, you have to be cognizant of the fact that not everybody is operating with the same level of understanding that you have, and you have to do it in a way where it's easy to understand for people who are new and unfamiliar, you also in particular have to remember that a significant portion of the clients and or stakeholders that you will work with are not technical people, as such a great deal of this is foreign to them, and in some cases it makes them nervous. It is your job to make sure that everyone walks away from the table with a very clear understanding of what's going on. I especially want you to remember that when it comes to focus groups and surveys that they fulfill the psychological needs of sellers instead of the psychological needs of users. These are old traditional methods and tools. They've been around for quite a while. But I have to tell you, they really do not serve your purposes. They provide some baseline level of understanding. But in most cases, they're false clues. Okay, They lead you down paths that are usually further than they should be from what really needs to happen. Remember the motivation here and remember who is really benefiting from that activity. Your software is only as good as the people who use it. Remember that this is a big one. If nobody cares about a feature, it doesn't exist. Okay, just because you've rolled out all these amazing things does not mean that anyone cares about it. It's a reminder to focus on the things that matter most and be ruthless about jettisoning everything that doesn't If you can't draw a straight line between a feature or function anything that winds up on the screen. You can't draw a straight line between that and a user need, or that in a business goal or that and a specific obstacle that the user or the company or somebody is dealing with its not worth doing. If it doesn't matter to anyone, it's not worth doing. I cannot obviously repeat that enough. You never want to write requirements until you know what people really need. Anything else is premature. Getting it wrong is very expensive and quite often equally as painful. The traditional way of doing this is that requirements come very, very early in the process before any work has been done. I don't believe in that. I think it's a mistake, and I think again, like some of the things we've discussed, it's It's a set of false clues and their guesses, in my opinion, until you have some sort of prototype that you can really put in front of people that they can concrete Lee understand, interact with in a way that makes sense of them. You really don't know what is appropriate. You don't know what is necessary. You don't necessarily know what people are even going to be willing to use. You have to operate on fact and the ideas behind you know, movements like lean and agile. ITER development and design of any kind is that we want to deal in reality, right? We want proof. We want evidence. We want to put something in front of people that they can actually interact with, and we want to get feedback that's based on that reality. We don't want people speculating. We don't want people guessing how they would use this. We want to actually see them do it and gather the evidence. You should not be committing to requirements list until you've had some cycles of actual prototyping and use. Always remember that the path to meaningful requirements starts with establishing context via personas via use scenarios and via exploring those areas and producing something that tells the story in a meaningful way that illustrates what really needs toe happen based on actual use. Context isn't just everything. In a lot of cases, it's the Onley thing. It's the only thing that matters. If you don't have context, you're working in a vacuum and you are guessing. Remember that in the early stages of a project. The minute you have user data, you're no longer objective, and that makes your persona work a lot less valuable. If you take everything that you've seen and heard as gospel, your perceptions are colored. Okay? It makes it very difficult to be objective when you're walking through the processes of empathy, mapping and situational mapping on and use scenarios that we talked about. If you have a preconceived idea already about what users need, who they are, what their motivations are, um, where they're struggling, what matters most. You're going to go down the path with all those things in mind, and they are going to skew your perceptions of everything that happens. So you want to start persona work before you know anything, take a quick shot at, start sketching stuff out and do not get married to any of those assumptions. And when it comes to empathy and situational mapping, these things should raise more questions than answers. The point is to uncover what you don't know, but absolutely need to remember that when it comes to user experience focused requirements , our job is not to come up with firm, solid answers a big part of the job. Everything that we have done so far together is all about asking questions. It's all about investigating its operating on the idea that we don't know. We don't know, but we're gonna try and find out based on a reasonable degree of observed evidence. So when you walk through some of these exercises and you wind up with even more questions than you started with, understand that that's not Onley normal. It's ideal. Always remember that task completion is not the same as success. Requirements should align with motivations, not tasks. We can line out tactical tasks and activities all day long. We've all done it. We're all good at it. And just by human nature is pretty easy to sort of lion out a laundry list of. Well, do this, then this. Then this. Then this. Then this. And bang, you gotta workflow. You have to remember that what you were trying to account for are the reasons the person is undertaking that workflow in the first place. What are they trying to accomplish, and what does the business or organization need them to accomplish? You must always be asking this question. What is success to the project? To the product, to the users and to the business