agile ux design with Jared Spool

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: and I’m Murray Robinson,

Jared: And I’m Jared Spool, at least that’s what my underwear says.

Murray: And today we’re going to talk about integrating UX design and development.

Jared: I appreciate you asking me to come on. 

Murray: I might start with a story. So I was leading delivery for a digital agency a few years back, and I found that the designers pushed back quite hard on, being involved in, scrum teams. And their argument, was that if you make us focus on buttons then you’re going to get a really bad design because we need to think about how the whole page is going to work before we do the button and before we can work out how the page is going to work. We need to understand the steps the user is going to do as they go through the site. And before we do that we need to understand who the user is and what they’re trying to achieve and what you’re trying to achieve. And the only way to do that is to do interviews. So we’re saying can you tell us where the button goes and they’re saying we haven’t even done the interviews yet .

Jared: They’re not wrong. These are things that should be known at the start of a project. 

You have to understand what we’re building and why we’re building and what we’re doing. We haven’t nailed down the specific solution yet but there is a direction. There is a goal. There is a set of plans. What does it look like when we actually succeed at what we do? How are we going to make somebody’s life better? We need to understand that at a minimum to be able to figure out where do we go next?

And if we just start talking about where do the buttons go, it’s like going to a tailor and talking about the size of the pockets before you’ve talked about anything about what you want the tailor to make. They don’t even know it’s a dress or a suit or, A kilt or, a hat and you’re just talking about what’s the optimal width of a pocket.

What are we using the thing for? What are you wearing?

Murray: Yeah. 

How did you get into this whole field, Jared? 

Jared: I was a software developer back in the late seventies, early eighties working on the software that was going with some of the world’s first personal computers. I get really interested in how are people going to use this thing? And then I just start exploring different ways of figuring that out. We had no methods for doing this and we had to figure all that out. The common practices today of running a usability test were things we invented because none of us knew what we were doing. 

People say well, how did you decide to go into UX? I’m like, I didn’t decide to go into UX, it showed up around me. 

Murray: How would you describe Agile UX today?

Jared: I think there’s Agile, and I think there’s UX. And I think there’s a thing that we call Agile UX, which is how you make both of them work together. Agile was not designed to think about users, let alone designers. It was about delivering. We’re gonna timebox everything because when we time box things, we get more done. And at the beginning of the time box, we’re going to predict how much we think we’re going to get done during the time box. And at the end of the time box, we’re going to see if we did that.

Murray: That’s true about scrum, but not true about Agile because Agile doesn’t have time box in it, if you go and read the Agile manifesto.. 

Jared: I know you’re right.. but most implementations of agile use some time boxing thing. 

Murray: Just what you were saying about the customer though, the Agile manifesto says our highest priority is to satisfy the customer through early and continuous delivery of valuable software but when they talked about the customer, they meant the business client that they are working for. 

Jared: I think that’s because at the time people in the I. T. space were order takers. They were being told by the bank they worked for or the military contractor that they worked for that they needed software that did X by this date. There were very few people in that room who were building consumer grade software. 

Murray: But I have seen since then, there’s been a big reorientation around the real customer and the real user in agile probably starting about 15 years ago. And in the last five years, I’ve seen a really big movement reorientate around products. Which is good. 

Jared: It is. But unfortunately in many organizations, it is still treated as order taking, particularly with the big frameworks they create all this insulation between the team and the users. 

Shane: I struggle with this idea of doing big UX up front. We’re not going to spend six months doing that because I’ll get it wrong. We’ll invest in the wrong things too early. So how do we iterate that process? 

Jared: What we have to do with agile is think about what does it look like when it’s running instead of what does it look like when we’re trying to start it? Because when we’re running, you’re learning who the users are. You’re learning what they need. You’re able to deliver things at a good rate because you have this knowledge that you’ve accrued because of work that happened before and we now know what to do and where to go. We get fixated on that starter moment. 

Shane: I agree that work done early to have a shared vision, to have a shared goal to know some things before we start coding and testing, have value. But what happens is we tend to silo the team. So we start pipelining. UX team, go and do some work. And when you’re finished, hand it over to the build team who’ll build it and then we’ll go and test it in front of a customer and get some feedback. So it’s the challenge of doing light work up front as an end to end team, getting the validation and then iterating. 

And I see that UX people want to go away and they want to understand the customer. They want to understand the personas. They want to do some interviews. They want to understand that problem because that’s how they solve it. And so how do we blend those two different ways of working that iteration and lots of feedback and lots of change with actually doing some light planning up front. So we’re all on the same page? 

Jared: How much waste are we interested in? How much are we willing to throw away? Because if we go 180 degrees in the wrong direction to start with at some point, the plane’s going to have to turn around and the change in direction as complete waste. 

