Join Murray Robinson and Shane Gibson as they talk with Donna Spencer from Maker X about user experience design in empowered product teams. We discuss user research, information architecture, and visual design. And the problem with the way UX is often done in traditional teams and agile teams. We discuss the value of having a UX person embedded in a product team and the responsibility UX designers have to educate other members of the team in UX. And finally, we talk about UX design models. The problem with design sprints and the value of evolving your design over time by going broad and going narrow.

Read along you will

Murray: In this episode, we talked to Donna Spencer about user experience design in empowered product teams. We discuss user research, information architecture, and visual design. And the problem with the way UX is often done in traditional teams and agile teams. We discuss the value of having a UX person embedded in a product team and the responsibility UX designers have to educate other members of the team in UX. And finally, we talk about UX design models. The problem with design sprint s and the value of evolving your design over time by going broad and going narrow.

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

Murray: And I’m Murray Robinson.

Donna: And I’m Donna Spencer.

Murray: Hi Donna. Thanks for coming on. We want to talk to you about agile and UX. Whether they should be separate or together. Why don’t you kick us off by telling us about your background and experience? 

Donna: So I’ve been what we now call a uX designer or a product designer since the late 1990s. I’ve done a lot of work in government. I’ve done a little bit in large corporate. I’ve done a lot of consulting with small organizations. I’m now working for a startup who makes software for other startups. I’ve also taught both Agile and UX, for a post-grad bootcamp. So I’m a UX practitioner but I, understand theoretical and practical agile really well.

Murray: And have you worked with or in Agile teams? 

Donna: Oh, yes. The first Agile team I worked in was probably about 2008, 2009. I worked a lot of traditional waterfall before that.

Murray: And what well known projects or sites would you have worked on? 

Donna: The most well-known is A B C I view, which is our national broadcaster’s TV streaming service. That’s my shiniest project. Otherwise, a lot of what I’ve done is invisible. Cause a lot has been internal software that runs government departments and processes. So yeah, I view is my shiniest thing.

Murray: All right. Let’s talk about the problem to be solved. So what is the traditional non-agile design model? 

Donna: Before Agile got really popular, I used to work a lot with business analysts. So often a business analyst and I would spend a lot of time figuring out what was needed. So we might call those requirements. We would figure out what needed to be done and then I would spend a chunk of time at my desk drawing up screens and specifications and provide it to a team. And I would usually stick around to both work through the detail and also to do things like user testing when we had something that we could put in front of people. So, traditional design upfront and handed off to a team.

Murray: So the project’s already well underway by the time you get involved. The business case has been done. You’re being brought in to say how the requirements might be implemented. 

Donna: Yeah, sometimes I would help with the requirements gathering as well.

Murray: Okay? So what’s the problem with that approach?

Donna: There’s lots of problems with that approach. Firstly, there’s a time slip problem. The things that you talk about early on that then get built a couple of years later, or even a short time later. Things change so you can deliver something that might have been accurate at the beginning but life’s changed. 

There’s a problem in that if I am designing a set of screens for an application and I don’t know what technologies are being used, then I can design something either that is impossible to build or that it actually doesn’t utilize the technology well enough because I don’t know what we’re gonna be using. So I designed a bunch of stuff that somebody tries to work with later and it could be overdone or underdone and I wouldn’t have any idea.

The other difficulty with that is that it is genuinely hard for people to understand how something is going to work and feel based on a set of diagrams and specifications. Not many people are good at reading requirements and understanding them. It’s like reading house plans. Most people can’t look at a set of house plans and get in their head what this thing is going to be and do. I worked on projects that cost millions and millions of dollars and went nowhere because by the time the consultant delivered the spec, the software still wasn’t what the organization needed for all those reasons.

Murray: So do you think that you were able to get a design upfront that was comprehensive, accurate. 

Donna: No, not a chance. So even now I work agile, I’ll often do a little chunk upfront because I’m trying to help a team visualize something. And like I’m experienced, I’ve worked with all kinds of tech. I’ve worked with all kinds of front end frameworks. I have a lot of experience. There is no way on earth I can get something right up front.

Murray: Yeah, but why is that? Is that cause you not trying hard enough?

Donna: Often you don’t know actual business rules. A client hasn’t thought yet about all the things that might happen through a process. Often, as I said, you don’t know the technology you’re working with, so you don’t know, what kind of constraints and opportunities it has. But also when you do stuff upfront, it’s really hard to do the nitty-gritty detail. So as an example, if I’m using a front end framework with a team, I’m gonna go through at the detailed level of design and define out how each component should work. If I don’t know what I’m using, how can I do that? So yeah, it’s just not possible.

It’s possible for really small apps and maybe really small websites that I have a lot of experience doing before. I can design upfront a basic website, but I don’t think that’s what we’re talking about.

Murray: Yeah. But what about the argument, that the requirements and design should be technology neutral because the technology should serve the requirements in design, not the other way around. 

Donna: That means that they’re still too high level because they’ve gotta inherently work with the technology. They’re built in a technology. So even login the organization I’m working with at the moment, we use a particular login provider. I don’t have to design log in. We’re gonna use a technology and use its strengths cuz there’s lots of ways you can do login. So no design isn’t technology neutral.

