Join Murray Robinson and Shane Gibson in a conversation about UX design with Debbie Levitt. UX Design is research based information architecture and interaction design that requires deep expertise. Most agile teams are feature factories that build things that don’t satisfy customers. Product Managers and Engineers don’t have the skills and experience required to do good UX Design. The democratisation, decentralisation and prototype first approach advocated by  Lean Startup, Lean UX and Marty Cagan is garbage. Design Thinking is light weight rubbish that doesn’t work. Agile doesn’t work for Design. UX Design should be done by UX experts in a functional team of at least five that works alongside product and engineering in a tri track agile approach.

Read along you will

Shane: Welcome to the no nonsense podcast. I’m Shane Gibson.

Murray: and I’m Murray Robinson. 

Debbie: I’m Debbie Levitt. 

Murray: Hi, Debbie. Thanks for coming on. So we wanted to talk to you about customer experience and user experience design and its relationship to agile and product development. 

Debbie: Super. Thanks for having me. 

Murray: Can you tell us a bit about your self and your experience?

Debbie: Sure. I like to say that I’ve been doing CX and UX strategy, research and architecture since the dinosaurs. So measured in decades and American in case you couldn’t tell. And I worked for many years in San Francisco at a lot of different companies. I joked I was contractor to the stars, but mostly I focus on anything that has to do. The customer experience or the user experience both from the sides of the digital experience. So researching and designing interfaces, as well as I’m usually a change agent in companies trying to help them improve their teams, collaboration, UX process customer satisfaction and outcomes. And that’s why people call me Mary Poppins because I fly in, fix everything, sing a few songs and fly.

Murray: Have you worked on any big name brands that we would’ve heard of? 

Debbie: I did some contracting, with let’s see, bank of the west, Bonko PABA. That’s an international bank Wells. Fargo’s an American bank. I worked on Macy’s, which is an American department store. I did a little work for Oracle and Cisco. I did a little work for Sephora, the makeup and fragrance store. I’ve tended to do a lot of eCommerce and SAS systems. That’s just the bucket I fell into with the little banking here and there. So those are some of the things I worked on and through my agency, my company’s called Delta CX. We’re a consultancy. Two years ago, we redid a really. Nice project. I’m proud of for Etsy. And I think most of the world has heard of Etsy by now.

Murray: Yeah, it is great. So, what is your definition of design? 

Debbie: It sounds so simple, but that’s already a wacky one because on the CX and uX side of things, we typically mean design to mean a full process that we typically call user centered design or human centered design. And so design is not just the bit at the end where people are putting together the screens or making them match the brand and have good visuals to us. Design is what we call the entire process. Even things you don’t think of when someone says design like strategy and research and what we learn from the research and how we change our strategy because of what we’ve learned from the research. And even content what’s written on the site, what images will we use? That’s not really visual design, that’s part of content. So all of this kind of rainbow of things in at least in the CX and UX world, we think of as design. 

Murray: Okay. So there has been a problem from, I think the agile community’s point of view with design. Because it’s So often done upfront in a big design phase, and then the designers move onto something else. And you have a development team. Maybe if you’re lucky, you can get a user interface designer to join your team. But typically it’s all done front and then the designers go away and the engineers have to try and implement something. And that means that the team is not learning as they go. And the designers are not learning from the engineers. What are your thoughts on integrating engineers and designers together? 

Debbie: Yeah. So I’m, writing down everything you’re saying, because there’s a lot of points here that I want to be able to respond to. So let’s start with the easy points first. Anyone working in CX or UX should be collaborating with engineers constantly. I love working with engineers. And so when I’m in a UX architecture or UX design role, I make sure that I’m meeting with engineers at least once a week, sometimes twice. And so engineers never feel like holy cats, what is this thing? You just handed me? I’ve never seen it before. So number one, there should be ongoing communication and collaboration. Not because I need engineering’s approval of my work. They wouldn’t understand UX well enough, to know if I’ve done good or bad work, but we need to be talking about if this is feasible, we need to be talking if engineering needs to create microservices, APIs, backend architecture that might need to be created because of something in the design. And do we have the time and resources for that? Or do we have to go with a different design until we have those time and resources? 

So number one, When I speak to both engineering and UX audiences, I tell them there has to be that collaboration throughout. We have to break down those silos and we have to make sure that we are meeting and talking about these things. And I know it does not happen always or often. And there is that siloing, but , there shouldn’t be that siloing. Number one, I don’t believe that there should be some sort of surprise moment where engineering gets a bunch of designs and the UX designers flip them, the bird, as we say in America, show them the middle finger and say, , good luck. Y’all and that’s not the right way to go. There should be the ongoing collaboration as well because engineering might find Ambi. They’ve gotta go back to UX and say what should be here. We also find that sometimes when there’s a QA build, it’s great for your UX designer to come back and mess with that QA build.

Not only to check for things that might be more visual or UX, but to check for things that fit into our definitions of done. Is the accessible, can people with different disabilities conditions and diagnoses all use this, or are we going to get sued? So I think there’s a lot of collaboration that can happen. So that should solve some of the things you said about oh gosh, the designers, just check it over the wall and move on to something else that often has to do with how they’re allocated. Typically there are not enough UX workers in a department and they’re typically taken off a project due to being needed elsewhere. Or I’ve been, taken off of projects at fortune 500 companies because, Hey, you gave us the screens and now we don’t wanna put you in the. We’re gonna save money by you not being on the project anymore. I don’t wanna budget for y’all ass. And so I think that if we budget for the uXers to stay on the project, cuz you know, engineers act like they left me they abandoned me and I’m joking. I’m being, silly and dramatic, but they act we just walked away and they don’t understand, we got forcibly taken off the project when we love to stay on these things. We love to see these things through. We want to stay on the project even once it’s released. And the feedback is starting to come back and we’ve got problems whose root causes need to be determined.

We want to be there and we wanna be part of that. We don’t wanna just see Engineering guessing it, how to fix some of these things. So , they move on to something else is an allocation and budgeting thing that should be fixed. And they’re not learning from each other as they go, can be fixed. If we inspire that collaboration. If your designers haven’t scheduled a meeting with your engineers, go schedule a meeting with your designers.

Shane: So , what drives that behavior? Is that because it is a specialized bunch of skills and therefore there are, extremely limited number of people that can do that work and therefore they are being moved on to the next, most valuable piece of work. Or is it because people actually just see it as coloring in and not something that you need to do in every iteration to build a good product? Or is it something else. 

Debbie: Both and more. It’s everything you said. Even me with 4,000 years of experience, my portfolio is on clay, tablets and Papyrus. Even with that, when I come into a company very often, I am overruled on my own designs by people who have never done design professionally. Or I’m overruled on my research findings by people who had nothing to do with the research. I think there’s a huge misunderstanding of what UX really is, why we’re there and what we’re doing. I tell people if you think they just make pretty screens you’re missing the fact that we’re really business intelligence, customer intelligence and risk mitigation, especially risk mitigation for an agile team, because we might think we’re fast but if we are continuously delivering garbage, then that’s a benefit to nobody. You’re not fooling the customer. And the agile teams are probably going to have to fix that later. That’s not a plus. So very often uX is poorly allocated, because they are rushed off to something else and they are misunderstood. And very often there aren’t enough of because people think, ah, UX, they just make screens. We don’t need too many of those people. And they don’t understand that if we are the bottleneck, you need to hire more of us, not take Debbie and put her on six projects. Instead of three, if you have a bottleneck, you have to solve the bottleneck by hiring qualified experts, not by asking the spare QA person. If they wanna stab at UX for a few hours, we want you to stab at UX about as much as you want me to write code.

