14. Keeping Product Visions User-Centered (feat. Anna Kaley, UX Specialist at NN/g)
30:56 Share

This is the Nielsen Norman Group UX Podcast. I'm Therese Fessenden. During last week's episode, you heard a number of voices from our extended NNG community and also from our NNG team. One of those voices was Anna Cayley, a UX specialist at NNG, and she's been researching how product teams and UX teams can better work together and also how people can strategize their businesses around a UX vision. ♪

So in this episode, you'll hear our chat about, first of all, what a UX vision even is, how it differs from an idea, how MVPs can sometimes prevent teams from achieving their vision, and of course, how teams can examine their own team dynamics to better achieve their goals. With that, here's Anna Kaley. ♪

Welcome, Anna, to the podcast. Thank you for joining us. What have you been up to the last few weeks? I know I haven't seen you lately, but it's always exciting to hear what each of the UX specialists is up to. So what have you been up to? Thanks so much for having me, Therese. It's good to be with you here today. Really excited to be working on a new course for Nielsen Norman Group.

So the course is called Product and UX, so Building Partnerships for Better Outcomes. So really excited to be working on that, digging into lots of research with practitioners, product teams that are having success with collaboration between product and UX, and of course, engineering as well. And so diving into lots of research, lots of theory, lots of practical application. And I'm really excited about how that

course is shaping up. I think that's going to be something really valuable for the UX community to, you know, not only kind of understand where product partners and product professionals are coming from, so be it product managers or product owners, but then also kind of thinking about, you know, we all want the same things in product development. You know, we want to make a positive impact for

the users that we're serving and then also the businesses that we work for. So how can we kind of break down some of the tension that sometimes tends to arise when maybe we don't have clear communication or maybe we're really not bringing everybody along in the right ways or we don't have kind of clear intentions or clear outcomes or maybe we're lacking a bit of vision. And so we're really excited for how that's all kind of coming together.

and developing a framework to help product teams kind of navigate that in a better way. So that's been a lot of what I've been working on. And then I'm also really excited to be working on a new UX vision and strategy series with our chief designer. So me and Sarah Gibbons in collaboration working on that series. So really excited about that as well. So

all about thinking through, you know, we talk at Nielsen Norman Group a lot about, you know, design best practices and creating fantastic artifacts. So journey maps and service blueprints and all these great things. But as kind of UX practitioners start to kind of rise into leadership roles or even have these opportunities to demonstrate more leadership, how can we really start to think about kind of setting a really strong UX vision? And then ultimately,

What can we do to kind of communicate our plan to kind of work iteratively over time to kind of moving closer to achieving that vision?

And so that's really where our strategy comes into play and how we can think about using tools like a UX roadmap to really help us get there. So Sarah and I are putting together five dates that will go very in-depth on all things UX vision and strategy. So between those two projects and those two new initiatives, I've been keeping very busy. I was going to say, do you sleep?

sleep a little bit here and there, but all the work is so exciting. So it's really motivating at the same time. So though I sleep, I'm also really excited to get to work on this stuff every day. Yeah, I'm excited. I think this is both of those topics are so important and I feel like they come up time and time again, no matter what class I'm teaching. And I

Thinking about vision, like I think of the word vision and it feels important and, you know, it's an important part of how we do anything in life, but it also kind of feels nebulous or like kind of hard to really obtain because it often doesn't really feel like a tangible thing. So what makes, you know, something a UX vision versus like, oh, I just have this really cool UX idea?

Yeah, that's a really great question, Teresa. So thinking about a vision, so if we kind of think about the definition of what a vision is, it's kind of this impactful future state view that, you know, either you have with an organization or

that a user has with an organization could even be a service. So kind of this, this impactful, purposeful kind of future state view. And if we don't have a vision or if we don't kind of have some purposeful, you know, semblance for why we're doing what we're doing, it's,

really difficult to kind of stay the course and see through kind of different projects we're working on, different initiatives to remember, you know, here's why this is important. Here's the outcome or the good thing or the positive thing that the people that we serve will now be able to do as a result of, you know, our work and really what we're prioritizing, what we're doing. And so thinking about

A vision, you know, it does sometimes feel kind of abstract or a little bit intangible. And that's okay because it truly kind of is supposed to. It's supposed to be something that you're always kind of moving toward and striving to become.

So even if you think about, you know, we use a famous example in one of our courses being a UX leader, you know, thinking about Apple back in the 80s, you know, they were already kind of envisioning Siri and thinking about what an iPad might look like in the 80s. But we certainly didn't have that technology yet. So even as we start to kind of move closer to maybe reaching these visions or achieving these visions, people's needs change.

