What is a persona & task flow in UX design

So before we get started I want to quickly just outline the brief for this project. This is an actual project from one of my clients. I thought that would be a nice way to explore XD, through an actual project. 

So what we had to do, there's kind of UX research side of things, and we had to build out a client brief, which I'll show you here. And we had to build out the Persona, just like who the target audience is going to be. So let's have a little look here on the screen. Both, what the client sent me as an initial brief, and then what we had to actually move it into, so we had an actual project to work through. All right, so let's check it out here now. 

So first up, like any good creative job you got to kind of get the brief right, especially for UX, because often the client, especially the client's idea with having really run through a lot of UX projects before, so I guess, I'm sure what's been covered, what's not covered, those sorts of things. So a brief is always essential for any project, right? So I figured I'd show you the one that we got. So this is the brief we've got from the client. Basically, it's pretty thin. They've got a website, bringyourownlaptop.com, and they've built this kind of back end for it, for their trainers to use, and they want to just release it to other trainers to potentially use it as a product. So they want a website, they want an app. Very, very kind of basic. 

So what I did is, I had a little look through their details through the analytics for their website. I know that about them, because I've dealt with them before, but basically I went through the UX research project working out who the competitors were, what the product does, its USPs, who their potential users would be, and built out a brief. So this is the thing that I emailed them. Basically just covers the basics of most briefs. Let's just quickly run through it. If you're not interested, you can just skip on, and we'll start making XD stuff, but in this case, project name, description, basically that's what they've said. Just kind of outlining the description. 

Who's it for is quite important. So we built a Persona, I'll show you that in a second, what the Persona actually looks like. But this is what we agreed with the client, who the potential Persona is. Now, the big thing with Personas is that you can guess, and you can have a best guess, but you need to revise potentially who your Persona might be because you might go, "Yes, definitely it's this person," but you need to allow wiggle room, and better spelling, and grammar. So we've built out who we think the client is for. We've built out our features list. Just to make sure we know what's actually going into the wireframes at the beginning, what the important parts are. 

We'll leave out things like a footer or other features that are kind of just normal, where the Contact Us page needs to be there. All of that stuff, so this is the kind of the unique stuff for the project. Competitors and Product Inspiration, this just helps us know, and the client know that we are aligned in terms of, this is the kind of thing we're building. 

Deliverables, this is super important. So, we go through two parts. It's Wireframing, and then there's High Fidelity. Basically, High Fidelity means-- Wireframes are really simple. High Fidelity has all of the font, colors, and images. We build wireframes purely just for client's approval. I don't go out and test wireframes, we'll talk about that later on. Then we build a High Fidelity prototype. And then we go out to some user testing. Based on the user testing, we'll do our usability report. And that can be big or small. Basically just feedback on what you found out in your user testing. Then once that's all finished and we've tidied up any of the problems with user testing we'll grab all of the UI assets for the developers. That just means, giving them images, and code and icons, and symbols so they can build the app for the website. So that's where our job's going to finish. 

I always have like a 'Not included' just in case the client-- just to kind of make sure the boundaries are set nice and clear. So they've asked us to prototype the back end, which is the kind of instructor side of this website. There is also a student side of it, which they've already got developed. They don't want us to redesign that, so I'm just making sure it's clear. They told me that it's clear we're not covering that, because they expect to use their current system. The instructor side is what we're going to be testing. 

Costs, so this is what I charge for this job. Jobs vary, often they kind of start at about 2-2.5 grands US and get up to about 10 grands for larger projects. This one here, basically I work out what my day rate is, and it's roughly about $800. And then I kind of work out how many days I need to work with something like a time line. Add in a bit of a buffer, then give them an hourly rate after that, so that if they do start asking for stuff that's not covered in the deliverables you can say, "Sure, I can do that but it's going to probably take me another half a day." And then they know your hourly rate, so they know that it's going to cost x, y, and z. And I find that's a good way from stopping the job to creep out. So job creep happens with every job. They go, "Can you quickly just add this extra little thing," and you are kind of-- you add it, and you you'll decide later on, if you bill them for an hour, and then the job forever runs, and you either surprise them with a giant bill, or you just suck in those costs, which sucks. 

So I make sure that at the beginning I give them a set cost because that's what everyone wants, nobody wants an hourly rate. I give them an hourly rate as well so that when you're chatting, and they're like "Hey, can you also do this?" and you're like, "Sure, it's going to probably take me three hours." They know what your hourly rate is, and you can add to your bill and everyone's clear right from the beginning. I always ask for 50% payment upfront to start the work. There's so many jobs that I end up starting, that never get finished. So I like to make sure I get 50% upfront so I can cover my cost for the initial part, the most important, doing the UX research, working out the features, that's the kind of super important part of the job, I think. So I always ask for a percentage upfront. You might have asked for something smaller than that, but 50% is quite common. And then 50% on completion. 

