UX Coffee Hours FAQ

I’ve been part of the UX Coffee Hours for the past 1.5 years, meeting UX researchers every week for a chat, mostly mentoring people starting out in their careers. While each session is different and insightful in its own way, I’ve noticed a few recurring topics. I’m writing my high-level take on these, so I can share it with future mentees for future sessions, making more time for deeper discussions.

I’ll update this FAQ from time to time as I learn about new questions from mentees that are interesting to answer in writing.

My story

Right now I’m leading a product design team at Krisp, working on noise cancellation and speech assistant software. We are still fairly early in our journey and recently started to figure out how we do user research. Before Krisp I was a manager at Trustpilot, a consumer review platform. I was leading the UX team on the business platform there. UX research was done by both designers within their respective design teams and by a separate research team. The most interesting part was how mature discovery practices were there, though we spent a lot of time figuring out the right amount of research to do. Before this I led the UX team at Emarsys, a large marketing cloud SaaS company, where we had as many researchers as designers, spread out in product areas. With this setup, researchers were fairly well embedded into the daily work of the product teams, which brought user insights closer to discussions. And before Emarsys, I was a UX researcher at Prezi, a presentation startup where I was also embedded in product teams.

In short, I’ve been mostly part of early / late scaleup tech product companies, so my answers come from that perspective.

What do people mean when they say junior, senior etc?

These can mean different things at different companies, there are no universally accepted criteria - just as there is no universally accepted description of what a UX researcher or UX designer does. When I had hired juniors, it usually meant the role should know how to perform basic tasks with at least one or two finished projects under their belt. So for example a junior researcher should know how to do an interview study or usability tests.

A useful model is to think about impact increase with title seniority increase:

• A junior impacts themselves, working on how to apply their craft, learn and improve their process and methods.
• A mid level impacts their close team, learned how to work with others efficiently, contributing independently to the team’s goals. They would still mostly apply methods by the book, think more about specific cases.
• A senior has a broader impact beyond their team, taking clear ownership with little supervision, communicating beyond their team in some cases figuring out new ways to do things that fit the context better. Seniors are also don’t need to get told what to do, rather they tell everybody else what they are going to do to further team and organizational goals.

Useful resources to learn more about how companies do the levels:

• https://www.levels.fyi
• https://www.progression.fyi/

What are the top skills for researchers?

Of course much depends on the company, how user research is set up, and the specific role.

In either case for me these are crucial skills, and ones I usually screen for:

• Curiosity. It’s the difference between getting sometimes a compelling and deep story from a user or just following the test script. The skill of asking questions, asking the right questions, and asking those often.
• Being organized. Having a structured mindset, and a drive to make things more structured is helpful when creating and following a research process, when analyzing and synthesizing data.
• Facilitation. On sessions with users and also on sessions with team members.

During an interview process besides the other skills we are screening for (like collaboration and impact) I’d get a lot of indirect evidence on these, like there are candidates who don’t ask questions during an interview even when presented with the option, or don’t describe a clear structure and rigor to their research projects.

How is your hiring process?

Right now at Krisp we have these steps:

• Resume screen - To figure out if what we see in the resume / portfolio / email to the hiring manager, so everything the candidate provided to us fits with what we are looking for. Details here are helpful, so I don’t have to wonder what the candidate did or didn’t do in the past or what vague terms mean.
• Hiring manager interview - A more general interview, where I figure out if the candidate worked om a similar context to us, if our understanding about design and UX process and concepts is aligned, and if the candidate’s goals fit with what we do, so we can provide them with appropriate opportunities.
• Technical interview - The candidate talks with a member of the design team and a product manager. This helps them to see how their future colleagues would be, and we can learn about things like collaboration, design process, past impact.
• Design review - With the product and design leads. We ask the candidate to bring a piece of work that they worked on in the past, and we have a sort of review / critique / brainstorm around it. The candidate can see how usually the discussions around work go, how is our culture and we can see how the candidate builds their rationale around their work and how they adapt or decline new ideas.
• People team interview - This is a short discussion around culture and some administrative things like salary.

This usually takes a few weeks, but can be done in a week if we are really efficient. We might custom tailor the process for certain candidates or roles.

In the past I had done take home tasks at other companies and things like assessment days where the candidate worked with us for a few days. Stopped doing these, as we want an efficient process that doesn’t take too much time either from us or from the candidate.

Do you need a portfolio?

There is probably no industry agreement on it, and much depends on the hiring manager or the design/research culture at any company.

In general I don’t require a portfolio when I hire. Though it’s useful to have, as it gives a better picture of past work done. It also gives me insights into how good are people in offline presenting and writing which are desirable skills to have. Portfolios should give a good understanding of work done, so just having some screenshots or example artifacts is not enough for a portfolio.

For designers, a description of the context, process and outcome besides the designs is helpful.

For researchers, it might make less sense to have pictures, but descriptions of projects, work done and impact achieved is nice to see upfront.

How to break into industry UX research from academia?

Talking with candidates from academia in the past, there are certainly differences between industry experience and academia experience. What I frequently observed, is that while researchers from academia have done some nice projects, their work differs in two major ways: framing and outcome.

Framing partly means just talking about how they did their thing differently, and sometimes they use more complicated terminology compared to what we would use in the industry. For a publication you need to be precise in the methodology you’ve used, but in the industry (maybe depends on who is interviewing you, lots of researchers have experience in academia) sometimes simpler method names are easier to get started with (just call it usability testing or interviewing). This applies to all parts when describing work done. You can always add nuance once you are in the discussion, so when you are through the first screener. An other part of framing is describing the process: methodological details are less important compared to context and impact. Storytelling helps a lot, for example using the STAR narrative structuring. A good tip is to check what words job descriptions are using and adopt those.

The other part is outcome: I’m usually looking for researchers who go beyond a study, engage with teams / developers, and had impact on the product. In academia outcome is publication, in industry it’s change in user’s behavior, or at least in the product or at least in the thinking of team members. So I’m looking more closely at how people talk about presenting, communicating their results, and how they collaborated with other team members which are important to get reach and impact. Unfortunately a lot of academic projects stop before users get real value from it (ofcourse this is fine and makes sense in the context of academia).

Good articles on lingo (and mindset) differences:

• From Academia to UX: Understanding User Research Lingo.
• Transfer Your Academic Skills to the World of UX.

How do you work together with product managers?

Both roles, so product managers and UX people (including researchers and designers) are a bit underdefined and might cover different tasks at different organisations (sometimes even at different teams). So there is usually some overlap or fuzziness there. For example product managers should engage with customers, but if that’s true what do researchers do? In the past I did my best work, when we figured out a good distribution of tasks between us and we had complementing skills, even if we took turns doing some things like user interviews. A good rule of thumb is that you should do your thing and support as opposed to gatekeeping: enable PMs who look to engage with customers, rather than trying to “own” this connection.

NNg had a nice research about this: https://www.nngroup.com/articles/ux-product-managers-overlap/.

What resources do you recommend to read?

Books:

• Don’t Make Me Think by Steve Krug: Great for thinking about usability testing and getting into the right mindset.
• Interviewing Users by Steve Portigal: great for user interviews, but also great to learn thinking about approaching research in general. Portigal also has a really nice podcast worth checking out.
• Just Enough Research by Erika Hall: Good overview in the various types of research and how to get started with them.

Blogs:

• People Nerds, dscout’s blog. Nice research related articles, not just on methodology but also on everything else around user research, like stakeholder management, communication, organisation of work.
• Nielsen Norman Group’s articles. Usually well researched and well written articles about various topics. They recently started to publish study guides around certain topics which are extra useful.