the market changes, you know, so that may also kind of force our vision to shift just a little bit so that we can continually improving and moving towards something that really has value and really has purpose. So that vision really helps us make decisions about where we spend our time, where we spend our efforts in order to kind of iteratively move closer to that vision. And so really important to have it, you know, without it really hard to make decisions about

We can't do it all. So what should we really focus our time on? What's going to have the most impactful outcome and really move us closer to that vision? So it can feel kind of intangible, but it should be something that's rooted in research. So something that we know people need and people want. And again, kind of that aspirational, here's how we can make things better. I think that especially in these times, I think everyone needs that strong vision, whether

whether it be for themselves or even for the product or service that you're working on. Okay. So it seems like the UX vision would be this kind of purpose behind what we're doing, whereas a UX idea might be a way to obtain that vision, kind of like looking at it as more of a technique or an interface element or a service or whatever that idea might be. Maybe that's a little bit more

not more tangible necessarily, but maybe has a form. Whereas this vision is going to be that underlying why behind it all. Yeah, exactly, Therese. So thinking about your vision and kind of even some organizations will use like

a vision or maybe a mission or a strategy statement. These are all really important guiding principles in product development. Whereas you can kind of think of your UX ideas. So maybe an idea you have for the interface, maybe a new idea that you have to work with customer support or even gather user feedback within an interface or within a part of an experience. All of those UX ideas that we have

ultimately should move us closer to reaching our vision over time. So that's kind of how you can think about the difference where, you know, I have this really great idea and, you know, here's what I think it's really going to do for the people that we serve. And, and really that idea should,

ladder up to or really should noticeably move you closer to achieving that vision. If it's an idea that kind of is moving you away from the vision or maybe taking you kind of in a different direction, that's when it's going to be really important, you know, especially important to rely on your product partners, your engineers to say, I have this idea and

you know, I'd love for you to help me understand if this is going to help us move closer to reaching our vision, or that might also be an indication that we need to do some more research. But, you know, if it's an idea, you know, a tangible idea that isn't really going to move us closer to reaching our vision, there might be

need to be some reprioritization or maybe collaboratively thinking through, okay, this is a solid initial idea. Here's how we can kind of develop that further or iterate further to really help us achieve our vision. So that's how I kind of like to think about the vision piece versus kind of individual ideas. Okay, that makes sense. Yeah.

Yeah, I can imagine that moving toward that vision sounds great and simple in theory, but I imagine in practice is a lot harder to actually do because there are so many competing priorities, whether that's the priority of, say, marketing or sales, but then also the priority of, say, engineering, where maybe they have a lot of feasibility concerns and such. So in terms of these lean and agile frameworks, the concept of MVP is...

reign supreme, right? The minimum viable product. So when I think of minimum viable product, sometimes they seem like

seem like they might fall short of many UX visions. So how do these frameworks fit in with achieving a UX vision or do they not fit in? What's your take on this? Yeah, that's a really, really good question. And MVP, minimum viable product, my goodness, there is so many misconceptions in our field around that concept. And there's a lot of different ways you can think about

an MVP and certainly, you know, a UX vision isn't something or even, you know, a company vision. So if you're thinking about, okay, I work in a huge enterprise and you may have kind of an overall company vision, you may even have a product vision and you might even have kind of a UX vision as an extension of both of those that, that certainly nicely kind of fit together as puzzle pieces or kind of ladder on top of each other. But regardless of kind of the vision that you're referring to and you're really driving toward achieving, you know,

even in kind of a lean UX and agile way of working. So whether you're working in Scrum or Safe, or even if you're kind of transitioning from Waterfall to one of the agile frameworks, you know, working in agile is a mindset. So you still want that

product vision or that UX vision to really help you and kind of guide you in making decisions about what you're going to work on each increment or each sprint. And so really, you know, you still want to have that strong UX vision, even working in Agile, if not, may even be more important in those cases where you've got a lot of different competing priorities and you really have to focus on, you know, how are we going to spend the next two weeks, three weeks, six weeks, however long that might be. And so,

I really think with MVP, you know, again, that minimum viable product, you know, I, there are so many thoughts that I have about it, but I think that key word in there is viability. So with a minimum viable product, so viability inherently means that it has the propensity to actually work for the business. So it has the, the,

opportunity to actually be successful. And I think that that's what some teams sometimes fall short of in thinking that MVP is just the fastest kind of

