7. Lessen Digital Misery with Complex Apps (feat. Page Laubheimer, Sr. UX Specialist at NN/g)
30:14 Share

This is the Nielsen Norman Group UX Podcast. I'm Therese Fessenden, and this month, I got a chance to interview a librarian. Okay, he's not exactly a librarian anymore, but he was one before he came to Nielsen Norman Group. Paige Laupheimer is a senior UX specialist at NNG who's quite passionate about two big topics, information architecture and complex applications.

In this episode, we got a chance to chat about a lot of things: how simplicity is not so simple in the context of complex applications, how to ensure our dashboards don't become thoughtless dumping grounds for data, how to handle redesign of a complex legacy system, and how to ensure your design recommendations are taken seriously by peers and stakeholders alike.

With that, I'm excited to introduce this episode and our guest, Paige Laupheimer. So I guess to introduce the episode and to introduce you, your background, I remember getting so excited when I heard about this, your background's in library science. How did you go from library science to where you are now? How did you decide that UX is your true calling?

Yeah, so I, you know, wanted to be a librarian growing up because I was a huge nerd and spent a lot of happy hours in libraries as a kid. So, you know, I went and I did the graduate school thing. And once I got finished, I spent time

working in science libraries, so kind of academic, big federal government science libraries. So I was working for kind of a sister agency to the EPA that focuses a little bit more on environmental exposures and health outcomes. And I was working in the library where

We would get requests from researchers, you know, scientists who were working on something and they would say, I need every paper ever written on the connection between these two different things. So I would spend days putting together these complex searches in databases full of both research papers and open data sets and things like that. They were kind of, you know, linked data that was shared publicly.

To kind of sum it up, I started off as a librarian because I was really focused on helping people find information that they cared about. And it turns out that there's a whole sort of sub-discipline within UX that is really obsessed with that concept, information architecture. And so I found...

myself applying a lot of the things that matter as a librarian, right? How do we sort of describe the aboutness of a resource in a way that is both kind of logically consistent and obvious to people? And then the other way that I really found a connection between these things is that a lot of the interfaces that people use in kind of the academic and science world to find information are

I mean, just the pit, right? And I found this sort of inner complainer in myself, you know, kind of really focused on what is wrong with this thing that I'm looking at? Why is this so unbearably confusing? And from there, that kind of led me down the path of learning a lot about human computer interaction and, you

I did my time in agencies and things like that and working with clients on projects that would vary from things that were more marketing-focused to things that were really all about taking big, complex work problems and putting a smiling face on them. That's how I made the connection with that. What I found over the years is that my real area of interest in UX is

I'm really particularly obsessed with two things. And one is information architecture. You know, the more I hear about trends like kind of throwing AI at everything, throwing machine learning at everything or search or conversational UIs, whenever I hear those kinds of trends like coming more and more to the fore, the more I think

you know, really these are the most expensive, complicated and error prone ways to solve problems that are oftentimes really just information architecture problems, right? Like how do we organize things so that people can get to what they're looking for with the least amount of mental effort? And oftentimes we are, you know, people kind of throw up their hands and they say, all right, I guess we'll, you know, build a huge complex machine learning system in order to solve that problem. And I often think that's,

you know, a questionable choice. The other side of things that I really care about is complex applications. You know, the things that people use as part of their work. So, you know, I think there's plenty of minds that are thinking pretty clearly about consumer-grade UX, right? And how to make

you know, e-commerce or your like consumer app as easy and fun and to use and all that kind of thing. Right. But I think there is a much smaller group of people who are really focused

focused on making the tools that we use for work where we don't get a choice as to what the tool is. This sort of complex app world is the place where UX people have the most opportunity to reduce kind of digital misery is the term I keep kind of coming back to, is this sense of, you know, people who have to use these tools all day long for their job and they're staring at them

day in and day out, and it is full of drudgery and it's full of, and we're like taxing people's cognitive resources all day long. So, you know, those are the two things that I think are kind of most interesting to focus on in UX these days for me, at least.