Shane: Yeah. I agree with that. So same with us. My original wireframe for the login for app had to username, password because that was naturally right. On the first cut of mvp, we used Google accounts. So there is no username, password. There’s type in your email and then it’s gonna take you to Google and they’ll authenticate you and we get it back. So that technology changed our design. I couldn’t put a username password there.

Donna: But there’s also new log in, patterns where you can send people a code. There’s new ways of thinking about it. So if I came in and design, username, password, there might be better things that we could do because a set of users access stuff in a particular way. 

Shane: Yeah. Classic example of that’s two factor authentication. Are we gonna invest technology that sends an email? Are we gonna invest technology that does an app on the phone that gives me my second authentication? 

The other thing, that after you’ve done some design for a while and built some stuff, a concept of a design system comes out. There’s a kind of concept of reusable design components that work with the technology that often it makes sense just to use them again. But when you hit something new, then you gotta go back and actually do more of a research understanding. 

Donna: Yeah, yeah, yeah. So I was also thinking there about projects where we are doing something fairly new and a little self-contained. So design systems are s uper important for large organizations who are trying to have a coherent approach across really complex things. And over time for even a single designer, just to be consistent with their own stuff.

Shane: So often we find when people come in as consultants they often get bought in when something’s a project. It has a beginning, it has an end it’s just gonna be worked on, but the big funding is gonna disappear. Do you find that the problem is people treat design as a one off task at the beginning and not as a inherent skill and capability in a team to keep feeding and watering and iterate that product. 

Donna: Look, that’s how I used to see design work. Companies would hire a designer or hire a consultancy to do the design work. I think that’s really disappeared in the last 10 years. That’s how I used to get work. People would approach me to do a piece of work. I would always make sure I had a, long tail way of hanging out with them. And as a freelancer, that was easy for me. But I stopped getting those kind of offers. I started to actually have to find work for myself rather than it come to me. Because I think most design work went in-house which is where it should be. So I think that there is less of that. And this is probably due to Agile.

Murray: Yeah. I wanted to ask you about the idea that research and design should be specialized skills done in specialized teams by specialized people. Cuz that’s the traditional model. You have a design team. The project engages them to do design work. And the reason you have a design team is it’s highly specialized. You need a center of excellence. And they’ll be much better, more efficient and cost effective if they’re all working together across multiple projects, just assigned one project after another. That’s a traditional model, isn’t it?

Donna: That’s certainly a model that I see in big ish organizations. And research and design is skilled work and there is skill that goes into it. There is skill in learning how to do research really well. Both how to set up a piece of research so that you’re getting valid representative answers and that you are talking to the right people and you’re talking to them the right way and that you’re not leading them.

That’s a skill talking to people and listening. And asking questions openly is a skill. Understanding detailed interaction design and how people interact with technologies and how they use things. How brains work is a skill, but these aren’t impossible skills. They just are things that some people are better at than others. 

I always think this is all about risk. If you’re working on something where doing it in an unskilled way will lead to really poor results. You wanna hire skills. But if you’re working in something where you actually genuinely have an opportunity to do something, get it out, get feedback, listen, build changes in, you don’t necessarily need exceptionally experienced high skill designers. So you can always balance this with what do we really need to do here? What’s the quality that we need? And there’s not enough super high skilled designers who really understand research well and who really understand interaction design and have worked with the right technologies. They’re just aren’t.

Murray: Yeah. Let’s talk about the research side of it a bit. There’s an argument that there’s nowhere near enough UX research done before people try and solve a problem. In the traditional model you were talking about, there’s already been a business case and a problem defined and requirements done. There may not have been any user experience research done at all, and in Agile it’s quite common for UX research not to be done very much either.

Donna: Yeah.

Murray: So is there a problem here that people are just not doing enough UX research?

Donna: Look, uX folks will always say that you’ve gotta do research, you have to understand the user problem, et cetera, et cetera. I happen to have spent most of my career working with startups and on projects and my preference personally is to trust the client somewhat. To trust that in doing a business case, in thinking it all through, that there is a problem to be solved. They’re not just putting money into something that doesn’t exist. And of course there are tons of things that we know have been built that have no actual use. But I am quite comfortable with the idea that you have a go at building something. That you use the skills of a team to take a good guess, get feedback on it, and then figure out it’s fit. It’s really hard to do generative research for a problem, particularly with technologies or ideas that don’t exist yet. It’s really hard to research things that aren’t in people’s heads.

I used to say nobody knew they wanted all their albums in their pocket. You couldn’t have done generative research that came up with the idea of an iPod. You might have picked up bits and pieces of it by observation, but it’s really hard. I reckon it’s much better to create something, even if it’s a prototype and then say, how might this help you do a thing?

Murray: There are people who say that if you do that, you’re gonna be biasing the people you are speaking to, to think about the solution that you’re providing. Whereas in reality, what you should be doing is questioning everything. Start with the customer or the user and say what are you trying to do and what are the jobs that you are trying to do? The whole jobs to be done framework and focus on their problem. And then if you understand their problem well enough, you can come out with a solution which is much better than a group of managers would think of inside a company. 