quickest thing that we can get out the door, but it's really not. It's thinking thoughtfully about, okay, if this is our vision, if this is really where we intend to go, what's the smallest increment of work that we can put out that truly supports that key value proposition that has the opportunity to really evolve into something that's viable so that we can learn from really quickly and

without extending, you know, overextending ourselves in terms of effort. So it has to be something that really does support an end to end experience that a person actually needs. It should also that MVP should still be kind of a stepping stone towards your vision. It shouldn't be kind of a, oh, let's just try this and hope for the best. You know, there really should be some grounding behind it to say, okay, this may be our first step into

into this space to move us closer to a vision. So the other thing I think teams often forget, and we talk about this a lot in Lean UX and Agile, is that your MVP is

Again, doesn't need to be just the most haphazard thing we put out. It still needs to be thoughtful. It still needs to support an end-to-end experience and kind of uphold a standard of an experience. But it doesn't always have to be working code either. I think some teams tend to forget that. With some of the amazing prototyping tools we have in Akshar and Figma and models like Wizard of Oz or concierge prototyping, there's a lot of ways to still kind of get that learning in.

from an MVP without launching code. In some cases, that may make sense. But in other cases, we can really kind of experiment and learn about this viability without kind of putting the most haphazard thing out into the market. And that would be kind of counter to the goal of MVP.

So still lots to kind of clarify, I think, in terms of our field when we think about that concept of minimum viable product. Yeah. And I love what you said too about viability, not just being, does it work? But like, actually, is this viable in our market? Is this viable for the business to sustain an end-to-end experience? Because I do think a lot of

companies go into MVPs with that idea of, we're going to get it out there and then we'll patch it up as we go, which I know to some extent you might have to, but there are so many other ways that you can test whether something is really going to be viable. So I think that's a really important point.

Yeah, doing some of that testing, I think early and often as well, kind of in that prototyping stage helps you just kind of diminish the risk that when you actually do launch, you know, you actually do have kind of your first release to the market. It just diminishes that risk that you get it wrong the first time, you know. So obviously, if we're doing our discovery research correctly, if we're kind of working with users along the way, it also helps to reduce that risk.

But I think, you know, that viability is so key. You know, does this have a solid chance to actually work and sustain our business, but then also serve our users as well? Yeah, for sure. And keeping with that UX vision, is it actually bringing you there? So is it a step down to there? Yep, exactly. Yeah. So when thinking about this UX vision and all of the steps leading up to actually achieving, and I know achieving the vision is,

might even be like who, who really achieves? I mean, it's usually like a moving target, right? There's usually like some ways to evolve that. Right.

Exactly. Yeah, it is kind of one of those things that, you know, even as you might get really close to achieving it and then there's always going to be something else, you know, okay, let's continue to do research with our users. Let's continue to look at our market. Let's continue to look at needs of both users and the organization. And often, you know, that vision will kind of shift or kind of change over time, you

incrementally and iteratively, just like our products tend to. So yeah, it is kind of a moving target. It's one of those kind of aspirational things that we're always kind of striving to move closer to. Yeah. So yeah, in thinking about that in this

this target and who ultimately crafts it? Because, you know, there could be a lot of people who have a vested interest in this vision. So should it fall to someone as like the ultimate decider of the vision? Like, should it be executives, shareholders, UX people, product people? What do you think of this?

Yeah, I think that that's a really good question, Therese. And I get this one often, actually, in our course, being a UX leader, you know, thinking about, you know, I'm just UX, like, do I really have any influence or any say at that kind of company vision or even product vision kind of level? And I really, I tend to believe that UX people do have the ability to kind of influence or even impact people.

that vision. So maybe they may not be the people crafting that vision statement themselves, or, you know, it may be done in collaboration with multiple different, you know, cross-functional groups. But I think that the knowledge that we have of users, and I think kind of the

immense amount of research we're often doing. So the insights that we have, and then hopefully that we're also kind of sharing with our other team members, I think we have tremendous value and tremendous insight to feed what ultimately is communicated in that vision or how that vision ultimately comes to life. So, you know, maybe at the company level or even a product level, we're working with our leaders, we're working with our product partners, marketing, um,

lots of different teams to kind of craft that vision or kind of impact or influence that vision. Whereas if we're even finding our UX team or our product team is kind of being pulled in all these different directions and we don't quite have a strong sense of how to prioritize and where to spend our time, then I really think UX can be someone who stands up to say, this feels like a lack of vision.

We're not aligned on our purpose. We're not aligned on where we should be spending our time, what we should be focusing on. Let's take a pause. And we also offer up a visioning framework, workshop framework in our UX leader course, where UX practitioners can be the ones to lead this and infuse a lot of those insights that they carry and bring those to the table in terms of crafting that

