Building Engaging User Experiences

Mike Gaigg, author of the Esri Press Book Designing Map Interfaces and UX/UI Team Lead within Esri’s Professional Services shares how thoughtful design helps drive easier collaboration and engagement.

Episode Transcript

(00:00):
From Esri, this is Engagement Matters, a show about people whose work depends on engaging

(00:11):
with stakeholders to make meaningful change.
No matter how you define your community, you can learn from the experts we talked to as
they shared their stories about motivating groups of people to care about issues and
take action.
On today's show, we'll talk with Mike Gaigg from Esri Professional Services as he shares

(00:32):
how thoughtful digital design, also known as UX/UI, helps drive deeper engagement with
users.
First of all, Mike, thank you for taking the time today.
I know you're busy with supporting customers and all kinds of stuff, so I really appreciate
it.
Thanks for having me.
So, before we get into all the work that you do here at Esri and the team that you work

(00:55):
with, I'm curious to get a little bit of the background that you've gone through.
How did you get into user experience and design?
Did you kind of fall into it or was it always a passion of yours?
Yeah, so that's interesting because I started studying computer science back in 1993.
And I was at a time when the internet was really only known to the people that study

(01:18):
computer science that worked at universities.
It wasn't really well known to the public, but really early on I was interested in "WWW",
the World Wide Web.
And I started developing websites back then
it was using the Mozilla web browser and that was before Netscape came around, right?

(01:38):
And everything was done with frames and GIFs and it was pretty fun and everything.
But then, yeah, so eventually I graduated from the University of Salzburg, where I studied
in Austria in 2000, with a Master of Science in computer science.
Then I got an internship at Esri in 2003.

(02:00):
And eventually I actually got hired by Esri and I started working with ArcIMS 3.
I don't know if you remember that one, but there was this HTML viewer and everything
was hidden in frames and JavaScript did some magic and everything.
And it was mostly about functionality.

(02:20):
And I was one of the first persons that started styling buttons and people told me, "What?"
You can change the color of a button?
How wonderful is that, right?
So I became known as the "button guy."
And I think that was kind of the start of this realization that, hey, you know what?
We need more of this.

(02:41):
And so I started building up a team of people and I guess fast forward to now, my team that
I need here in professional services, Esri has 13 people.
We consist of UX designers.
UX designers are those people that focus on the experience of the end user.

(03:02):
We have UI engineers, people that still design, but they also help building the code.
And then we have actually three cartographers on the team too.
So I think as a team, our focus really here is to help people work together to solve problems
for our customers.
And yeah, that was kind of my story in a nutshell.

(03:24):
Yeah, that's really cool.
I mean, and I think it's funny that you're the button guy, you know, I bet there's the
people at Esri that have been here for, you know, 30, 40 years that still know you as
the button guy.
Maybe, maybe.
But I certainly do now, that's what I'm going to call you now, the button guy.
Now I'm actually known as "The Beautifier" because what I hear most of the time is, hey, make

(03:47):
this interface shiny or sexy, whatever that means.
Yeah, I think I'd like "beautifier" better too.
So okay, so jumping into a little bit of kind of like, what does it look like when you're
actually trying to solve a problem for a customer?
Is it just they come to you and they're like, hey, Mike, I hate the way this app looks,
help me.

(04:08):
There's got to be a formalized process that you have to go through to help step people
through designing better and being more user-focused.
Yeah.
So most of the time our customers, when they approach us, they have an idea of what they
want and that's from a business perspective, right?
But what I realize is very rarely they truly understand the problem that needs to be solved.

(04:34):
And so there's a couple of challenges with that, right?
Because I fully recognize people that have an idea in mind.
It might not be the right one.
Sometimes they have a technology in mind, right?
And our approach would be, well, let the technology drive the solution.
In other words, well, there's this mountain full of tools, we call it ArcGIS, right?

(04:57):
You only need to climb that hill and then everything is easy.
But that might not be ideal either, right?
Other times, maybe their managers, their executives, they told them, hey, you got to do something.
And that kind of dictates a solution, which is then difficult because success really means

(05:18):
making the boss happy.
So I think what I realized is that we really should follow some sort of process and we
call it the "double diamond," but it's essentially only doing two things, right?
So first I'd call it user experience research.
You really dive into this problem space and trying to understand what are all the potential

(05:41):
problems we can solve.
And then we narrow it down to the right problem to solve.
And then the second step is to design the application, which is now how do we solve
this problem right.
And figuring out, you know, what is needed in your app or site.
And so that's the process that we follow.

