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 Laubheimer 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 Laubheimer.
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?
Like, 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 research papers and open data sets and things like that.
They were kind of linked data that was shared. To kind of sum it up,
you know, 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 is a whole sort of sub-discipline within UX that is really obsessed with that concept, you know, 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 about-ness 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 awful.
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 know, I spent I did my time in agencies and things like that and working with clients and on projects that,
you know, would vary from things that were kind of more marketing focused to things that were really all about taking big complex work problems and putting a smiling face on them.
So that's kind of how I made the connection with that.
And so, you know, what I found over the years is that my real area of interest in UX, 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 UI,
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,
I guess we'll 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 set 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 and how to make, you know, e-commerce or your 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 on making the tools that we use for work,
where we don't get a choice as to what the tool is.
The 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 and we're 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, 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, you know, 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?
Right? So I think about it like, you know, for consumer products,
the simplicity that we're trying to do is we're trying to hide the inherent complexity of the domain, right?
And make users not worry about it at all. Like e-commerce behind the scenes is remarkably complex, right?
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, you know, buy paper towels or whatever it is they're trying to get to, right?
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, right? It's not going to enhance their decision making to be aware of any of that complexity.
But if you have a, you know, 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 don't, they base their decision making on subtle nuances in 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.
And, you know, what's in frame is what I currently need.
And so, you know, I think of that zoom level, whether we're talking about literally zooming into a data center,
we're talking more about kind of abstraction of sort of, here's the total set of things available to you.
Let's kind of 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.
One of the people working there was a guy named Larry Tesler. And Tesler, he came up with Tesler'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 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, you know,
I've heard a lot of people refer them as just like a metrics garbage can, right, where we just take whatever metrics are available to us.
And we, you know, 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.
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.
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 Desperat. I'm probably mispronouncing his name, unfortunately.
Listen 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.
You know, basically kind of many indicators of are you looking at something that's good or it's bad, right?
Is this something that's kind of a – 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, you know,
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, you know, 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?
You know, whatever it is, 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.
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 that we should think about more?
So, 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 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 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 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 what they are doing a good job at work,
but our interface is kind of communicating a little bit differently from that.
So definitely some food for thought.
Yeah, alert fatigue is real.
I mean, it's as real as, you know, the sort of notification fatigue we get if we let Twitter blow up our phones all day long.
And, you know, 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 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, you know, 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. 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,
that 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,
if I, you know, I'm an information architect by training,
right? If I went into your house while you were sleeping and rearranged your kitchen cabinets
so that they were organized more logically,
right? 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, you know, things are, you know,
maybe the organization is superior,
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 did I leave my cast iron pan, right?
Which one of these cabinets could it possibly be in?
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 loop, 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,
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 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, you know, one of the other things is give people an opportunity
to kind of switch back and forth between old new versions for a while
as they get used to things.
That's really, really helpful to people.
And, you know, give them some sense of control
that the final switchover to the new system won't happen on a day
where they have some, you know, some big project due, right?
Where they have some big deadline that they have to, you know,
now deal with, you know, your changes too.
So 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.
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,
and I love the phrase information architecture
because it's not like a smattering of, you know,
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 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 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 the things people use every day.
That's not the right way of thinking about it
because you're just kind of constantly leaving people unbalanced.
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 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 like comedy improv,
but, you know, 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 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 two better solutions can often, you know,
helping them kind of arrive on those better solutions on their own
is a good way of thinking about it.
But, you know, 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 like 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 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?
You know, 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 co-workers.
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 know, 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 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.
Yeah.
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 under, 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 page 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.