vision. So I think, you know, at the higher levels, you know, UX can absolutely influence and impact that vision. Whereas even kind of at that lower level, be it for their own UX team or their product team, they can kind of be the one to say, feels like we're going off course in a lot of different directions. Let's reset and let's think about defining a vision together collaboratively. So with engineering, with product, so that we can kind of move together, move forward kind of in this really aligned,

partnership so that we can prioritize where to spend our time and what's really going to be best for users and the business. So I think UX has a tremendous opportunity to kind of step up and again, influence, but then also be kind of the initiator as well. Yeah. On that. Yeah. On the topic of responsibilities and UX and products, since those did come up quite a bit as you know, the,

basically they can be the indication for whether we're following that vision, right? Maybe it's UX that speaks up or maybe it's even product that speaks up like, hey, we have this roadmap and this seems to be a different or unrelated task. So in thinking of these two groups,

I think there's a lot of overlap, which can be a really good thing. There are also lots of cases that I've heard of, at least, of butting heads over who is actually the owner of each of these respective things. And so this is deviating a little bit from UX vision, although I'm sure it has a lot to do with the UX vision. But...

Because UX does overlap with so many departments. I've seen this too with marketing, right? Where everyone kind of wants access to customers and

you know, research with them and marketing often has a lot of those research opportunities and UX also wants those. So, you know, how does one negotiate these types of overlaps? And I guess, especially since you've got that UX and product course coming up soon, let's looking at it from that perspective, how do we negotiate those differences and, you know, those overlaps?

Yeah, absolutely. I think there's a lot of discussion about kind of role overlap in our field and kind of in the tech realm in general. So I think acknowledging the overlap exists is a really healthy thing to do. But just I think talking about the fact that the overlap exists.

is kind of a little bit short-sighted. Like we also have to think about, okay, this is happening. We have to maybe ask why it's happening. And then also how can, you know, since it is happening, how do we navigate it? So how do we kind of make sure that if we're unclear on who's supposed to do what throughout product development, that we kind of say, you know, we kind of take a pause or we stop and we say, okay,

Here was my understanding, you know, for example, as UX, I'm going to probably be the one to conduct user research and discovery and collaboratively with product do that research and maybe some of that collaborative analysis and synthesis. And then maybe we'll move into product.

maybe like an alpha phase where we're looking at lots of different prototype ideas and we're maybe starting to test some of those. So if at any point there's someone who's like going off on their own and maybe creating wireframes, who's not UX. So just kind of an example that often happens or that people often ask me about my product manager or product owner. If you're working in scrum,

just kind of came to a meeting with wireframes and it made me feel like I wasn't maybe focused on the right things or that I wasn't a good designer or that I wasn't a good prototyper or, you know, there was this breakdown in communication. So I think acknowledging that, you know, it doesn't often happen that overlap because someone is trying to be malicious or trying to, you know, throw someone else under the bus. That's not often why it happens. What I'm finding in my research is that there's two main reasons.

It's a lack of context and clarity around kind of how the product development process works. So maybe there isn't really a clearly defined process or even a clearly defined model that everyone's aligned on. And then secondarily, just good old fashioned communication breakdowns. So I think in technology, we're trying to move so quickly in our fields, both product, UX, tech, CX, all of it. It's all...

growing so quickly. So lots of people are trying to kind of come into the fold and get ramped up really quickly. And so sometimes because we're trying to move so fast, we don't have some of those conversations about, I

here's how I'm envisioning my role on this project or this product. Or if you're more working on features, that's important to know too. What type of team are we working with? Are we working on a product? Are we working on a project or a feature? And that's really going to change some of the role dynamics as well. So it's not so much... There are things that we have to negotiate and navigate along the way, certainly. But I think

fundamentally and really foundationally, it comes down to being really clear about, you know, here's how user centered product development works. Here's where everyone can kind of shine and maybe share some ownership, but also establishing some healthy boundaries.

But then also in those moments where conflict may arise, how can we think about in a healthy way? Because conflict can be healthy. Competition can be healthy. It's when it moves to a place where it starts to be detrimental to productivity, detrimental to the product, or even detrimental to people's

people's individual contributions and their morale that we want to really think about addressing it. So I would say negotiation, I think probably is, you know, of course, something we need to think about, but I think we don't have to do as much negotiation if we have kind of clear roles, clear responsibilities, and kind of clear communication throughout. And then in those moments where we need to negotiate, we just kind of