Murray: So I wanted to revisit, how do they collaborate because in the agile community, there’s a view that we should have empowered product development teams that have everybody in the team required to build a product from beginning to end. If you’re a project manager designing a project, you would allocate a full-time UX UI designer to the team throughout. If you have, a significant user interface and then they would work with the engineers, probably one sprint ahead, doing designs. 

Debbie: So when we talk about an empowered team, I’m always amazed that everybody’s empowered except uX. I’m always amazed that UX is still misunderstood. Underutilized. Thrown off projects after 10 minutes, not brought in until it’s too late. We don’t even get to estimate our own time. When’s the last time anybody listening went up to a, UX researcher or designer and said, there’s something we wanna ship in Q4. How much time do you need to do the right research and the right design on this said, no one ever. So if we’re going to empower teams, then let’s make sure we’re empowering everybody on the team. And let’s make sure that empowerment means playing to people’s specialties and utilizing them for what they bring to the team. 

I also see people saying empowerment, but they really mean fake democratization or fake decentralization. Where they’re really saying we just want everybody to do the UX work. Cuz UX looks fun and creative and our jobs are gray and desaturated and sad. And we wish we were doing this fun stuff and UX take it from me, it’s almost never fun because I spent most of my day fighting with product and engineering. It’s non fun. But I think if we want to say we want empowered teams to meet that has to do with playing to specialties, making sure nobody’s the bottleneck by making sure we’ve resourced and allocated correctly and making sure that every role or person has been included in all of the planning, release, planning, sprint, planning, whatever it is So that UX has the right amount of time to good work. we know that we can get UX work done fast, but that work is often poor work. Experts can tell the difference, but many others can’t and that’s okay. I can’t tell the difference between good code and bad code until it runs. 

Don’t just say empowered teams. I want to see you live it , especially with anybody with a UX title and real quickly, we typically don’t say UX UI, because those are technically two separate jobs. A UX designer or architect is actually a different job than a UI or visual designer. I know people are used to saying UX, UI product designer, who does UI and UX. In my world we see these as two separate things like you can say full stack dev, but that’s two separate things that somehow got glued together. And sometimes the people are genuinely good at both and let’s face it. Sometimes they’re not good at both.

Murray: Shane. And I have an ongoing argument where I say that there’s nothing wrong with people having roles in a team. So there’s nothing wrong with having somebody called a tester, who does mostly testing. And somebody called a designer who does mostly design And somebody called a software developer who does mostly software. Whereas Shane’s view is that these are just skills and we want a team that has all the skills and it doesn’t matter who has it. And really we wanna be really, very flexible about who does, what 

Debbie: I would love to talk about this, cuz I hear this a lot, especially for agile coaches and scrum masters and the questions that I always ask them and I don’t get an answer. So I would like you to tell me what UX skills are. So when I hear uX is a skill, we know it’s not a skill that’s like saying engineering is a skill. So what are the skills of UX?

Shane: I work in the data and analytics space. When we working with data and analytics, we figure out each of those skills that are required, to be a self organizing team end to end and then we map people out to the skills that are strong at. The skills that they’re okay at. They like doing, but it’s not their specialty, they will jump in and do a good job, not a great job and the things they hate, because those are the skills they don’t have. And then we look for the ability if we can, across the entire team to have at least two people that are strong in those skills. And that gives us failover, gives us ability for two people in that team to be able to pick up that work when it needs to be done. But for UX I’d have a really bad guess of, some researchy stuff, some drawing stuff, some maybe pro typey stuff. And my UX person is gonna absolutely kill me when he hears this podcast. Because I know he does all that stuff and he is good at it, but I really don’t know what the T skills are for that end of the process. 

Murray: You like, 

Debbie: And then I definitely wanna respond to Shane I’m taking notes wildly.

Murray: Okay understanding what the business goals are, finding out who the customers and users are likely to be going to talk to them about what the hypothesis is. So helping people generate hypotheses about what the problem is that we’re trying to solve and then going and talking to a whole lot of people. You might go and observe people and talk to them in stores. I know Ida does a lot of that sort of stuff. And then coming up with solutions. So there’s the whole double diamond process that people go through. So coming up with hypothesis researching coming to some conclusions, developing some prototypes and some screens testing, those, getting feedback, and basically going through that sort of loop. 

So things I see people do, there’s a lot of mapping of user processes and the system processes that might need to support them. Then that eventually turns into a whole lot of screens if we’re talking about e-commerce sites or something like. And then hopefully working with the engineers to turn that into something real. And what I would really like to see is all that happening incrementally and iteratively. So we just pick off a small part and we do that and we experiment with it and make sure it works before we go on and do the rest. 

Debbie: Okay. So I have extensive notes on what both of you have said. I think they’re really great and interesting. So thank you for that. And let me please take some time to respond to these. First of all, having written down what Shane said, he was talking about how we try to group people by the skills into strong. Okay. But not that good at it. Need them in a pinch, probably not our key players and people who hate doing the thing. But I wonder if any of those lump people into, they suck at this because hate is just a self-reported emotion about whether or not I want to do a task.

I know a lot of people who love talking to customers and they’re absolutely garbage at it. I don’t want them anywhere near the customers. They’re doing incredibly flawed research that are going to send us in wrong directions as a team and a company. So I think that when we’re assessing people’s skills, it can’t just be, do you like. Do you like to do it? Are you a good boy? Yes, you are. We should really be assessing for levels of talent, skill and proficiency levels of experience and things like that. And maybe Shane was just giving me the short version and he does this, but I just wanna say it out loud to make sure that we are remembering that a skill assessment is not, do you like doing it? Let’s make sure we’ve got more depth than that because you both can draw screens. Let’s face it. You both can draw screens, but I might look at your work and say, Unfortunately, this is not strong UX work and I would not want you drawing screens.

So I always remind people that the expert gets to decide who’s strong. Who’s okay. And who’s not good at it. I don’t want either of you to decide who’s good or not good at UX. And you might agree with that. But I have seen companies where the product manager is going to decide who’s good enough at UX or the scrum master in some cases.

Number two. let’s talk about Shane’s model of pairs. I absolutely agree in my model for how I believe UX should be resourced. I’m putting two architects or what some people call designers together. These are people who do information, architecture, interaction, design, and prototyping. That’s what we call the skills. And then I’m also putting three researchers together where possible. So actually I have a, a UX team of five because research tends to go more slowly. So if you would like us to pick up the pace, you need more people and you need qualified people. It’s not gonna go faster with people who are playing pin the tail on the research.

And Ooh, I wish I were a researcher. So I like to say the dreamy dream, future UX team as part of your agile or scrum or however you’re looking at it team. Would be three researchers. They don’t all have to be leads or principles or high level. It could be one high level person, two lower level people who are paid less and have less experience, but five highly qualified people that way you do have that pairing. And you do have that backup. If someone is sick or quits or is fired or whatever, the case, you have someone with complete knowledge of the product and the process. I do want to see them 100% allocated because UX is usually spread so thin. We’re put on three to six projects and then people are yelling. That’s not agile, but they yell that at me. And I say, but I didn’t decide UXs budget and hiring capabilities. So please yell at the people who make the budgets and help UX get more people because a UX department really can’t too big. When I worked at Macy’s, we had 45 designers and four researchers and that was way too small.

We were part of the tech building in San Francisco that had 800 people. And that was not enough for the number of projects we were doing. So let’s move on to what Murray was saying, which was, he was listing some things, that he says UX will do. They make screens, they make maps. They talk to people, they might observe things.