Murray: Jarrod when people do these big detailed designs up front, what proportion of those designs do you think end up being implemented as they were defined ? 

Jared: Well, if they are, I think there’ll be a complete failure of the design. We’re always going to get new information. That’s going to cause us to want to go someplace else and we just have to be okay with that.

Murray: I agree with you. We’re not building the same car 50, 000 times. We’re doing something different every time. Product development and software development is a process of learning what people want and how you’re going to build it. And therefore the big design work up front has a considerable amount of waste in it, but you do need to do some to get going.

Jared: Yeah, I’m not a big fan of defining a lot of things up front but we have to separate out the discussion of what is design and what is UX, because they’re not the same thing. Design is saying this is what the buttons will look like. And this is what the fields will look like. And this is what the flow will look like. And if you do that without understanding anything about the users and what they need, you’re going to build something that nobody wants and can use. The whole team need to know why you’re building this thing and who you’re building it for and what success looks like for them. If you do a good job on this thing, how are you going to make their life better?

So how do we get the whole team, not just the UX people to understand what that picture of done looks like, such that we’re all in agreement at the exact moment we have hit it. Now we’ll probably learn that iteratively. We probably will have a fair amount of uncertainty at the beginning, and we have to over time refine that certainty, but that turns out to be more important than actually building the thing, at least initially.

Murray: We keep coming back to this idea that it’s not about the planning up front, although we do need to do a little bit. It’s about how can we get the whole team to think about UX? How can we integrate UX people and software people in a team. So what’s your thoughts on that, Jared? How would you suggest we do that? 

Jared: So I got a five step plan that I’m running for office with. Step number one, we have to make Agile all about delivering great user experience. It’s not about delivering a product or delivering a chunk of code. If your users don’t have a great experience, you have failed. No matter how brilliantly the code is written. So we have to just get alignment on this across the entire team to say, look, we are here to deliver great user experiences as a team together, not the UX people do the user. One of the problems of calling people UX people is that there’s this perception that everybody else doesn’t have to worry about the UX. It’s not my job.

The second step of my five step plan, is we’re going to use actual research of real users To drive what the meaning of done is. Now, when we do that research, we’re going to do it all the way through the project. So we’re always doing research. We’re always feeding the project with new insights about our users. 

One of the interesting things about great design. And great products is that they don’t just work for the mainstream. They handle the edge cases. They handle the strange sequences of events that happen because life gets complicated. They handle the scale. 

I was talking the other day to a system admin who handles all of the new employees that come into the company. And on a given week, a peak might be 150 new employees and his job is to get them all set up with email, to add them into active directory. To do all these things. And he’s got a flow and he knows how to get these folks into the system. And he’s good at this. And then one weekend, the merger with their new partner company gets approved. And that week he has to add 30, 000 people into the system because now they’re the same company and now they all have to have access to the same information and he could handle 200 in a week. He could not handle 30, 000 a weekend. How do we design for that? And there are lots of solutions, we don’t have to nail that down, but we have to agree that some users need to do 200 in a week. And sometimes that same user needs to do 30, 000 in a weekend. And we have to define the definition of done to include both of that. And so we have to understand the margins in addition to the normal flow.

Murray: So that’s about doing user experience research throughout the process. To interview, real customers or users for a morning every two weeks. Is that the sort of thing you’re talking about? 

Jared: Yeah. I mean it’s probably not enough volume, but it’s definitely the right frequency. 

Really what you’re trying to do is get everybody to understand the problem. And given that a given team at a given moment is working on a specific thing, we need to understand how to feed the knowledge that we have about who those users are and what they’re doing to that team so that on day one of whatever the first sprint is, they’re not starting at complete ignorance.

They’re starting with a certain amount of knowledge that is really beneficial so they can avoid a whole bunch of risk that comes with zero knowledge about what you’re supposed to build, which unfortunately is how too many projects try to start.

Step three is establishing UX metrics based on an outcome. So it could be, I’m trying to get a new way of putting a phone number into a form. I just need to input phone numbers in a way that we don’t throw error messages to customers anymore. In the United States it’s because you put dashes and spaces in your phone numbers, because that’s how you write them everywhere else, except when you’re using a computer. So we’re going to throw an error message at you that says, stop putting dashes and spaces in your phone numbers. Why you’re a computer. You can take them out. So we’re going to fix that problem. 

So if we do a good job, how do we improve someone’s life? We can say, well, we’re going to stop giving them error messages. The phone number they enter is the phone number they’re going to get instead of having to do it twice or three times while they figure out what the syntax of this thing is. Okay, that’s a simple improvement. That’s not going to take a lot of work.

