Book Recap: The User Experience Team of One by Leah Buley

TL; DR: If you want to do user research but don’t know where to start and could use a collection of no-nonsense tools that focus on practicality instead of formal correctness, consider picking up this quick read.


The User Experience Team of One by Leah Buley is written for a specific kind of person.

If you’re a part of a mature product team or your company has one, this book might not be for you.

But if you need to be able to go from idea to a solid, research-backed product spec without much help and don’t have a ton of experience, this is absolutely the book for you. A few scenarios where it will come in handy:

  • You’re working on a side project and want to take it to the next level without leaving your day job.
  • Everyone is suddenly asking you to “provide a strong vision” and a “crisp roadmap” without giving you a lot of specific direction. You’re not sure where to start.
  • While you historically relied on your intuition to figure out what you (and your team) should work on, for whatever reason, that is no longer working.

If this sounds like you, you could benefit from this book.

If you don’t have the bandwidth to read an entire book but would still like to learn a bit about how to do user research in the next five minutes, read my Poor Man’s Product Research Tips post instead! 😏

Format & Contents

The majority of the book is a collection of practical UX research and design tools & practices, organized based on where in the overall process they come in. There are also a bit boilerplate-feeling, “what is user research?” and “how can I grow as a UX person?” chapters that seem safe to skip for most readers.

The parts of the process the tools & practices cover:

  1. Planning & Discovery introduces methods like UX Project Plan or Strategy Workshop to help you set the overall project goals & rough direction.
  2. Research lists methods that take you through conducting user research and information synthesis.
  3. Design goes over essential design tools like Wireframes and Task Flows.
  4. Testing and Validation helps you validate your designs through Black Hat Sessions, UX Health Checks, and more.
  5. Evangelism shares tips on leveraging artifacts you produced throughout the process to spread the UX gospel in your organization.

Altogether, the tools & practices portion of the book is around 140 pages.

The Good Parts

The User Experience Team of One is a great book to give you a quick sense of the glaring gaps in your UX design process. It also helps you patch them by providing practical tool ideas you can quickly put into practice. After finishing the book, you will likely walk away with a few concrete ideas you can try in the following weeks or months.

The book presents all tools with a consistent structure that makes the book a great reference. I especially appreciate the inclusion of:

  • Average time Being explicit about how long something should take makes it easy to prioritize where to put your effort.
  • Try it out – Step-by-step instructions make a bulk of each tool’s description. The steps are always clear and easy to imagine.

If you suffer from imposter syndrome as a product manager, this book should help. You are likely already doing a fair amount of the activities mentioned in the book. Seeing that you are not that far off in your process from someone who has written a book on the topic and most of the gaps in your process are relatively straightforward to patch should make you more confident about the level of your product work.

Lastly, if you like paper books, do yourself a favor and get it in paper format. It’s full color, quality paper, and lots of fun to leaf through. Mine arrived only after I wolfed down the ebook, and I wish I had waited for the paper book as the ebook doesn’t contain any of the visual flourishes of the paper edition.

The Bad Parts

The book was written in 2013, and part of it feel stale. Picking up the book, I expect that the problem area will lend itself to evergreen content well, but there are two areas where the book shows its age:

  • If you work remotely… – These sections are written in an era where working remotely meant you were working alone, detached from the physical office where the rest of your team is located. Therefore, the tips presented are impractical for fully remote organizations and doubly so for async ones.
  • Mentioned software tools – Figma has taken the world of design by storm, and many of the tools mentioned in the book feel a bit obscure at this point.

The second thing to mention is that at 39USD for an ebook, the book feels relatively expensive given the rather casual nature of its content. At the same time, this is a book for a particular market, which makes the price feel more justified.

Note to Europeans: Avoid ordering from Rosenfeld if you can. They are very slow to ship and send books from the UK, making it likely you will need to pay a not-so-small import tax.

Biggest Takeaway

If you’re not talking to your current or prospective users, find someone to talk to and schedule a call this week.

Before you get your bearings, ignore articles about selection bias, unrepresentative sample sizes, etc. Instead, focus on getting the ball rolling. Remember that since your research techniques are not rigorous, you still need to apply your product taste to check them, and you’ll be fine. Once you feel comfortable scheduling calls and talking to real people about your product, you can gradually add more rigor to your process.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!


Poor Man’s Product Research Tips

My team is responsible for developing a diverse array of integrations into other products. We don’t use most of these products and lack the intuition to figure out how to connect them with our products in a helpful way. For that reason, user research has become indispensable to help us learn what integrations to develop and what shape they should take.

At the same time, our company as a whole is vision-led, without dedicated user research resources. If you want to make user research happen, you have to do a lot of the leg work, with only occasional help.

And that’s exactly what we’ve been doing over the past few months. In this post, I’ll share a few tidbits that I’ve learned that help with running lightweight user research efficiently on the side.

The below ideas assume that you want to do user research but don’t have much experience and need the process to be dirt cheap, as you need to take care of your other responsibilities.

