Just like building an app, this newsletter is a little chaotic

And just like an app, it's in beta and hopes to be more reliable

First, an acknowledgement: It feels weird to send this newsletter out after this past week, with everything that’s happening in the world. I am not going to write about that here, definitely not right now at least. But I don’t want this going out and seeming cavalier without at least saying something, so here we are.

With that said, next on the agenda is some good news. First, tomorrow I’m starting a six-month contract with Mozilla. I’m looking forward to it, in large part because I’m excited to be at a company whose values align so well with my own. Curious to see how that will affect my work, and curious to see what will happen after the initial contract ends.

Second, and maybe more exciting for this audience: It’s been years since I had a piece out in the wild, so I’m thrilled that my return to form is a book review for the NYT. I reviewed a memoir by a woman who worked at Amazon for 12 years, and you can find it here.

You’re maybe thinking: Hmmm. A memoir about working in tech? That sounds like what you’re doing? And I mean, kind of? Obviously my experience allowed for a specific perspective as a reviewer, given that I am also a woman, a writer, and someone who started working in tech before some of my most recent coworkers were even born.

Just gonna let that one sit there for a second.

Anyway, after I read the book and filed my review, it occurred to me that some of the things in the book that are, in fact, horrifying hadn’t fazed me. I imagine I’d have found it all more shocking or surprising if I hadn’t worked in tech on and off since the early days of Web 1.0. I mean, I never worked for Amazon, so I’ve avoided some of the more egregious types of awfulness, but like most, I’ve endured plenty in my career. Plus we’ve all heard the stories from friends and colleagues who worked at Amazon. Honestly I think as tech insiders we already know the worst shit is true, and possibly even a *downplayed* version. I think a lot of non-tech folks aren’t sure what’s urban legend and what’s real when it comes to tech. I mean, how could they?

the lifeboat

Which of course got me to thinking about how there’s so much people don’t know or understand about the tech industry. Not just random people, either. People in my life, with whom I’m close and to whom I talk on a regular basis. People I’m related to! Even wilder, people I work with. What I do sometimes seems opaque or confusing, even to people who sit next to me in meetings.

If this describes you, please don’t feel bad. Well, unless you work with user researchers, in which case feel at least a little bad. My joke for many years has been: “If you want a profession in which you spend at least 50% of your time not only explaining your role but justifying it, including to people you regularly work with, then be a user researcher!” Ha ha ha oh how much fun we have.

Okay so: What is my job?

The first sign that I will not be able to fully explain my job in a single newsletter is this: I can’t give you a single title or name for the role I’ve had for more than a decade. Here are some of the options: user researcher, user experience researcher (UXR), design researcher, experience design researcher. There are probably others, but I’m blanking. Please add more in the comments if you think of them!

When you think about it, one of the smartest things that computer programmers and data analysts did was rebrand themselves. Would you rather be a computer programmer or an software engineer?A computer programmer is someone who provides a service for an existing platform. But a software engineer? Now you’re the one who builds. Or a coder?? Hello there cyber cowboy!

And the data scientists? Man, put the word “science” in your title and suddenly what you do is real! It’s not just numbers, it’s science numbers! And it’s definitely worth a lot more money.

The title “user researcher,” which I will also refer to as UXR for convenience, does exactly none of these things. What is a user? What are you researching? How are you doing the research? What’s it for? Are you just engaged in some pointless research for the sake of it? Are you even making or producing anything? How is it useful? At least quantitative research has big numbers, albeit not as big as data science. Mostly it’s more of that “soft” sciences that isn’t rigorous and real, right? Wrong.

(Please put a pin in that because I have a lot of thoughts.)

user research

On the most fundamental level, a user researcher does research with people who use your product, who could use your product, or who don’t use your product and you want to know why not. Our job is to explore how well they understand the product – everything from the ways it functions and how they interact with it, to the actual value they get from it, how it serves their needs (or doesn’t), and the ways it fits into their lives. More than that, our job is to understand who are users are, what their lives are like, and what they actually need, on a deep human level.

In essence, a UXR’s job is to be the voice of the user. We do this as part of a team that is tasked with building a product or a feature, or even developing content. We do everything from highly tactical work that validates existing designs and ideas to super exploratory, generative work that helps our teams figure out where to go next, and why. I’ll explain more about all this eventually, but first let me talk about why this work is so important.