Okay. There are other things like, if we do a great job on this ICU telemedicine project, how do we improve people’s lives because we’ve done a great job making telemedicine better.

Now we’ve got a big list of things. And once we have that list of things, we can start to build metrics for them. There are success metrics, which show the moment we achieve that. There are progress metrics, which show us the progress we are making to achieving that. And there’s something we call problem value metrics, which are basically the cost of debt, the cost of UX debt, the cost of technical debt. We actually use those as metrics to show the progress that we’re making so that we can keep our debt under control. 

Step four is that we have to always assume that there will never be enough UX people to do all the UX work that every team in the organization is trying to do. So that means we have to expand skills without expanding the number of UX people, Which means we have to build the entire team’s UX capabilities up. There’s no reason why your partner can’t learn where to put a damn button. 

At least we can build them a design system that puts the button in the right place every time. We know how to solve this problem. We expand the capabilities by either building tools that help us do this, or by bringing in skills and knowledge. 

And then step five is to focus on building out a five year picture of what a really great product or service looks like. Where do we want to end up? We want to end up with something damn awesome. So what is that going to look like? Let’s paint a picture of it. We don’t have to nail it in stone. We don’t have to say this is what it is. But let’s at least get an idea. 

If I’m going to take the family on vacation, I just don’t, drive in a random direction and hope I get somewhere. That’s not how we plan a vacation. We’re like, what do we want to do, kids? We want to go pine the fjords. Okay, so if we’re going to go pine the fjords, Where are the fjords? Let’s at least set a destination that makes sense. Now, we might stop along the way at places we didn’t anticipate and have a lot of fun. In fact, we might have so much fun we never get to the fjords. And that’s okay. But we at least should know that the direction we want to head in is the fjords.

Murray: This all makes a great deal of sense to me, Jared. 

The challenge has often been, how do you integrate all those people together? I just like to put them in one cross functional team that has UX and design people with developers. And then I love what you were saying about teaching everybody all about UX. Decentralize UX into the teams, teach everybody about UX get everybody to go to a customer interview every now and then. 

Jared: Not every now and then. I think it should be a common thing. I think there should be interviews, not just interviews, but actually observing people in their work. There’s a lean process that I was just reminded of the other day called the Gemba walk and In the Gembe walk you get your executives to go walk the factory floor, wherever the work gets done. And the whole idea is to get people out of their desks out to where the work is actually done.

So if you’re building trading software, you go to the trading floor. And if you are building software for a car manufacturer spend time in the factory, watching people put doors in and hoods on pickup trucks. That’s got to be happening on a regular basis. If the agile team is in their cubes and they’re not getting out to where the work is done, to where things are used they’re not building something that’s useful. And frankly, That’s the most important thing you can learn about UX, which is how to actually spend time with your users and see how they use the things you build.

Murray: Research from, the Standish group and others shows that only about 30 percent of the product features that we build for people are used regularly. So, 70 percent of what we do is actually waste because people don’t really want it.

Shane: Yes, but what 70%?

Murray: That’s the question. That’s why we have to talk to people.

Jared: Yeah, it’s exactly right. It’s so funny. People don’t want to do big design upfront, but they’re okay having 70 percent of the things they build wasted. Really? That’s just whack to me. 

I’m not advocating big design upfront. I think that’s a bad idea, but I also don’t think that good research is big design upfront. I don’t think learning about our users is big design upfront. I don’t think understanding what done means is big design upfront. I don’t think figuring out the measures that we’re going to use to measure success is big design upfront. And I certainly don’t think that understanding why we’re building this thing in the first place is big design upfront.

Murray: yeah we just want to do this all the way through .

Jared: Yes, exactly. 

Shane: Yeah, I agree. So I think it’s probably time that Murray and I go into a bit of a summary round. So you talk about, all of the people in the team should be upskilled to do UX because it’s a team behavior, not a role. We don’t pipeline the work. But we also know that understanding the problem early is really valuable, but we don’t want to over bake it. So no six months requirements documents, but no walking into sprint one with a team who have no understanding what we need to build and why and what does success look like. So blending UX into that early work done is valuable.

And love the idea of taking definition of done having another version, which is definition of awesome user experience. How do we know that actually we’ve delivered something to the customer that makes their life easier rather than just delivered some software that worked. So let’s define that up front. 

Murray, what do you got?

Murray: I think that there are times where users want things that you can’t afford to deliver. Because they’re not financially viable for your organization, or they’re not technically feasible for you to deliver. So I think we need to find a balance of what’s desirable for the user, what’s financially viable for the organization and is technically feasible.