I love that phrase, "lessen digital misery." I may make that the title of this episode just because it's so on point. It is so on the ... I don't want to say on the nose, but it's just so accurate when we think about B2B or enterprise types of solutions, which again, to your point, are things that people often don't have a choice in using.

So I guess a follow-up question to that, which is, I think you mentioned putting a smiling face on these complex workflows and a lot of our energy mantras, or at least the main energy mantra of this, particularly of this podcast is keep it simple. So what is...

the way to think about complex application design. Like how does one simplify a complex workflow when it's complex, you know, by default? Is there an answer? Like, does one simply simplify? Like, what is your wisdom here? What would you advise? Yeah. So I chuckle about this all the time.

In the complex kind of application world where you're often dealing with stuff where, I mean, not to put too fine a point on it, but I think there's kind of an upper limit to how much simplicity you can employ in these kind of contexts, right? I mean, keep it simple is a great mantra to hold, but I really think one of the things that we need to...

kind of return to is, are we trying to hide the complexity completely from the user? Or are we trying to just show the piece of it that's applicable at the moment? So I think about it like, for consumer products,

The simplicity that we're trying to do is we're trying to hide the inherent complexity of the domain and make users not worry about it at all. E-commerce behind the scenes is remarkably complex. The logistics, the fulfillment, managing millions of SKUs,

Creating a navigation system like an information architecture to access those millions of SKUs so that people don't lose their minds trying to buy paper towels or whatever it is they're trying to get to. All of that's really complex. But in that world, in the consumer world, we're trying to hide all that complexity from our users because they don't care, they don't need to know about it. It's not going to enhance their decision-making to be aware of any of that complexity.

But if you have a geneticist who's working with CRISPR technology, you can't hide that stuff. Because first of all, you as the UX practitioner probably don't know what's really applicable to that person at the moment, right? They're the expert and you're not. And also, if you hide that stuff, they don't love it, right? They base their decision-making on subtle nuances and things that you could never have expected. So...

I think about simplicity being more about the kind of level of abstraction that's currently in view, kind of like the zoom level, right? You know, on Google maps, if I am looking at my local neighborhood in Google maps, because I'm trying to find like, you know, is there a hardware store nearby? I know that the rest of the city still exists around me. I just don't care about it at the moment. Right. And I,

what's in frame is what I currently need. I think of that zoom level, whether we're talking about literally zooming into a dataset or we're talking more about abstraction of here's the total set of things available to you, let's zoom in on this smaller subset right now.

So that's where I think about simplicity being really important. And the way that often plays out is in focusing on the ways that we can kind of reduce the number of things that people have to keep in their kind of short-term working memory at any given point. That's where I think of simplicity as being really important. So, you know, at Xerox PARC back in the day, right, the sort of research agency that, you know, invented the kind of modern graphic user interface, right,

One of the people working there was a guy named Larry Tessler. And Tessler, he came up with Tessler's law, right? It sometimes gets called the law of conservation of complexity, right? There's a certain point where you can't reduce complexity anymore. Simplicity is not necessarily the answer. So.

Yeah, that's how I think about it. Yeah. There's only so much you can simplify and you still kind of have to offer people options. They still need a way to navigate these big complex workflows or data sets, whatever it might be. On that topic of how people navigate and make sense of things,

a pattern I've seen dashboardization, at least that's what I call it. The dashboardization of things, usually kind of intranets and enterprise apps. But what do you think of this trend of using and relying upon dashboards as a way to communicate meaning? Yeah, dashboards. So, you know, I saw pretty heavily, I think

I've heard a lot of people refer them as just like a metrics garbage can, where we just take whatever metrics are available to us and we choose a data visualization that's appropriate for it. And we try and squeeze as many of them under screen as possible. And then we let people look at them and kind of make no sense of it. Dashboards, when they're done well,

They're all about managing attention, I think is the way I think about it is we often have a large amount of data. And the point that we're trying to do is draw people's attention to the things that are either potentially good or bad that need some sort of human decision making applied to it, some sort of human sense making, right?

And so, you know, just because you have a lot of metrics on a dashboard doesn't mean that anyone's going to be able to draw the right conclusions from it. You know, a big part of good dashboard design is really understanding what the metrics are that you're dealing with, right? What kind of numbers are you dealing with? What are they measuring? What is the kind of inherent instability of those numbers?

