Structuring UXR development conversations
Creating structure as a manager and getting clarity as an individual contributor
👋🏻Hi, this is Nikki with a 🔒subscriber-only 🔒 article from User Research Academy. In every article, I cover in-depth topics on how to conduct user research, grow in your career, and fall in love with the craft of user research again.
Being a manager was one of the highlights of my career, which is probably why it makes so much sense that I went into full-time coaching and mentorship.
Watching someone grow and develop as a user researcher is hugely gratifying. To be with that person through the ups and downs, to work together on solving problems, to understand their hopes and dreams, and to help them unlock achievements they didn’t think possible is one of the most rewarding jobs I’ve ever had.
However, as an individual contributor and a manager, I struggled with creating development plans and having development conversations. Many of these processes and structures weren't in place, especially as the first UXR, solo UXR, or small UXR team. Without the structure of what to discuss in development conversations and how to create a plan, I had difficulty understanding how to operate in my career.
Instead, development conversations and creating plans were stressful events culminating in a few points I ignored until the next feedback round. And in those times, I tended to feel stuck and stagnant in my career.
Where was I going in my career? How was I getting to the next level or moving forward? What did I have to learn or do next to get a promotion? What did it mean to be a manager versus an individual contributor, and would I be good at it?
I often felt demotivated and lost whenever unsure of what was next or how to improve. It was like my brain was too scattered to focus on what I needed to do. It was unsettling, making me feel like I was endlessly repeating the same days and not really getting where I wanted to go.
When I started out as a manager, the last thing I wanted was for anyone I was managing to feel this way. It was one thing for me to feel uncertain, but for others to rely on me for direction and guidance and not get any of that would be my worst nightmare.
I wanted to change the way I approached development, both for myself and for my reports. I wanted the future of people’s careers and what was next to be exciting, a conversation to look forward to, and a thoughtful and followed plan. I set off to do just that: make development conversations and feedback as relevant and significant as possible.
What development means to me
Throughout the years, my definition of development has changed fairly drastically. I am a recovering perfectionist who is also impatient.
When my perfectionism and impatience mixed, it led to a perfect storm. I expected to be good at everything the first time I tried it. It was like I should be able to read how to do something and then do it 100% right.
For a while, that mechanism worked okay for me, especially in school. I was good at school. I could study and get all the right answers. I could write great papers. I could argue a point. But that came to a screeching halt when I entered my professional life as a user researcher.
Although I came from a boot camp and thought that I learned everything I needed to in that boot camp and through the subsequent books I read, I hit up against the cold hard reality:
I wasn’t automatically good at user research because I had read how to conduct a usability test.
I didn’t know how to create a persona.
I didn’t know how to write proper research questions.
I didn’t know how to build a customer journey map.
I lived by the Pippi Longstocking quote:
“I have never tried that before, so I think I should definitely be able to do that.”
Development meant that I would be the greatest user researcher tomorrow. I didn’t think through what I wanted to accomplish, what I enjoyed/disliked doing, or where I saw myself in the future. I just wanted to be the best (the very best, like no one ever was).
This blind drive for achievement meant that when I actually thought about the big questions, like where I wanted to work, if I wanted to be a manager, or what I wanted my career to look like, I had no idea.
Talk about unsettling.
Luckily, over the years, I had people who asked me those important questions, which forced me to look at what development really meant to me:
Taking small steps to work toward certain accomplishments in your career through improving skills, making meaningful professional impact, and excitement in learning, while balancing mental and physical wellbeing.
It wasn’t about charging ahead to be the best. It was about cultivating a career that made me feel like I had an impact where I was working and that I was excited about. Is it true that I loved every part of user research? Nope. I still hate recruitment.
But, generally speaking, I am excited to learn new things about user research and to understand different perspectives. Every day I am excited to develop my skills in new and different ways, and I am okay with that taking time.
Remember, small steps lead to big, sustainable changes.
Creating meaningful development at your org
Every organization is different when it comes to structuring feedback and career development. I’ve been at organizations with no real set structure and those with a very strict process.
Generally, I’ve seen that companies have two feedback cycles/development conversations per year, otherwise known as performance reviews (I will use all these terms interchangeably). One is bigger than the two and holds the space for promotions and pay raises, while the other is less intense and more just to ensure everyone is on the right track.
This might not be the case for your company — you may have these performance reviews happen quarterly or once a year. I recommend taking your organization’s cadence and applying these conversations to that cadence before trying to change timing (if you feel you need to change it). For instance, when I worked at a company that only did annual reviews, I still worked with my direct reports on having these conversations every six months because an entire year without feedback felt wrong.
Regardless of how loose or structured your organization is, I’ve always found defining what development means to me incredibly helpful and sharing that with my reports so we are all aligned and on the same page.
Defining development at your org
The first step I recommend is sitting down and defining what development means to you and the type of space you want to create within your workplace — either for your team if you are a manager, or for yourself if you are an individual contributor.
Defining development can be challenging because it is one of those buzzwords that we don’t think about. This can mean we adopt a definition of development that might not work for us, such as striving to get to the top of some pyramid, becoming a manager, or getting promoted.
Many people don’t necessarily want to be a manager. Some people don’t want to get to the top of a particular pyramid because that means dealing with politics. Others might want to move horizontally across an organization to try out different roles.
There are certain goals that we can bake into our development just because they feel like the right thing to do or the things we “should” be driving for. But development should mean doing things we enjoy, discovering new things about ourselves, and, ultimately, working toward a fulfilling and impactful future.
That’s why I find it so valuable to sit down and define what development means to you, and also, if you have a team, define what that means to your team. It can help others get into the mindset that they don’t have to be in a certain role or do specific things to be successful in their careers.
When I did this, I defined development as incremental steps toward a greater goal and future self that I want to achieve personally and professionally that aligns with my values and needs.
Some questions you can ask yourself and your team if you’re looking to define development include:
What does growth look like for me?
Are there things I should be doing that I don’t want to be? What are those? Why do I feel pressured into them?
Are there areas I am interested in that are “wrong?” What are those? Why do they feel wrong?
How do I want my professional and personal development to intertwine?
How would I define development without any “shoulds?”
With this, you (and your team, if applicable) can create a shared understanding of what development means to each person. This makes development conversations much more relevant, personalized, and fruitful for each person because you have a much deeper understanding of what they need and where they are headed.
Setting up the necessary frameworks
Once you’ve defined development, it’s important to set up the necessary frameworks for these assessments and conversations to happen at your company.
There were many times I went into performance reviews unclear about what I was being assessed against. Had I done my job well? What criteria was my manager using to judge my performance? How would I know whether or not I was able to be promoted?
A lot of organizations can lack this type of structure, which makes performance reviews and development conversations confusing, stressful, and frustrating. If someone believes they did a good job, and did a whole lot of work, it can be incredibly frustrating to hear the work they did wouldn’t be taken into consideration for a promotion because it wasn’t 100% aligned with some hidden job criteria.
I remember, in one of my first roles at a start-up, I wore quite a few (around 50, it felt) different hats: I did some wireframing, user research, market research, product management, and customer support. It was fun experiencing all these different roles, but I was busy. And, when it came to my performance review, in which I was expecting a promotion, I got a hard kick to the rear end.
No, I wasn’t getting promoted. I didn’t do enough user research-related activities. There were some boxes I had never seen that hadn’t been ticked off.
I was certainly ticked off after that conversation.
That experience, early on in my career, made me realize how important transparency is in development and performance conversations, and I vowed never to let myself or my reports fall into a similar fate or situation. I recommend having some pieces in place to make the whole process more transparent, like:
A skills inventory that colleagues can use to understand what skills they have, the level of that skill, and where the gaps are
A career framework that clearly states what is necessary for each role (what good looks like) and what work is necessary to get to the next level
Questions people can use to get useful feedback from peers and colleagues
This documentation helps colleagues understand where they are, what they are being assessed on, and demonstrates what they need to reach the next level. In my development conversations, I include exercises with the skills inventory and the career framework because it helps spread transparency and ensure everyone is aligned on the assessment criteria.
Keep reading with a 7-day free trial
Subscribe to The User Research Strategist to keep reading this post and get 7 days of free access to the full post archives.