Hostile Sheep UX Research
We want to understand the problem space.
Before anything gets built, we learn the shape of people's lives, the market you're in, and what actually matters to your business. That's how we ensure our design fits your users' needs, and never becomes another thing working against them.
Problem discovery
Before we can help you build the right thing, we have to see clearly through what's obscuring it, for the people you're building it for, for the market you're operating in, and for the business trying to make it work. Discovery is where all three come into view at once, not one at a time, and how we go about it depends on what will actually get us the clearest picture, not on habit or convenience. We also start by asking your own team what they believe is going on, every organization carries theories about why things aren't working, and naming them early means we can actually test them, instead of leaving them to resurface later as doubts.
- Users. We want to reach the widest, most honest range of perspectives and choose our methods to achieve that goal. Users are the experts on their own experience. Understanding what's really driving a decision, not just what someone did or said they'd do, takes deliberate probing and cross-checking against everything else we're hearing.
- Market. We look at what already exists in the market, competitors, comparable services, leading practice elsewhere, so we know whether a problem is genuinely unsolved or just unsolved by you.
- Business. We talk to the people inside your organization who feel the problem too, support teams, frontline staff, whoever absorbs the consequences when the system doesn't work, since the business's own experience of the problem is data, not just the end user's.
We're always looking for ways to give something back to the communities we work within. That often means bringing on a local research assistant, someone who gets real hands-on experience and a closer look at their own community, while we get someone who already understands the context we're stepping into.
What you get isn't just a pile of notes. It's a clear, shared understanding of what's actually going on, and why, before anyone starts designing a response to it.
Problem definition
Discovery leaves us with pieces from a few different vantage points, what people told us, what the market shows, what the business feels. Definition is where those pieces come together into one precise, complete picture, not a quick summary of everything we heard, but a problem statement specific enough to act on.
- Synthesis. We push past the surface-level complaints everyone already knows about to find what's actually driving them. A vague finding isn't the same as a usable one, "the checkout is confusing" doesn't tell anyone what to build. We write problems with enough precision that they're ready to act on, not just agree with.
- Prioritization. A precise problem is rarely one-dimensional, it usually has a few real facets worth naming individually. We help you see which parts of that picture matter most to address first, and which can genuinely wait, without losing the single, coherent problem they're all part of.
- Hypothesis development. By the time a picture is this clear, early ideas about what might address it are already starting to surface. We capture those hypotheses here, without designing them yet, that's the raw material that carries into the solution space.
What you get isn't a wall of findings. It's one precise, complete problem picture, the specific facets of it worth prioritizing, and the early hypotheses that give design somewhere real to start.
Care and safety are part of our method
"Exclusion happens when we solve problems using our own biases. The people who face the greatest barriers are the ones who can teach us the most about building better systems." — Kat Holmes
All of our research runs through the same test: does this work for someone on their hardest day, not just their easiest one. That's not a courtesy we extend when it's convenient, it's built into how we do the research itself, because a system that holds up under stress, low bandwidth, or an unfamiliar device helps everyone.
- We plan for real conditions, not ideal ones. Not everyone has a fast connection, a new device, or a quiet place to talk. If the way we run research assumes any of those, we've already lost the people we most need to hear from.
- We treat crisis as ordinary, not exceptional. Many of the people we talk to are living through the exact situation we're studying, not observing it from a comfortable distance. We design for that as the real condition, not a rare edge case.
- We ask, and keep asking. Consent isn't a form signed at the start and forgotten. We check in throughout, and we treat "I don't want to answer that" as a complete answer, not an obstacle to work around.
- We prefer curiosity to control. Steering someone toward the answer we expect doesn't just risk harm, it produces bad data: people perform what feels safe to say instead of telling us what's actually true. Staying genuinely curious, and aware of our own assumptions, is what gets us the real answer, not just a comfortable one.
- We look after the people doing the asking, too. Hearing what someone's actually been through, a paramedic describing their worst calls, a parent describing a system that failed their kid, takes something out of the person listening. We take that seriously as part of the work, not something to push through quietly.
Get this right, and it's not just the people we're studying who are safer for it. The findings are more accurate, and the people doing the work hold up too.
These are the deliverables clients ask about most, not a complete list. Every engagement is different, so what you receive is shaped around your problem, not pulled from a menu.
Problem statement & synthesis report
Built from everything gathered across user interviews, field studies, surveys, stakeholder interviews, and market analysis, including the theories your own team brought in at the start, tested against what we actually found.
Why you need this
Imagine finally naming the real reason something isn't working, not just the symptom you've been circling for months. No more debating what 'confusing' actually means. Just one clear, specific problem the whole team can act on.
User personas
Personas built to guide the development and evolution of products and services. Each one articulates what people are actually trying to accomplish, written as jobs-to-be-done. They also define the thinking styles behind how different people approach the same task. Built from user interviews, surveys, and field observation.
Why you need this
Do you want personas your team actually uses, not demographic profiles with stock photos that get referenced once and forgotten? Because these personas are organized around what people are trying to do and how they think it through, they answer real design questions: which path someone will take, where they'll hesitate, and what they need to move forward with confidence.
User journey maps
A visual map of how people actually move through your product or service, step by step, across every touchpoint, including the ones outside your product. Built from user interviews, field observation, and the real paths people take, not the path the org chart assumes, this map often feeds directly into the synthesis report.
Why you need this
Your team sees their own step in the journey clearly, support sees tickets, product sees screens, operations sees process. A journey map puts the whole path in one view, so the moments where people get stuck stop falling into the gaps between departments, and everyone can finally point at the same problem in the same context.
Market scan & competitive analysis
A clear picture of the landscape you're operating in: who else is solving this problem, how they're approaching it, and where leading practice has moved. Built from reviews of comparable organizations, similar services inside and outside your sector, and the standards your users have already learned to expect elsewhere.
Why you need this
The bar for your product isn't set by your industry, it's set by the best experience your users had anywhere, this morning. This report shows you where that bar actually sits: which problems are already well solved and worth learning from, and where the genuine gaps are, so you invest in the difference that matters instead of rebuilding what already exists.
Accessibility & inclusive design evaluation
A systematic review of where your product or service creates barriers, measured against WCAG standards, and beyond them, into the gaps a compliance checklist alone won't catch. Built from expert evaluation, often including testing with people who actually use assistive technology, not simulations of them.
Why you need this
Passing an automated scan and being genuinely accessible are two different things, plenty of products clear the first and fail the second. This evaluation tells you where you actually stand on both: what puts you at legal risk, what quietly turns people away, and which fixes matter most, so accessibility becomes something you've verified, not something you're assuming.
Prioritized opportunity list
Every opportunity worth pursuing, whether it comes from a problem the research surfaced, a gap the market scan revealed, or an idea worth testing, ranked by evidence, not gut feel. We prioritize at two levels: the RICE method for scoring individual opportunities, and a broader look at desirability, feasibility, and viability to keep the whole picture honest. Shaped with your team, so the ranking reflects your real constraints, not just our view from outside.
Why you need this
Research usually surfaces more opportunities than any budget can touch at once, and without a ranking, whichever one got mentioned in the last meeting wins. This list gives you a defensible answer to "why are we doing this first?", one you can take to leadership, a funder, or a skeptical stakeholder, backed by evidence instead of opinion.
Findings presentation & workshops
The research, worked through with your team, presented, questioned, pulled apart, and turned into decisions, not attached to an email and left to fend for itself. Sometimes that's a single presentation. Sometimes it's a series of working sessions. It takes what it takes for your team to genuinely own the findings and know what to do with them.
Why you need this
A report nobody absorbs might as well not exist. These sessions are where findings actually land, where your team gets to push on the evidence, ask "but what about...", and work out together what happens next, leaving with a shared understanding instead of seventeen private interpretations. It's the difference between research your organization has and research your organization uses.
Introducing the new Hostile Sheep
We’ve always been here to challenge what needs challenging and protect what matters most. What’s changed is how clearly we see the systems we’re part of and how intentionally we choose to engage with them. Hostile Sheep is no longer just our name. It's our stance. If you'd like to know what we stand for, we wrote it down.