Deadlines, every job's a little different. But this is what we've done. There's a kind of them and me. So I'll do the user research to get started with. The wireframes get delivered to bringyourownlaptop then. Then they give me feedback by a certain date, then I give the High Fidelity, then give me feedback on that High Fidelity, and then it actually goes to user testing. And then we allow a couple of weeks for user testing. This can be different, depends on how—

For this project, we're going to do a lot of, what's called Hallway testing or Over the Shoulder testing. We're going to try and meet up with people, to do physical live stuff. Find people that match our Persona, and actually work with them. Now again, we're not going to cover full on testing here. I've got another course for that. Check out "How to be a UX Designer" for some of the testing techniques. But yes, we're going to do Over the Shoulder stuff plus we'll probably do some unmoderated testing where we go to, say, usertesting.com. I find this really useful. You can just send it to them, and people record themselves. It's cheap, it's quick, and it's something you don't have to organize meetings for, and you have recordings so you can snip out bits, so you could show the clients some of the results. 

Then there will be user testing, and completed report. Basically just feedback about, this is what happened in the user testing, these are the changes we're going to make, and you make those changes. Once the final changes have been done we'll hand over the assets to the developer to get built which in this case would be-- I'll probably end up doing the web side of things. At least the front end web design stuff, but the app and the back end development will have to be done by a developer, which is totally out of my zone. I'm more of that creative side, the front end side. So that is the kind of brief that we send through to the client. 

Always make sure that-- I bet you, I 100% promise that this will not get hit by the 4th of December. Mainly because of the feedback. So your client will see this date, and say they'll do it, but things will just turn up late. And it will just be one or two days late, and I just make sure that as soon as it is a couple of days late I revise the next time line so that they know that it's them that pushed that out. So when it's like two months overdue it's not because of me, it's because of their poor feedback. So be really kind of rigid at the beginning, saying that "It needs to be here by this date," and as soon as they're late add that to the time and just kind of push that out because this is going to look long if it pushes over to the next year because it is going to add kind of another couple of weeks in the middle of Christmas. So we should have been handing this over kind of mid-December, and before you know it, it's February. And they had in their head the middle of December. So just be very careful about time lines and deadlines. 

Now again, this is my process. You might be working in an agency and that $4000 just wouldn't cover their rent, so you might be starting in the $5000 and ending in the $50,000 mark depending on how large the project is. You might be just getting started and you might be taking on work a lot cheaper than that. You might be doing designs for $1500 or even $500 to get your first job but I figured I'll show you where I'm at as a freelance UX designer so you've got some sort of idea of pricing, time lines, and briefs. 

Let's have a quick look at the Persona that I've got made. So this is the Persona that we built for this project. Now, the initial brief's kind of a rough outline. What we've done since then is some UX research into who this person is most likely to be. The nice thing about this particular client is they have lots of Google Analytics and have a strong YouTube channel, so it's easy to get in there, and see actual hard data about who’s using their channel, who’s using their product, and then talking to the client about who this potential person could be. Then what goes into this will really depend on your project. 

So we've given this guy a name, Peter. That's a fake stock library image but I feel like it represents the person. We'll give him an age, his job title, and the place he lives. Now, what goes in here, what you really want to do is be able to communicate where, after reading this, know the person. So, do you need to write down the toothpaste he uses, or the car he drives? Potentially, but potentially not. If it's a Prius or a Ferrari, that's kind of an indication potentially of what kind of a person he is. I've seen some Personas that just get into like minutest details but I guess, what you want in there, just so you can have enough in here to kind of walk away and go, "I understand where Peter's coming from in relation to my product." So it could be shorter than this, probably not much shorter, but I wouldn't make it too much longer either. 

So have a read through this just so you understand who Peter is while we're doing this project. What I've done for you, is, in the exercise files there is a folder called 'Persona Template' and you can use this if you want, there's an Illustrator file, you can switch out the images, and fonts, and stuff, and use it if you like, you have total permission to use it. But yes, have a read through and see how Peter does things. So have a read through and understand Peter, and as positions, that when we're building in XD we can make some decisions based on what Peter would want, not what the client wants, and not what I want personally. All right, so that's the brief in Personas. Let's get on to the next video.