think about the needs of our team members. So our product owner, our product managers, they're really responsible for making decisions. So as UX, what we can do is really kind of come to the table and say, product owner, I acknowledge that you need to make decisions in order to get a good product. And so maybe instead of saying something like,

We just need to have a consistent look and feel, you know, as UX, we can think, okay, that consistent look and feel that's going to translate to maybe, you

cost efficiency in terms of implementing new features or new components. And so that's something that our product owner, our product manager cares about. So we care about having this consistent, really amazing design and look and feel. Our product owner or product manager may not see that right away until we as UX can kind of translate that

into something that really gives them a good basis for better decision-making. And so I think that fundamentally, in addition to that kind of clear process, clear communication, really understanding how we can connect our work to factors that our product owners care about in their decision-making is where things really start to get good. But I would say it takes practice on the part of UX.

And it also takes acknowledgement from our product partners as well. We truly are supposed to work in product development as partners. UX doesn't report to product. Product is not the boss of UX. And so I think sometimes we forget that and we have to kind of acknowledge, okay, here's what you need from this partnership. Here's what I need.

and making sure we're kind of acknowledging that along the way. You know, for a field that's supposed to be so based on empathy, sometimes we do forget to kind of empathize with each other throughout the process. Yes. And I just, I love that you use the word partners because as you were talking about communication and establishing responsibilities and really just being open and clear about those responsibilities,

And how a lot of this has to do with communication breakdowns. The first thing I thought of, I'm like, it's kind of like a marriage, right? Where you have this, you kind of have this relationship, right? And the two, again, not necessarily being the boss of each other, but being two that work together. And when they do work together, create this really fantastic outcome, which is a product that's really well-informed and a UX team that's able to make these iterative changes really well. So, yeah. Absolutely, yep.

Anyway, yeah, just...

I just love metaphors like that because I feel like it does help in those moments where I'm just grumpy or, you know, starting to be a little curmudgeon about, oh, well, this person didn't bring this up or, oh, here I have to go again, you know, clearing up the air. But that's such an important part of our work. Like, I think there's just a lot of, I don't want to say politics, but certainly a lot of deconflicting, you know, or basically making that communication a lot more clear. So, yeah. Absolutely. Yeah.

And I think a lot of that too, you know, when we think about viability, feasibility and usability or desirability, you know, I think that there are that kind of, I'm thinking of like the three circles and overlapping in the middle, all of us are responsible for value at the end of the day, value for the people that we're serving and value for the business.

But we can kind of think about, okay, UX is really centered on that usability, that desirability. Engineering is really focused on that feasibility. Product is really focused on viability for the business. And so I think remembering and kind of coming together in the middle of that is value. And the way that we kind of maybe think about our independent disciplines, but then how they all come together to create value, that's really what we have to remember.

And that's not to say that engineering can't also be focused on viability or focused on desirability and usability. We kind of all have to keep each other in check when we're working together. But that's kind of how I like to clarify, you know, who is really responsible for what. And then where those overlaps exist, that's where we're really seeking to come together to drive value for people and also for the business. Yeah. And thinking of value too as...

I feel like it's often a buzzword that isn't really appreciated enough. I mean, value is how meaningful an experience is to a person. And I think if we can kind of remind ourselves that that's the ultimate outcome, then all of our efforts could be much better aligned. And I feel like it would be a much, much better outcome overall.

Awesome. Well, can you believe it? It's already been a half hour. Time has flown by. So to kind of close out, if there is any way people can follow you or your work, are there any channels or websites you can point people to?

Absolutely. Yes. Feel free to follow me on LinkedIn or Twitter, whatever social medias everyone is comfortable with. So I'm at akaleeux on Twitter and then Anna Kaley on LinkedIn and always love to keep in touch with other people.

other practitioners in the space. So feel free to follow me. So Anna, that wraps it up. Thank you so much for your time. I've had so much fun and I feel super inspired to just pursue my own vision. So thank you. Awesome. Thanks so much for having me again.

That was Anna Kaley. Her UX Vision and Strategy five-day series with Sarah Gibbons begins on October 18th. So if you're interested in learning more, make sure to sign up at our website. But regardless, if you join that series, remember that we have thousands of free articles and videos and other UX learning resources. You'll find all of those at nngroup.com. That's N-N-G-R-O-U-P dot com.

And of course, if you like this show and want to support the work that we do, please leave a rating on Apple Podcasts and hit subscribe on the podcast platform of your choice. This episode was written and produced by me, Therese Fessenden, and all post-production and editing was done by Jonas Zellner. Thanks for listening to today's show. Until next time, remember, keep it simple.