Contrary to popular belief, building products, especially at an inconceivable scale, is hard. When you have a product that hundreds of millions of people, or even a billion (!!!) people use, it’s quite a task to somehow serve all of their needs, support them, not piss them off, and continue to engage and delight them so they do not grow bored or annoyed and leave for fresher, newer pastures. All while trying to meet business needs that may be in direct contradiction with what might best benefit the people who actually use your product.

Hold up, I’m getting ahead of myself. You see, one of the great risks in making a product is that you make it for yourself. That’s fine, if your entire audience – or TAM (Total Addressable Market) in business-speak – consists of people like you, and anyone who happens to find what you do intriguing. This is why Silicon Valley developed such a reputation for making apps that seemed primarily to benefit men, likely software engineers and designers in their 20s and early 30s with excess income, a dislike of being inconvenienced in any way, a sense of entitlement, and an ability to see literally every aspect of life as ripe for disruption.

And hey, sometimes this method works, at least for a while. Twitter was born because a group of guys thought it would be cool to have a way to keep up with what their friends were doing without having to, like, call them up and say hi. It was originally envisioned as an SMS-based (that’s text messaging) platform where people could share their current status – I guess like ICQ or AIM except only status, no chats.

This is why a lot of tech “gurus” get a reputation for being geniuses: They had a smart idea and saw an opportunity, or a whitespace if you will. Then they made something that caught on – maybe in a way the inventor(s) intended, but just as frequently in ways the inventor(s) could never have imagined. Sometimes the original idea is a little bit more luck than genius, and the real genius is in the followthrough: Turning this idea into something that people actually want to use. But that takes a lot of work and a lot of iteration.

this AI generated image of a product team is kind of freaking me out

In tech, products are made by teams that consist of multiple roles. Let me run through them quickly:

• Product Managers (PMs)

• Software Engineers (SWEs) – front end, back end, full stack, DevOps, iOS, Android, QA, security, etc.

• Data Engineers (DE) – are they software engineers? Yes but I break them out because they’re the ones building data pipelines so DS can do their jobs.

• Data Scientists (DS)

• Designers

• Content Designers, sometimes known as UX Writers

• User Researchers (UXRs)

• Sometimes there are Project Managers or Road Managers, people who help keep things organized and projects on track, but not every company has them

• Operations

This doesn’t take into account things like org structure and hierarchy, especially at larger companies. The bigger a company, the less autonomy and agility a team has to build whatever is necessary. The more each of these groups have to communicate with leads/directors/VPs, aka the people who review all your work and decide if it fits in with the roadmaps and business needs.

(The best part of all that is the people who make the decisions don’t do any of the actual product work so a lot of the time it’s like trying to get permission from your parents to do something they can’t approve of for reasons you don’t know, or they don’t like for reasons you can’t discern, or maybe they’re just having a bad day. This is deffo another conversation for another day.)

Anyway!! You may look at an app every day and hate every single design decision or user experience, and you might have a lot of ideas as to how to improve the thing. You might very well be right. But you might not be taking into account a whole lot of things like: Would that work for every type of user? Or the majority of users? Or is there a business decision you don’t know about that prevents us from doing things that way? Or was there were engineering decisions that led the product to be structured a certain way, or that built up a lot of tech debt (this is what you get when you prioritize speed over perfect or even good code, and it’s a mess that eventually needs cleaning up), so even if the design team agreed with you, trying to actually do that at this point would be such a massive undertaking as to be borderline impossible.

This is not to excuse many, many, many of the bad decisions that have been made at many companies. Nor is it meant to make heads or tails of some of the inexplicable leadership decisions that get made, despite the protestations of scores of people who are deeply involved in all aspects of building the product and working with users. It’s more like a taste of how complicated things get.

A little like how this newsletter got complicated. I guess I can’t fully explain what a user researcher does without also explaining how products get made. Very chicken and egg here.

chicken and egg

So let me leave you with this thought, and then I’ll try to dig more into it all next week. In my personal and professional opinion, a truly skilled UXR is a mix of the following:

• An investigator

• An interpreter

• A translator

• A storyteller

When a UXR really does their job well, they don’t just tell you whether your product helps them feel closer to their friends. Instead, a UXR will interpret what friendship means to them, why friendship matters, and how friendship happens. The UXR will then translate all of those insights into a language that feels natural, one the entire team can adopt and share. When you really nail that, you have the opportunity to change more than just the product in that instant. You have the chance to change the way people think about the product, and that’s where the real work happens.

Huh, no wonder I ended up in this field.

Until next time, when I’ll try to explain more of how all this works. Stay safe everyone.

Lxx

****

No recommendations from me this week. Instead, tell me what you’re enjoying.