In this episode, Matt and I talk about how to turn user research into something useful and compelling, that will help you both understand the problems you’ve defined, and enable you to communicate with others about them. We debate various ways of molding all the stuff you’ve gathered into a valuable tool that will help you keep your project on track, and enhance your chances of success.

Some highlights:

• Why you should synthesize user research into something you can share
• What kinds of documents are best to help you illustrate the discoveries you made during your research, and convince stubborn stakeholders to make changes
• The value of involving users in the design process
• How important it is to create user research documentation to help you estimate your project scope and cost.

Ultimately, we uncover valuable secrets that will help you make the most of the time you spent researching!

Where you're only really thinking about one person and you're thinking about that one person's experience through a journey.

And that journey could be at any level of zoom that you want it to be.

But you're describing this overall process that someone's going through.

We bring you practical, actionable advice to help you improve your UX design skills.

You can find detailed show notes and more at www.

everyonecan.

design.

But, you're not the only person working in many cases.

You're not the only person designing.

You need other people to be brought along with you.

So how do you take what you've learned, and actually get it into a format that other people will understand and agree, that haven't participated and been in all of the interviews and been in all of the different sessions and all the different methods we talked about before.

Yeah, How do you use personas? What kind of effort do you put into personas? Why don't you tell us about them a little bit? [00:04:23] Matt: Yeah.

They're doing the same kind of stuff, but they're coming to it from different perspectives.

You then have different personas for the people that are coming with those different perspectives and how they each see the world.

And so you have to deal with like, "Well, it's not a one-for-one here, so can I create an archetype of People Who Are Doing Shipping?" And I don't need to know what kind of role they are technically, I just need to know, "Well, there are people that try to do shipping.

" And so how do I deal with them, and design for like, more of the job they're trying to get done, and think of them from that point of view, versus thinking of them as a specific person? We decide what we're going to break off.

We do, like, a first MVP.

And so like, I completely separate Jobs to Be Done from, like, epics and user stories because that's something that like our engineering teams are doing later.

'Cause we're separated, right? Like, we're separate from our engineering teams.

It might not just be one epic.

There might be a lot of epics that eventually go into like, making that job as easy as possible and things that you can enhance over time to make that job as easy as possible.

And at the beginning, you don't have time to delve into the details right away, and you don't want to delve into the details too quickly, because then you never get to the end, right? You want to kind of go full circle through the process and we talked a couple weeks ago about sketching lightly at the beginning.

And that's part of this idea when you're talking Jobs to Be Done and then maybe at the next step, those become your epics and your user stories from there.

And so I think ,there's just an idea of, at the start you're pretty loose about it, but you are trying to get some things down, you're trying to put things into categories, trying to organize the information that you're getting into some kind of structure so that you can then later structure further in a more detailed fashion.

So I start off with a general persona, especially if it's new to me and I don't know who the folks are that are all involved.

So try to understand the roles, and like you were saying-- I guess archetypes to some extent.

I don't necessarily use that language, but I think that's kind of a similar idea.

Once you have those user stories, when you're actually ready to delve into it on a more detailed level, you can start to create workflow diagrams.

And those are going to describe a rough estimate of how you think the process will work.

And so it will be at the point where you are ready to actually start creating prototypes, let's say.

You don't need to create a workflow diagram for something that is very, very straightforward.

And as you're doing that, that allows you to create some sort of architecture in your mind, and allows you to understand the information and the challenges that you might have.

And then you can start to create your prototypes and also information architecture, which we can talk about at some point.

So that's that process.

And how detailed you want to go will depend.

How much time do you have? How much budget do you have? How complex is the actual project, that kind of thing.

And then also, things like the customer journey are really great at showing, "Where are the problems?" And so, when you're doing, like, a current state, "Here's what it is currently.

The experience looks like this for people.

They're trying to do this, then they do this task, then they do this.

Here's the highs, here's the lows.

" So trying to understand how to bridge that gap is actually kind of difficult, because you don't actually know what their process is.

Just to your point about what are we describing, are we describing current state or future state? I have been going through and thinking I'm describing future state with the client, and then maybe they get a little bit sidetracked or I don't understand exactly what they're trying to accomplish because I don't know what the process is today.

And then, I think the fun is when those people also run businesses where there's people that they're interacting with, but they aren't paying attention as much to like what's those people are actually doing-- 'cause they're in their own world, they're running the business, they're trying to get stuff done.

That sometimes you can be like, "All right, and then we also heard this.

" And they're like, "What? That's news to me.

I didn't know that that was a problem.