(06:04):
It's really interesting.
And I think to somebody like me, I typically think of like, oh, UX/UI experts, they just
make things pretty.
And it's so much more than that.
You know, like you said, you're looking at requirements, you're trying to make sure that
you understand what's going on.
Do you have an example of a project that you've worked on that makes this double diamond approach

(06:26):
a little bit easier for people like me to get?
Yeah.
So imagine somebody building a trails application.
Okay.
Right.
So we have trails data.
The first thought we have is, hey, let's put it on a map and publish it, call it a viewer

(06:47):
application maybe.
And we call it a day, right?
But actually that's not really the correct approach, because what we really need to do
is we need to first understand the strategy, which means like we need to ask questions
like where are we now as a project team, right?
Where do we want to be?

(07:08):
How do we get there?
And how do we define success?
And here again, it comes down to understanding the business needs.
Like why are we doing this?
What's the vision?
What's the goal?
And then understanding the users and their tasks.
So who are those people that will eventually be using our application?

(07:28):
And it's very easy at this point to say like, oh yeah, it's the general public, it's everybody.
But that's actually not really true either, because then when I ask, well, you say it's
everybody, would it be my mom?
Would it be your mom?
And they say, well, maybe not your mom.

(07:48):
So typically how we go about solving this is we try to define personas.
And you know, personas are those groups of people defined by what they have in common,
like the task they need to accomplish.
And when we now come back to this trails application, we start asking, okay, who are those personas

(08:08):
that use this trails application?
We could say like, okay, well, there are bikers, there's riders, hikers, equestrians, and you
can come up with 15 different personas, but those are actually not true personas.
And we've worked through this, and that's why I'm bringing up this example.

We actually distilled it down to two personas (08:28):
the casual trail user and the professional.
So the casual, those are the ones that are not well prepared, they wear flip flops, they
don't bring any equipment, and they just want to have fun, they enjoy just being out in
nature.
And then there's the professional, so they go out on multi-day activities, they're really

(08:52):
well equipped.
Sometimes they bring their own paper maps, and they need something very different.
They need to find camping spots that are right out on those trails.
And just by having this understanding of these two groups of people, you can already realize
they might even need different maps with different level of detail on the map, different workflows,

(09:17):
what are they looking for, like when they're really adamant on finding the easy trails
versus "I don't care" trails.
And so understanding that there's different types of people with different needs will
then help you to identify the data that is needed to support those personas, identify
any of those gaps in the data.

(09:40):
For example, do we have the opening hours for those trails?
Do we know the status?
Which group of people is more likely to submit an issue with a trail because they truly care?
It's probably the professional.
And then maybe there's a section for a professional and they have certain tools that the other
group doesn't have.

(10:02):
And now maybe you're wondering, okay, how do we even find out about those personas?
Or, you know, how do we go about it?
And it's typically asking questions.
So we talk with people, we interview people, sometimes we run a survey.
And so that's kind of the first step and then the next step is to translate this knowledge

(10:24):
of who the people are, what they do, what they need into some sort of visual, right?
Sometimes we call it wireframes or mockups.
We iterate those visuals.
And that all happens before we start developing and then we refine even during development.
And all this together will then help us to come to an end product that is more useful.

(10:51):
And we know that only if it's useful, people will actually use it.
And that's kind of what I think defines a high quality product that it's useful and is
being used.
So the process is a lot more complicated than I realized.
And I think that example that you talk through makes a lot of sense because it helps me understand

(11:11):
that what you're trying to do is understand the organization's goals first, then digging
into who you're actually serving, then looking at the data you have, and then finally designing
and building.
The design and build is the last part.
And you're doing all this research first to make sure that the tools you build are as
engaging as possible for people.
You want them to use them.

(11:31):
Yeah, that's absolutely right.
And I mean, you said it's complicated, but it's actually not really complicated.
It's more like doing homework.
So if you investigate a little bit upfront and you do a little bit of research, and I'm
not saying days worth of work, it might be only hours, right?
Then that really helps you to avoid unnecessary rework down the road and quite frankly, to

(11:58):
maybe even be hated a little less.
Because I think engaging, making it engaging and as easy as possible is our goal here.
So if your app is too difficult to use or it's not intuitive, users will blame themselves.

(12:20):
So then as you keep trying to make it better, they might actually start blaming you.
And I think that's actually true for external users and internal users.
For external users, once they start blaming you, what happens is they will actually just
simply stop using your applications.
They will just disappear because guess what?