And what I find is when people think about UX work in UX skills, They often have a very surface perception of it, which is normal. You don’t really know what goes into our worker makes it deep. So I don’t expect you to have that depth, but I think it’s better for working together and agility.

If you start to at least understand what the depth looks like, even if you know you couldn’t do it, for example, it wouldn’t make sense for me to say engineers, they type letters on the screens. You’d be like, oh my God, she’s an idiot. Now I don’t think either of you are idiots. And I know UX is misunderstood and many of us have patience and sympathy, but we have to remember that making a screen is our output.

It’s not our process and it’s not our skill. Talking to people is what you can see. It’s the tangible aspect of research, but you probably didn’t see the research planning, the research recruiting the The research analysis and synthesis the finding insights, pain points and opportunities. So you end up taking something that is a, a huge process with a lot of science built into it and saying they talk to people.

The problem is when we see UX at these kind of surface things, it’s really easy for everyone on the planet to go I can do that. And that’s because we don’t have a standard for, the quality of that work, because I know that both of you could talk to people. You’re doing it right now.

I know that both of you could make screens. That doesn’t mean that you’re using our best practices. That doesn’t mean that you’ve studied human behavior in cognitive psychology, which is at the core of UX work. Art is not at the core of UX work. Art is at the core of UI and visual design work. So we are studying human behavior and cognitive psychology as the core of our work, the God parents of UX are psychologists and anthropologists and behavioral scientists and things like that.

And just to round up a couple of other notes I made while Murray was talking, Murray mentioned IDEO. I would recommend that people stay away from that stuff. That’s going to be your kind of design thinking type of stuff. I wrote a medium article that I hope people will Google for. It’s called, was design thinking, designed to not work. And if you just write that in the word medium, you’ll probably find my article. And that’s where I teach you about the history of modern design thinking. It was nothing until idea was running low on money and they decided they had to come up with something that they could train and make certificates in so that they could own a, method or practice. Now, in reality, I’m not the target audience for design thinking because I’m doing user center design and human center design. Design thinking is a really bad Fisher price, water down micro deriv. Of it. Now, double diamond is a derivative of user center design. I made a face when you mentioned it, but double diamond is the closest derivative to user center design as you can get to user center design. Design thinking and ID stuff is the furthest that you can get from good uX work done well by specialists. So be careful there. And also I wanna remind people that when UX research and CX research are done really well, it is actually best to not start with a hypothesis.

So I know Murray was saying hypothesis first, then let’s go out and find stuff out. But I would say use your critical thinking here. First of all, if you believe in the scientific method the hypothesis stage is actually the third stage out of the five. The first stage is observant research. The second stage. Defining a problem. And then the third stage is come up with a hypothesis that might solve that problem. So I encourage UX and CX researchers out there to not start with a hypothesis to start solution agnostic, to start idea agnostic, unless we’re specifically testing an interface or a concept, but if we’re doing early generative discovery, exploratory research, this should be hypothesis and solution agnostic and aiming to just learn about behavior tasks people’s perspectives, things like that are going to help guide, not just our designs, but our strategy. 

Shane: So couple questions on that. When you talk about your team of five, so you talked about two designers and three research skills. When you use the term peer, do you mean what I would typically call peer, where both designers are working together on the same thing and doing that together or does they tend to work on their own? 

Debbie: Super question. In research, it’s a little bit of both. So sometimes for example we just have so many interviews to do that. I’m gonna do half of them and my other researcher’s gonna do half of them. and our third one’s gonna be our note taker. So in that case, you have two people, conducting the sessions and you have one person who’s acting in a slightly different role. If you think about planning, research, that’s something we do very collaboratively at my company. That’s when the whole team can get involved because when I’m planning research, I know you’re not gonna do the research. I don’t want you to do the research or the analysis, but I do wanna talk to you when I’m planning the research.

Hey Shane, Hey Murray, Hey, product manager. What do you wish we knew. What are your unanswered questions? What are some of the guesses and assumptions you’ve caught yourself having? What’s some data you have that you’re worried might be outdated or Shane what some data your team has, but you don’t understand the why. That’s my job.

And so to me, that planning is a larger collaboration with more of our teammates, but thinking just about the UX team themselves, in some cases, they are doing the same thing at the same time and just adding more smart brains to that. And in other cases, it’s you know what you work on recruiting those people and scheduling them and getting them in the calendar. I’m gonna be setting up this other thing. So sometimes it’s a little bit of both.

Murray: I wanted to ask you about the relationship and overlap between user experience design and product management. Because you’ve got people like Marty Kagan in his books inspired, and we’ve had him on saying that a lot of things you are talking about should be done by the product manager, things like customer research and mapping out user flows and things like that. What are your thoughts on that?

Debbie: I recently wrote a 4,000 word medium article on that called should product managers do user experience, research or design. So I’m sure that will be easily Googleable if you throw the word medium on the end. I think it’s really interesting. You have a product guy come out and say, look, I don’t care what product managers used to do. I don’t care that for decades, product was a strategic job that organized this and that, and acted as someone who was interpreting business goals and business strategies and KPIs coming down from executives. I don’t care what that role traditionally been. And Hey, I don’t care what scrum.org says the product owner does.

I’m gonna tell you that the product manager is uX researcher, a UX designer and all these other things. It appears to me to be a land grab out of fear of the future of the product management role, because I think that’s changed over time. And I think the more we talk about self organizing teams and self-managing teams, and the more we talk about shouldn’t everybody with at least a few years of experience, be strategic in their work. And shouldn’t everybody, understand the business goals in the business strategies and the things, that we’re working towards on the business side and the user side. And then I think we might end up in a critical thinking spot where we go. Then what does the product manager do? And people go they’re gonna roadmap, and I go, sure, that’s fine. But you know, UX does roadmaps as well. I think when you have like a scrum.org product owner definition, that’s a very clear role. There’s almost no overlap with UX. When you look@howscrum.org defines the product owner, it’s very much this person who’s almost part of that engineering team, And there’s almost no overlap with UX. but I see these product, people like Marty and theres, and they’re saying you have to do the research. You should be making user flows.

You should be doing design. And I think, what’s going to happen is product managers will put themselves out of business because if a product manager job says you should be able to strategically roadmap, and here’s a list of UX skills we want you to have, who’s gonna get that job. The UX people are going to get that job. And I think a UX person is going to end up edging out product people for their own jobs. If you take your average product manager, and imagine that there’s an open UX job at your company and they’re gonna apply for it. Do you think they’d get the, I. Do you think a UX professional would look at a product manager’s background and go, oh, holy poop. On a stick. . Look at this man. This person’s a really qualified and experienced and talented UX professional.

Let’s get them in here for that interview. And so I find that even though we have these land grabs and we’ve got the land grabs for mad child as well I think that we have to remember that. When you hire a UX person, you’re putting them through three interviews, six interviews. Sometimes we have to do a design challenge and we have to do design right there in the interview. Or we have to tell you how we would plan a research project right there in the interview to prove we know our stuff. The bottom line of my 4,000 word article is if a product manager does not qualify to make it through all of those interviews and challenges and get a UX job, I don’t want them doing UX work. You wouldn’t let me write code. You wouldn’t let me do data analytics. Even if I’ve taken physics with calculus, even if I have an MBA and I’ve done statistics, you don’t want me to do that. And I support that. 

