This is the Nielsen Norman Group UX Podcast.
I'm Therese Fessenden.
Today we're sharing an interview that I had with Garrett Goldfield.
Garrett is a UX specialist at NNG with 20 years of practical experience in the UX field.
Previously at Intuit, Garrett managed the user centered design group, the UCD group,
for Intuit's tax division.
He's taught about 10 of NNG's full day courses over the years, one of which is the one person
UX team.
So in this episode, we discuss what it takes to succeed as the lone UX wolf of your organization,
and how solo UX practitioners cannot just survive their daily workload, but thrive,
and perhaps even transform their places of work.
So without further ado, here's Garrett Goldfield.
So Garrett, welcome to the podcast.
How has your week been?
I know we've had a long conference, so I'm curious how it all went for you.
Well, hi Therese, thanks for including me in this broadcast.
I've been very excited to be a part of it.
The week has been fantastic.
So I went through the classes I was teaching this week, the human mind and how to optimize
or thrive as a UX team of one.
And as you could probably hear, I'm a little hoarse right now and a little bit tired, but
it was great.
The attendees were fantastic, the questions were great, and we had really good interactions.
That's awesome.
And yeah, I'm always impressed by all of our speakers for being able to make it a full
week of talking through some really complex topics.
And you say the speakers, but I am impressed by so many of the attendees because they're
here four, five, six days a week.
And it's a lot of material to absorb and all different time zones, all different backgrounds,
and they can come together and absorb this material.
Yeah, especially lately with the virtual conferences.
That's something that before, when we did these in person, it would be great of course.
I loved seeing people in person and I'm really looking forward to when we can do that again.
But it's also interesting to see how much more global each batch of people is now in
these virtual settings where you don't have these constraints of air travel.
So that's been a lot of fun.
And you teach a lot of...
I know you taught two classes this conference, but you teach a lot of different classes.
How did you get here?
What is your journey?
How did you get to NNG?
Yeah, interesting story.
I think I do teach something like 10 of our classes here.
It's wild.
Well, I thrive on the diversity of all of it, because so much of UX is connected.
And so all of these tendrils that go out into these other domain areas, I just find fascinating.
And where we have come as a profession is to kind of represent the field of UX as a
field where UX practitioners are often put in a role of being a jack of all trades.
And so for me, I really adopt that mantle and I like it.
So where I came from, I always knew I wanted to be in psychology.
And so my background is in psychology.
My undergraduate work was in experimental psychology, and I was all set to go to graduate
school in clinical psychology.
And I was going to be a therapist, a counselor, maybe even going into psychiatry.
I started to get to a point where I was second guessing whether I want to do clinical psychology
is the main thrust of my career.
And so I started looking in other places and I found, of all things, something I had never
heard of, which was human factor psychology.
And I started to see how that could be applied to technology and the computer industry.
And I could get the best of my worlds of investigating how people think, but not necessarily
in terms of their own personal issues, but into the tools they use.
And that just unleashed all of this interest in me that I started pursuing.
So after that, after graduate school, I went and got my first job at General Electric.
And then I worked in the aerospace industry for a few years before moving on to a company
called Intuit.
And I spent a lot of years at Intuit working on financial products, Quicken, QuickBooks,
TurboTax.
I spent a lot of time in the tax world.
And back in the day, or in kind of the earlier days of user experience work, our community
was much smaller.
And we would kind of keep tabs on one another and things like that.
And so I had worked with a woman named Hwa Hloringer.
And Hwa and I worked together at Intuit and she had moved over to Nielsen Norman Group.
Well, we were still in contact and still friends.
So a little bit less about 20 years ago, as I was thinking of making a move, I was considering
other companies, other opportunities, she became aware of this.
And before I knew it, I had received a call from Jacob Nielsen where Jacob had said, so
I heard that you were thinking of moving on.
And so, like I say, back then it was kind of a different timeframe.
Our industry is a little smaller.
So he and I had a wonderful conversation over the phone and next thing I knew, I was an
employee of Nielsen Norman Group.
That's so cool.
And I got into the field, I think I was kind of lucky in that it was gaining more traction.
People started refining the concept of human computer interaction and it was a field that
could really be studied.
Whereas before it was kind of like you were in human factors and it was applied to these
other things.
And I just think it's so remarkable.
Like all of this stuff that we learn, all of these skills, there are so many skills
that you need to thrive as a UX professional.
So when someone is a one-person UX team, like how do you cultivate all of those skills?
Like is it even possible to be a one-person UX team?
Because when I think about it, you have things like research, you have design, prototyping,
development.
There are so many facets to the work that we do.
So how do people do it?
I would love to know, like do people come to your classes at like group therapy?
I would just really like to know, like is it even possible to be a one-person UX team?
Yeah, it's funny you bring that up.
Yeah, our courses are often, I suppose you would say they are small therapy sessions.
There's a lot of commiserating, a lot of sharing.
And what is sounding to me at times is that the situation is so similar from audience
to audience, country to country, year over year.
I mean, I started this course under another name roughly 13, 14 years ago, because this
has been an ongoing process for us in this field.
And also to the point you brought up, our field has evolved so much.
When I first got into the field back in the mid-90s, I was a usability researcher.
There's been a lot of evolution in this profession from research into design to all the other
aspects you brought up, architecture, interaction design, visual design, even to a certain extent
some front-end coding.
And so your question about is it even possible, yeah, my answer is absolutely yes.
I mean, seriously, you can be a one-person team and you can thrive as a one-person team.
As long as you, I would say, understand your organization and you can fit in and have the
like requisite skills to be that one-person team.
And so as a UX professional, we are often trying to understand our user in order to
create better systems for their needs.
So we research around who our users are, our target users, and we design systems for their
particular needs.
Well, as a one-person team, I think we have to do a similar process in our organizations.
We need to understand our colleagues, our stakeholders, our organization and how it
runs so we could better cater our UX work and our processes to fit into the organization.
And why this is so important as a team of one is because our organizations typically
will not change for just us, for one person.
And so we sometimes have to alter some of our processes to get the best UX work we can
in.
So this involves things like communication, knowledge of our work, talking the talk, being
able to articulate why we want to do the things that we do.
Good relationships, establishing good interpersonal relationships with our colleagues.
It involves being efficient in the way that we approach our work and developing an empathy
so that when we do get pushback, when we are limited in our scope, we realize that it's
not that people don't necessarily value our work.
It might be because they don't understand our work.
And that's a big part of what we need to communicate.
Yeah, I think it's always fun thinking about empathy because, of course, as UX professionals,
our whole drive is to better understand our users.
But we often get so tunnel visioned on empathizing with end users that we forget to empathize
with other people around us and getting to the heart of what might drive other people
in our organizations.
What might it be that they're hoping to accomplish?
And I think there are a lot of common goals that we often share that we just don't really
realize that we share.
So I really like that point.
Yeah, absolutely.
So if I'm working with, let's just say, a product owner, and a product owner is pushing
back on me because I want to do another usability test or another iteration of design, most
of the time it's not because they don't value that work, but maybe they are being measured
or judged on meeting the project timeline.
And so if that is the case, and I can empathize to that, then certainly I can understand their
point of view.
I don't take it personally.
And then I can try to devise other ways to get that research or the design iteration
maybe without extending the project timeline or explain it to them in such a way using
terms that resonate with them because they're thinking about timelines and deadlines where
I can get my point across better.
Got it.
Yeah.
So I would love to know, based off of, you've already taught this class many, many different
times across the years, and are there any cool examples of UX teams of one, like maybe
some really cool work, some cool case studies that you could share?
So in this course, when I start thinking about things like success stories, can teams of
one be successful, part of my answer, I mean, certainly my answer is yes, of course.
I wouldn't be endeavoring to do all this and teaching this course so many times if I didn't
think you could be successful as a team of one.
But part of this is how do we define success?
So to your question, certainly there are a lot of success stories, people that have made
huge contributions and impacts.
But is our measure of success doing something big and grandiose and different?
We're just saying, as a team of one, there's so many challenges anyway, working in isolation,
taking on not only the roles of the UX practitioner, but also oftentimes having to manage our projects
because we don't have a UX manager, or being our own administrator, our own person that
is calling all of our meetings and doing every little bit of work that oftentimes are spread
across groups.
So are there successful examples?
Absolutely.
But sometimes the success that we are looking for isn't defined as big grandiose wins, but
just being able to do our UX work in a meaningful way while still being a team of one and doing
all these other things and wearing all these other hats.
But with that said, certainly I have seen such wonderful tools and processes come out
of teams of one due to the necessity of having to create these tools.
So the efficiencies around creating templates that work, the proactive approach of instead
of waiting for projects to come in and then reacting to them, building knowledge bases
with current tools that are being used in the organization.
So building knowledge bases, building repositories of documents, templates, and processes so
that as a team of one, these individuals are ready to jump on new projects and efficiently
take them on rather than spin their wheels when new things come through and they're kind
of juggling all of these different projects at once.
Yeah, that seems like that's the answer or the go-to strategy.
When you are one person, systems need to work for you so that you can make the most of your
time.
Yeah.
For some of us, we almost get into the mode of just survival.
So you would ask the question, is it a big therapy session?
And yeah, sometimes it is because we as UX people want to do such a good job and we hate
turning down projects, so we quickly become overloaded.
And so part of what it being a successful team of one is, is just getting to a point
where you can contribute meaningful UX work, still have a life balance and not feel overwhelmed
stress and not feeling that you're not a team player because you have to turn down or push
back on work.
These are huge wins for a team of one.
That seems like a common challenge.
What would you say are the most common challenges for some of these lone UX professionals?
There are a variety of common challenges, things like being overworked, the need to
produce a deliverable overnight for lack of a better term.
So it's a lack of insight.
A lot of organizations feel that what we do in the UX world is really around visual design,
which is completely understandable because that's our deliverable to them.
A lot of our organizations and colleagues and coworkers don't see all the work that
has gone into creating a design.
So when we output it, they think it's magic.
They think Garrett's a great designer.
Look at this.
He can do this all the time.
Wait, so you're not a magician?
I'm just kidding.
I might create pretty decent designs, but in order to create those, it takes a mountain
of work.
So if I had to summarize the answer to your question, I think the biggest challenge the
teams of one have in organizations is that the organization doesn't quite know what UX
is and, therefore, they don't know how to use us.
So all of these symptoms of that being overwork, late inclusion, relegation of UX work as kind
of a second-class contributor that is a nice-to-have but not a necessity, all of these things come
out of our organizations and our colleagues not quite knowing who we are and what we do.
And once again, it's very understandable if you empathize with their points of view because
we use terms in our field that people outside might not understand, contextual inquiries
and heuristic analyses, these types of words, and if we can communicate better, let them
know what these things mean and the ultimate impact.
So in our course, we talk a lot about communication and explaining the kinds of work that we do
in really common vernacular, but even more so talking about what the impacts are to the
organization and to the end user.
And once we can demystify a lot of that, then people that have the project plan, project
owners, stakeholders know when to include us in the project plan, hopefully early on.
They know what it means when we say we need another round of research or another iteration
of the design and don't just resist, but we get to a point where we get a cultural change
and some better understanding of why we as UX people are requesting these things.
What you just said actually about vernacular of UX, I'm so guilty of doing this where I've
gotten kind of accustomed to some of the vocabulary about research methods, about UX methodologies.
And if you've been in the field for a long time, then it kind of comes naturally to discuss
these terms.
But you're absolutely right.
If I were to explain this to someone who is not as familiar to the UX world, for example,
some of my family members, if I were to use those terms, they would look at me like, what
are you talking about?
Of course.
And I would not probably build a great connection that would probably be a terrible conversation
to be in.
I wouldn't want to be in that conversation.
So I think you're right and it's important that we kind of catch ourselves when we're
speaking with coworkers and I'm not necessarily like dumbing something down, but just speaking
in a more conversational way that is more inclusive of the audience that you might have.
So I think that's such an important point.
Yeah, I agree.
And to your point, nobody wants to be in a conversation that they do not understand.
And so if I'm trying to explain to my colleagues what it is I do, and I'm using these complex
terms that are either vague or confusing, nobody's going to sit down with me and say,
oh, really?
Explain that to me more.
Define all your terms, just like how we're busy, they're busy.
Like an interesting example of this is in my class this week, I had about 30 people.
And in those 30 people, I was looking at the registration information.
These are all UX people, but there were 15 different job titles amongst these 30 people.
And we try to think of ourselves as like, oh, we're UX people.
So either we're a UX designer or UX researcher or architect or something like that.
But no, that was not the case at all.
We had such a variety of job titles in our own field.
And I think one of the challenges that we have is that we have so many skill sets in
the field, each organization or kind of industry perhaps labels what we do differently.
How can we expect other people to know what we do if as a profession, we have such a variety
of terminology we use?
And as just one more example, when I saw this, I was noting to the audience, to all the attendees
in my profession, what titles I've had.
And I started just listing off.
I started as a user researcher.
I went into being an operator interface engineer.
I was a human factors engineer, a UX designer, an information architect, a UX specialist,
a user experience manager.
All of these are titles that I have had for essentially doing the same job.
No wonder, you know, people don't get it, our organizations don't get it.
We have to be clear.
I know there was a previous episode I've done with Jacob Nielsen.
So that was episode one side note for our listeners.
But in episode one, we discussed vocabulary sprawl, how we have so many different words
for sometimes the same thing.
And sometimes those words take on new meanings as well.
And maybe what it used to mean then does not mean that now.
And so it's a constant struggle to communicate well.
So yeah, I just think that's great.
And I know even our titles, UX specialists, is one of those intentionally vague titles.
But I think it does fit for us and what we do.
But on the flip side, it is such an exciting emerging profession.
We get to be on the forefront of really a profession in its infancy in how we apply
the experience that our users are going through and the products and services they use.
So whether it's websites, it's applications, whatever it might be, industrial design, we
get to be on that cutting edge of how we define this field, the areas that we go into.
We get to discover and be detectives in the sense of what makes a difference to people
when using technology.
What are the things that have a huge impact on them?
What are the things that have smaller impacts?
And when we start to discover these things, we can apply those research findings to the
work that we do and the designs that we create, and we can differentiate and really help people.
It's an amazing profession that we're in that we get to make a difference, a positive difference
in people's lives.
And so even though there are some challenges, I think the rewards far outweigh.
When we think about these small UX teams, because personally, I think any UX team, whether
it's a UX team of one or a UX team of 250, a UX team having one is already such an improvement
to not having one.
So I guess my next question would be are there ever times that a one-person UX team is appropriate
or should UX teams of one consider expanding on a regular basis?
I guess I would like to know if there's a case for having a one-person UX team.
Oh, sure.
Absolutely.
Absolutely.
Now, generally, I will say that being a UX team of one in the long term is probably not
going to be the best recipe for success.
And for a variety of reasons, some of which I've already mentioned, you are doing a lot
of work that is outside the UX role just in order to make your job happen.
You're acting as your own manager, things like that.
As a UX team of one, you often don't have a career path to find within your organization.
And so there's nobody watching out for you and your promotions and things like that.
Not only that, if you're a UX team of one and wearing multiple hats and you're doing
research, you're doing architecture, you're doing design, et cetera, et cetera, it is
hard for you to focus on the singular area or maybe one or two areas that you are most
passionate about and you have the strongest skill set in because you are wearing the hat
of everyone within the UX community.
But with that said, there are absolute reasons why you might want to stay a team of one.
And some of those might be the advantages that you get to be the sole expert in your
organization.
It's an area of pride.
If you, like me, like to do multiple things within the field of UX, be a jack of all trades,
this is certainly a way to do it.
As a team of one, you get to kind of map out your impact, map your future if you've got
kind of that power to do so, and really see your products improve based on the work that
you have done.
So there are a lot of rewards that come out of being a team of one.
But like I say, in the long run, it might not be the best formula for success to stay
a team of one, but also as teams of one, do expand over time and expand your recognition,
the applicability of your work, show your return on investment, et cetera.
It isn't always about growing your team.
You can grow your team of one in other ways.
So it doesn't necessarily have to be headcount.
You can grow in terms of how much respect you're getting in the organization, how much
understanding you have, the earlier inclusion in your product life cycle or your development
life cycle.
So growth can happen on an ongoing basis, even if it's not in forms of a headcount.
Yeah.
So that was actually a good segue into my last real big question, which was for those
who find themselves in this predicament of being a solo UX professional, maybe they're
the first to break UX maturity ground, which is so exciting.
And I love how you framed it and maybe that's part of it, how we frame the challenge of
being a solo UX professional, really seeing it as an opportunity to grow UX in that particular
organization.
So do you have any other really big pieces of advice to solo UXers?
Oh, sure.
Sure.
And one of the points you just brought up is when you do grow, if that is part of your
goal as a team of one, think about how that growth happens.
So I had mentioned as a team of one, you are wearing many hats and you might not have the
opportunity to concentrate or focus on the few particulars of your passion.
But as you do grow, you being the one UX person, you're going to probably have some input into
how that team grows with headcount.
And so if you love doing research, for example, and you don't love doing as much, say, interactive
or visual design, provide that input when your team grows that we should hire a visual
designer.
That way it would compliment some of what you're doing.
You get to concentrate more on your passion and the other new hire gets to concentrate
on their passion.
So this is good.
Also it allows you the opportunity to think about whether you want to be an individual
contributor or manager and where your career path goes that way.
But getting back to your question, what are the recommendations for people that are team
of one?
And I actually think it's a great position to be a team of one, at least in the beginning,
because you can have big impacts and you can start to shape what UX is in your organization.
But the first thing I would say is think about building relationships.
So relationships are really how UX gets deeper and more integrated into the organization
and how we can start to shift culturally.
And when I say build relationships, I mean true relationships.
Speak with your colleagues, speak with your managers, your decision makers, see how they
think, how they feel about UX, use this as an opportunity to align the thinking on what
UX should be in the organization, and this is your opportunity to sell it as well.
Another thing, be proactive in creating your resources.
Don't only wait for new requests to come in for products and services and designs.
Try to think ahead about what you will need for, say, the next time you do research, the
next time you do design, is that you need process docs for research.
You need templates for running your usability test.
Maybe it's pattern libraries for some of your design work.
And what I would encourage you to do, which a lot of teams of one don't do because they're
so overwhelmed and overworked, is like today, set aside an hour a week or an hour a few
times a week in your calendar just to give you the opportunity to proactively improve
your processes, create some of these templates or methodology docs that are going to make
your life easier in the long run that you can reuse.
Let's see, a few other things.
Protect your time.
Nobody is going to do it for you.
So if you need to say no to a project, if you've got the power to do so, think about
doing it.
Think about how you negotiate when new projects come in.
So not just saying yes to the project, but think about what you can really do.
And if it is a project, you can see the potential for success.
And if not, instead of owning that product support from a UX standpoint, maybe you negotiate
instead that you can be a consultant on that project.
So you're not burning yourself out or depleting your contributions to other products and features
because you have to fully support each one that you do.
Probably the last thing, and one of the most important things, is always keep an eye on
your return on investment.
So this involves a little bit of extra work, meaning like you need to do some tracking
of the work that comes in, what you support and what you don't.
And also a little bit of tracking on the projects you support ideally turn out better.
The projects you don't probably don't fare as well.
And at periodic moments when your organization is available to listen, you present this material.
And this is the way that growth happens because unfortunately, a lot of the work that we do
in the UX field is invisible.
And if we, as a team of one, don't let other people know, then they're going to continue
to think that what we do is magic to us, that it's just purely hocus pocus and our skill
set allows us to create great designs.
So if we don't show them the impact on what we do, show the return on investment, then
it remains invisible.
And if we really want to grow, and again, whether it's growing headcount, growing your
own respect, growing the place at which you get inclusion in your product life cycles,
you need to prove the impacts that you're making.
Teams of one in any discipline in our organization, it's too easy for them to remain invisible.
So we have to do a little bit of evangelizing and a little bit of kind of blowing our trumpet
on when we do make impacts.
I think that's great advice.
I think we totally should toot our own horns because the work we do does make a positive
impact.
And I think that's something to celebrate.
So to kind of end on a nice happy note, I do think there's hope for solo UX practitioners
everywhere.
So thank you, Garrett, for your time.
It has been a lot of fun.
Time absolutely flew by.
It's great.
Thank you.
It's my pleasure.
Thanks.
Thanks for listening to this episode of the NN-G-UX podcast.
To learn more about some of the resources that we may have cited in this episode, check
out the show notes for more details.
We also have a weekly email newsletter where you can get updates about the latest research
and info on upcoming UX certification opportunities.
So to learn more, go to nngroup.com.
That's N-N-G-R-O-U-P dot com.
Finally, if you're listening on Apple podcasts and you like this show, perhaps you want to
support the work that we do, please leave a rating.
And no matter what platform you choose, please hit subscribe.
Thank you so much for your support.
Until next time.
And remember, keep it simple.