Hostile sheep Information architecture
Structure is the part people feel first.
Every product carries an invisible organizing logic, and people bump into it constantly, whether or not anyone designed it deliberately. We make that logic intentional: shaped by how your users already think, tested against how they actually behave, and built to hold up as things grow.
Solution discovery
A precise problem doesn't always point to one obvious structure, it often opens up several worth considering. Solution discovery is where we generate real options for how your information could be organized, before committing to any of them. The shape gets drawn from what the research told us, how comparable services structure the same territory, and how the people who'll use it already think.
- Frame How Might We questions. Every structure starts with a question worth exploring, not an answer already decided. We take the problem statement and shape it into How Might We questions that open up the widest possible range of structural directions worth pursuing.
- Model. Each How Might We question can be answered a dozen different honest ways. We map that range into schematic models, draft taxonomies, navigation concepts, and system dynamics maps that show how everything connects, including the services people arrive from and leave to, quick and rough, concrete enough to react to, cheap enough to discard.
- Generative co-design. Sessions open with the How Might We questions themselves, put directly to the people who'll actually live with the structure. Where a group needs a nudge, the mapped models are there to offer as thought starters. Card sorting lets people group your content the way it makes sense to them, and working sessions invite them to reshape our models or sketch their own. Different thinking styles produce genuinely different structures, and that's the point: we want the widest range of directions before we start narrowing.
What comes out of this isn't a final architecture. It's a small set of genuinely different structural directions, grounded in evidence and shaped by the people who'll actually use them, ready to be narrowed and tested.
Example: IA Models for The Lemonade Stand Website
Product Logic: Classic, Pink, Raspberry, Strawberry, Seasonal
Task Logic: Order ahead, Visit the stand, Book us for your event, Meet the kids
Audience Logic: Thirsty people, Party planners, Our neighbors
Three honest structures for the same little stand, the question is never 'what's the sitemap,' it's 'which logic serves the people arriving.'
Solution definition
Discovery leaves us with a few genuinely different directions, each defensible, none yet proven. Definition is where we find out which one works best when real people try to use it, then commit to it fully, sharp enough for design and prototyping to build against immediately.
- Experiment. We ground our experiments in the How Might We questions discovery raised, and put each candidate structure in front of real people, measuring how well it holds up against every question it was meant to answer. Rarely does one structure win outright. The candidates tend to agree on some things and split on others, and that split is usually the most useful finding, it tells us exactly which pieces to combine into something stronger than any of them alone.
- Standardization. A structure that only exists as a concept isn't usable yet. We convert what survived experimentation into an actual information system, defined taxonomies, controlled vocabularies, consistent labeling rules, checked against the wider ecosystem it has to live in. This is where a promising idea becomes something a real team can build against without everyone interpreting it differently.
- Translation. A structure is only useful if everyone understands how to work with it. We translate the same underlying system into whatever each audience actually needs, a governance document for the team maintaining it, a taxonomy spreadsheet for the people building it, user flows for the team designing around it. Different formats, same structure underneath.
What you get isn't a sitemap. It's one tested structure, standardized into a system that holds together, and translated into whatever your team needs to actually use it.
Good structure is invisible
"Information architecture isn't just about making things easy to find; it is about taking the overwhelming mess of reality and giving it a structure..." - Abby Covert
Cognitive debt is the mental burden a system quietly hands people, extra decisions they shouldn't have to make just to find something, language that makes sense internally but not to anyone outside, structure that only works if you already know how it's organized. It doesn't stay contained. Left alone, it compounds, and it shows up everywhere downstream: in support tickets, in abandoned tasks, in people who stop trying.
Most of that debt gets created, or avoided, right here. A confusing category structure, a taxonomy that doesn't match how people actually think, labels borrowed from internal jargon, a flow that assumes knowledge nobody outside the building has, these are foundational problems. You can add all the delicious, beautiful decorations to a batch of sugar cookies. But they'll still end up in the trash if the dough is bad.
- We treat jargon as debt. If a label or category only makes sense to people who work here, it doesn't work. We rewrite it until it matches how people actually speak and think, not how the organization does.
- We build for how people think, not how you're organized. Categories and taxonomies get shaped around real mental models, never an org chart. That's the only kind of structure that holds up once real people use it.
- We measure more than task success. Getting someone to the right place isn't enough if they had to guess their way there. We pay attention to the hesitation and confusion along the way, not just whether someone eventually arrived.
- We design for people who don't already know their way around. Not everyone arrives already oriented. Clear wayfinding and consistent labeling mean anyone can find their footing immediately, no prior knowledge required.
- We build structure that scales without fracturing. Today's content isn't the only content this has to hold. Clear guidelines keep the system coherent as it grows, instead of slowly turning into a mess nobody can maintain.
Get the foundation right, and everything built on top of it, prototypes, interfaces, every interaction that follows, has a real chance to work. Get it wrong, and no amount of polish downstream will save it.
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.
Schematic models & site maps
Structural models that show how information actually relates, groupings, hierarchies, and the logic connecting them. Early on, several of these can exist side by side as candidate directions. As experiments reveal which logic holds up, the models consolidate into one clear structure. That structure can then be expressed however your project needs it: a site map, a content model, a taxonomy, an intent model for an AI system, or something else entirely.
Why you need this
A site map lists pages. It doesn't tell you why things are grouped that way, or what breaks if the grouping is wrong. What you get here is the structural logic itself, which means it isn't locked to one output. The same model can drive a website's navigation, a search system's categories, or how an AI product interprets what someone's asking for, because the thing being defined isn't a set of pages. It's how the information is organized underneath.
Target-state user flows
The specific paths people take through the structure to get something done, step by step. Where a model shows how information relates, a flow shows how someone actually moves through it: entry points, decision points, what happens when something goes wrong, and where they end up. These are built around the tasks that matter most, not every possible route.
Why you need this
Flows are where the awkward moments get found and resolved on paper, while changing them still costs nothing. Everyone downstream, design, content, development, is then working from the same understanding of how this is actually supposed to go.
Taxonomy & controlled vocabulary
The categories your content is organized into, and the specific words used to name them. A taxonomy defines how things group and relate to each other, often derived directly from the schematic model, expressing that same underlying structure as a working classification system. A controlled vocabulary settles which term wins when several could work, so the same thing is called the same thing everywhere it appears.
Why you need this
Shared vocabulary puts your content in your users' language, not yours. Consistent naming makes the system predictable to learn. And a multi-faceted taxonomy means people find things their own way, rather than the single path you happened to anticipate.
Target-state journey map
A map of the experience you're building toward, step by step, across every touchpoint someone passes through. Where a current-state map documents what's happening now, this one describes what should happen once the new structure is in place: where people enter, what they encounter at each stage, and what changes about how it feels to move through it.
Why you need this
This is where the whole experience gets seen at once. Complex journeys span phases, channels, and cycles that no single team owns end to end, and a target-state map is what holds them together in one view: how technology, content, and process combine into something a person actually experiences. For anyone trying to think holistically about a service rather than one screen at a time, it's the clearest picture of what you're building toward.
Target-state system dynamics map
A model of how any ecosystem behaves once specific changes are introduced. Typically, built as stock-and-flow or causal loop diagrams, it shows how information, work, and demand move between parts of the ecosystem, and how those parts influence each other over time. Where a current-state map reveals existing bottlenecks and delays, this one predicts what happens to them when you intervene.
Why you need this
A change that looks obviously beneficial in one place can create load somewhere else, or get absorbed entirely by a feedback loop nobody accounted for. Modelling the target state is how you see those second-order effects while they're still hypothetical, and it's what turns "this should improve things" into a specific claim about which delays shorten, which bottlenecks ease, and where new pressure is likely to appear.
Structural governance document
The principles and guidance for how the structure adapts as things change. How to evaluate whether something new fits the existing model or signals that the model itself should shift, how vocabulary expands without fragmenting into taxonomy sprawl, and what to consider when two parts of the organization see the same thing differently. It also covers the operational side: who owns which decisions, how changes move through your workflow, and what permissions sit where. Written with examples, for the people who'll be making these calls long after the initial work is done.
Why you need this
A resilient information architecture evolves as user needs shift, as the market moves, and as the business changes. This is what makes that possible: your team has the reasoning behind every structural decision, not just the decision itself, so they can extend the model confidently, recognize when something genuinely doesn't fit, and adapt it deliberately rather than working around it.
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.