Jared: Are you trying to tell me that I’m never getting my jet pack or flying car?

Murray: Yeah, I’m not No, you can have a jet pack, it just won’t be safe. Flying cars, I think we call them helicopters.

Jared: Okay. Fine. Keep in mind, user research is not just walking up to people and saying, what do you want? User research is spending time with folks, trying to figure out how we can make their life better. There’s almost always a viable ability to make somebody’s life better. If we spent the right amount of time studying what their current life is like. 

One of the things we learned early on in our world is that you don’t ask users what they want. You spend time with them trying to understand their world as much as possible and figure out what you can do to make that a better world.

Shane: Yeah, but that is key, it’s not a requirements gathering session. It’s a, it’s an observability process, isn’t it? 

Jared: Yes. 

Murray: Understanding the problem to be solved and the jobs to be done is the way I like to think about it.

Jared: Yeah. I’m not a big fan of the jobs to be done language just because it’s very transactional and it doesn’t account for lots of things that we can improve in the world that aren’t transactional.

We need to do a lot of work around. Facebook and misinformation, but that’s not going to happen if we treat it as a jobs to be done problem. Jobs to be done is a very low level transactional approach. And certainly we need to know what people need this thing to do for them. But at some level, there’s more nuance and subtlety that jobs to be done is not going to help us with.

Murray: So how do you like to think about it instead then? Is it about the problem that the user has and the pain that they’re experiencing?

Jared: Yeah, I mean, we can map their current experience on a scale of frustration to delight. So we can spend time with the folks in the factory putting doors and hoods on pickup trucks. And we can watch them and we can see where’s their process frustrating to them, where’s their process frustrating to their management, where does the work they produce frustrate the person who buys the pickup truck. So we can look at those types of dimensions and we can see where that frustration exists where it meets or exceeds their expectations, that would be on the delight side. And we can map that out. We can just literally take a timeline of all the events and say, these events produce frustration. These events exceeded expectations, anticipated needs, and we’re delightful. And then we can focus on the lowest points of that graph. And we can say, how can we raise them up? How can we reduce the frustration, make them more delightful? And in that process, we can start to make improvements. And we just iterate over that. 

So we don’t just want to look at the day is where the assembly line is working. We want to look at the days where things are happening on the line that are unusual, like the 30, 000 new employees in the company scenario. And when we do that we can see where there can be improvements and there’s really no end to the work. We’re just getting to smaller and smaller increments and reducing that marginality. Our first release worked just fine for 80 percent of the users, but 20 percent of a million users is still 200, 000 people. How do we start, to gnaw away at helping those 200, 000 people have a great experience and work our way through. Including the, every five years we acquire a 30, 000 person company and I have to figure out how to get the employees merged with my company. So we look at that marginality and we figure out what, needs to happen there. And from there we are getting better and better. And this is completely in line with the Agile ideas of continuous improvement, of constant refinement, constant refactoring. Nothing about this is incompatible.

Murray: Yeah. This is great. I love it. 

So where can people find out more about you and learn from you, Jared?

Jared: We have a community which we started for people who want to understand how to lead UX, which doesn’t necessarily mean they have to be UX people. They just want to deliver better user experiences in their product and service. We call it leaders of awesomeness. And if you just Google leaders of awesomeness, you will find the URL, which is leaders. centercenter. com, which is the probably the best place to find all the stuff we’re currently doing.

Murray: If somebody’s trying to learn more about this, what book would you recommend that they read?

Jared: Scott Birkin just came out with a fantastic book. How Design Makes the World. I’m a big fan of Josh Seiden and Jeff Gothelp’s books they have two that are particularly awesome. One is called Sense and Respond. That’s the book you can give your management. Cause it really talks about this idea of what it really means to iterate to really understand the world. And then they just have a new edition of their original book Lean UX, that just came out. Which is pretty fricking fantastic. 

Murray: Yeah, I’ve read both those. I think they’re great. And I also, recommend people go and watch your videos, which are free. 

Jared: In the leaders of awesomeness, I do a session every Monday that’s open to the public that talks about all sorts of things. And we’ve done a whole boatload of them on agile and UX, and they’re all around UX strategy.

And I’m a big fan of Jeff Patton’s work, so I would look to him. 

Murray: User story mapping.

Jared: Yes. And the videos that he does are fantastic. And then there’s another brilliant book. Written by Chris Risden and Patrick Quattlebaum, and the book is called Orchestrating Experiences, and that is a fantastic resource for anybody who really wants to get a good understanding of how you really do get to the subtlety and nuance of fantastic design.

Murray: All right. That’s been great. What do you think, Shane?

Shane: Yeah well, this has been great. Thank you. And we’ll catch you all later.