Sure. I learned basic programming in 1979. Sure. You don’t want me writing code? Let’s all agree on that. I think there’s a lot of problems there. That’s why it’s a 4,000 word article. But ultimately we’re lowering our standards if we make it seem like product managers could do this. The rallying cry typically is, but product managers are not gonna have firsthand knowledge if they don’t do the interviews themselves.

Everybody listening to our interview right now has firsthand knowledge of that interview because they’re there. You’re here right now. So let’s say you too. Let’s imagine that I’m the interviewer in a UX interview session. You two are my data and engineering buddies and you are listening live to this.

You can even message me with a couple of questions you’re hoping I’ll ask you don’t have to run the interview. Why? Because running the interview requires like 10 skills that probably neither of you have ever worked on. It takes people years to become good at interviewing and we never ask stuff like, what do you want? What do you like? What’s missing? We don’t do that. And So I tell people, Hey, product managers, if you wanna have firsthand experiences with customers, come sit on uX doing the interviews because the best vantage point is of the observer, not the three ring circus that’s going on in my head when I have to do a research session where it’s part, voice acting job, because I wanna make sure that I sound friendly and neutral and part it’s an acting job. And it’s a , critical thinking mini lawyer, mini detective job, where I have to come up with a follow up question for that person without making a face or using any body language that might make the person feel judged without asking them a double barreled question where you ask me two things at the same time. Cuz remember the show started out with Murray asking me for things at the same time and I had to write them all down and make sure I get all the barrels of the. 

So these are the techniques that we learn and they’re hard because even now you want to do a great job interviewing me and you are, but you’re asking me double, triple questions. And so I’m furiously writing down all the things. We can’t do that as interviewers. And so I’m just saying that product managers need to figure out what they want their job to be, but if it starts to move into something that says UX, be careful because you might not like the long tail of that when UX starts taking your product jobs, because they’re full of UX skills and we are more qualified for them than you are. Is that the outcome you want.

Murray: I do know a couple of really good uX designers. Who’ve become product managers, 

Debbie: because 

Murray: cause they’re a good fit to the current description of product managers, which is inspired by marty. 

Debbie: sadly. 

Murray: But the argument is that the product manager is, the one who’s balancing all the balls between what the business wants, what the customer wants and what the engineering team can do so viability, desirability, and feasibility. 

Debbie: I hear that too. 

Murray: And. in order to do that, they need to be involved in all of it. 

Debbie: But that’s the funny thing. It’s the fake slippery slope, because first of all, if the product manager is really all of that, then you’ve just given the middle finger to your team. Where is the sense of the team? You just said empowered team before that doesn’t sound like an empowered team. That sounds like a subservient team with a mommy and a shitty mommy. Where is the empowered team? If one person. To do everything and decide everything. I want To see the triumvirate, the triad, the three voices of product UX and engineering or what some people are now calling the quad product, UX engineering, and data and analytics, where these people are equal team members with equal voices where we’re not run by mixed message mommy who is going to try to tell us what to do. And so I think number one, you have to take a good, critical thinking look at that because is that who Shane wants to be? Does, Shane and his team want to answer blindly to a product manager? No, they want a decision to be made based on their knowledge and expertise.

They don’t want the product manager to steamroll that or overrule it. And I am constantly overruled at companies by product managers and engineers who think they the user experience better than I do. That’s ultimately insulting. It creates conflict. It’s bad for morale. And it’s why most of the UX people, are quitting or wish they could quit or trying to become a product manager so they can run the shitty show.

Murray: So what should the product manager do then? 

Debbie: That’s a really good question. And I just interviewed someone for the book I’m working on. I interviewed a multi decade product guy about that, and, that’s what I said. And, it’s a tough question, because look, we do want product to have all of the information. We want them to understand the users through the research that UX has done. We want them to understand the users through the data and analytics that chain’s team has, but have you ever noticed the product manager doesn’t show up and go, I better do the data and analytics myself, that’s where it’s a fake slippery slope because the product manager claims they need to do it themselves or have that firsthand experience. But yet they’re not claiming that for qA, when QA reports that it’s been tested, coded, documented, and it’s deployable the product manager, doesn’t go. Oh, , I’m gonna do it. And so again, there’s a lot of fake democracy and fake slippery slope stuff. Where if you say product has to have this monster hand in the research and design because beep op Babo, I go, okay. But where’s product insisting that they be part of pricing strategy, sales structure, a corporate strategy. Are they getting involved in making sure the kPIs aren’t bullshit? Are they trying to do data and analytics and pretend they’re on chain’s team? So to me it’s a slippery slope land grab that doesn’t pan out when you use critical thinking.

Shane: I’m doing a bunch of courses with Reforge at the moment to up my skills in the product side of things. I’m doing, a course on monetization and how to set pricing strategy. I’m doing a course on data and how to use metrics, to determine whether the bets we are making are the right ones. I haven’t gone through all the modules yet to see what else is. but I can pretty much guarantee that there’s no UX module. There’s no CX module. So all those other things you said yes, they’re saying the product manager should do, but they’re not saying they should do the UX. 

Debbie: But there’s a difference between doing the data work and how to best utilize the data work. And so I think that product can utilize what comes from uX without doing the UX work.

Shane: I just got one question about that team of five. So what we know is we know that teams of nine or less are more effective. We know that when there are more than nine people in a team, the communication lines become too blur, too many and it’s harder than having a team less than nine. So if our optimum size of a team is five for that CX UX piece, How have you seen it work? When you add the rest of the skills you need to go end to end? How’s that managed? What works and what doesn’t in that scenario?

Debbie: Not a lot works, but here’s what I’ve been suggesting for people. Number one, you don’t have to put all five people necessarily on the agile team, but also remember that, this UX team is its own team. And so they are a team to your team where they are your partners, because remember agile and a lot of these engineering things that we’re talking about, agile, scrum, xP, these things. They were not made for uX, they were made for here’s how engineering should do engineering things. So hypothetically while I think UX should be assigned to an agile team. And in that sense, semi embedded in an agile team we’re not totally on the agile team because we’re really many sprints ahead. And in fact, we don’t think in sprints at all, we’re only stuck thinking in sprints because you said so, but really we usually think in terms of hours of work and days of work, and we don’t think in sprints. Because our work’s completely different. It’s completely different than coding and testing and documentation. So ultimately I do suggest that if you do want somebody more embedded on the team, have your pair of designers share a seat. The researchers will be involved with the other people on the agile team, but not as day to day as the designers, because the designers are gonna be working with engineering as they’re designing.

And then when engineering is implementing, they’re gonna come back to the designers. And so I think that there’s a much closer relationship here. I think the researchers are a little bit more on the periphery. You’re mostly gonna see your researchers in planning when you come and watch the sessions or you watch the videos of them or when the researchers comes and gives their report. So it’s less of a day to day thing. And that’s why I think that if you can just get those architect slash designers a little bit more embedded, they can also represent the uX research from time to time as well.

Shane: Okay, let me just, make sure I got this one. So you talked about hypothesis is third, not first, so you said observe and research front first. And then after you’ve done that after you observe, find the problem, and once you found the problem, then come up with a hypothesis that you want to test.

And so I can infer from that actually, that’s why the researchers are working outside of the team because they’re working ahead. They’re looking to observe and do the research first, before the problem’s found, then the problem gets formed and that’s when the designers come in. And then there’s a next round where the problem, the hypothesis over to the engineering for delivery of the solution. So I can see how that handoff works in a flow kind of way if I got that right. 