And then understanding what's a good and bad sort of threshold for them. There's a great researcher named Nick Desparat. I'm probably mispronouncing his name, unfortunately. I listened to a talk with him a while back where he introduced a concept of basically valence, like emotional valence that we talk about in psychology of this sort of positive or negative direction of an emotion.

and talked about it as a way of thinking about what belongs on a dashboard. Basically, many indicators of are you looking at something that's good or it's bad? Are the numbers you're looking at something that require your attention, require your sense-making?

And he also proposed something that I think is just brilliant in its simplicity, which is the idea of instead of using one threshold for any number to tell you, is this good or bad? He proposed something called the four thresholds. And I think this is so good, right? Below this threshold, we're in crisis, right? The point which you'll literally drop everything to resolve this. Then you have kind of actionably bad where,

It's bad enough that you'll actually do something about it, but probably no one's going to get fired or screamed at over it. It's just like, okay, we have to do something about this. And then there's a sort of neutral zone. Then you have actionably good right above this number. Things are going well. Let's find out why. Maybe can we apply something that we're doing here to other areas of the business? Or can we give a bonus to the person who came up with something really smart? Whatever it is.

Um, maybe we should add more team members to it, expand that project, whatever it is. And then, you know, a threshold for extraordinary, right? This is beyond our wildest expectations. Um, and we really need to understand why this is doing so well. You know, is there maybe something that we didn't account for? Was there some sort of assumption that we didn't, that was wrong or we didn't understand, um, that we should think about more. So, um, yeah.

You know, dashboards, they live and die by whether or not you're actually answering questions for people rather than just saying, oh, you know, the executive, the VP I'm talking to asked me for these five metrics. And so I'm going to put them on a pie chart, you know, in front of me. And to really kind of dig in and say, OK, what how did these affect your decision making? That's going to tell me everything.

how I'm going to visualize it and what sorts of, you know, thresholds I'm going to put on this. So I'm telling you when you need to pay attention to something. And also so that I'm not, you know, alerting you constantly to things that don't really require your attention, right? You know, they need to be more than just sort of like a screaming crisis center for them to be effective. I love that you talked about that valence of emotion because I,

That is something that's going to affect people day in, day out. Are we screaming red alerts at everyday users for something that really isn't that important, but now is going to impact kind of their emotional well-being? Because now they're thinking, am I doing a good job at work? When in fact, they are doing a good job at work, but our interface is kind of communicating a little bit differently.

differently from that. So definitely some food for thought. Yeah. Alert fatigue is real. I mean, it's as real as the sort of notification fatigue we get if we let Twitter blow up our phones all day long. And by the end of the day, we

want to, you know, curl up and into a ball. The same thing goes with dashboards, right? I mean, you know, if we're constantly pinging someone and saying, this metric is one-tenth of a percent below, you know, some arbitrary threshold we decided, you have to take it, you know, you have to drop everything and take action now. And we kind of run into a vigilance problem, right? Like people can't stay attending to that all day long and have any kind of cognitive resources left at the end of the day.

Right. Yeah. On the topic of looking at the systems we have and trying to design them to be a little bit better, I kind of want to tackle the big question of redesigning a legacy system because I'm sure a lot of people listening right now are like, I know exactly which one I want to redesign. So if...

If you are redesigning a legacy system, I know a lot of teams are often faced with this decision. Do we just start from scratch and build something brand new? Do we throw the baby out with the bathwater, which is, I think, a horrendous metaphor, but I'm going with it. Yeah. Where does that come from?

I know, right? But the thought of doing that starting from scratch can often be appealing. But at the same time, there can be some merits to that legacy system as miserable as it might make people. So what advice can you give people as they're facing this Herculean effort of redesigning a legacy system or a system that people are already used to using?

Yeah, this is the part of UX that I think doesn't get taught in a lot of schools as much as I would love to see it happen, the kind of change management side of things. Because if you have something that's been around for a while, there are people who are very, very used to how it works. They're very, very used to where things are. And when we change things arbitrarily, not only is it frustrating to them, it also completely rips up their productivity, right? I mean, it's the kind of... The metaphor I use a lot when describing this is...