Donna: Yes, people will say that, but there’s something wrong in there. And the wrong thing is that people don’t know what their problems are. So I was talking to a bunch of developers recently cause I was trying to do some design process work to help make sure that, our developers have an easy job working with designers. So I talked to them about work they’ve done before and good process and bad process. And not one of them told me the thing that I actually know is the problem. Because they didn’t know it was a problem. They didn’t know that it’s a solvable thing. They don’t know it can be better. We dont know our problems. We dont know what could be easier in life.

Shane: Yeah, as we’ve moved on from talking to people that come primarily from an agile domain and to people that come from a product domain, but actually work with agility. I’ve struggled with the whole, if I asked them what they wanted they’d ask for a faster horse. I’ve struggled with the whole Steve Jobs persona of he just knew what was right. He’s an asshole about it, but he knew what was right and he demanded that. And where I’ve got to now is this idea around where you gonna place your bet

Donna: yep. 

Shane: You gotta reduce uncertainty and so you do a bunch of bets to reduce uncertainty. So I’m more comfortable building an MVP for a problem, I think exists, and then go and test it. I’ve got a bias now that problem exists. I’ve got some bias of this is how I think I might wanna save it and I can only now iterate that problem. But that’s my bet. I’m comfortable investing my money and my bet is actually, we’re gonna be revolutionary and we’re gonna do it in a way that nobody’s ever thought about it before. 

You just have to figure out your context, where you wanna put your money, what bet you want take, and then follow that process. And if you can’t articulate that, then actually you’re just gambling.

Whether you got a team of five researchers upfront or you’ve got a product built, lean, and in front of the customer, if you don’t understand the choice you made, that’s when you’re in trouble. 

Donna: Yeah. I came up with a model at one point years ago, and it was all about risk. It was like how much do you know? What’s your opportunity to learn as you go? Because sometimes it’s hard to learn as you go. Sometimes it’s hard to actually get in contact with people and get feedback. What’s the consequence of taking that dive and having a go at something? 

It would be genuinely good to go talk with some people and find out how they do this thing and look for gaps, or look for potential problems. Or you make something and you show it to them. And you don’t have to do that in a biased way. You can still show things to people, ask open questions about it. Try to put it into their life so they’ve got something to react to and go, oh yeah, I really would like all my albums in my pocket.

Murray: Yeah, it’s interesting. We’ve been talking to people about patterns and pattern libraries recently and it’s pretty clear that if you are aware of a pattern, you start to see it in the world around you. But if you’re not aware of a pattern you don’t even see it. 

Shane: I was listening to a podcast yesterday and it was a guy called Andrew Tokley. He’s a product coach and he walked to the length of New Zealand. And he listened to a lot of podcasts when he did that. And one of the ones he remembered was a podcast where a psychologist or somebody was talking about the human brain and saying first half of our lives, it’s about filling up our brain with new things. About learning. Second half of our life is about pattern recognition.

Donna: Yeah. 

Shane: Do you find actually that it’s the more experienced people who are actually better at discovering those UX patterns and doing that research because they are patent matching, or is that actually a danger that they are trying to align it with a patent so therefore people who don’t have the patents are actually gonna truly discover the new things?

Donna: I think it takes some experience with the world to listen and to understand what you’re hearing. And it takes experience with different cultures and different kinds of people and getting out of a bubble to really understand what you’re hearing when you’re talking to users.

So there’s really something in experience in the world. But that’s not always about age. You could have lived in four countries by the time you’re in your mid twenties, and be really good at identifying that people think and react in different ways. And you could live in one place for your whole life and not understand what you’re hearing. 

Murray: We’ve talked about problems with traditional ways of working, I just want to go through some of the criticisms of lean UX and empowered product teams and so on as the alternative way of working. So people will say that they undervalue the specialized skills of UX researchers and designers. Another issue with them is that it’s very expensive to build something to learn from it. And it’s better value to mock something up to learn. So build, measure, learn is very expensive unless you’re just building prototypes or mock-ups,

Donna: Or proofs of concept of technology or small parts of things that you can build quickly. You don’t wanna do build, measure, learn if your build is expensive and complex. You would try to learn off prototypes in that case. But if you can build something to prove a technology, to prove an idea and get feedback from it, and you can do that in a cost efficient way, then that’s a good way of learning.

Murray: The other criticism I’ve heard from designers is that if you try and design in an iterative and incremental way, focusing on the short term, focusing on the next sprint you get highly fragmented designs. 

Donna: Yeah. Yeah, you absolutely do. That is absolutely true. I’ve worked in a couple of places where they were designing very feature driven. Here’s your slice this week. We are gonna do that, then you’re gonna do that, then you’re gonna do that. And I’m like, oh, I can’t just, spit out features one by one because you do need a coherence across an app that you building, designing. There’s always global things, like navigation and overall flow and where do you put the settings? And designing a screen when somebody’s creating content you wanna know how you’re gonna be editing it so that you can design it so it can be used once. 

What I do in basically everything is do a really skinny horizontal view of as much as I know about, so that I can get a big picture of what something looks like as a whole. And then you can dive down into the vertical slices and do things in detail. But if you haven’t got a picture of that horizontal whole your designs will be really patchy and scratchy and they will feel very linear. They’ll feel like you’re going through an old style wizard where you do this, and your task is done.