Debbie: I think that’s pretty good. I try not to say handoff people have some bad associations with it, but really you can look at a model called try track agile. I didn’t invent it. And basically imagines that there’s three streams of work going on simultaneously. The first is all of that research, whether it’s research for exploration, discovery, early stuff, or research that comes back later because when we test our designs, we consider that research.

So the research could be early. It could be later. So we have a stream of work that’s research, and they’re constantly working on something which means you need at least one specialized dedicated researcher who is doing that stream of work. I would love to see three, your second stream of work in tri track. Agile is actually both your product manager. And your architect or designer, because the idea is that in a better way of working, we are more influenced by what came from research than feature factory BS. A lot of us are in feature factories. Somebody says, Hey, we should build this thing or we should copy that competitor.

And then we go, great. That’s a feature. Put it in the backlog, tell UX to make screens. This. feels fast, but is it really customer satisfaction? That’s something we haven’t even barely said in almost an hour together. Where is the customer satisfaction? Where is the customer outcomes? How do we know we’re building the right things for them? Just because you have some good data and you’ve written some good code and you think it’s ready to go? Doesn’t mean we solve the right problem at all. And so the second stream in tri track agile says, now that we have information and insights and opportunities from research, let’s prioritize those now note that we’re not prioritizing features, we’re prioritizing just what should we work on in general? What problems are we going to solve? What new opportunities do we think we might wanna chase? And that’s what we prioritize. And that again, brings back the triumvirate because engineering should be involved in prioritization as well. So product UX engineering, say, what problems should we be solving or working on or new things. Should we try in what order? Then you’ve got mapping planning and all of the UX design, architecture, testing, improving kind of stuff. And of course your third track in tri track, agile is all of delivery, all of engineering because we don’t care how you do it. We don’t care if you’re agile or waterfall or Kaban or XP, or God forbid safe, or, some combination of these things.

We’ve done the best work that we can do. And now it’s an assembly line, agile and lean were based on assembly lines and that’s really how we can end up talking about big design up front, because design has to happen first. It can’t happen later. You can’t release the product. Then design it, but big design front is one of those gas lighting, negative framing phrases that we say to try to bully people into disliking something, even if they don’t understand what it is, It’s why in America, we have that TV commercial that says four outta five dentists recommend this gum versus 20% of dentists. Think this gum is total crap. That’s negative framing. And that’s what we use a lot of times with UX work, we say it’s bloated without understanding what that time is going to. We say it’s waterfall without understanding what the UX process looks like and why we need to do some things in a thorough, proper correct manner. We say it’s big design upfront because we don’t understand that design has to come up front because whether or not you have a uX team working on your design, your product is gonna have a design. It might as well have a good one. It might as well have one that was done deliberately with talented people because. It’s gotta design, but will people wanna throw it out the window? And so calling it big design up front just creates morale problems, conflict problems, and isn’t it amazing that six to nine engineers working on something for two months is fantastic and agile. But when 2, 3, 1, 5 uX people wanna work on something for a month, God forbid, two months, everybody spontaneously combusts and says big design upfront, not agile, not lean. We hate you and your mom too. Well, that’s funny you get two months to work on this. And I get three days. That sounds like you don’t know what I do.

Murray: I was a business analyst for a long time, doing big requirements front just before the big design up front. I think I was possibly one of the best business analysts out there. I would do this great staff and I’d keep up with all the international best practices. So I would have eight weeks to write a big requirements document, let’s say, 80 pages and then there’d be four weeks of review and revision and then it would get approved and go off to the next stage. And I always thought that I was doing brilliant work and it was really well, but what I realized was quite often the work I did would go nowhere. It would just be parked, for whatever reason they’d lose the funding or somebody would look at that and say, that’s, too expensive. So it was really all wasted because there was no result for a customer. And the other thing that happened was. If I stayed on the project, I would find that the developers would complain a lot about what I’d done? They’d either complain or they’d ignore it completely. It’d be one or the other often they would say, we dunno what you’re talking about. We never looked at the requirements or they would say, no, you were wrong about this and that. And the other thing, and we had to change it.

So I’ve come to the conclusion that no matter how good I was at analysis and I was pretty damn good that I could only be about 70%, right if I was going well and about 30% wrong. And then everything I did would feed into other people, doing things wrong. So if I did 30% wrong, then the architects would take that and they would build something out. And then, a whole lot of money would go into it and that’d be wrong as well. so I think from my point of view, as a business analyst, it’s much better if I do high level business analysis, in a week or two at most prioritize what needs to be done and then start working on it. So we can get feedback on whether it’s worth doing, whether I’m on the right track, whether we’re delivering business value or, customer value. And it feels like the same sort of argument for design. 

Debbie: Thank you for the story. One of the problems with the whole business analysis requirements thing is that it’s still very feature factory, and it’s so rare that any business analysis requirements document has actually come from uX research. So very often what happens is that stakeholder or executive says, this is the thing we wanna do. Murray, write us up the document that tells everybody exactly what to build. Was especially true before you had UX people on your team. So you would have the requirements document that said it has to look like this. It has to work like this. It’s gonna have a window that comes up with a dancing bear and two buttons on it.

And then what happened was that was passed straight to engineers in the old days. And the engineers had to build something that as Murray pointed out, either somewhat matched what he wrote or they just did their own damn thing. These are the things that we did when we didn’t have UX professionals on the team. And I think that if we want to welcome UX professionals in our company and on our team, then we have to start to realize that the requirements document is from another era. Now, I think there are times to have documentation around any legal limitations we should know about anything we tried before that went badly.

Definitely, some of those guardrails are important to document and share with the team, but UX will definitely quit a job when all we do is get documents that says, it’s a window that pops up and it’s got a dancing bear with two buttons. And I might say, I’m sorry, but I think in this case, we’re, we’ll test it and we’ll find out, but our best practices tell us that you don’t want a window to pop up. We’re going to use this technique and the dancing bear doesn’t really need to be. But someone will say to me, Debbie, you’re doing it wrong because the document says it has to be a popup window with a dancing bear, And I’ll say, but I’m a problem finder and problem solver. This isn’t the right execution of the right idea. And I’m told, follow the document. And so we, I think that especially if we claim to want these empowered teams, and as we want to respect people for the experience and knowledge they have in their own area, then we can’t just say, Hey, uX is the people that we just hand a requirements document and they make the thing that’s in there. Or UX are the people that draw the idea in the product manager’s head they’re the secretary. These are not good utilizations of these experts, which means this is the lean sin of underutilized talent. We are being wasteful, we’re creating risk. So I think we have to take. Second look at what kinds of requirements documents we really need in a world where we have product managers doing product management, hopefully and UX researchers, and architects doing their stuff where I don’t need a requirements document.

I remember Wells Fargo giving me a 400 page requirements document. And the only thing I really needed to know in there was that this is going to have to be in English and Spanish because of the laws of the state of New Mexico and the rest of it was stuff that I felt like I, I either didn’t need to know or was trying to tell me what my design needed to look like, which again is not the best utilization of either of us.

Murray: Now I can’t let you go without talking about lean UX which I really liked. It’s been quite a long time since I’ve read it, but there does seem to be quite a lot of UX design in there, but they’re using the lean model, making everything very iterative. There’s a lot of stuff in here. I’m just looking through prototyping, interviews. 

Debbie: You’re throwing buzzwords at me. Remember just because something has prototyping or interviews, and sticky notes doesn’t mean that it’s anything like UX. This is audio only, but I’m looking at a video of Shane and he’s sitting next to a wall of sticky notes. Guess what? That doesn’t make him good at uX. And just because you’ve put sticky notes on a wall, doesn’t mean you’re good at uX, just cuz you use the word prototyping or customer journey map doesn’t mean you’re doing uX work or you’ve done good uX work. So lean UX has a lot of problems. I have hours about this on my YouTube channel.