I'm an information architect by training. If I went into your house while you were sleeping and rearranged your kitchen cabinets so that they were organized more logically, no matter how good a job I did, you would be, first of all, freaked out that I did that weird thing. But also, you'd be extremely upset when you try and cook a meal, even if you recognize that maybe the organization is superior to

But you don't know where anything is. Right. I moved recently. And so trying to figure out while cooking, where is, you know, the strainer? Where is, you know, where do I leave my cast iron pan? Right. Which which one of these cabinets could it possibly be in? So.

So what the biggest piece of advice for changing and redesigning things that people use every day is to go slow, right? To change one thing at a time.

And also to bring in as many of those users as possible, not only in your research process, but also kind of having a closed feedback loop with them too, where they feel like they have an understanding of why things are changing, that they have some say in what that will mean.

what it will look like when they're changed, that if they run into frustrations, there's someone actually listening. And it's not just some sort of tell us what we can do better, you know, form field in an email, right? That there's actually a human being on the other side of it who's taking seriously what they're saying. But the biggest thing is just slow change. You know, if you can change one thing at a time, let people get used to it, kind of learn,

Practice with it for a while until they understand how it works and then change something else. That's usually a better approach to it. But, you know, a lot of it are the kind of smaller soft skills, especially if you're designing an in-house application. Go talk to the people who are going to be using it. Right. Do your user research and then also keep in touch with them. Right. Make sure that they feel like they have some knowledge.

sense of agency over what's going to happen with this application they're using every day. It's not easy, but it can be done successfully. And one of the other things is give people an opportunity to kind of switch back and forth between old and new versions for a while as they get used to things.

That's really, really helpful to people. And give them some sense of control that the final switch over to the new system won't happen on a day where they have some big project due, where they have some big deadline that they have to now deal with your changes too. Yeah.

That's how I approach redesigns, but it's always going to be rocky. There's no smooth path to a redesign. And so it's all about kind of minimizing disruption for people and making them feel like they have control over the changeover as much as possible. Yeah, you're right. It's always rocky. I can't think of a single redesign that hasn't had at least some sort of friction or some sort of challenge before.

And what is probably going to be the most challenging for a lot of teams is balancing that feedback, listening to it sincerely, while also still thinking.

and I love the phrase information architecture because it's not like a smattering of user requests or feature requests. It's something that a designer actually has to intentionally put together with the goal of making this understandable. And architecture as a word is just such a good metaphor as well. It's just a collaborative effort, but it's also, there's still an architect who is still managing this whole thing. So

So I guess this is a good final question, which is a tough one, but what advice could you give designers who may have this kind of overload of information, maybe even a design by committee situation where lots of people have an opinion about what this 2.0 is supposed to look like? How do you balance these different goals and these different requirements? I know there's probably no single answer to this, but what would you say is most helpful?

moving forward. Yeah, you're asking the simple questions here, Therese, right? The ones that have a nice little bow to wrap them up in. I really like how you described, how you talked about the information, the architect as actually a really important part of this metaphor, that there is someone who

um knows what they're doing and is making choices because you know even though digital products can be changed easily and quickly there is more permanence to the decisions we make than we often pretend is the case right there's this kind of like lean agile mindset of like move fast and break things and i'm like no not in not in the things people use every day that's a that's

not the right way of thinking about it because you're, you're just kind of constantly leaving people in balance. So the idea that even the sort of smaller decisions have a little bit of permanence is I think an important input to how we kind of manage big changes. And, and,

Being a tireless user advocate is like often the kind of glib, I think, response to this. But that's also a surefire way to make sure that the UX person kind of gets seen as like the grim reaper for every idea, right? Like anyone, you know, everybody else proposes an idea and the UX person is there to tell you why users don't want that and why it won't work for them.

You know, a good way of thinking about it is it's kind of like, not that I have ever done comedy improv, but there's this well-known principle of yes and, right? That when you're doing improv as a comedian on stage, whenever someone suggests something, no matter how harebrained and crazy an idea it is, you always say yes and.