Where when you designed holistically, you can actually figure out ways that something feels much more fluid where you move around it in a less linear way. So yeah they’re absolutely right that designing feature by feature can make really crunchy designs.

Murray: Yeah. And leads to very frustrated designers 

Donna: Yeah. It’s hard because you’re like, I don’t know what to do here because I need to put this into a whole.

Murray: What do you think about the argument that Agile is an engineering approach and engineers don’t respect designers and researchers anywhere near enough? 

Donna: I think that’s all individual. I work with engineers who super respect designers and design skills and working together well in a team. As an idea and as a way of working in a team and planning work and working collectively, it’s a great idea. It doesn’t have to just be for engineering. It did come from there. And there’s some hangovers they’re about engineering but we learn and we change and we adapt our ways of working. 

Murray: All right. Well, let’s talk about the solution then. So there’s a lot of problems with the traditional way of working and there are some problems with an extreme short-term focused, agile way of working. So what’s the, best way to work in your experience, Donna? 

Donna: There’s no one best way because there’s no one team shape is there and there’s no one organization shape. So what a startup does in a small team is not the same as what a bank does when they’re trying to produce things across a whole organization that actually have to talk each other. So there’s no, perfect, way. And that matters because you can’t say you have to do it this way because it’ll work in one context and not another. The Spotify model worked for Spotify cuz Spotify had a particular culture and a particular way of working. You can’t just pick up that thing and drop it onto another organization. So you can’t just apply everything to every project. 

Murray: So you’re saying you don’t believe in best practice?

Donna: I believe in good practice and I believe in patterns. And I believe in analyzing what you are about to do and what needs to be achieved and figuring out a good way of getting there.

Murray: Okay,

Shane: Yeah. Best practice is bullshit.

Murray: Okay. Let’s talk about teams. How do we integrate people with research and design skills, with people with engineering and test skills? Should we do that? 

Donna: Of course we should. How else do we think things are going to happen? If we don’t have the people who are doing the big picture planning of a product, whether that’s a product owner, some ux, the engineers, the whole team together, we’ve gotta integrate the what are we doing here with how does it work? How does it look with building it, with checking that all of that is actually built well and achieves what we need to achieve. That’s a team. It’s not some people handing off work to each other and never talking to each other again.

Murray: do you like the empowered product team approach that Marty Kagan talks about? 

Donna: I haven’t read Marty Kagan for a while, but I think empowered product teams are amazing.

Murray: Yeah. You’re gonna get no argument from us. The idea about teams focused on a product and the outcomes from the product rather than focusing on a project. And teams that are cross-functional a multi-skilled, be able to take an idea all the way through from beginning to end in one team. 

Donna: Yeah. I think that approach is really sensible. Works really well. It also works well for me because being in this field for a long time, I have a lot of core UX skills. I’ve got a lot of random other skills. I can write, I can do some maths things. I understand finance really well. Cause I ran a company for a long time. There’s other things I bring to teams. And I don’t like being put in my box and just say, okay you do the screens. I’m like, but actually I can help you do QA and I can do stuff. Why would we hire for somebody really specific to do just qa when actually all of us can do that at a level of quality that’s appropriate. I don’t want anybody thinking that I don’t value qa, cuz I totally do. That was just an example.

Murray: That is an interesting example, though, because you could test a product for the user experience from the user’s point of view. And you may well find things that nobody’s thought of cause they were too focused on business rules and features. 

Donna: yeah. And I do that. But I can also help think through all the exceptions so that we test all of the things that could go wrong as well as the happy flow right through the middle. See, cross-functional, empowered teams are sensible.

Murray: Yeah. Can other people in the team do any of this stuff? There’s an argument that really only the user research specialist should do research and only the user design specialist should do design. And other people in the team, if they try and get involved with it, are just gonna mess it up.

Donna: That just devalues the humans you work with. Imagine you’re working in a team. You’ve got a bunch of nice people and you like working with them. Some of them are really, genuinely good at talking, listening and deeply understanding. Those people can definitely do user research. But if some of those people on the team do not enjoy talking to people, aren’t good at listening and understanding what people are really saying and what they really mean or only listen for the things they want to hear. Those people are probably not gonna be the ones that you want to be talking to potential customers. 

I have very little strength in visual design and aesthetics. Nobody wants me doing the high fidelity, high illustration, visual design. It’s not my skill. And if I try to do it, my design’s gonna look like the five year old did them. What I’m really good at is all of the flows and interactions. And understanding how people look at things on screen and how they think. And the complexity of dealing with a whole product. But I don’t do high fidelity design. Somebody with a skill in that does it. You shouldn’t do things that you are unskilled at, but you can help. You can be involved. You can support. 

Products need words in them. Some people are better at writing words than others. So no, it doesn’t have to be people with specialist skills, but it does need to be people who know where they fit into a set of skills.

Murray: Yeah. So if somebody asked you to design a team of 10 to develop a product or a service that had a important visual element to it, what people would you put in that team? What roles would you have?

Donna: Oh look, all products are different. I’m never gonna give you a black and white answer here. Am I? What design skills or what? 