#1 Talk to users before planning anything

User research can be intimidating to start with if you don’t have prior experience. There is a large body of theory on meticulously planning your research – calculating sample sizes, thinking about different kinds of interviewer bias, sending out screening surveys, etc. I’d recommend that you hold off on the planning a bit.

Instead of jumping straight into planning, conduct a few semi-structured user interviews first. It doesn’t matter where you find the users; internal users work as well. Prepare a couple of questions, but let the discussion descend into chaos if the interviewee feels like sharing. Look for similarities between what interviewees care about.

Once you have a couple of interviews under your belt, you will be in a much better place to decide on the exact goals of your research and what questions to put into the screening survey. Talking to users gives you a better sense of which direction you want the research to take. It’ll also whet your appetite for more opinions, which is crucial for grinding through dozens of interviews with a smile.

#2 Practice writing meeting minutes

If you’re alone for the interviews, writing coherent meeting notes is a critical skill for executing user interviews.

There are two main ways you can record the contents of a user interview.

First, recording the audio/video of the meeting. This approach gives you a carbon copy of the meeting for posterity. Nothing else beats it in terms of completeness. It doesn’t come without downsides, though. Unless you combine it with an outstanding transcription tool, reviewing the interviews is very time-consuming. And no matter what the interviewee says, knowing you’re being recorded makes many people uncomfortable and alters their behavior, making them less willing to share.

Second, typing up meeting minutes as the interview is happening. You can opt for having a colleague in the meeting to type up the meeting notes. This is great but also risks that the interview will start feeling more formal, making the interviewee less comfortable sharing.

Personally, I enjoy typing up the meeting notes myself as they are happening, for a few reasons:

  • Provides the most “private” atmosphere conducive to interviewees sharing the small and embarrassing details that can reveal significant usability gaps in your solution.
  • I end the meeting with a complete transcript containing bits of my thoughts about what the interviewer said, things to check later, etc. It takes only a bit of time to polish the transcript up after the meeting, and it’s ready to be shared.

This said, making meeting notes of a user research interview is hard. You need to keep typing and thinking at the same time. You are not used to the particular person’s accent and way of speaking yet. And sometimes, you just don’t get what the interviewee is trying to say, so you’re not even sure what you should be writing down.

If you’re not strong at doing this kind of note-taking, I recommend you volunteer to be the meeting notes taker for as many work meetings as you can, even if no one reads them. This helps you improve your speed and notes coherency over time, making you a stronger interviewer in the process.

#3 Source Interviewees on Reddit

This bit of advice only applies if you work on something that is or interacts with a consumer-facing service, it might not work as well for business-to-business offerings.

Sourcing people for research on Reddit is a slam dunk.

Compared to any other potential source of interviewees I’ve tried (Twitter, emailing existing users), Reddit is an excellent source of candidates for users research, for a couple of reasons:

  • Ease of use – While sending bulk emails takes you down the path of trying to put email addresses from a CSV into the BCC field (I’m doing it via Excel + Outlook for Windows), writing a post on Reddit is as easy as it gets.
  • Better engagement – Without knowing too much about Reddit, it feels like it’s where people go to deep-dive into a topic, not only skim the surface. If you ask folks to fill out a survey, people who upvote the post also tend to fill it out. Conversely, my tweets asking the same end up with more likes than responses.
  • Diversity – One of my significant concerns about Reddit is that I’ll end up talking to people that fit a similar mold. It couldn’t be further from the truth. Within a span of a few dozen interviews, I ended up talking to university professors, actors, product managers, CEOs, students, and more. While interviewing Redditors will skew your sample towards the “advanced & passionate” crowd (whatever that means in your context), it’s a great starting place for many kinds of user research.

I’m not arguing that Reddit should be your sole source of interviewees, but that it’s a great start. If you can, pad your sample with different kinds of users. Namely, users that just entered your product category or are trying out your product will provide a great counter-balance to the Reddit crowd. This combination, in turn, gives you a stellar overview of the field, from rookies trying to figure things out to “wow, I didn’t even know you could make that work in my app” kinds of users.

#4 Learn mocking & reuse existing mocks

At some point, you will want to show the interviewees mocks of your ideas. If your company has designers, asking for a little bit of help can take you far.

I got very fortunate to get help from one of our stellar designers when thinking about the first batch of mocks that I’d like to show to the users in the interviews. He prepared a few mocks and shared them in Figma, which allowed me to reshuffle and iterated on them quickly without depending on someone having time to help me.

If your company already uses a tool for mocking, learn at least the basics. Ask around about where do designers store mocks and if you can use them. If you can find a cache of pre-existing mocks, you’ve hit gold. Adopting existing mocks is much easier than making new ones from scratch; reuse saves you a lot of time.

Hopefully, the tips above will help you kick-start your guerilla user research, generate great ideas, and fine-tune them while also having a ton of fun!

Cover photo by David Travis via Unsplash