If you just go to YouTube and right Delta CX lean, U. Pop the popcorn. You’re gonna be there a while. And you’re right. Lean UX took the lean startup as a jumping off point. And what happened was lean UX first came out in 2012, right on the heels of lean startup. And basically it acted like you’re probably not gonna have many or any UX people who work on your team. So just make this a team sport. Anybody can do UX, everybody can do UX and they actually go as far to say that if you have a UX special. You shouldn’t use them that they’re just gonna be some sort of facilitator or I guess creepy ghost flying over you, but you don’t let them do the work. And they use a lot of negative framing to try to scare you. Oh no, a specialist doing the work is going to be trying to remember what word they use. I have it in episode one 15 of my show, but I grabbed a couple of the words out of lean UX and show how they kind of trick and Gaslight you into thinking that working with a fully qualified UX research specialist is a bad idea when, of course it’s not.

And so lean UX loves to work on guesses and assumptions and just run with those. UX is a model that in short is learn, build, test iterate. Lean’s startup tends to be a model that is build. Test learn iterate. And there’s a learning piece upfront. That’s really important that lean UX downplays, if not removes, because it’s mostly based on lean startup, which is just build first and lean UX basically says, just get out there with your assumptions and guesses and hypotheses, you’ll eventually figure out if they’re true or not. But I say there’s nothing lean about that. I don’t know how you define lean, but there’s nothing lean about cycles of wasteful guesses.

Murray: I’ve got the book here. And what is the definition of lean UX? The third point is we prioritize learning over delivery. 

Debbie: But he doesn’t, he also says that his model is not doing work by committee and then says everything has to be done as a team effort. So again, you have to have your critical thinking on you can’t fall for, this is like listening to American politicians, I’m gonna make sure you get good healthcare vote for me. And then of course, you vote for them. The lobby pays the politician F your healthcare, just because the book says it’s important to have good research, but then if you look at how they say that son, it’s not. So let’s fast forward to 2016 when the second edition of the lean. Book came out. It was quite different from the first because everyone hated the original version of the book. It didn’t make sense for UX. And the 2016 version is evidently worse. Most UX professionals who were UX experts and veterans and professionals in 2016, which is already six-ish years ago, read this book and said, absolute garbage.

This makes no sense. Why would I ever use a model that completely disempowers UX? Why would I ever use a model that says anybody can do our work? Whether or not they’re doing it? It was completely disempowering and a lot of us just threw it away and left it. The problem was because we’re generally nice people. We didn’t leave a lot of negative reviews on Amazon. We didn’t say out loud that this was garbage because the funny thing is for all of you engineering and data guys, when you start a new job at a company, you’ll notice that. And especially if anyone noticed this in 2017 or whatever, no UX teams were using lean UX.

Almost zero UX teams brought lean UX in on their own. Lean UX is something that’s been forced on us through things like safe, agile and scrum.org. This is not a methodology that we select. This is not a methodology that empowers us. And this is on a methodology that empowers how we do things, and in fact, if you look at the lean UX canvas, which was stolen from the business model canvas, which makes no sense, cuz we’re not making a business model, but again, he was picking up from, he was trying to ride on the coattails of lean startup. So it’s a business model, but if you look at the lean canvas, it makes no sense because the first box is what’s the business problem.

Then this clearly isn’t about UX. UX stands for user experience. I would expect a UX related canvas to start with what is the problem the user is having and how do we know. This is the problem they’re having. What do we know about that problem? The fact that the lean uX canvas starts with business problem, and it has the solution right there in it is wow, that looks nothing like UX at all. This is just a festival of guessing. I know some people liked the book. They generally don’t work in uX. I found two types of people love the lean UX. People who don’t work in uX because they often love how much it disempowers us and says, anybody can do this. These people shouldn’t have any power or final say, people love that. And I think you all need to look in the mirror as to why you love that so much. And then the second type of people who I find like the lean UX book are people who are now just starting out in UX and they have a lot of low confidence. and they’re worried that they’re bad at the work that they’re guessing at the work. And when they see a model like lean UX, that says you will absolutely never do any UX work alone. All of the UX work in lean UX is always done by committee in meetings with other people that’s really reassuring for a newbie who says good, cuz like I’m the only UX person at this whole company. And I hope nobody notices that I’m guessing at it. It is really easy to camouflage yourself and your low level of skill when your work is always done with other people and there’s no real accountability for your skill level 

Murray: I want to disagree with you there because I worked for a hundred person digital agency, a few years back in a leadership role and our CX director loved this book. 

Debbie: And what was their background? Marketing 

Murray: No digital agency, UI design, not research, but digital agency, website design.

Debbie: Website design and UI design are not uX. Website design does not take users into account. Website. Design is let’s make what we like or let’s make what the client asked us for.

Murray: He used it to argue for user experience research, but he would say things like everybody can be a designer and we need everybody in the design meetings. You said nobody, no designers. He’s a very experienced designer. He now is at, bain as $6,000 a day customer experience design consultant. 

Debbie: Congratulations on your cherry picked example. Look, there’s probably someone who misses hitler right now. Let’s just go right for Godwin’s law and say Hitler out loud. There’s always someone who has that opinion. There’s always the person who lived to 110 and smoked every day. And that’s fine. I know there are UX people out there who either like lean uX or think we should use it. I shouldn’t say none. That’s unfair. And I apologize, but I will say that, especially in 2016, before you add all the flood of today’s bootcamp graduates and UX newbies, when you had people who came more from academia and science and stuff. When they saw this book they threw it out the window did a hundred percent of them do it, probably not. But I have never seen a company that willingly brought in lean UX other than your one guy, and you can have him and, he’s not here.

So we can’t ask him why. And I find that sometimes people think that if we just tell people that everybody is a designer and get involved with UX, that they’re gonna respect me more. I’ll teach them the value of design. It’s evangelism. I’ll teach them the value of design. If I say, everybody can do this, be involved in it, but we actually end up teaching people, especially when we say everybody can do this, that it’s not specialized. We teach people it’s not specialized, it’s not important. And we can just do it in a room with sticky notes and guesses and, playing twister. And so I think that I understand the people who’ve brought in design thinking, design, sprints, lean UX, and other fake UX approaches thinking maybe then somebody will talk about design and care about design and care about my job and care about our customers. But it’s extremely rare that something like lean UX is the Trojan horse for good UX work. When it’s something that completely undoes our profession.

Shane: So just wanted to check what else you wanna cover before we go summary? 

Debbie: The only one we didn’t talk about and I can make this short is, some, it might have been new Shane. Someone said UX being one sprint ahead. I wanna make sure that people understand that to me sounds like poor planning, because what you’re saying is that you have a week or maybe two weeks buffer between when my work is done and when your work is done. And we’ve already talked about how, in some cases, uX when done well, because I’m assuming that someone wants you X to do their work well, quality over speed. If you just want the fastest thing I can do, I can get you something fast, but it’s not going to be necessarily good. Even with my 400 years of experience, having me rush something out could still be a low quality poor solution. So ultimately UX needs to be many more sprints ahead, because if we have. Weeks of research work. And we’re going to wait to see what that research says, especially we’re going to wait to see what that research says to even come up with a product strategy. Then that stuff happens way ahead and remember product managers don’t measure in sprints. They don’t have to estimate their time in sprints or as part of the agile team. So as part of tri track agile, I tell people if you really wanna know, UX should be at least four sprints ahead, people panic, but ultimately UX should be uninvolved in this stuff. We have nothing to do with your ceremonies.