Murray: Would you have one information architect, one UI designer, six engineers or two testers. One requirements engineer? 

Donna: No. I want a team of people with skills and to bring in the specialist skills you need. So actually you don’t need somebody on a team all the time to produce high fidelity designs and branding. Like a logo gets made once a brand gets made once, it might get tweaked over time, but they don’t need to be on the team full-time all the time. So that’s a skill that you might bring in. You might bring in research skills if you don’t have them on your team for particular pieces of work. Depends how your organization’s structured. You don’t need a researcher sitting on a team the whole time if it’s not a research heavy project. But if it is a project where you’re doing continuous discovery and you’re going out and talking to users every couple of weeks, you might want an individual there all the time. It depends on the product and the team structure. You’ve gotta analyze what you need and I certainly hear people say, you need a researcher, you need a hi-fi designer. you need some project management and a tester. And we talked about our 10 person team. I think we don’t have any engineers now.

Murray: Yeah, that’s true. Particularly if you have three UX researchers and two designers. , I dunno how you’re gonna afford any engineers. 

Donna: Yeah. Who’s actually producing to build, to research and test?

Murray: But a cross-functionally empowered product focused team still does need to draw on a specialized group from time to time. So people who do high fidelity wire frame designs for you. How do you set that up? So what’s the role of that other team and how should that specialized team work with the product teams? 

Donna: Oh, again, it depends on the size of your organization and what skills are around. we used to do pieces of consulting work. You can prep a set of wire frames. You can prepare the requirements for how the brand should communicate and how it should be reflected in the world. And you can get somebody to do a piece of work around that where you know, they deliver it in a project, they deliver it over maybe a couple of weeks.

And then you need a, ongoing stream where you can get advice. Get additional changes cuz it’s never gonna be complete. So if I’ve, had somebody do a high fidelity designed to something I’m working on, and then I come up with a layout that I hadn’t thought about before we might need a bit of extra work, or we might need that person to qa to make sure that we are not missing important things that we just haven’t seen because we don’t have the skill to know what to look for.

So you can have, skills brought into teams to deliver chunks as long as there’s a way of having that available to you later for both QA and bits of ongoing work. And that way you don’t need somebody full-time sitting around trying to make work.

Murray: Yeah. we talked to Jurgen a Apollo about this. He has his unfixed model and I think he would call that group the capability crew. And the idea is that the product teams are customers of that specialist team. 

Donna: Yep.

Murray: Which is quite different to the normal model. The normal model is those people are the experts and the police and everybody has to do what they say. But if it’s a capability team and the customers of product teams , and most of this capability is in the team except for where it just doesn’t make sense for it to be, cuz it’s not used all the time. That’s quite a good model. I

Donna: Yeah. I will say though you do need a person to look after the user experience, across the whole time. You don’t just get the UX done in a chunk. Somebody needs to work on the whole thing. 

Murray: Yeah. And you can still bring in experts from time to time to help. Yeah, I agree. The product team needs to have ownership of the user experience, not just outsource it to somebody else who comes and goes.

Donna: Yeah. 

Murray: So we’ve talked about customer research and organizational structure. Let’s talk about the process. There’s a traditional model which is the phased and gated model. There’s double diamond, which is supposed to be done iteratively. There’s lean UX from Jeff Gothelf. There’s design sprints which is interesting, very contained. And then there’s continuous discovery from people like Teresa Torres who we’ve had on. What process model do you recommend when we are trying to work with this kind of integrated product teams? 

Donna: One that I use. So I teach undergrad UX, and I use this with my students. It’s called a design funnel. The design funnel contains those ideas of going wide narrowing down that the double diamond has. The double diamond doesn’t actually tell you how to do anything. The double diamond literally says, don’t forget to broaden your ideas before you select them. That’s the point and it isn’t, intuitive for people to say that let’s go wide and let’s broaden out before we select what we do.

So the design funnel. You start with a world where you don’t actually know very much. You learn some things maybe from research, you make some decisions and narrow down your world. You might do a bit of prototyping. You test it with people, you learn some more things, you make some decisions, and you go wide and narrow down over time through a process. But it’s only a model and it’s only way of thinking. It isn’t linearly, this is what you do day to day, but is a good way of thinking about the fact that you take in information at lots of points in a project.

And each time you go a bit wider, take in some information and then narrow down to focus on your goals. I like it as a way of thinking about how to get from one end of a process to the other. A problem with the double diamond is that it’s got arrows going backwards and nobody likes going backwards. It feels like you’re going backwards. Nobody feels like they want to go back. And it feels really uncomfortable to say we’ve gotta learn some things and then we might need to go back and everybody goes, oh, I don’t wanna go back. So if you think about it more as a funnel where you are, narrowing down the world the whole time, then you don’t go backwards ever. But you might learn some things and narrow down. what other models did you mention? 

Murray: Design sprints. What do you think? of that? 

Donna: So I have a strong opinion about design sprints. My caveat is that this is about the design sprint as it is defined in the design sprint book. So sometimes people doing design sprints where what they’re really just doing is a series of workshops over a period of time to learn some stuff.

I have problems with the design sprint methodology as the book says to do it, in that it actually isn’t user centered. Users in that process are treated like people to verify your good ideas towards the end. there isn’t really any kind of discovery or any focus on user needs at the beginning.

