 If you have any questions at any points, just feel free to stop. So the next slide is the agenda slide. And what we're going to talk about today quickly is what is user experience? Why is it important? Who does it? What's the process? What's produced? And how you can help? And then we'll have time at the end for questions and answers. And if there's any questions along the way, feel free to let me know. So if we go to the next slide, you guys already know a little bit about me, but so this is me. You at least can put a face to the picture or to the name. And I think the first statement on there is important. It says, I like to make things. And I think that's probably why you all do what you do, because you like to make things. So at the end of the day, that's the shared thing that everybody has in common is that we like to make things for other people. And that's an important attribute that we all share, whether we're engineers, whether we're designers, whether we're scientists. It's just the act of making things is very important. So let's go to the next slide, which is what is user experience? We hear a lot about this right now. You hear people talking about user usability, user experience, creative direction, user interface design. It's become kind of a buzzword. But I'd like to broaden the definition a little bit first. So if you go to the next slide, which should show a tablet. So everyone knows that this is a user experience. When we think about usability, user testing, user interface design, technology, we think of something like this. We think of a website, we think of a mobile phone, we think of a tablet. So we know this is a user experience. If you go to the next slide, you're going to see the inside of a car. Actually, it's a Ferrari, so it's a fun car. And the point there is that, believe it or not, this is also a user experience. The way that the designers and the engineers have decided to present information, the way that they've decided to make the seats feel, the way that they've decided to display air conditioning controls and gear shift levers, the way that the pedal works, the way that the car sounds, all of that contributes to user experience. If we go to the next slide, I don't know if any of you have seen this, but this is a new thermostat, which is available. It's very modern, and it displays the current information, and it's very efficient, high efficiency. But the point is, this is also a user experience. An engineer and a designer came up with this idea for how to simplify a thermostat. If we go to the next slide, this is a copier, a photocopier. We've had these for many, many years. And again, somebody had to think about things like what color should the buttons be? Should stop be red? Should start be green? What is the icon that we want to show on there? How does it feel? What's the size of the buttons in relation to one another? So again, what we're seeing here is another example of a user experience. And then if we go to the next slide, should be looking at a roller coaster. And yes, you know that you may not have thought of it as a user experience, but obviously it is. Somebody had to think of what would be fun and entertaining. So in other words, a user experience isn't simply something technical. It's not just a website. It's not just a user interface. It's anything that is created for other people to enjoy, to learn from, to be productive, to experience. So the reason I bring this up is I think it's important at the beginning to shift our perception of what user experience is away from something very narrow to something very broad. And I'm going to explain why in more detail in a moment. So if you go to the next slide, this is actually the definition that you will find for user experience if you go to Wikipedia. User experience is the way a person feels about using a product, system, or service. I won't read the rest of it. You can take a look at the second paragraph. But what you see in there, the highlighted words, are feeling, perception, subjective, feelings and thoughts, dynamic. The point being that user experience is a subjective field. It's not scientific. There are metrics that we can use to measure usability. We can measure how effective something is. We can measure whether people like it or whether they don't like it. But at the end of the day, user experience is something intangible in a way. It's something at a gut level. It's something that you get a sense for. We all know when a user experience is good. We all know when it's bad. So if we go to the next slide, the reason I'm talking to you is to talk about user experience as a professional discipline. So we often use the abbreviation UX, which means user experience. And UX refers both to the discipline or the profession of user experience, as well as to the kind of end product we build to user experience for people. So the term was coined in the 90s by Donald Normman. I don't know if any of you have heard of Jacob Nielsen or Nielsen Norman Group, but they were very early in the computer days talking about usability. They started to talk about users and what that meant, how important it was that software worked for people and that things actually be positive experiences, that there was more to it than just lines of code. When I started using a computer, you made everything into a DOS prompt. Actually, even earlier than that, you coded in basic. That was how you interacted with a computer. And then with the advent of a user interface, we started to think about how do we present information visually to people? How do we present sounds and sites? How does it feel? What does it look like? So when we're talking about user experience as a professional discipline, we're talking about software, web, mobile applications. But again, I encourage you to always remember that it's much broader than that. Every field in some level has a degree of user experience involved in it. And just to give you an example, even humans provide a user experience. If you go into a store and the people who work at the store are very, again, friendly or not helpful, you could say that that's a bad user experience. So when you're designing a retail store should work, you want to think about everything, not just the way clothing is placed, but also the way your staff interacts with people. So we've talked, if we go to the next slide, which says, fact, users are people. We've talked a lot about user so far, but I really want to just, again, broaden it a little bit. Remember that a user is a person. It's not just this anonymous type of entity. It's actually a human being. Your mom is a person. She's a user. We would never think of you never saying, well, my mom's a user. But if you design a website, or you design an application, and your mom can't use it, she's a user. And you've created a bad user experience. So remember that users are human beings. They're people. That's why we're in this business. We're making things to help people. And a great UX professional is never going to forget that. They're always going to try to shift the conversation away from something cold and clinical like the word user and move it towards people. So for example, when I'm talking to clients at Metsoft, I often talk about them. I often talk about customers, people. I try to move it away from students, employees. I try to move it away from the term user experience and try to talk about these people. Because when you start to think about your end user as a person, it suddenly makes it more apparent that you have to do good work for them. So you're not just designing some anonymous sense that you're actually thinking about people who are going to interact with something. So if we go to the next slide, this is how I think about a user experience. So people will try to make it very cold and cold. It really is two things. It's what's the user? Who is that person? And what's the experience that you're creating for them? Is it fun? Is it helpful? Is it productive? Is it efficient? Does it work? So again, I keep this in my mind when I try to think about the fact that we're designing something for human beings. And it's more than just something cold and clinical. So if we go to the next slide, the question becomes, well, why is this important? Why does it matter? And I'm going to talk about it a little bit in terms of a professional context. So if you go to the next slide, you should be looking at a jet airplane. And there are four buttons on the panel here. If you can't read them, I'll read them to you. It says windshield washer, FM radio, ejector seat, and cabin. And I don't know if you've noticed anything wrong with that series of buttons. But I wouldn't put an ejector seat right in between all the rest of those buttons. Because if the person is flying an airplane in an accident with an ejector seat, they're going to go flying out of space. In other words, the way to present information to people can be very, very important. For example, maybe you have a program where you hit delete and it didn't prompt you to say, are you sure you want to put an ejector seat in? And you've lost the file. Some of you of X designers somewhere failed to think about the fact that there's a possibility somebody might hit delete by accident. In other words, what we're talking about, you have to think through all possible situations. You can't take anything casually. Every detail of what you're building is important. And not just from a design perspective, but also from a technology perspective. So an example is a project that we were recently working on where latency was a real issue. In other words, the response time of the website to the user control was very, very slow. And they said, well, that's a technology issue. That's not a user experience issue. And of course it's a user experience issue. If a person sitting there waiting for something to happen, that's a bad user experience. So we couldn't fix that for the time being. So what we did was we let people know. We sent them a message which said, this may take several minutes. Please be patient. It's not good. Don't get me wrong. Nobody likes to see that. But it's better than not telling the user anything. It's better than not telling somebody that they're going to be waiting for a while. Otherwise you know you sit there and you wait, wait, finally you get frustrated and you close the window. So if we go to the next slide, we're talking about why user experience is important. Bad user experience can result in unhappiness. We've already talked about that when you have to wait too long and things don't work for you to leave a file that you didn't want to. It can result in ill will. So if you're a business and your competitor starts to offer a better interface to their bank website, for example, then you offer for your bank website. People are going to get frustrated with you and they're going to leave your business. It can result in mistakes like we were just talking about accidentally deleting a file or inputting the wrong information because the user experience isn't clear. It can result in accidents. An example of that is if you're designing highway signs, if those highway signs are not clear, they don't make sense and people have accidents because of that. Fraud. So we've all heard about identity theft. If you don't design the login system to be secure and also clear, you can open yourself up to fraud, lawsuits. In other words, user experience is much more than just visual design. It has serious implications for your business, for your organization. And so it's important not to forget about that. There was a story recently about an airplane pilot who was taking his plane off in a very, very dense fog and he lost his way and he was actually flying upside down for a short period of time and because of the speed nobody could tell. And so he tried to go up, but in fact what he was doing was going down and he crashed the plane and everybody aboard the plane was killed. And it came down to the fact that the display of information was incorrect. It never let him know that his plane had gone upside down. And so you say, well that seems like an extreme case, but it goes to show that somebody hadn't thought about the fact that the pilot might actually end up, believe it or not, it's entirely possible to fly a passenger airplane upside down. And so they hadn't thought of that and what ended up happening was several dozen people were killed. And I know that's an extreme example, but the point is, and it's something very important and depending on what you're designing, it can have serious implications. A little bit of a lighter example is I was on a project where it was a bang website. It actually was a stock website where people could buy and sell stocks and somebody very accidentally traded $10,000 of stock without knowing that they had done it because it wasn't clear to them what they were doing. It didn't make sense. The user interface didn't make sense. And they traded $10,000 that they didn't want to trade. I mean, you can imagine how upset they were when that happened. And it was all because somebody hadn't designed a user interface to be clear. It didn't make sense to the user. So if we go to the next slide, you should see a bunch of dots on the screen. And on the left side, this is not meant to be a laundry list, but these are some of the examples of things that make a bad user experience. And on the right side are some things that tend to make a good experience. So on the left side, we have things like scary, buggy, rigid, meaning it doesn't adapt to me as a user, unattractive, slow, inaccurate, complicated, hard, dumb, meaning it doesn't learn. So a system that learns is actually better than when it doesn't learn, inflexible. On the good experience side, we have efficient, easy, accurate, smart, fun, adaptive, fast, reassuring, responsive, delightful, beautiful. A couple of those might seem surprising to you. So for example, beautiful and delightful. But if you think about it, if a car doesn't look attractive or if a banking website doesn't look like professional and it doesn't look like something you wanna do business with, you're less likely to have a positive experience. We've done tests where we use two examples of the same interface, one which looks very attractive and one which looks different. All the features and functions are the same and people report having a better user experience when the website is more attractive. All things being equal, aesthetics are important and that's where visual design comes in. So are there any questions so far? So we'll go to the next slide which says who does UX? And so I know that I've been bouncing around and talking about how UX is very broad, but for a minute I just wanna talk about the narrow context of a user experience team. So for example, some of you may be working or may wanna work in a company that builds websites or software or mobile applications or equipment. So when we talk about that, there's actually usually a user experience team who does that kind of work. And if we go to the next slide, you're gonna see some of the people who are involved in that. There's a UX lead, that's kind of what I do. That's the person who's in charge of making sure that the user experience meets all of the defined objectives, is usable, attractive. So that person is kind of the person who's most responsible for making sure that the user experience works. That can also be a creative director in some contexts. It can also be a lead interface designer, but we're just calling it a UX lead or UX director. The next is the content strategist. That's somebody who tries to make sure that they know all of the words, all of the copy, all of the information that needs to be presented to the user. An information architect is somebody who will be designing the way that the experience works. So they'll be thinking about user flows, they'll be thinking about user interactions, they'll be thinking about features and functions that the experience needs to provide and how those things should work. And they're not just thinking about the right way things are gonna work, they also have to think about what happens when things go wrong. We have a copywriter, that's somebody who's actually writing the copy, writing the words, that's somebody who's experienced in writing copy for that specific medium. You have a UI designer, sometimes called a graphic designer, that's somebody who's in charge for the way that the end product looks and feels. And then you have a UI developer and that can be a coder, that can be an HTML implementer, it might be a flash programmer, it might be an interface developer, but that's the person who takes all of the design and information architecture and actually makes it work and often ties that into any kind of back end system like a database or any kind of content management system. So, if we go to the next slide, I'm gonna keep parking on this and you'll hear me say it over and over again. Ensuring a positive user experience is everyone's responsibility. So you have your user experience team, but one of the things that I always talk about here at Netsoft is that everyone should be thinking about the user experience, it's not just the people who have that title. And I've actually found that engineers, business analysts, project managers have great ideas. And again, because they are also users, they're also people who have an insight into what works and what doesn't work. I tend to listen to everybody. People have great ideas. I've designed things that I thought worked really well and I've had a project manager say, you know, what if it did this and that's really helpful to me. I've seen engineers who have incredibly great ideas about how to make something more pleasant, more efficient, more usable. So everyone on the project team should really consider it their responsibility. You know, if you're a developer and you just think about code, you know, there's a couple of things to think about. You know, it's not just what are you building, but also what is the end result of this code, how fast is it, is it reliable, is it responsive. But then also to look at the user interface and look at things that other people are developing and how to say it now. You want to be as collaborative as possible. So we're going to talk about the process if you go to the next slide. You know, I didn't want to show every process here because each project, each type of project requires its own process. I mean, developing software is different than developing a website. But we're going to look at kind of a typical process and we're going to look at it from the UX team perspective. We're not necessarily going to be looking at all the things that happen on the back end or all the things that happen in project management. We're mainly going to be looking at what the UX team is involved in. So if you go to the next slide, you know, you'll often hear people refer to UX as a UI design. Some companies, it's not just people, it's companies will actually say, hey, oh, our UX team. And they're simply referring to the designers, the people who create the interface. And, you know, that's not what we're talking about. We're talking about the whole UX team. So if you go to the next slide, you should be looking at a little funnel here. And in that funnel are three things. This is for a typical client project. You're working in a consulting firm or you're working for a company who makes something like software or websites. And the three main inputs that I think go into a user experience are business requirements. In other words, what are we trying to achieve? What is the goal of this? Is it, you know, and you usually have multiple goals, but so what is the business driver behind this? Or drivers, why are we trying to do this? The technical constraints, meaning what do we have to think about? What's the platform? What's the coding language? What's the timeframe? What's the technological expertise? You know, so these things are important. And then user considerations, meaning what do people, the actual end users of this thing, what are they hoping to get out of it? So, you know, at a very high level, just to make it oversimplified, if this was Amazon.com, you know, the technical constraints would be, it's a website and a mobile application and so there's certain programming languages and things that they have that they can use. There's business requirements, which are pretty obvious. We need to sell as many products as we can about frustrated users during the experience. And then there's user considerations, which is how do we get people to buy things? What are they looking to buy? How do they feel about their wish list? How do they feel about recommendations? You know, how do they want to rate products? So, or do they want to rate products? So, all three of those things come together and they really determine the end user experience. And what you're seeing here is that there's many, many inputs. There's many things to consider when you figure out what the end user experience is. You're not going to put something on there that doesn't satisfy a business requirement, it doesn't make sense from a user perspective and it can't be built from a technical perspective. So, if we go to the next slide, this is kind of a typical user experience process. And now I'm talking about the UX team here. So, the first thing I always want to do, I want to understand the users. Who are they? What are they trying to accomplish? What are their goals? What are their aspirations? What are their limitations? If I'm designing a major, much older audience, for example, I need to understand their technical capabilities. I need to understand what type of device they're going to be using. I need to understand what time of day they're going to be accessing. Understand what I should be building. We would develop our content, meaning we would try to figure out all the information and features that the product under service needs to have included in it. We would organize that. We'd come up with a way to organize it. How should it be presented to the user? We would then design the interaction. So, in other words, how does somebody get to a specific bit of content or a feature? And then as we're getting towards the end, we would design the interface. So, what is the actual thing that the person sees? How does it look? How does it respond? How does it behave? And then I put this last slide on here because this is very important. Test, fix, and repeat. You know, a user experience process doesn't end once you build the thing. You know, you have to then go out and say, does it work? What's not working? How do we fix those things? How do we move forward? And that's an iterative process that goes on and on and on and on. As long as your product is out there, you should be testing it, fixing it, and learning from it, you know, because things change all the time. So, if we go to the next slide, we're gonna talk a little bit about what's produced. So, what are the kinds of things that a user experience team actually makes? And if you go to the next slide, you're gonna see the same steps that I talked about earlier. They're phrased a little bit differently. Research, content, information architecture, UI design, usability testing, and implementation. So, some of the things that you're gonna see are user interviews. We're gonna go out, in the research phase, we're gonna go out, we're gonna talk to users. We're gonna try to talk to them where they're actually gonna be using our product as service, not necessarily in a lab or in a focus group room. We're gonna look at what the competition is doing in a competitor audit, so we make sure we're at least matching what they're doing if not feeding it. We're gonna do best practices. So, in other words, even outside of what the competition is doing, what's the best in the industry? So, for example, if I'm designing an insurance website and there's a checkout process where I'm buying my insurance, I don't wanna just look at the checkout process from insurance websites. I wanna look at the checkout process from all great experiences, whether it's Amazon.com or, you know, someplace else that has a really good technical process, I wanna learn from that. A technology audit, I wanna know what are the constraints from a technology perspective, what platform, what programming language, what's the content management system, because that's gonna help me define what I can build a brand audit. So, what's the brand? For example, we just did a project for Edna International. They're a baby international insurance company. Their brand is all about being a concierge, being a helping hand. So, we had to make sure that whatever we built, really supported that brand objective. One of their competitors takes a very different approach. They look at it as kind of a service orientation. So, that website that they designed doesn't have as much hand holding. It's not as guided. It's much more free form. We're gonna do user personas, which is we're gonna try to understand who the people are and actually create a visualization of that that we're then gonna measure all of our work against. And the end result, there's a UX brief. And that's, when I say brief, that's like a document that outlines all of these research steps and acts as a Bible, if you will, or a guiding document for the rest of the work. When we get into content, we're gonna develop a content strategy for how to produce the information and then we're gonna write the copy. Information architecture is often what many people think of as UX in the profession, but actually UX is broader than that. But information architecture is things like use cases. In other words, how are people gonna get through the system? Functional requirements and specs. That's often a shared document between the technology team and the business team and the user experience team. Site maps, user flows and wire frames. We're gonna take a look at a couple of these in a moment. When we start to get into UI design, we're gonna create a visual vocabulary. What does this look like? What are the colors? What type basis? What are the buttons look like? What does photography look like? We're gonna design the face. We're gonna build a prototype oftentimes for testing so it might be partly functional prototype so that we can go out and test on it and learn and see what needs to be revised. And then we'll probably create UI guidelines so that teams that are working on it down the road understand how they should be doing things like buttons and forms, how they should be presenting information. We're gonna do usability testing to make sure that what we're building actually works that people know how to use it. And then we're gonna actually go into implementation where we do the front end or presentation layer implementation. We're gonna make revisions and fixes based on what we learned and we're gonna document as much as possible what we're doing. So are there any questions on this? Okay, so I'm gonna take you through, if we go to the next slide, I'm gonna take you through a recent project that we did very quickly. So we're gonna look at a few artifacts. These are not all of the artifacts but these are a few things that were produced. So this was for an app that we just recently launched to help people eat healthier, to help them make healthier eating decisions for one of our clients. It's an iPhone app and we're actually gonna be building an Android version soon. So this is the user flow and it looks like a schematic or a wiring diagram but it basically shows how the user will travel through the different pieces or screens in this application and it basically is showing how a person will get to different types of information, how they can go to something and back from something. And this is a very simple user flow but I thought it would be better to do something simple so that you could actually read it. If we go to the next screen, we're gonna look at wireframes. So a wireframe is like a, it's like a schematic version of the user interface. It's not designed, it's just usually black and white. These can be low fidelity which means they can be done in paper sketchy form. Literally I've done wireframes that are just paper sketches or they can be more resolved and the more resolved versions allow for testing so you can actually take something that's not designed but which is dysfunctional and put it in front of users to see how they actually interact with it and then you can learn and make revisions. And if we go to the next screen, we're gonna see what those same wireframe screens look like when they were finally designed. And so this is where we were talking about UI design. This is where a designer has actually taken the schematic version of the wireframe and turned them into something that's hopefully more pleasant and approachable and more in line with the brand and more in line with what we're trying to convey to the user on a more emotional level. And then if we go to the last, to the next screen, we see what the final product looks like and this is something you can download now actually. So if we go to the next slide. So I was just saying, that kind of takes you at a high level from user flow through wireframes, through UI design and through the final limerable. These are some of the artifacts that were produced in a user experience project for like a mobile application. So if we go to the next slide which says what is your role, you've heard me say this before. We go to the next slide. This is something that usually surprises people but I've said this in the beginning and I'll say it again. You are a user experience professional even though I have the title of UX director. I like to think that everybody within the firm that I work for is helping to build a user experience. So they should all be thinking about how we can actually create something that meets all of our objectives. But most importantly that everybody is thinking not just about the job, it's immediately in front of them. Whether it's coding something or designing something or writing something, but always thinking at the end of the day whatever I'm working on is going to be consumed or interacted with or used by human beings. And that's, if you hear somebody start to talk about user experience and they're not talking about that, then I wouldn't trust them. Everybody has to be thinking about this whether you're an engineer or software developer or a solutions architect. You want to be thinking about what is the end result of what I'm building, how will people who are using it interact with it? And so if we go to the last slide, I tried to go quickly because I know we were running short on time. I just wanted to open it up to see if there are any questions or any comments or anything that people might have. Depending on what aspect of user experience you're interested in, obviously you want to be an avid user yourself. So if you want to build websites, the first thing to do is visit as many websites as you can and try to learn what works for you and what doesn't work. So that's obviously step number one. Think of it this way. If you wanted to be a novelist, you wouldn't want to read as many books as you possibly can to understand what works. But that said, user experience is a very young profession. Typically if you do go to school, you're going to study something like graphic design or if you are more interested in the technical side of it, you might study human-computer interaction, which is called HCI. You might also study the technical side of things like HTML development or programming, but those are all tools and skills that lead into something else. I do know that if you go to LinkedIn, for example, there are actual user experience groups that you can join and people do links to blogs, links to usability websites and user experience websites. So there's one called UX Professionals. There's the UX Design Group. So you want to do as much as you can in terms of research online, learn as much as you can by reading blogs and websites. I wouldn't say that there's any one specific book. Actually, you know what? I'll take that back. One book that I like in particular is called Don't Make Me Think by Stephen Krug. Okay, are you... The book really kind of goes over the things that I've gone over here, but it talks about it in terms of building a website or an application. And if you think about the title, Don't Make Me Think, what he's saying is you want to create an experience that doesn't frustrate users, doesn't make them have to worry about what they're doing. It's an easy to read book and it's fun. And I found it to be very helpful in helping people understand kind of the basics of usability and user experience. So the user experience is not scientific thought, but do you think that it will not harm the creativity because using all the time of the user's army create and look over and over again, you will not get something extraordinary or something original that it seems you will get all the time in the same things? Incredibly good question. Thank you for asking. So Henry Ford was the guy who invented the Model T, one of the first cars. And he famously said, if you ask people what they want, they'll tell you that they want faster horses. They won't tell you that they want an auto. People think about what they know. And if you are a creative person, you have to be thinking one step ahead of your potential users. You can't just be thinking about meeting what they want. So if you want to be an innovator, if you want to be on the cutting edge, it's not just about trying to do what users want you to do. You have to be anticipating what the next thing is. You have to be creative. You have to be imaginative. Here's the thing. Most of us are going to end up hopefully doing this for a living. So if you build something that people don't want or that people find confusing or people find frustrating, then you're not. I agree with you that the original idea of the initial concept should be as creative as you can possibly make it. At the end of the day, if you hope to make a living doing this, then you have to listen to what users are saying. So you can't just design in a vacuum. Now, to your question, you have to be very, very careful though because I think you're absolutely right. If all you're doing is trying to listen to people and trying to figure out the next step, then you could get locked into doing work which is very boring. You could get locked into doing work which isn't helping people. So I definitely think you're right. It's a balancing act. And I would just add one last thing, which is this. The more you do this for a living or the more you think about it, yeah, I can oftentimes anticipate what users are going to think about something without having to talk to them. So we do a lot of what we call it. Which is I'll take something that I've designed and I'll share it with people that I work with and I'll say, does this make sense to you? So I don't want to be informed when users are testing on something but I might just ask somebody, hey, what do you think about this? How do you, does it make sense? Do you know where to go to find x, y, or z? What are you looking for? But, question. Question. How many? About the question. My question is about high-level project oriented languages, for instance, I just started to learn, let you and it actually has all the components. And one person, in fact, is controlling various things, starting with the functionality and with the user interface. And the one person is a team, in fact. Is there any kind of recommendation or ideas or some references that these kind of developers may use? Welcome. That's interesting. So what you're saying is that there's one person who's probably a developer who's building the entire thing from start to finish, including user experience, the user interface. Yes. Have this particular domain expertise. If you're not working with somebody who has a bad capability, for example, you obviously run the risk of making something that's not usable. I mean, hey, that is gonna be bad but it may not be as good as it could be. So I don't have a resource because I'm not, you know, there's tons of ways to learn about usability research. What I would recommend is if you're building something like that, you know, either who hasn't experienced or backgrounded this, look at it with you, you know, at certain points or launch it. So, for example, if you're designing an application, it's gonna be used by a certain type of person before you ever launch it. Normally, I would highly, highly recommend that you take whatever it is in whatever form you can and share it with them and get their feedback and ask for honest feedback. Ask them to find, to tell you where it works and where it doesn't work, what they found confusing. And you wanna do that in terms of a task orientation. So, if your product that you're building has to allow you wanna say, show me how you would do this using my product, you wanna watch them do it, you don't wanna guide them and you wanna note every place that they make a mistake and take a note of that and figure out how you can make it better so they don't make the mistake the next time. I'm like a one-stop resource for them but my recommendation again would be if you can partner with somebody who has expertise and then also share it with your target audience before you actually go live.