Interviewer: What's the role of UX teams when building software products?
Jeff: There's obviously a need for UX designers. The interesting conversation I think becomes around a UX team.
Yes, there needs to be a UX team in that designers need colleagues to learn from, to work with, to bounce ideas off of, to share challenges with, etc.
But ultimately those UX practitioners need to be distributed into the product development teams. So you need to have a UX designer on every team in the same way that you need to have an engineer or product person or QA people. So they have to be ultimately dedicated to individual teams. That's the real, the most effective way to ensure that both the customer and good design ideas make it into the product.
Interviewer: So what could be their most significant task that they need to accomplish, once they are embedded on a product team?
Jeff: I think the most significant task that they should be worried about is in most cases the user experience designer is the champion for the customer. And so, their task is to make sure that the work that the team is doing exceeds acceptance criteria such as works as designed.
Works as designed is a nice place to start, but it doesn't necessarily mean that the product is usable or desirable. So I think that it's critical that UX designers ensure that the voice of the customer is heard throughout the process. And that the work is iterated on, optimized, until specific positive changes in customer behavior take place.
Interviewer: So what's the best way to integrate UX into agile methodologies within teams?
Jeff: You need to have UX people on the Scrum teams themselves. I think that any organization that says that they're agile but doesn't build cross-functional Scrum teams is lying to themselves. Because that immediately halts the agile process.
In other words, someone's gonna have to do the design up front, at that point. And as soon as you've got that process taking place, you're no longer practicing any kind of agile software development. You're back to waterfall. The key is to make sure that designer's on each team.
Now, the designer's responsibility is to be present, and active and proactive in their Scrum team. So they have to attend stand-ups. They have to attend Scrum planning, they have to attend retrospectives, they have to help estimate, they have to help scope, they have to help prioritize.
And if they're truly participating as an integral member of the team like anybody else, then it should design in an agile experience happens. In an agile world happens because design is participating in that world. The team will adjust the way that they work to support design activities.
Interviewer: From your experience, what do you think are the major challenges when you are trying to foster this lean UX culture?
Jeff: I think there's a lot. Some of the biggest challenges are exactly what we just talked about. Which is convincing designers to take part in Scrum teams. And to participate as full members of the team. I think a lot of designers feel overwhelmed, or perhaps even outnumbered in those situations, and don't want to participate, or don't find value in their participation at all times.
And that starts to build divisions, in there. Another consideration is changing the way that the team works. From a team that's focused on delivering features, delivering output, to a team that's delivering outcomes. Which is measurable changes in customer behavior. That's not a design, or an engineering, or a product thing, it's really a management criteria.
It really boils up to incentive structures undefined have an incentive structure that rewards people undefined matter if that feature is well designed, doesn't matter if anybody uses it. Just get the feature launched. Changing that is difficult because what we also really want to do is we want to reward people for making customers more successful.
If customers are more successful, we can dump their behavioral change and we can measure that. We can measure their behavior. And see that that's happened and if they're being more successful they will continue to subscribe to our service, buy more stuff, tell their friends, spend more money and whatever it is that we're trying to get them to do.
Interviewer: I want to know if you think that the designer can participate on business as usual making in the process of developing products. If that's the case, how this designer take that leap?
Jeff: Absolutely, I think that the designer can be the voice of the customer, the expert voice in the room about the customer. And offer that insight into business decision making.
I think that there's so much input from designers and researchers and UX people that can positively impact design decisions, I mean business decisions. It's unfortunately detrimental to the decision making if you don't incorporate all the various points of view before making those business decisions. However, the reality is that it's never going to be 100 percent customer decisions.
We're going to make decisions that work for us as a company and work for the customer as well, in most situations. But in many cases, the customer is rarely considered. I think that designers can step up and offer that insight regularly, companies will make better decisions.
Interviewer: So I wonder now, what's the future of design teams as we know them inside the tech industry? Are we talking about perhaps design teams dissolving and becoming part of product teams, perhaps? How do you think about this?
Jeff: I think this goes back to my first answer. I think that there will always be room for design teams. Think about, if you're familiar, with the Spotify model. That's an interesting model of what to kind of look at.
They've got dedicated designers on cross functional product teams. But there is also a design team, and that design team is responsible for professional development, for support, for inspiration, for discussion of nerdy design things that nobody else wants to talk about. There's always going to be room for that. I just think that if you're trying to staff projects from a central design team, like a central agency, I have personally seen that model fail.
Most companies have seen that model fail ultimately, or they're continuing to try to make it work. The lack of UX strategy as its own unique thing doesn't negate the need for UX and UX designers. It just means that we have to take a holistic point of view. And to do that, you need to be part of a cross functional team. Where all those points of view are regularly available and discussed.
Again, periodically the teams come all to a design meeting, to review, to share best practices, to talk about what they learned, to build pattern libraries, whatever it is. But I think that the internal agency is ultimately an anti-pattern.
Interviewer: What do you think is the future, or the evolution of the product teams within our industry? Do you see any foreseeable way these product teams are going to look like in the near future?
Jeff: I think the future of product teams is made of product design and engineering, and supporting disciplines. What I mean by that is, and when I say design I use it as an umbrella term to really cover all the various forms of design from UX to visual to interaction to content, all the components of the presentation layer from the development etc.
But product management design engineering at the very least and then follow it up with support from whoever else the teams need to be successful.
For example, if you worked in a medical services company you may need subject matter experts from the medical field to help you to do your job well. If you're a financial services you may need access to bankers to help you do your job well. I think that's the key, the point is to make those cross functional teams as autonomous, and empowered, as possible. So give them these outcomes to achieve, these behavior based goals, and then let them figure out how to best get there.
Interviewer: Giving a reduced amount of time for a scope or a sprint, what's the best way to assess what's the right UX research method?
Jeff: The way that I advise teams is to sit down and decide what is the most important thing you need to learn next, based on that, the next question is what is the least amount of work that you need to do to learn that. Then that usually speaks to some kind of activity.
The least amount of work that you can do to learn that is not lazy, it's simply an opportunity to do just enough work to take the next step. That's ultimately the key here, the key is not to do more than you need to. The key is to do just enough to move the conversation forward.
So, those are the two questions that I always [inaudible], what's the most important, and the interesting thing to is when you have those conversations with teams there's usually a broad spectrum of answers to that question: 'What's the most important thing you need to learn first, or next?'. It's amazing how as teams get better at answering that question, the scope of the answer to that question decreases.
For example, let's say you were building a new financial services, or just a new subscription product, and you ask the team, 'What's the most important thing you need to learn next?'. Then say, 'Well, we need to learn if people will pay for our service.' That's not actually true.
The most important thing is you need to find out whether or not there is a need for your service. Then whether people will actually value a solution to that need, and so forth. You can move your way through the conversation, all the while, increasing the amount of evidence that you have for investing further in your idea, in your feature, in your product, etc.
Interviewer: Going back to your idea of teams rewarding lounging, not discovery, do you think that there is a right balance between this rapid launching of MBBs versus a thoughtful problem discovery phase?
Jeff: Yes. There has to be a balance. What's the risk? I can't recall, I'm trying to think about if there was ever a time that I was in a situation where all we got paid for was discovery, just nonstop discovery. At some point you have to ship software. Yes, there's a balance. There's a balance of saying, 'We have enough information to take a risk and build something.' When that is, is completely contextual to your business. I would recommend that you build something fairly quickly. Does that mean code? Not always.
Sometimes it's a prototype, sometimes its a wizard of Oz MVP type of thing, where you're faking a service, it feels like a real service but there's not a real service there. The goal is to get your potential customers experiencing what it might be like to use this product or service, and to give you some feedback quickly. The sooner that you get that feedback, you can determine whether you should actually invest-- I think that's the key.
Finding that balance is difficult. It's really difficult because we like to believe that our research activities will yield very clear results. The reality is that they don't often. Sometimes you'll get some feedback from experiments from a research study that says that the audience is split. We could go option A, or option B.
I think at that point you really need to double down, you take a risk and see what happens. The thing to remember is that when you take that risk, it's a small risk. You're not just deploying everything down that one path, your deploying another small step. If it continues to work well, terrific.
If it doesn't, it's OK to go back and try the idea that you chose not to work on. That's the key, people feel like, 'Well, we made a decision, undefined