So it’s not a user-centered process. It’s a product-centered process. I also have very large issues with the way decisions are made in that process. And primarily that it’s about getting some ideas out and dot voting. And dot voting is not a good way of making good decisions on how to move forward in a design process.

Primarily because people will vote on things that look more aesthetically pleasing, even if they’re not better ideas. They will vote on things that are generated by people with the higher, power. So you can actually end up with a wrong or a poor choice just by the mechanism of voting. It’s a poor decision making framework. Because of the time pressure and just the way it’s structured only like really shallow ideas come out and you don’t get time to do reflective work. Really understand whether the ideas gonna work. Like really go deep with them.

So you end up with shallow stuff that has been chosen in ways that maybe not be ideal. And you think you’ve come out the end with the right idea, but there’s just a lot of thinking that’s not done well in that process. So I don’t ever use design sprints though I absolutely get people in virtual rooms to work through ideas together, explore things and make decisions. I just wouldn’t do it in a five day or four day defined process.

Murray: So your funnel process sounds similar to the continuous discovery process that we talked about with Theresa.

Donna: I don’t know in her process whether there is that kind of idea of going wide and narrowing down of making decisions and working towards your goal or whether hers is just more, make sure you talk to users frequently and are always getting input. I guess each time you get input you are going wide.

In the design funnel kind of idea. Some of the way that you can go wider is working with your team to generate ideas and to explore different ways of doing things, which isn’t necessarily like a continuous discovery with users.

Shane: I’d combine the patterns, I’d say we’ve got a whole lot of uncertainty. Continuous discovery allows us to constantly talk to people to reduce the uncertainty to go to the next level of funnel. And you could actually combine them and say, you have to use continuous discovery to move down the funnel. And that would be okay cuz it’s like we’re constantly getting feedback from customers about what we want to bet on. That would be a great combination of those patterns. 

Donna: I don’t always know how all of these work cause I don’t necessarily read these books. Or I might skim them and I’m like, oh yeah, that’s stuff that I know that I do. And the audience for those is people who are newer to these processes. As an author, I know this, you distill things and you write them in black and white. This is a process kind of way because that’s a way to teach. And it helps people understand. I would like to be able to be more black and white, but it’s not how I think 

Murray: Yeah, I think Lean UX has a funnel idea as well. 

Donna: Yeah, maybe it does. 

Murray: I like that idea that ideas are coming in from everywhere you’re coming in cuz you’re talking to customers every week. They’re coming in because stakeholders are saying things or managers Or the team have ideas

Donna: Or you might get a opportunity from a really neat piece of technology that you didn’t know existed, and you’re like, oh, wow, that will let us do something different or easier. But it works in this way. So you change it, you’re like, wow, I just saved a whole lot of time and money by a new idea coming in.

Murray: So there’s ideas coming in from everywhere They come into a funnel and we have to evaluate them 

before we build them. If it’s a funnel that gets narrower, that means that you are eliminating things because you did some research or you did some prototyping and it wasn’t the right thing to do.

The problem I see though, is the funnel becomes an assembly line where senior managers put ideas in the top of the funnel and then expect them to be analyzed, design built and tested and come out the other end. 

Donna: Yeah. In that case, that’s more of a funnel with sharp sides. There’s no new ideas coming in. When I draw the funnel the edges are all jagged. Cuz you go wide, you narrow down, you go wide, you narrow down. My funnel would have scratchier edges. Cuz you’re learning stuff.

Shane: Yeah, there’s a, really good sales book called Leaky funnel. So it’s a funnel of holes. So that’s, what yours is. You’ve got holes in the funnel and as you pour more and more water in, stuff’s gotta leak outta the funnel before it can go through. You can’t just keep piling it in. 

Donna: Well, let’s just say we, throw ideas out of the funnel because we’ve made decisions that they’re not 

Shane: Yeah. 

Donna: thing we are gonna do right now. 

Shane: So, there you go. You’ve got a leaky design funnel. That’s your pattern. That’s your thing. You need to write book on it. 

Murray: What advice would you give to a product manager that you are working with when somebody, some hippo, some exec says, I want this.

Donna: The thing that needs to happen there is for the person who’s being asked to do a thing, to understand whether that thing is a good and correct thing to do. So a senior manager might say, this thing has to happen because there are actual legal requirements or there’s regulatory frameworks and there’s regulatory stuff and you’ve gotta actually do this thing and , that’s probably valid. But if it’s just a, Hey, I was talking to somebody over dinner and they said we’ve gotta add AI to our project, then the product person has to build a relationship there so that they can dig into it and say, okay, let’s understand why this thing, where’s it coming from? What is the goal here? Instead of what is the thing. This should be their skill, is understanding whether the thing they’re being asked to do is the right thing or not. And sometimes that’ll be, let’s go check this with users and make sure that there is a need for the thing that somebody’s told us to do. But sometimes it’ll be let’s go check the law. Let’s go check that the business viabilities there.