We have nothing to do with how you want to plan engineering work. UX has to be able to estimate and plan their own work. And we have to do this early enough so that there is that runway. There is time for UX to do good work because every time you don’t give uX time to do quality work, you’re bringing risk to your project, to your product and to your company. 

Shane: So would you say that adopting a patent based on a flow of work is the best way of including the UX CX process? And what I mean by that is there’s some things we need to have answered before we are ready for the next piece of work. So please don’t spend forever doing it, but, here’s the definition of when we know we are ready to progress to the next thing, do the design or the information architecture. So go do that. And we flow the work through and it’s done when it’s done. It’s done when it’s fit for purpose. And then we can move on to the next piece that’s required. 

Debbie: You should have quality standards for UX work because a lot of scrum masters and agile coaches tell me it just has to get done. Just check the box. I’m sure it’s good enough. And I’m going, holy cat’s my world’s on fire. Another thing that people don’t realize is that if, if you have a a UX practitioner with five or more years of experience, especially seven or more, they should be able to estimate time quite well as an agency and consultancy. I have to estimate time all the time for my clients. Cause I have to know how much I’m gonna charge them. Hey, your project is five weeks long. It’s gonna have this many people on it. I’m gonna bill you this. Do you wanna work with me? And I can plan time down to the day for multiple people down to the hour for multiple people. And I am rarely late. The last time I was late, one of my software companies corrupted our video files and I had to wait a week for them to fix that, but left to my own devices. I am not late because I can estimate a project down to the day. You wanna know when that research is going to be done. I can tell you exactly when it’s gonna be done. You wanna know when that design’s gonna be ready for testing? I can tell you exactly when it’s gonna be ready for testing. Now that’s because I have extensive experience in both of these things. And so I know how to estimate that time. I’ve made enough mistakes over the years to. That. And if you want it done faster, you’ve gotta hire more qualified people.

Putting an unqualified product manager on my research project slows me down, which we forgot to mention because now I have someone who’s bad at this. Who’s trying to help me out. I either have to try to teach them, try to fix their work. That’s a slowing me down thing, not a relief. So I, I think what you said is right, and really it just calls back to the idea. When done well, we really have an assembly line and the best you can hope for is an efficient assembly line that works well together without silos has good points of collaboration and communication and understands and respects each other’s specialties and UX work. Isn’t always going to take months, but we are usually measuring in weeks and engineers and others need to stop panicking over that because the same people who want eight weeks for engineering panic at me wanting to, come on. That just tells me you think my work’s not important. And I start looking for jobs, 

Murray: So how do I measure the outcome of user experience design and whether I have a good user experience designer or not? 

Debbie: So one of them sounded like, how do I measure the design, whether or not the product has a good user or customer experience. And the other is how do I measure the person? How do I know? I have a good person working with me? two very different questions. Okay so first let’s talk about the person. It’s really hard to measure if a UX practitioner is doing a good job or not, because we so rarely give them the amount of time they need to do good work. So for example, if I say Shane tomorrow, you are going to be in an opera. You’ve got one day to learn your. Get out there on stage and do this opera. Shane’s gonna do. I hope. Okay. But probably not great. And I don’t want someone to say, you know what, Shane’s not that good. An opera singer. Hold on. He might be, we don’t know. We didn’t give him enough time to be prepared to do his best work. So I say, I absolutely want UX held accountable. I absolutely do want us to judge people on their quality of work.

And I especially want us to judge product and engineering when they’re trying to do UX work. But the problem is did they get enough time to do a good job? So ultimately I would say if you want to judge a UX practitioner, that person is best judged by a manager who comes from the work. Very often. UX is slotted into organizations, answering to marketing it. Sometimes product, their manager wouldn’t know a good or bad UX person. If they jumped up and karate kicked them in the face. We need to make sure that UX departments have a proper hierarchy with qualified managers, directors, heads, leaders, whatever you call them in your particular country and make sure that they came from the work.

Someone like me, who did the work for Aquion years and is now typically in strategic and leadership positions. I can look at UX work done by whoever, and I can tell you where it’s weak and where it’s strong. So that’s how we judge that. How do we judge the outcomes of our work? When the product is live in the hands of the users and customers, that’s gonna be a number of different ways.

And typically that’s where we’re going to have to look at any metric that is really a symbol of quality and not quantity. How much somebody does something, how much they paid this time around. Probably not a measure. So typically for more UX oriented stuff, we do look at server performance because we know that even though that is a tech issue, it is something that the user perceives as a user experience issue.

Everyone who says this website is slow, had a bad user experience. I’m doing air quotes. So even though that’s not my job to fix, it is part of the user experience. So slow, poor performance, disorganized databases, bad metadata. These are all things that have to be improved. What are some other things that we can watch for when we’re not a feature factory when UX is done well, We consider ourselves task oriented. You can Google task oriented design. It’s an approach in UX. And basically it says we are wholly focused on what the user or customer sees as their task or workflow. What did they come here to do? Because if they don’t do that, They didn’t get their task accomplished or maybe they didn’t get it accomplished easily.

And we can all think of a time when we went online to pay a bill and it was beyond DOD. It was a mess. We couldn’t do it. We didn’t know our account number. We had to call them up. So think about the task people are trying to accomplish. Now, are there metrics that help us determine how well was that task accomplished?

What kind of time did it take? Were there errors during that task? Could that task be simplified when you start taking the approach of seeing the user’s task and workflow through their eyes and its efficiency, forget delight, forget empathy. These are the side effects of your task going well, I can’t delight you paying your bill online.

If it sucked, make sure paying your bill online was freaking awesome and almost did it for you in your sleep. Then you’re. Feel delight. So we can typically measure the user experience side of a product or feature through things related to the customer’s experience of the task time on task. Fewer support tickets about this feature, cuz y’all know your customer support teams log what feature or part of the system people are calling about.

We can know if there are now fewer tickets about this thing because we made it better or refixed a problem there’s so much we can know. And some of that’s going to take collaboration with customer support. UX is not into surveys. We typically don’t survey people and say, what do you think? How do you like it? Would you cry on the side of a hill? If you couldn’t. That stuff marketing does. Marketing does the whole NPS thing on a scale of zero to 10, would you recommend us to a friend and that’s a measurement of someone’s ability to self-assess whether or not they might recommend you to a friend in the future that is technically not a measurement of loyalty.

It’s technically not a measurement of happiness and it’s technically not a measurement of the quality of our, whatever. And we’re left with a quantitative metric that still doesn’t tell us why what’s going on here. I gave a company nine on the NPS survey until the day I left them. So it’s not a measure of loyalty.

So be careful of some of those so-called UX metrics that include NPS or include bizarre questions. Would you miss this if you didn’t have it, or one of my favorite bizarre questions is, how well integrated did you find this system?

And I was like, holy cats, killing UX heuristics. And did the concept of information architecture by not even asking people a question in a way in which they think, talk about said no one ever was this well integrated, your customer doesn’t know what’s integrated with what they just know. They’re trying to get their task done. They don’t have a sense of integrations. They don’t have a sense of what was consistent about this. You’re using inside terms, inside baseball, as we say for something that doesn’t even, it’s not even on their lexicon mental map. So look out for things claiming to be UX metrics that I find super bizarre.

Murray: All right. I think we better go to summaries.

Debbie: If you. insist, I’ll you.