(12:40):
There's actually a rule that says most of the users will spend most of their time elsewhere.
So just thinking that you are the center of the universe is not true.
So you as an application developer or somebody that has an application, hosts an application,
you have to be truly outstanding to be used in the first place.

(13:00):
And then for internal users, if they don't like what they're receiving, then I mean,
on one hand, you could say, well, guess what?
They must use it.
There's no other option.
I mean, they are our slaves.
But the truth is, they will start hating you and they will start sabotaging you.
And believe me when I say that. I've seen it.

(13:23):
And you don't want to get to this point.
So that's why spending a little bit of this user experience up front really pays off down
the road.
And there's another rule of usability, and it states that your application should match
the real world.
Sometimes we also call this the "mental model."

(13:45):
And I could give you an example for that.
Yeah, that'd be great.
Let's assume that we are designing an application for a bookstore.
So the conceptual model is that you have tables full of books, right?
And each table has fields.
A field that might be the author, the title of the book, the year published, etc.

(14:09):
So that's a conceptual model.
Now the mental model is how people see the bookstore.
And imagine you walk into Barnes & Noble's or something, right?
And you look for a book about hiking in the Alps because that's what you do this summer,

(14:29):
right?
Then you go to the travel section.
In the travel section, you look for Europe, right?
And then maybe for, I don't know, some of the countries in Europe.
Or maybe you go to the section that is outdoor sports and hiking.
So as you can see, the mental model of the user is about their tasks, what they need

(14:50):
to do, what they need to accomplish, right?
They would not search for an author necessarily.
They would not search for Austria, right?
Because they are interested for hiking in the Alps.
And so I think the reason why I'm saying all this is if you keep those rules, those usability
rules in mind, and you design with the user's mental model in mind, then your UI will automatically

(15:15):
align better with what the people expect.
And understanding and doing this little bit of research to find out what this expectation
is will then lead to a more intuitive application, which then will be more engaging because it
resonates with the people.
Yeah, I love that example because I think it's something that we've all experienced.

(15:37):
You know, even if you shop for books online, you can search for the exact title of the
book you want, which sometimes you might know.
Most of the time you probably don't, like you're saying.
But you might also see that "you might be interested in" section on the website of books that are
similar to what you're looking at.
So I think it totally makes sense when you're mentioning this mental model because that's

(15:58):
how we operate.
But as technologists and Esri employees, it's really hard, at least for me, not to see everything
as a map, right?
Like, oh, there's a problem, you need a map.
You're saying that to engage people, you have to learn not just how people think, but also
what's the easiest path for them to follow, which might not always be a map, unfortunately.
Exactly.
So what you're saying is like, if I have data and the data is spatial, then it must be on

(16:21):
a map, right?
Right.
Well, I mean, the truth is, there's a lot of value on seeing your data on a map.
But consider the scenarios.
Let's say you're the city of Redlands and you've spent a lot of time on modernizing,
digitizing, and now you have all this beautiful data available to you.

(16:43):
Let's say you have routes of trash trucks, right?
And you have all these detailed routes that go through your city and which day the truck
is at which location.
And your first intuition as a city is you want to make this data available to the public,
right?
You want to show off what you've created.

(17:06):
I think that's great, right?
So now you kind of try to find a use case, or maybe there's actually a use case already,
because people call in and ask you, when is trash pickup day in my neighborhood?
Right?
I say, oh, well, I can answer that question, right?
I have the data.
Let's make it available.

(17:26):
And I think the first intuition is, let's put it on a map.
And then you realize, a map with all those lines really doesn't make too much sense,
right?
So then maybe you start trying to figure out how can you do it better, right?
Well, how about we aggregate all those lines into polygons, right?

(17:47):
And then we have those different colored polygons.
Each color indicates a day.
And then if a resident comes to this map, they only need to click on a map and they
see immediately that there's this one polygon.
Maybe it includes three routes, but it doesn't matter.
Trash pickup day is Wednesday.
Now when you turn the table, and I think it comes back to this question of who is using

(18:13):
this application and what do they need is, do people really care about seeing a map?
Or do they only want to enter the address into a search box and receive the answer "Friday,"
right?
Or "Friday, April 5," or whatever it is.
Yeah, totally.
I mean, that makes a lot of sense to me.