Murray: We had somebody say, a salesperson said that IBM have to have this feature. They always use it. It’s very important. And then the team went and did some research on their product and found that IBM never used this feature. So Yeah, a bit of research. Same with legal issues that sometimes executives are saying, you have to do this for a legal reason, and if you investigate it, you find that, no, that’s just common industry practice, but the law doesn’t require you to do it that way. 

Donna: I’ve pushed back on those things quite a lot where they’re like, oh no, we’ve gotta do it for legal or privacy or regulation reasons. And I’m like, okay I’ll go read the Privacy Act.

Murray: Or compliance with some sort of quality standard. 

Donna: Yeah. You go read it and you’re like, oh, actually what it really says is this.

Murray: So what is the relationship between product and ux? Should product people do ux? Do UX people make good product managers? 

Donna: Again, I’m not gonna give you a yes, no black and white answer. Product people should understand in detail what the product problem is they’re solving and what is the user problem. The user need, the tasks that people actually want to achieve with this product. They need to understand it, and they need to understand it deeply and care about it a lot.

That doesn’t mean that they’re necessarily the person who should be talking to the recruiter to get the panel of participants to do the research with. It doesn’t necessarily mean that they’re the one who has to talk to every individual in user research. It doesn’t mean that they have to read every single support ticket that ever comes in.

But they really should understand all of that. But product managers are busy, they’re juggling a lot of internal relationships. They’re often juggling a lot of coordinating with other products that work together. So it can be a really busy job then carving out a chunk of time to be the only person to talk to users is probably just not practical. But they do need to deeply understand those user needs as well as they deeply understand the business needs.

Whether UX people make good product people, I think that some UX people probably are very, very good product people because they already have that open-mindedness, ability to research, ability to listen. They may not be good at coordinating a technical build though. And often a hard thing about leading a product is also understanding how to structure a backlog in a way that the tech folks, the developers can do their work well.

Somebody who’s like purely done research is probably not gonna make a great product manager cuz they don’t understand how to work with the tech team. But certainly there’s a lot crossover in skill. I think.

Murray: All right. Shall we go to summaries, Shane?

Shane: Sounds like a plan. All right, so you started off talking about the difference between internal versus external. You spent a lot of your career working on products that are internal to an organization, not external, like a public facing app or a website. I’m now wondering actually is it different. Do you design differently for that? And if you would, why? 

The next thing we talked about is this common problem we have in agile and we have in product. The earlier we do the work, then things change by the time we use it. So things change between the requirements and the design to when we actually get round to building it. So you don’t want to leave too much time. So the traditional fixed mindset way of working of do a piece of task and hand it over and wait doesn’t help us.

I also like that idea about design stuff is sometimes overdone or underdone. Where do we get that balance. And actually that’s where people with those UX and design skills have that ability to just know that it’s about right. 

And the other one that came through quite strongly is there is this middle set of skills, which is somebody who understands the technology side and understands the design side and the subject matter expertise, and then they merging it together. They’re not a concierge, not an orchestrator or conductor, but they are that glue. In the agile world, we had the idea of three amigos. It’s the trifecta of three sets of really strong skills and expertise being brought together to work as a team to solve some of those problems. 

I love the comment. People are not good at reading requirements. Wire frames are great, they just help, but they’re not the answer. 

I also love the idea that research and design is skilled work. It’s a set of skills. And people often have trouble describing skills, but you actually brought some in and I think you’ve probably got a whole lot more in your brain. If you could just write ’em down, that would be really helpful for me. 

So yeah, you talked about removing bias. How do we do research work? Removing bias from that research work that is a skill. We talked about the skill of listening, but then hearing that’s a skill, 

And then we talked about the idea that it’s all about risk. So there is no black and white. It’s about what sort of bet you might wanna make. 

Donna: Yeah. I like your phrasing of that. Of what kind of bet are you gonna make? I might use that phrasing cuz it’s a good one. 

Shane: That came from one of our other podcasts. And I was like, ah, finally got a word I used to use hypothesis, and I was like,

Donna: Yeah. And that word is loaded, but like, what kind of bet are you gonna make? It’s a good one. 

Shane: And so when we talk about risk, we want to know the risk criteria and you gave us some good ones. What do you know already. That was a great one. Can you learn and iterate. Are you actually able to do it? And then what’s the consequence of the wrong bit? 

There is no perfect way. There is no best practice. It’s all about context. And it’s about good practice and patterns. And I stopped writing after that cuz like I said, as far as I was concerned, you answered it perfectly and I was done. There was some good insight though, so that was good. Murray, what do you got?

Murray: Yeah I think the approach you put forward is one that we basically agree with and we’ve had quite a lot of people saying that this is the way to go now. Empowered product teams made up of people with strong skills in all of the things you need to do to build a product from beginning to end, including research and design. But that doesn’t have to mean that somebody is a very narrowly defined information architect. And that’s all they do on the team. In fact everyone with a strong skill also has a lot of other things to offer the team that they can do. So this is the idea of T-shaped people. 

And if those people are working together in one team, then the person who’s really strong, they might be called an information architect or UX designer or researcher or something. That person can actually bring other people in the team up on their skill by getting them to help do the research. So rather than having a team of five specialist researchers and designers sitting outside working ahead of you, It’s actually a lot better to have that skill in the team, have an expert in the team who can then bring the whole team up. And the reason why that’s better is because you are able to look at everything continuously. There’s a lot of ideas coming in all the time. You can examine them all immediately as a team. There’s also a lot of questions gonna be coming up all the time from the team. How do I implement this? How do I implement that? Which, if you’ve got somebody like you in the team, then you can just get onto that straightaway.