Shane: Alrighty. I love it when we have somebody on the show who has passion about what they do. And you’ve gotta say that about you, you, you love this shit. So we started out by saying, when we do that CX U x, we should involve engineering because we wanna know that it’s feasible. That what we think we can do is feasible. And if it’s not, or if we don’t have time, then we make trade off decisions. We make a choice that we are gonna do something slightly different. That’s not as good as it could be, but that’s a choice we make and we need engineering , colleagues to be involved to help us with that.

Yep. The next one was, there is a behavior about everybody is empowered except for the UX team. The UX team get shorted at the beginning and the testers get shorted at the end. So we should empower everybody. The next thing is if we see that the UX team or people are the bottleneck, then fix the bottleneck. And it’s something that we subscribe to in any agile mindset is where there’s a blocker, work to remove the blocker, whether adding more people 

Debbie: please add qualified people 

Shane: or, changing the way the flow works. And involve them at all the stages. I like the idea of UX team of five, three researchers, two designers it gives me some what good looks like. And then the way we manage it to keep below a team of nine is we start looking at flow, and a hundred percent allocated, good practice or good patent for any team. Not, a team of CX UX, people that are across six to eight projects whenever they have time. I like the idea that CX and UX comes outta psychology, not outta coloring in, it’s a behavioral science. That’s what the care of it is. It’s about observation and research and then that goes into designing something that’s gonna work. And I love the idea that hypothesis is the third thing we do. So we observe and research first we find the problem second. Then we have a hypothesis of how we may fix it. And then we carry on. I also like the idea that UX people don’t think in terms of sprint. I never really thought about that way. So us artificially putting something that sometimes works for an engineering team onto a team that doesn’t typically work that way is asking for a hiding. You then talked about tri track agile. So you, talked about a research piece, then a product manager architecture piece, and then a delivery engineering piece, all big pieces. And it reminds me of dual track agile, and I’m not a great fan of dual track agile. And so now I’ve gotta go back and think about it again, 

Debbie: I would love to hear why you don’t like dual track agile. 

Shane: Because I’ve seen it done wrong nine times outta 10. It’s the way we do it. We go back to big re requirements front that actually aren’t useful. And then it’s done and we can’t iterate it when we find out there were crap. So it’s the implementation, not the practice. So I need to go back and think about that. So in my head I have this mental model now of lean uXs ship it, then observe and CX UXs observe design, ship it observe iterate. 

Debbie: Do you wanna know that you’re going in the wrong direction? I would love to know before engineering writes a line of code, 

Shane: Yes. Although I would say that if you don’t have an expert in CX uX, there may be shipping it and observing it’s a better approach than having somebody who doesn’t know what they’re doing, spend a lot of time doing something wrong. 

Then last one for me. Ideally if you are using iterations at a time box, if you are using a sprint. pattern let your cX team be four sprints ahead, give them the time to do that research and then focus on or concentrate on the collaboration points, not handoffs, but the collaboration points as you flow that work through and optimize around that. If you can, and then you’ll get the same speed typically because we’ve done the right work at the right time. So that was me 

Debbie: Love it. Thank you. Beautiful. 

Murray: Yeah, you made a really strong argument for specialist teams and design departments and what I would call center of excellence and, that sort of thing. and that’s generally considered an agile to be completely wrong and you should be put up against the wall for saying that because it introduces major delays and handovers in the process. You’ve persuaded me to have another look at it at try track agile. I think that sounds like an interesting way to combine engineering product and user experience research. So I’m gonna go and have another. Look at that. I have worked with quite a lot of designers and I have seen them get very annoyed about having to work at the same time as the engineers in the sprint. They’re not thinking in terms of user stories, they’re thinking much more big picture in terms of what is the user trying to achieve and what are the steps they have to take? 

Debbie: We don’t need user stories. User stories are, take our solution and translate it for the engineering team. I don’t need user stories, just like I don’t want requirements. I wanna be a problem finder and a problem solve.

Murray: So I enjoy your criticisms of marty Kagan’s empowered product teams and Jeff got’s lean UX. 

Debbie: Yay while he is empowering the product team. He’s killing UX. So good luck, 

Murray: I don’t think that traditional product management is the right approach either though I have actually been a traditional product manager in a, large commercial consumer products organization. I used to engage research agencies to do things for us. But then must be something in between and maybe it’s try track agile. 

Debbie: Thank you. I think. 

Murray: And just the importance of doing more customer research. Even when I argue we’ve gotta have a designer in the team, we’ve gotta budget for them. Then everybody just wants a UI designer, not a UX researcher. So it’s quite hard to get that, unless you have a department, that’s just doing it all the time. If you have people who are doing user experience research, and customer research and they’ve got people coming in all the time, while they’re going out to people all the time, there’s actually pretty easy to make use of that and incorporate that in your team and go and ask them questions. So that’s probably quite a good model. So you’ve given me quite a lot to think about 

Debbie: Cool. 

Murray: Debbie. I still don’t like specialized teams and centers of excellence. I think that they’re 

Debbie: like centers of excellence, 

Murray: Okay.

Debbie: But we need specialists. 

Murray: I do like specialists more than shane but I dunno about departments 

Shane: so I’m wondering, if we look at the unfixed model. that we had on quite a few guys ago, where. 

Where he talk . Where he talked about. There is a need for small teams where there’s specialization. That’s hard to get into the main teams and those small teams engage with the other teams when they’re needed to do that work at the right time. But there’s not enough of them for them to be embedded. 

Debbie: We call that an agency model and it’s basically where uX or these specialists act like an internal agency oh, we need this thing. We’ll come do this. Pseudo internal agency. And the problem is that because it’s usually reactive and because it’s come to us, if you need us there, usually isn’t the good ongoing collaboration that there should be. And then sometimes the team is saying we should probably have a researcher here, but add, I don’t feel like it, or I don’t wanna add that line to the budget. And so they don’t get it, and so I think that the problem with some of the implementations center of excellence or community of practice or whatever ends up creating this silo.

It creates these people who are on this island as Ooh, these are the golden specialists up in a tower. And just go to them if it’s beyond you. No one wants to admit anything’s beyond them. We’re probably fine without them. And I think that it creates this unfortunate artificial almost class structure. So no, I would rather see UX architects, UX researchers, one on one with their agile team or product team or whatever people are calling it for whatever they’re doing and not have it be like, here’s your specialist up in this ivory tower? Cuz that’s what people, that’s what engineers yell at me UX you’re in your ivory tower. And I’m like, who put me there? I don’t wanna be there.

Murray: All right. We could go on, but we all have other things to do 

Debbie: Yeah. I’m working on my book. I’m working on my next book. 

Murray: That’s what I wanted to ask you. How can people find out more about what you think. 

Debbie: Sure I am easy to track down and always happy to have the conversation. Even if you disagree or you feel like we’re doing it wrong, what should we do? I’m always happy to give some free advice. You can always track me down on my website, Delta CX. You can always head over to our YouTube channel, Delta CX, also, same thing I have over 600 hours of video on the channel. So chances are, if you put Delta cX in a couple of words that are on your mind, I’ll have something for you. Also every Tuesday live, I do office hours. Ask me anything where I take live questions so you can catch me there as well. But , and we also have slack and discord communities where I am there helping people out with whatever their questions are.

Best the best way to go is go to Delta cx.com/ links. And that is my page of links that will tell you more about the YouTube show and the slack and discord. And if people want to contact me for stuff or some of the coaching that I do, and just come on and just tell me what’s going on and I’ll help you.

Murray: All right. Thanks very much. That’s great.

Exit: That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening.