The Experience Team Of One A Research And Design Survival Leah Buley

Going Solo in UX Doesn't Mean You're Lost

When I first got assigned as the only person responsible for research and design on a product team, I thought I was in over my head. The workload was real, the stakeholders were plenty, and there was nobody to bounce ideas off at 3 PM. That's when I started digging into Leah Buley's approach to solo UX practice. It changed how I worked permanently. Leah Buley's book isn't theory. It's a field manual. She walks through the actual mechanics of running research, making design decisions, and managing stakeholder expectations when there is no support team behind you. The core premise is straightforward enough: you can do solid UX work alone if you structure your time, pick the right methods, and stop trying to do everything perfectly. What most people miss about the book is how specific it gets about time allocation. Buley doesn't just say "do user research." She breaks down exactly how to run a usability test with five participants when you have three days and a Slack channel full of interruptions. I found that practical breakdown more valuable than any academic textbook on the subject.

One thing the book handles well is the psychology of working alone. There's a chapter on impostor syndrome that isn't fluffy motivational content. It's grounded in real scenarios — like when a PM asks why your research took two weeks instead of two days, and you have to explain methodology without sounding defensive. She gives you language to use. I've used those exact scripts in meetings.

What Actually Works When You're the Only UX Person

The research methods section is where this book earns its keep. Buley covers the full range — contextual inquiry, diary studies, card sorting, tree testing, A/B testing analysis — but she filters everything through a single question: can one person execute this without burning out? Her take on usability testing is probably the most useful part. Most guides tell you to recruit five to eight participants and run moderated sessions. Buley shows you how to adapt that process when you're also handling product management questions on the side. She recommends remote unmoderated testing for early-stage validation and reserves in-person sessions for deeper exploratory work. That distinction alone saved my team months of misdirected effort. I ran into a specific edge case that her book prepared me for. We were designing a checkout flow for an e-commerce platform, and I needed to understand why users were abandoning at the payment step. Traditional usability testing wouldn't give me the full picture because the issue wasn't about interface confusion — it was about trust signals. Buley's framework for combining task-based testing with empathy mapping helped me restructure the study. I added a post-task interview component where participants explained their emotional response to each step. That revealed the trust gap faster than any heat map ever could.

The workaround I ended up developing was creating a hybrid research plan that blended a quick unmoderated test with follow-up semi-structured interviews. It took about four days total instead of the two weeks a full moderated study would require. The data was cleaner too, because I wasn't trying to parse behavior from metrics alone.

The Stakeholder Problem Nobody Talks About

Working alone means you answer to everyone. Buley addresses this honestly in several sections. The problem isn't just having too many requests — it's that stakeholders don't understand what research can and cannot answer. A common mistake I see solo practitioners make is agreeing to do a full research sprint when the stakeholder actually needs a one-question survey. She provides a stakeholder request triage system that I still use. It's essentially a decision tree: define the question, determine what evidence would change the decision, and match the method to the evidence needed. If no existing data answers the question and the decision is high-stakes, you run the full method. If the decision is low-stakes or the question is already answered, you push back and propose a lighter approach. This framework has prevented me from taking on unnecessary research projects more times than I can count. Another counter-intuitive insight from the book is about documentation. Most solo UX people think they need to produce comprehensive reports to prove their work. Buley argues the opposite. She recommends short, visual summaries that get shared within 48 hours of completing any research activity. The reasoning is practical: by the time you finish a polished report, the context has shifted and nobody is reading it anymore. A one-page summary with key findings and recommended next steps actually gets actioned.

Design Work Without a Design Team

The design execution section covers wireframing, prototyping, and design systems when you're doing it all yourself. Buley's advice here is pragmatic to the point of being almost blunt. She recommends starting with low-fidelity sketches before touching any design tool. Not because low-fi is inherently better, but because solo practitioners spend too much time polishing pixels instead of validating concepts. Her take on design systems is worth noting. She suggests building a minimal system — not a comprehensive one — focused on the components you use most frequently. I built a system with roughly twelve components and it handled about eighty percent of my design work. The time I saved on not having to design buttons from scratch every time was significant. There's a section on prototyping tools that acknowledges reality. She doesn't push any particular tool. Instead, she matches tool recommendations to project phase: paper prototypes for early ideation, Figma for mid-fidelity testing, and interactive prototypes only when stakeholder buy-in requires it. The message is clear: match the fidelity to the question you're trying to answer, not to whatever your team at another company is using.

Where the Book Falls Short

For all its practical value, the book has limitations that matter depending on your situation. The first is scale. Buley's methods are optimized for small to medium product teams where one person owns the UX process. If you're working at enterprise scale with multiple product lines and hundreds of stakeholders, the frameworks need heavy adaptation. Some of the examples assume a level of autonomy that doesn't exist in larger organizations. A second limitation is the focus on digital products. Most case studies come from SaaS and e-commerce contexts. If you're doing UX for hardware products, healthcare platforms, or embedded systems, you'll need to extrapolate significantly. The research principles still apply, but the day-to-day mechanics are different enough that the book won't be directly applicable. The third gap is in team scaling. The book assumes you stay solo. It doesn't address what happens when you eventually hire other researchers or designers. I found that section missing because transitioning from solo practice to leading a team requires a different skill set that Buley doesn't cover. If you're in that position, you'd need supplementary reading on people management and process documentation.

Practical Takeaways for Getting Started

If you're considering implementing the approaches from this book, here's what I'd suggest based on experience. Start with the stakeholder triage framework. It's the highest-leverage change you can make because it prevents scope creep before it happens. Then pick one research method and run a complete cycle — planning, execution, analysis, and sharing results — within a single week. The speed forces you to make decisions you'd otherwise postpone indefinitely. Build your documentation habit early. I wish I'd started writing one-page summaries from day one instead of waiting until I felt like I had "enough" data. The habit of communicating findings quickly became the single most impactful change to how my work was received by stakeholders. Keep a research log. Buley mentions this briefly but it deserves more attention. Track every study you run, the methods used, participant counts, key findings, and what you'd do differently. Six months later, this log becomes invaluable when a stakeholder asks "what did we learn from that checkout study?" and you can reference specific dates, numbers, and conclusions instead of guessing.

The book is available through most major retailers and in various digital formats. It's not free, but it's positioned as a practical investment rather than an academic text. Given the time it can save on avoiding common pitfalls, the cost pays for itself quickly if you're regularly working as the sole UX practitioner on a team. Overall, the Experience Team of One framework works because it respects the constraints of solo practice instead of pretending they don't exist. The methods are scaled to what one person can actually sustain, not what a ideal research team would produce. That realism is what makes it useful rather than inspirational.