So the team can swarm around the problems they’ve got and resolve them. Cause they can do everything beginning to end. And that removes all the handoffs and the delays and the misunderstanding and the heavy documentation. So it’s massively streamlined now. 

There’s still a place for some expert UI designers or researchers from time to time, but they need to sit in a team that treats the product team as their customers. So they’re not the gatekeepers or the police. They are a service being provided to the product teams when they need a surge or they need some specialized skills that the team doesn’t have.

And we want those people to continue to be available to the product team on an ongoing basis. And, by engaging with this specialized group, which I think is called the capability crew in the Unfix model, then they are also teaching the team the skills at the same time. So this makes a lot of sense. It’s also describes how you can scale up. Each product team should have somebody with strong UX in it who can help build the capability of the team. And then you can have some people in specialized teams sitting across several teams, like in a program who can help build the capability of the whole program.

Donna: Yeah.

Murray: I think in terms of a process, I like the funnel approach. I think combining that with continuously talking to customers and continuously testing prototypes makes a lot of sense. I think the important point here about that funnel is that we have to take things outta the funnel that don’t pass our test of what’s worth doing. And not many people are doing that at the moment, which is a shame. 

You need to be able to say, we are gonna have this idea backlog and things are gonna go into that. And then we are going to prioritize them for research and proof of concepts. And if they prove to be high value, we might then move them into build. But it’s gonna be a lot of things that are just gonna get knocked off at that point or parked or whatever, or say, yeah, it was an interesting idea. It was worth exploring, but it didn’t make it into the worth building. 

Donna: Which means you’ve gotta have criteria around your goals and know what’s worth building.

Murray: Exactly. And you’ve gotta be able to push back on your managers and say, that was a good idea, let’s explore it. And then be able to say, we explored that and the feedback wasn’t good or it’s a good idea, but it’s not as good as this other thing. So effectively you’re treating all these bets as things that have different return on the investment. So I think that’s good. And we’ve talked about how we can do all this sort of thing continuously, so that makes a lot of sense. And products, not projects. Skills. Not roles.

Shane: The thing I don’t like about the funnel is once it’s outta the funnel, it’s out. And that’s not true in my view. Often we park things on the side of the stream, we go, it came down the stream a bit. We made a bet it was a bad bet, it was gonna sink. We don’t wanna let the bet go. We push it on the bank, it’s never coming back. But we’ve done things that we said didn’t work. We’re gonna trash it. And then six months later, for whatever reason, it solved another problem. And so I like that idea of flowing work, that idea of a stream.

Donna: And my funnel was mostly to keep the good little things about going wide and narrowing down with double diamond, but not going backwards. Not going upstream. 

Murray: I agree with you that, things might not work out and you park it, and you might come back to them later, and I also agree with you that you are not done once it’s deployed. In fact once a feature is gone out to your customers and your users, there’s a whole feedback loop that has to happen where you monitor their usage of it. You talk to them about the problems they’re having with it, and then you use that to refine what you are doing. 

Shane: And we’ve gotta be clear. That’s brutal. Spend all this time building this feature and then monitoring that nobody ever used it, that is a brutal process for a product person that is horrible. 

Murray: But that’s a massive source of waste. The research shows 70% of the things that people built for internal applications and also for customers are rarely or never used. So what a massive source of waste that is. We can reduce the risk by talking to people and testing prototypes with them. 

Donna: I don’t know how anybody counts that stuff. 

Murray: I will tell you, there’s a company called Pendo who provides product services to SAS platforms and they can tell exactly how, which features, and also the standish Chaos Group have done in-depth studies of internal applications and some external ones. So it’s all comes the same thing. 

Donna: just made up for a story.

Murray: It’s just that nobody likes to say this because in an organization everything you do has to be a success.

Donna: Yeah.

Murray: Alright, that’s good. Now, how can people find out more about you and what you think, Donna? 

Donna: All my old talks are on my website, which is mad mob.com au. Mad Mob with two as. That’s probably a fine and easy place to find what I’ve talked about in the past. And you can find my books there as well. 

Murray: What are your books? 

Donna: I wrote a book on information architecture, which is old now, but there’s still some good context called Practical Guide to Information Architecture. It’s on my website for free because my distributor decided that they wouldn’t distribute it anymore. There’s also a really good book on presenting design that you can buy It’s really skinny. 10,000 words, how to present, design and get great feedback.

Murray: and are you a consultant these days? 

Donna: No, I’m working in-house these days for a cool startup called Maker X.

Murray: maker X, what 

Donna: Yeah, 

Murray: X do?

Donna: We build software products for other startups and ventures. So I’m working on lots of different things all at once and my team are amazing.

Murray: All right, great. Thanks very much for coming on.

Donna: Great to see you. 

Murray: That was a no nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to build great teams that create high value digital products and services, contact Murray evolve.co. That’s evolve with a zero. Thanks for listening.