It is my pleasure to introduce Melanie Lindahl of the University of Texas at Austin. She's going to be talking about UX research and testing on that ever minimal EDU budget. Melanie is a creative UX professional with over two decades of experience in higher ed. She has become known for her thoughtful, user-centered approach and brings in inventive techniques for gathering user input. Melanie, thank you and welcome.
Thank you very much. So I'm going to share my screen now-- hopefully, soon. And I will double-check-- are you seeing-- are you seeing my-- what are you seeing right now? Are you seeing my research notes? Or are you seeing my screen?
I am seeing your research notes.
OK. So we don't want that. So how about that?
Now I'm saying your presentation.
The screen? OK, great. That just means that things are flip-flopped now. So now I have to figure that out. OK. I'm going to scoot myself over here a little bit, but rearrange my space. Oops, don't go that far yet. So how's everyone doing so far? Hopefully things are good. You're learning a lot.
OK. So as Ron said-- thank you for that introduction. I'm Melanie. I work at the School of Law here at the University of Texas at Austin. Today, I am going to show you some ways that I do UX on a small budget-- sometimes no budge-- hopefully that you can go apply to your projects as you need them. And also at the end, we're going to talk about ways to illustrate to your leadership or your decision makers that spending even just a tiny bit on UX work ends up actually being cheaper in the long run.
So to get us going here, just a tiny bit about me. I've worked in higher ed for a long time. I have my Nielsen Norman Group UX certification-- very good content from Nielsen Norman Group. If you're ever needing an answer, that's probably the first place I would go.
I have a degree in art, masters in basically web development. But that master's program really focused on usability, and so that's where that strong enthusiasm came from. And so for many years now, I have been finding cheap ways to get feedback from my users for the projects that we need it for. And yeah, so I'm going to give you some examples of what I've been doing today to help my team out.
Now, to get us going, our agenda-- we're going to go through some just general project phases that people have in a project and some of the more common UX activities that I do during each project phase. How much time I spend, how much money I spend. And then at the end, we're going to do a cost comparison-- like I said, between doing your UX versus no UX.
But first, please pay attention to an important announcement to just please do something. Please do something. A little UX is better than none. Some is better than none. We know that user experience work helps users. Of course it does. We know that it can also help us achieve our business goals, absolutely.
But I know, even doing all this work for so long-- I can still overlook that the UX work I do doesn't just allow me and my team, but more importantly, it allows my leadership to make decisions that are rooted in facts and data. For example, when redesigning our website a couple of years ago, we were working on our main menu. And you know how you always have a prospective student main menu item? And it's like, what do we call this thing?
And so leadership wanted to go with Admissions because that's what we've always done. And they're like, this is what people are coming here for is to learn about admissions. OK, I hear you. But I've already done so much UX work on this project-- journey mapping, personas, all kinds of stuff, knowing what our business goals are. And I really thought that the label Future Students was going to have more meaning for our applicants and our admitted students.
But leadership, they weren't quite convinced, and that's OK. They needed some data. So I did some A/B testing with applicants and admitted students. They were waiting in our atrium for like 15, 20 minutes for this admission tour to start. Great. They're just sitting there. I'm going to go test stuff with them.
So I gave them a task to see how the main menu performed for them, this A/B testing. And the testing did show that prospective students preferred that label of Future Students in the main menu instead of Admissions, because Future Students brought them into that mindset of already having been admitted and figuring out, what would it be like to be a student there? And the admitted students were like, yeah, I'm already admitted. I don't need admissions anymore. I want to know what it's going to be like there so I can make my decision on where I'm going to go.
So we went back to leadership. And I said, hey, the testing data shows that the website performed better for these people with this label. We don't want to go with Admissions because that was our assumptions of what has always been. And we want to stay away from assumptions when we do this kind of work.
OK. We're going to kick it off with that early phase of a project. I'm going to tell you some things that I commonly do. And just to note that-- so what we're going to talk about today is a handful of good things you can do. But it's not everything-- not even scratching the surface of all the good ways to get feedback and research and testing.
And you can also do these things during different project phases. This is just going to guide the presentation today. So to start off, a big one-- it's hyper important. It's surveys. These are one of the easiest things you can do to understand your users more.
They're easy to set up. They're easy to administer. They're easy to digest those results. And you get to ask for future volunteers to test your stuff. So the last question in my surveys is normally, hey, would you like to keep chatting with us about this topic or maybe even testing it when we build it later? Cool. Put in your email, and I will be in touch.
So now I already have actual users who have volunteered to engage with me during future project phases. So I tend to usually do a survey at the beginning of a project because I want to know what the most common tasks our users are doing. This is called a top task survey or a top task analysis, and it is invaluable to me. I will use this data throughout the whole project. It really jump starts stuff.
So what this does is it tells me what the most common user tasks are. But more importantly, what it's really telling me is, what does our product need to do for people? What are they going to be coming here to do? So the basic idea is that you give users a lot of choices, and they pick their top five. That's it.
You can also use a top task survey like this to understand what the future state of your product might be like, instead of how it's currently being used. For example-- so we needed to overhaul our registration system, online registration. So our law school has our own system. The main campus one here at UT just doesn't have quite what this quirky law school rules require, so we build and maintain our own. OK, we had to rebuild it.
So I sent a survey to current students saying, hey, I know you got registration pain points because we all do-- even stuff. So what are yours? What is your ideal workflow? But also what features would you like to have in a new registration system? And you like to put top task survey results into a graph like this because you can pretty easily start to see a pattern, right?
There's usually a chunk at the top. A lot of people chose that. Pay attention to those things. Let's see if we can get people those things. And then there's a section in the middle. Still a lot of people chose this stuff. Pay attention. And then there's stuff that definitely falls off.
And then there's things that it's 0. They got no votes. I didn't even include it on this chart. So what these results, what this graph is going to tell me is what the most popular tasks are-- or in this case, future features for registration system. And now I can begin thinking through, OK, how would people complete those tasks? Or how would they even use a feature like that?
So to set up a successful top task survey, I do the following. You get a lot of options for them to choose from, like 30, 40. Honestly, the more the better. But I gotta tell you, users don't read through a long list of choices. They're not going to read them all.
So why are we going to put them all on there? Because it's important, and we are going to randomize that list so that each user sees a different order for each of those things. This ensures the ones at the top aren't the only ones taken up. And then you just make sure they can't select more than 5, and that's it. It's very cool. It gives you a lot of data.
The good news is there is no additional money, just your time to do this. I don't have to ask accounting for any money. So this will take a little bit of time, and I get a lot of good data. And because there's no additional purchases required, this is going to get-- here's our cost meter for today. It's going to get one duck bill.
Do you see that guy down there in the corner? So you know how restaurants when you Google restaurants, and it has the dollar signs for how expensive that place is going to cost you? This is our cost meter for today. Our duck bills, our duck dollar signs. So this one's cheap-- one duck bill.
All right. Another way that I like to get feedback at the beginning of a project is really just by talking with users. It's quick, it's informal. You can talk to a lot of users in a short amount of time. You ask them a couple of questions.
Keep it minimal. You can get through 15, 20 people in an hour. That's a lot of really good feedback that you're going to get. It's a great way to learn about pain points that they are having or even a recent experience that they had that you're trying to understand.
So, for example, we had this old-- I think we called it our status page. It's where applicants would go to see, did I get admitted to law school? Did I get waitlisted? My application isn't even complete. Do I have things missing? They used to look at this all the time, and we had to rebuild it because it was super old code.
So I chatted with some first-year law students at the beginning of their first semester because they just came off of that admission experience. And the feedback about the page was actually fine. But then one student said one comment, and it changed the entire projection for the project.
So he said-- oh, before I tell you what he said. So we register our first-year law students for their fall set of classes because it's a predefined set of classes. So we do the registration for them-- cool. So he said, hey, I love seeing my class schedule. Awesome. I love seeing the professors and definitely the room numbers and where I had to go.
But then the first week of class, I couldn't access this anymore. I don't know what happened. And I'm thinking-- I'm like, oh my God. What is he talking about? And I realized he's right.
He's looking at his admitted student status page. His status page. He doesn't have admitted status anymore. He's matriculated. He has current status now. He can't access this, and he doesn't know where to go to find his current student class schedule. Holy crap. How have we missed this this whole time? Because we didn't ask anybody? That's terrible.
So we ended up-- on that one piece of feedback, blew our minds. And we ended up building this new dashboard system that followed a person from the time they applied to when they're admitted to then when they become a current student and they have a class schedule and then through graduation-- one place to go for whatever they need. So chatting is a really wonderful way to get a feel for who your users are-- what they're going through, what they're needing.
So quick chat-- so I have this little method for doing quick chats. So I set up a table in our busy atrium at the law school, and I choose the morning on purpose. And I wait for a couple of classes to get out, and I open up a couple of boxes of donuts, and I literally just bait students into talking to me. I have a sign. And it's like, hey, do you want a donut? You just have to chat with me for a hot second.
And sometimes they don't even take the donut. They're just like oh, this is just fun. I love this stuff. And I'm like, favorite student ever. So I also am known for of ambushing people, but in a nice and polite and friendly way.
Oh, hey. Welcome new students to orientation. You're waiting to get into the auditorium. Can I ask you about your admission experience? Is that stressful? What do you feel when you do that? I may not even have a project that I'm working on, but that feedback is valuable. I will tuck that away. Get that feedback anywhere you can.
So the good news-- quick chats are another minimal cost activity. Take a little time to write up the questions that I want to ask, a little time to do the chatting. Review what I found-- what did I learn? How do we move forward with this information?
But I do buy an incentive. Bait-- I just call it straight-up bait. So I do buy donuts. And so this is going to go to two duck bills. So I've already spent $15, and now we're already up into the next tier. So my cost meter is very small and snug, but it is higher. And we don't have much ever, do we?
Now we have some research and we have some data to go off of. We're moving into our ideation phase. How are we going to solve these pain points that these people are having? How are we going to get these users to complete those tasks that they told us about?
So after we get some basic feedback, I got those top tasks. Then I start to dive into specific topics with individual users to understand their needs more, and I even start to begin brainstorming solutions with them. It can be a lot of fun. So during an interview, I learned about their processes. I really dig into those pain points that they have. You really have to understand the problem if you're going to solve it for them.
Oh, I've got some great examples. So I'm going to go back to that registration project that we did. During the interviews, we found out beautiful information. And we ended up coming up with this-- a lot of cool applications came from those interviews. So I'm going to stick with this project for a bit.
We were interviewing current students, finding out how do they prepare for registration. So we found out just to review-- you know when people are reviewing class details over and over and over to figure out which classes they even want to register for? So we found out everyone was doing one of three things, maybe more.
They were leaving browser tabs open for weeks. And I'm not talking like a cute, little 10 browser tabs. I'm talking 30 to 50-something browser tabs. You can't read-- how do you know which tab is which? You can't tell what the page title is with that small-- that doesn't work. That would blow my head up.
Or they were copying and pasting all of the class details-- and that's a lot of classes-- into a separate document to review later. And some of them were even making detailed handwritten notes about every class they were interested in. This was taking them ungodly amounts of time and effort. Please spend that effort somewhere else or go to bed. Whatever it is, I want to give you some time back, please.
Can we simplify this for them? Yeah, we have a homegrown class schedule. Of course, we can whatever we want. We made a class favoriting system for students. They log in, they click that little heart, and boom-- it goes to their favorites. They can do whatever they want here. They can reorder them. They can write notes about them, whatever they want.
It's theirs. They can do what they want. They don't even have to use it, I don't care. And a bonus-- when we ended up building that registration system, they can just pop in their favorites into their request for registration. Boom, boom, boom. Submit it, done. Beautiful, easy-- way easier than what we had before.
And so another example related, same project. So each student was creating several elaborate-- just so many Google calendars. Or they were doctoring these crazy Excel templates just to see. You know that visual hourly grid for the week that we have to visualize our schedule to see open pockets during the day? They spend so much time on this, just so much time.
Let's help them out. We made our own visual schedule planner because of this. They can make multiple weekly grids. They can rename them. Guess what? They just have to click that little red heart and they can add their favorites here. It just automatically pops it in, done.
And guess what? When they're registering, of course they can literally import any of these schedules that they planned and pop it in their registration and submit it, done. It is this beautiful ecosystem of registration tools that we made because we spent the time to learn their behaviors. What was working and what wasn't working? Their pain points-- what were super frustrating for them? And what their ideal workflow would be.
So I do Zoom interviews now since 2020. It's so much nicer. It's just so much easier for everyone's scheduling. We also do compensate users' time with a small gift card for current students. Prospective students, it's a lot harder because there's more rules. But I've also used leftover hats and I've provided people lunch. You can do lots of that. People always sign up for food. Food is a huge hit with college students, so go with it if you're not sure. Just go with food.
OK, costs. Yeah, so a few hours of your time to do the interview. You do have to do the interviewing, so it does take a little more time. I normally just interview five or six people. It's not that many. Because again, you're just having this open dialogue and working through some ideas, trying to understand their problems more to give them what they need. Then a little bit of time to review what you learned, come up with the recommendations for the project. So this activity, I'm going to give it two duck bills due to that user compensation and a little bit more added employee time.
OK, I wanted to break from my structure a little bit to take a moment just to talk about offering compensation or how to entice users to come talk to you when you have no money to spend. I'm sure we are going to be in this boat at some point. Oh, by the way, this is the only image I created with Gemini.
I am super literal with my animal photos, and I love it. It cracks me up. I was like, Gemini, make me a realistic photograph from birds' eye view, shark under a boat, blah, blah. It even made the person a fisherman. I didn't even ask for that. It's perfect. I got my bait in there-- excellent. Good job, Gemini.
OK, so first off, make sure you're allowed to use whatever incentive you're using. There are rules, and I have learned every college and state is different, especially with prospective students. So just be careful. Do your due diligence, get it approved.
Oh my gosh. Who else has gobs of Halloween candy left over? It's insane. Why are we buying this much candy? So bring that to work, use it at your quick chat table, and encourage the students to come for you. I'm telling you, food works.
Leftover swag is huge. When I used to work in athletics, we always had some fanfare items to give away, so call your athletics department. See if they will donate a few things. Ours are lovely. They would probably give me the moon if I asked for it. Maybe your department even has leftover shirts from some event.
People love stuff. They just love free stuff, right? One time we had bandannas. I don't know why. Why do we have-- we have bandannas, cool. Somebody said I could use it. Cool. Here, use these bandannas. Now everybody is signing-- we have too many people trying to sign up now.
The incentives work. Just get creative. Oh, when I was writing out this slide, I was like, you know what? I'm going to try something. I'm going to try a raffle to see if we could do a profile on the website for a student. They could win something. So I don't know. Just, again, get creative. That's the whole idea.
OK, back to business here. So ideation, solutions-- we love the brainstorming phase. I get to figure out how to solve people's problems. Heck yeah, I'm here for this. So I do brainstorming with everybody-- just me, users, team members, stakeholders, leadership, anybody. You probably have done a post-up activity, even if you didn't know it.
I like to do post-up activities where we take 5 to 10 minutes and just post as many thoughts and ideas as we can as a group. And then we go through them one by one and we categorize them and we group them. Now that's affinity diagramming. And by doing this as a group, you walk away from this activity with a collective direction, which is really important.
This example is using Miro, M-I-R-O. It's a great free online collaborative tool. We used it a ton over Zoom during our website redesign project because we just dismantled that information architecture, had to build it back up-- really wanted to be thoughtful. But I've also done this with users during interviews, like with card sorting, figuring out their priorities.
This is a great thing. You can really adapt it for whatever you need. OK, so yeah. Post-up activities, affinity diagramming-- it's just all employee time. And really, honestly, it's not much of it. But holy moly, it can really help your group understand your needs more. Whatever it is you're brainstorming, it can really get everyone-- again, that collective direction. So one lonely duck bill. It just doesn't take much to do this one.
Moving into the design phase now. So this is going to be more about iterative testing of designs. Just a moment. I needed that water. Hopefully you will have less design meetings because of this because honestly, ugh, they're the worst.
So let's talk about paper prototypes. This is Johnny Fives Jam. I don't know if you can see. I put my actual paper prototypes in his hands, and I act like he's rolling around getting his input with my paper prototypes. So what I love about these is they are quick and they are easy.
I like to do this when I need to know the general steps that users do to complete a task or how they might find specific content. Just having some basic wireframes, because this isn't artistically amazing. Anyone can do this. And knowing interaction details, like, OK, if they click that button, then a filter panel appears. So I need to have a screen for that. Draw out a piece of paper, got it.
But from this, I'll learn. Oh, they didn't find the Filter button or they didn't even think about filtering at all. So I'm getting that feedback before I've even begun the heavy lifting in the design phase. And something that's cool about this technique is that the user is much more likely to suggest changes to you than if I showed them a refined mock-up that I did on my computer. It looks like a rough draft, and so they have less qualms about giving you feedback.
I carry around a pencil. I'm just like, hey, I just have to redraw it, erase it, and redraw a box. It's going to take me 5 minutes. But if I had a high-res mock-up, I think it's going to take you longer, and I don't want to make you do that work. So stick to that rough draft feel.
So how I go about this-- I do it the same as quick chats. So I find a busy place. Sometimes I'll offer up that incentive, like I'll buy those donuts, get that Halloween candy out, whatever it is you got. But honestly, these mock-ups are mobile. Just walk around and find people.
Hey, you're in line for your coffee getting made. I'm working on this design for this thing. Can you help me do this? People love giving opinions. They can just hold the paper. You just give them the paper, they just hold it. Or they can put it on a table and you give them a task.
Always give them a task-based question. You don't ask people, hey, do you like this? No, no, no, no, no. Hey, can you favorite a class? And see if they touch the paper. You pull up another screen, piece of paper, whatever it would be that happens when they touch whatever they touch on that paper prototype. Did they complete the task? We're going to find out.
It's so much better to know now than when I'm designing it later. Move on. Ask them one, two questions. Move on to the next person. You get through 15 people in an hour. It's cool. Oops. I've got to go through this, right? That's where I was, this is where I am.
OK. So it doesn't take that much time to do this. I usually do about an hour of testing, and I can get plenty of feedback in that hour. If you're walking around finding people, you don't have to buy an incentive. Whatever, it's one duck bill. If I'm having to set up a table and I need to buy donuts, then I'm going to make this two just to be safe here.
All right. So I like to do testing for specific UI elements when I'm not really sure which way to go when I'm designing. So I've tested all kinds of very small things. Do you remember the main menu wording that we tested at the beginning of this presentation? Iconography-- there was one time we had to-- there was one icon. It was strange and irregular. And we were like, are they going to get this? Turns out half the people didn't, so we were glad we tested it.
So if you're not really sure which direction to go when you're designing, maybe it's a layout issue. I had to test the placement of a button one time in a layout. Again, glad I did because a lot of people, they skimmed right over it. So just test that one thing. It won't take you very long.
Give the user a task. You give them a task that's going to lead them to that area or make them interact with the element you're trying to test. See if they can complete it easily without confusion. It shouldn't take them long. So I do this the same as quick chats, same as paper prototyping. I find that hopping place in the building. I will get a table usually for this because I usually will have a Figma prototype. Maybe you have Adobe XD.
Maybe you've done a proof of concept. You've coded up a proof of concept. You got a little demo that you can do that. That would be great. You've already got it. You can do a high-res mock-up if you want. It definitely needs to be a little bit more refined, though. So just give them a task, see how they do. See how the user does. You're going to know fairly quickly if it's working or not.
So this one, you spend a little bit more time creating the thing that you have to test, so it does take a little bit more time. Doing this kind of testing is worth every penny. It's great to know, OK, are the users going to get tripped up by that icon? Or are they going to find that button? Whatever it is, it's great to know that now before you code up the thing and it's all set and you're doing your testing at the end.
So I'm going to give this one two duck bills because-- yeah. Oh, I'm going backwards. Two duck bills because I do buy an incentive, usually, because I have a table set up. The big one is user testing.
Now, this section is going to be about more formal user testing of the whole product. This is called User Acceptance Testing, UAT. And when I say formal, honestly, I'm talking semi-formal here. I'm not doing super structured testing sessions where I'm doing time on task testing, which means I'm seeing how long it takes each user to complete each task. Unless the testing needs that, that's stressful.
I don't want to do that. I'm not setting up video cameras in rooms. Ugh, no. But I am paying very close attention to how I write my script. I stick to that script because I want to be consistent so that my results are accurate.
I pay very close attention to how I write my tasks so that they're not misleading or biased in some way. And I am testing for discoverability, findability, usability. And in case you don't know, there's the standard. If you want to find most of what you need to find before you launch, you just need to test five people. That doesn't seem like a lot, right? But honestly, it's absolutely true. I have found it to be completely true. I usually do six, actually. In case somebody drops off, I want to have a backup.
During this type of testing, usually people are finding straight-up bugs. We find so many bugs. I've tested this thing 500 times. How come this thing didn't come up for me? Yeah, it didn't. That's why we're testing. Content issues, maybe, like something's not quite right with naming. Naming things is hard. Maybe you didn't get it right.
UI issues-- they didn't see that button, probably. I don't know. We're going to test it. Every now and then, maybe a workflow problem. But to be real, our team doesn't have big issues arise during this type of testing because we've been doing good UX work throughout the whole project.
So now we're at the end, and we're getting close to launching, and we have a few small changes we have to fix, but that's really it. We launch, boom. It's marvelous. It's so nice. OK, so I do bigger testing like this now over Zoom, and I'll go over that in a moment.
So when I do any UX work, but definitely during user acceptance testing, I think about, OK, what do I need to walk away with from this testing? What answers do we still need? Could they find that button? Could they complete a task? You always give task-based questions.
Where are you going to get those? Hey, you did a top test survey at the beginning of the project, so you can just go back and get those popular top tasks and create questions. Hey, go do this task, user. Go do this task, and you're going to see if they can do it or not. You're going to learn a lot.
So I am looking into AI now. I wanted to address this because everyone always asks me. I am looking into AI now for doing note taking for me, but honestly, I'm not sure that's going to work because it needs to be a human, because we're noting confusion on the user's part.
Our note-takers are noting confusion. Did they skip over that button when they were supposed to click on it? We're noting that stuff. It's not just what's spoken. So I'm not sure that AI is going to help me much in that regard.
OK, so I do Zoom testing for my product testing now, and I've been doing this since 2020. It has been amazing. I will never go back to in-person testing ever unless the thing we're testing is in person. But honestly, in Zoom, I can easily record the session. Are you joking? I just click a button? Oh my gosh, that's so much easier now.
I can see the user's screen without creepily sitting behind them and to the side and sitting over their shoulder like I used to have to do with in-person testing. My note-takers can pay attention to facial changes instead of staring at their face the whole time. It is so nice. Our testing has gone so much better. We have gotten so much more good feedback because we're testing over Zoom. I love it.
Oh, quick PSA-- Public Service Announcement. So before you test, please tell your users that you're not testing them. They are testing your product. If they can't complete your task, the product is failing them. They are not failing the task. Users actually, surprisingly, sometimes-- even really confident people, they get actually down or stressed when-- they're like, I'm supposed to be able to do this, right? I'm like, maybe not. We're testing the thing. You're just along for the ride. So please just let them know that. It helps. They really do drop their shoulders after they hear that.
OK, so this is definitely the most expensive thing that I do because we offer better compensation for this type of testing. It is important testing. To be honest, we just do $15, $20 gift cards for current students when they test our stuff. It's not that much, right?
Amazon cards are desired more than Starbucks, I have come to find out. OK, cool. This activity does take more time because you're doing that. You're also doing-- I included note-taker time in here just to be real. So because of those two things, this is going to get the whole party of ducks at three duck bills. Huge party, they're living it up.
OK, we're coming to a close here. Now we're going to briefly go over how to show that spending a little bit on user experience is actually cheaper than not doing anything UX-related. So this is a little trick I've gotten from the Nielsen Norman Group, and I've built it out for you-- I really built it out.
Use this concept. Make it your own, but use this concept. So let's say that we do three UX-- we're planning our project. And we're like, you know what? We need to do UX through this whole thing. We're going to do something at the beginning.
Let's do a survey. We want those top tasks. We want that stuff. We're going to do something during the design phase. I just popped in paper prototyping here. And then we're going to do some user acceptance testing after we've built the product.
And I went crazy. I did $25 gift cards, everybody, for five users. So all of these hours and costs that you see listed here, we've already gone over all that. I just cut and paste it here. That's it. Oh, I did add two hours in the testing one on the right because you're going to find bugs. And you've got to fix them, so I added that.
Total employee time to do these three things is 21 hours. That's typically just mostly my time. But there is additional cost because I want to buy people lunch when they test or I want to give them a gift card or I need to buy some donuts to get people to come talk to me. That's the sticking point. I have to go ask my grand-boss or the accounting manager for that money. I have to buy it with something. So people don't always want to give me that money.
So I look up the average UX designer salary for higher ed. Please keep that in mind. And it averaged at $33 an hour. And then adding this up, the total for doing these three activities during our project is $850. Most of that is my time, but I do need to ask for a little bit of money. But maybe it's not going to get approved. Hold on to your butts. I get really loud on the next ones because it drives me crazy.
Now, if you don't do any UX work on a project, this is what I have experienced. You end up with extra requirements meetings to figure out what the heck is this thing that we're building supposed to do? Because you don't know, because we didn't talk to our users. We have our assumptions. We have our business goals, but we don't really know what users need on it.
And then you end up having extra design meetings-- ew-- before you launch, because somebody's got to fill that white space that you carefully placed there. And I don't have that dispensable design from the user feedback that that button has to be in that spot because that's the most important thing that they told us they need to do here. I don't have that. So you end up having meetings about this and arguing about it. And it's gross, and I hate it.
So these meetings cost more because they involve decision makers. Those people get paid more than I do to make those decisions, so this stuff costs more than just my time. Oh, boy. Now we've launched and we didn't test. OK, so now where are all those bugs getting found? In the live environment, on the website, on the registration system-- whatever it is we've built. And now you're spending staff time fielding calls and emails from users who are having issues after you launch.
So this could also be going on for years, potentially. I'm being generous. It's four hours, but whatever. Sake of argument, we're just going to say that. And then you have to have more meetings-- oh, gosh-- after you launch to figure out, OK, what's our priority for fixing this stuff? Who's going to do what? Who's going to write that content? Because nobody can get to where they need to go.
There's user flow issues. But the menu doesn't-- how is this thing not working on phones? Our usability-- oh, we didn't do anything for that. Whoops. Oh, great. So now you have to have these meetings. And guess what? They cost more again, because people have to make those decisions, and they get paid more than I do.
All right. Then you have to actually do the work to fix them-- to fix the bugs, to fix the thing that doesn't work, the things that the users found. And I am being abundantly generous that this is only going to take four hours of your time to fix. But we're just pretending here that this is the peachiest dream we could encounter.
So let's put this together. Not doing any UX, you have 35 hours of meetings that involve higher salaries, and then you have more time that people are having to spend fielding calls and fixing issues. Yuck. So let's compare. Doing UX? $850. Remember that nice, lovely low number? Yeah, that's total.
Remember, survey, paper prototyping, product testing, all of that stuff. We're on track-- mostly staff time, but I do need to get $155. That's really the problem here. But then not doing any UX, look at the meeting costs. Over $1,500? So your expenses end up being more than double than just doing some UX work throughout the project.
So if you ever have to justify even spending $50 on buying people lunch or donuts or whatever it is, have this prepped ahead of time. It is cheaper to just do the UX work in the first place. And again, like we talked about, if you can find that free stuff, the swag from athletics, the hats, the Halloween candy-- if you can actually get creative with this stuff, it's just costing you a handful of your hours, of your time.
OK, a little side note, I'm going to end on. I've clearly bought so many donuts for current students. It's a thing I do. And guess what I have found? Current students don't take jelly-filled ones, at least not here in Austin.
So a little user testing on buying donuts? Just stay away from those, and you'll have an empty box of donuts. Thank you so much. I love talking about this stuff, so I'm delighted to be here. Happy to answer any questions.
Thank you, Melanie. That was terrific. Anyone have any questions for Melanie? No, I think you covered everything very well.
Oh, there is one in the webinar chat here. Have you seen attitudes about UX change within your organization, as you have demonstrated how easy it is to do over some of your projects? So yes. When I was working in athletics, I worked there for a while. And this kind of thing was not-- this is a little while back. It just wasn't a thing that they even thought about.
So I had to integrate it slowly because it was like, why would you ask people what they want? I'm like, ah. And so I integrated it slowly with some surveying. And then they started to see, oh, wow. That's very interesting feedback. And then we had to redesign our website.
And I was like, we need to do some focus groups. Let's get some fans in here and see how they need to get to the information to come to an event. This is some of it's about making money, so maybe this could be better if we could make more money, if more people could come and get what they needed. So once they started seeing those successes, my job got so much easier.
Here at the law school, they already knew that UX was good. That was such a dream to come into a place that already valued it. And yeah, once you start having more success after more success-- and I've got to tell you, when the amount of time is saved from answering phone calls and emails, especially in admissions-- the admissions office gets so much stuff. When that starts to go down and they are able to see the fruits of that labor, everyone starts to really encourage the work to be done. Yeah.
We have one more.
OK.
How do we deal with long UI/UX change approval times?
Oh. Who's asking that? I would like a little bit--
It's anonymous.
Long change approval times. So I'm not quite sure if that means it takes a long time to approve things or if it's like a long-term UX goal. So I don't know. But I'll just answer based on approval times. I don't know. So honestly, I stopped asking for permission. I don't know if that helps.
I just do it. So the more that I can show people that user experience work is part of the project and not in addition to the project, then it's not really a question of getting approved. It is just part of the project. It's part of the workflow. It's part of the project timeline. I don't know if that answers the question. I'm not sure I entirely understand the question, though.
Well, we can certainly follow up. I think we're at time. So again, Melanie, thank you so much. Appreciate it.
You're welcome. Have a good lunch, everybody.
Thank you. And for everyone else, we will be taking a lunch break until 12:40. Thank you.