And I think there's something to that as the UX person is that oftentimes, you know, not, not to be like an irritating Socratic, you never give an answer to anything and always ask a question, but there is something to kind of drawing out the assumptions that people are making and kind of, you know, showing them to better solutions can often, you know, helping them kind of arrive on those better solutions on their own is a good way of, of thinking about it. But yeah,

The real answer is soft skills and being able to be a human being that other people want to work with and want to listen to is one of the hardest parts of all of this. And I think that is...

The most undersold skill in UX is being someone that other people will respect and listen to. And, you know, we don't get there by screaming about how like that's not what the user wants and that's not going to help them. The way we do get there is by, you know, kind of showing the math that we're doing, right? Like showing the expertise behind things.

Really showcasing the fact that UX is, I think of it as an engineering discipline, right? It gets sold far too often as arts and crafts. But what we're doing is we're taking a problem that seems superficially simple. And as we dig into it, there is nuance. And we have to guide people through all of the nuance.

but in such a way that we don't end up creating a nightmarishly complex solution to the problem. And that's tough, right? I mean, so we have to be the person that other people are going to listen to and take seriously and building our credibility is, you know, a big part of that is showing the work, not in a way where, you know, we have to kind of

We don't obnoxiously lecture everyone around us, but in a way where people are inclined to listen. And so that's speaking to people where they are, right? The other members of our team, understanding what are the concerns that bother them? You know, what is kind of pushing them to think about this solution as the right way to solve some particular challenge, right? Yeah.

We're really, really good at extending our sort of empathy to our end users, and we're really not as good at extending that same sense of empathy to our coworkers. It's true. Yeah. And yes, and. That technique actually, yes, and, is phenomenally helpful. And I've certainly seen a lot of benefits to that. Because even if you don't take someone's idea straight out of the box, you might want to take that idea and look at it.

and really examine where that's coming from, because it might actually be a very well-intentioned thought that has some credence. And if we can address the root cause of that, like, okay, this person proposed this,

a red alert on the dashboard to kind of bring us back to an earlier example, because they want to be helpful. They want to help someone action on their, whatever it might be, whatever that metric might represent. Maybe it's, you know, actioning some overdue items that are overdue by 30 seconds. So, so this is where we can start asking questions and saying, okay, why do you want to implement this? What is this going to help do? And if,

what it's going to help do is help people action on those overdue items, then maybe we can propose a solution that accounts for that exact need, kind of proving that, hey, we heard you. We want to put this together now and see if this helps our users. And that way you're taking into account your users' needs and maybe their own notification fatigue while also being able to entertain and not just entertain, but really internalize those thoughts and opinions of the

folks who maybe don't have that formal UX discipline, but certainly have that same sincere goal of helping people lessen their digital misery. So yeah, very much a political role. I think a lot of people go into UX not realizing how political it can get. Seriously. Yeah. But yeah, soft skills are extremely, extremely valuable. And if you've got them,

That makes you a huge asset to your organization for sure. Well, Paige, can you believe it? It's already that time. I've had a great time talking to you. If others want to follow you, whether that's on social media or any other channels, where could you point people to? Sure. I rarely but occasionally tweet. My handle is at Paige level with an underscore in the middle.

Very fitting for an information architect, by the way. I just have to put that out there. Yeah, it was specifically chosen. I tend to do more lurking than I do tweeting these days. Most of my writing, I try and do in long form, and most of that ends up on the NNG website at one point or another. Awesome. Well, thank you, Paige. It's great talking to you. Thanks so much for your time. I appreciate it. Thanks, Therese.

Thanks for listening to this episode of the NNG UX podcast. If you want any information on stuff that we talked about in the episode, check out the links we've listed in the show notes found in the description of the podcast. We have a number of upcoming UX certification events, some already happening as I speak.

And we publish free articles and videos every week. So definitely sign up for our weekly newsletter if you want updates on the latest events and UX research that we've been working on. And of course, if you like this show and want to support the work that we do, please hit subscribe on the podcast platform of your choice. Thank you for your support. Until next time, and remember, keep it simple.