(18:35):
I mean, sometimes I just want to get an answer.
Like I don't want to have to go through two or three different steps.
I think what it really hits on to me is it's hard to engage people to begin with.
And correct me if I'm wrong, but you're saying if we start putting all these kinds of complex
tools in front of people, we'll lose them pretty quickly.
Sometimes engagement is as easy as just answering the question.

(18:56):
Sometimes it's a two-way conversation.
But either way, that whole experience needs to be as easy as possible for people so that
they're not focusing on the process.
They're focusing on actually doing whatever it is that we need them to do.
But sometimes building an easy experience for the end user isn't as straightforward
for a customer.

(19:18):
As I'm sure you're keenly aware, you're challenging assumptions.
You're asking lots of questions.
You do all these things like how do you keep those conversations open and collaborative
so that both the end users that your customers have and the customer that you're working
with both win?
Yeah, I think you bring up a really good point here because it's obviously always a challenge

(19:39):
to balance those two priorities, the end user needs and the business needs.
Because I mean, they are tightly coupled.
There's two sides of the same coin.
And you cannot have one without the other and only the marriage of the two will result
in a successful application.
And I think the challenge that we run into many times is that some people, they don't

(20:03):
have the right words to express what they really want, how they feel, what kind of UI
they need.
And maybe other times people have them to speak up and that's especially true in larger
groups.
So having those conversations is really crucial.
And typically when I get involved in those conversations, I ask a lot of "why" questions.

(20:29):
I try to understand the reasoning behind the assumptions that the customer is making.
And I will ask for those pain points.
What are the pain points?
And you know, once I start asking for pain points, that's when typically people wake
up and say, "oh yeah, well, here's one, here's one."
But yeah, drilling down into this understanding of "why are we doing this" is really crucial.

(20:53):
And I ask why so often that people always hate me.
At first I would say at the end, they always love me.
And yeah, so I think another good approach is really to explain your reasoning, at least
from my perspective, to always try to show examples of what we are talking about, why

(21:16):
one solution is better than the other or why one request wouldn't necessarily work.
And sometimes it's actually this combination of business needs versus end user needs.
Let me give you an example for business needs.
So oftentimes our customers ask us to build a dashboard.
But we know that the target audience of a dashboard is really an executive or a manager.

(21:40):
So it's not really for the public.
So as soon as I realize they're asking for a dashboard, but it's for the
"public," right, I know we're having a problem and we need to dive deeper.
Another example for maybe an end user need is this story that I've heard some time ago
about Facebook, where the number one requested feature on Facebook from users is to see

(22:03):
who has seen my profile, right, to get a list of all the people that have looked at my profile.
Now Facebook already announced that this feature will never ever come because it conflicts
with the business need of the community.
Because once I make this information available, then people will not look at other people's

(22:26):
profiles anymore because they don't want to be discovered, kind of.
So it will never come.
So even though that's the number one request by users, there's a direct conflict with the
business need.
And so you have to always balance those two.
And at the end of the day, I mean, you pick your battles, right?

(22:46):
Sometimes you just let go of a request and other times, especially when I, from my perspective,
feel very strongly about a decision, then I just pick my battle and say, you know, I'm
sorry, that's against all my rules.
It's not going to happen.
So I know we talked a lot about UI/UX, the ideal process, asking all those questions

(23:11):
and why this is important.
I think at the end of the day, after we understand the needs, it's really important to translate
those into a design.
And the typical process that we follow here is we create wireframes and wireframes are
sort of sketchy looking mockups kind of.

(23:32):
In other words, a picture is worth more than a thousand words or like seeing is believing.
It's really important that these abstract conversations that we are having are being
translated into something tangible, like a picture.
And then working through those pictures iteratively with the client will help us to get everybody

(23:56):
on the same page to make the customer being heard.
So they have this feeling of being heard.
And I think at the end of this process, the end result will be a better looking application,
an application that feels more intuitive and the overall quality will be much better.

(24:19):
But the important piece is that everybody on the team, the customer, the designers,
the project managers, the developers, they're all working together hand in hand throughout
the whole process.
So that's, I think, in my mind, the ideal process and will lead to really high quality
output.

(24:43):
That was Mike Gaigg, author of the Esri Press book, Designing Map Interfaces, and UX/UI Team Lead
within Esri's Professional Services, sharing how thoughtful design helps drive easier collaboration
and engagement.
To learn more about UX/UI, check out mapuipatterns.com.

(25:04):
If you enjoyed this episode, please share it with a colleague and don't forget to check
out the other podcasts available from Esri, including "Field Notes" and "Reinventing Planning."
Learn more at Esri.com.