You're not there to, you know, cast aspersions on one particular department or whatever.

You're just there to gather information, and that can make it a little bit easier for them to hear your recommendations, rather than if somebody internal comes and tells them about this problem, it's easier to discount.

They can find some reason to discount something that's coming from somebody inside the organization.

This could be the journey of someone that is purchasing something on a website.

Those obviously are, like, different time horizons, right? So you can think of whatever scale you want to think at.

But you're describing this overall process that someone's going through.

And what are the highs, what are the lows? It's a way of gaining empathy and allowing people to understand what's actually happening as people are moving through a process.

So if you think about marketing and there used to be a traffic person who would go and take a folder around to different people and make sure the process is followed and all that kind of stuff, you're there dictating that process and describing it in some sort of visualization.

And then, you can add into that, "Well, this person has their own swim lane where I'm describing what they're doing.

Maybe I can also describe how they're feeling.

All those other things that I would have within a journey map is at my disposal to be able to put in there, if I wanted to tell that story.

But I can use that to describe each of those different roles and how they interact across the long process that involves different people.

So you're thinking of like, what are the touch points that that customer is having with that front-stage actor? And then we kind of draw a line, and then below there is backstage, which are like, "Hey, so the person in front-stage put in the order.

The person in the backstage got the order, had to make the order, put it all together, wrap it up.

People don't know what they're supposed to be pulling up at any given time.

And something like that, time is of the essence as well, and sorry to interrupt you, but that's the type of thing we are gathering when we do the personas as well as what kind of environment are they in? When designers are doing customer journeys, they're like, "We're building this great experience for that customer," right? And then they realize at a certain point, "Well, if I build a great experience for them, but it's a horrible experience for the people that are providing that service, then I've failed.

" We build it so that the business can run.

And in many cases we actually get shut out from dealing with the front-stage stuff.

Like, "You don't need to talk to our customers, you don't need to do that.

" But in certain cases, that might be useful for us to do that, if I was working for a company, for example, that was doing T-shirt printing.

Because obviously we were building software for them to run their backstage, right? Run that integration between the front-stage actor who's taking the order, and then giving it to the people in the backstage to be able to fulfill those orders.

And I'm like, "That's great.

We definitely want to nail that, but I also need to know what that experience is like for those front-stage actors who are on the phone, who are in the emails, in order to build a system to help them do the work that they need to do for their customers.

" Which means I need to know what customers are calling in with, and what problems they're dealing with, and what kind of questions are being asked to them and what they hope to have in order to design that experience up front.

So it's kind of this weird thing of like, if I am used to building customer-facing websites, I want to start thinking backwards to what's happening behind the scenes.

Versus us, I'm used to designing behind the scenes.

Those are the tougher people to deal with.

They often don't have the same ability to abstract the information as we do.

And so when we draw it out, it helps to make it more concrete and people can understand better what you're saying, when you're talking about, I don't know, a task flow or something.

These can be hard concepts to picture, even for ourselves, so when we draw it out, it makes it clearer and it makes it easier to understand.

So you could see it going left to right in time, and then also up and down depending on whose hands the information was in.

So those are really helpful when you have a very large overview that you need to create.

That's super helpful to be able to do that.

I could not do my work without these artifacts.

Here's a question I might end with here.

This is closer to a consulting question than it is like a design question.

But I am curious, how do you estimate with your people or how do you charge, and when do you charge certain things? I'll give you the example, how I did it when I was consulting, was that we called the whole design process-- we called that discovery or blueprinting.

And it was basically doing the entire design process, ending with mockups.

Like, you know, high fidelity mockups.

And we would charge a flat rate for that.

I would get a general idea of like how big the project was, by talking and scoping with them.

I do a discovery phase, if you want to call it that.

I usually estimate a number of hours.

Is it 10 hours? Is it 20 hours? They can pay upfront for let's say this 20 hours' worth of work.

And in that time we will do the-- what we've been talking about, the personas, the user stories with some acceptance criteria, and some workflow diagrams, at least.

And that in and of itself is valuable.

And then, I use the Agile method to do poker planning, or some version of that, where you're assigning points to the stories and you're just getting a relative sense of how big each story is compared to every other story.

And you get a number of points for your entire group of stories and then you assign how many hours do you think a point is going to be.

And then you multiply that by your rate, and then, that's your number.

Where do I have latitude in knowing I might not have everything right? We're at a phase now in the design process where we know a lot more than we did.

We know the problems very well.

All right, well, thanks a lot Matt.

This was super fun.

We'll talk to you next time.