Hostile Sheep Interactive Prototypes
A solution isn't proven until someone tries to use it.
We design with real people, not just for them. What comes out of that gets built and validated with real people too, including real assistive technology users, until it holds up under actual use.
Solution discovery
A defined problem doesn't point to one obvious way to solve it, it opens up several honest possibilities. Solution discovery is the divergent half of this process, where we generate as many real, viable concepts as we can before narrowing to one.
- Frame How Might We questions. Every solution starts with the problem reframed as a question worth exploring, not an answer already decided. We take what's already understood, research findings, business constraints, whatever groundwork exists, and shape it into How Might We questions that open up the widest possible range of solutions worth pursuing.
Example: Prototype Questions for The Lemonade Stand WEbsite
How might we let people know when the stand is open?
How might we make it easy for party planners to book the stand for an event?
How might we help neighbors feel more connected to the kids running the stand?
How might we make it easy for people to give more than the price of a drink?
- Map directions. Each How Might We question can be answered a dozen different honest ways. We map that range out as scenarios and user flows, quick and rough, sometimes several side by side for the same question, sometimes a storyboard instead, when a single scenario is complex enough to need one told in sequence. These give the internal team something concrete to align around, and give us real stimuli to design the co-design sessions from.
- Generative co-design. Sessions open with the How Might We questions themselves, put directly to the people who'll actually use the solution. Where a group needs a nudge, the mapped stimuli are there to offer as thought starters. This is the first time an interface exists at all, sketched by the users themselves, as many concepts as we can capture, while we get them talking through why they drew it that way.
What comes out of this isn't one direction. It's a wide, varied set of interactive concepts, framed, mapped, and sketched by the people who'll actually use them, ready to converge into one.
Solution definition
Discovery leaves us with a wide set of concepts, each viable, none yet proven. Definition is where we converge them into one, build it out fully, and prove it holds up before development ever touches it.
- Prototype. We build out what discovery surfaced, the How Might We questions, the maps, the concepts people sketched, into real, working prototypes, sometimes more than one, when more than one direction still deserves a real test. This is the first time a full experience exists, not a fragment or a flow on paper, but something a person can actually move through start to finish. Each one carries a claim, what we believe it does, and why, sharp enough that testing can prove it wrong.
- Experiment. We put the prototype, or prototypes, in front of real people, and where the stakes call for it, real assistive technology users, testing each one against the claim it was built on. What we learn in a session gets built in before the next one runs, so the prototype keeps evolving as confidence builds. Where we started with more than one direction, this is also where they converge, down to the one that's earned its place through repeated real use.
- Translation. A stable prototype is only valuable if everyone using it understands it. Most often that means a design system the team can build future screens from, and user stories that carry the reasoning into development. It can include roadmaps or other deliverables to help ensure our work makes an impact.
What you get isn't a finished product, that's development's job. It's one tested interactive solution, proven stable through repeated real-world testing, and translated into what your team needs to build it with confidence.
Prototypes make it safe to fail.
"If you find an error before coding begins, it costs a fraction of the time and budget to fix. But the true cost of a broken digital experience isn't just financial, it's the immediate and irreversible loss of your user's trust and agency." - Dr. Susan Weinschenk
Modern software development often prioritizes pushing things live fast, letting the end user stumble over what didn't work and report it back. That's a reasonable trade for a food delivery app. It's not one we're willing to make when your platform handles something someone actually needs. A prototype exists to find the break before a real person does, not to look finished for a room full of stakeholders.
- We refuse to use your most vulnerable users as beta testers. If something's going to fail, it fails here, in a prototype nobody depends on yet, not in the live system someone needed to work.
- We test with real assistive technology, not simulations of it. A screen reader user testing a prototype finds things a sighted researcher guessing at "accessible" never will.
- We treat a broken prototype as a good outcome. Finding the dead end now costs a conversation. Finding it after launch costs someone's trust, and sometimes their access to something they needed.
- We keep testing until the prototype is stable, not until the schedule says we're done. Experiment and Prototype loop for as long as it takes for confidence to be real, not scheduled.
- We stop the guesswork before it reaches a real person. A prototype exists so the interaction decisions get made deliberately, with evidence, instead of by whoever happens to be building the real thing later.
Get this right, and the mistakes stay contained to something nobody depends on yet. Get it wrong, and someone finds out the hard way, at the exact moment they could least afford to.
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.
Interface inventory
A catalog of the interface patterns already in use in your current solution: buttons, form treatments, navigation conventions, iconography, whatever's already been built and is already being used. Not an audit of whether it's accessible or well-designed, that's a separate conversation, just a clear picture of what exists today.
Why you need this
You can't decide what to change until you know what's actually there. An inventory gives us, and you, a shared, accurate picture of the patterns already in play, so Solution discovery can build on what's genuinely working and knowingly diverge from what isn't, instead of quietly reinventing something that already exists or missing an inconsistency that's been confusing people for years.
Scenarios & user flows
A spread of concrete directions, mapped for a single How Might We question and laid side by side, as stimuli rather than a chosen path. Each one is a different honest answer to the same question, a possible scenario or user flow, low-fidelity and fast to produce, meant to prompt a reaction, not agreement. Several often exist for the same question, since the goal at this stage is range, not a single best answer yet.
Why you need this
A dozen honest answers to the same question, laid out together, show the real range of what's worth considering, not just the first idea that felt obvious in the room. That range is what makes the co-design session that follows genuinely generative, rather than a group quietly agreeing with a decision that was already made before they walked in.
Storyboards
Where a scenario or user flow lays several possible directions side by side, a storyboard follows one specific moment of use from start to finish, including the context around it: where someone is, what device they're holding, what's happening around them, not just what appears on a screen. Storyboards typically emerge from the same step as scenarios, sometimes instead of one, when a story works better as a stimulus than a spread of touchpoints, sometimes alongside one, when a scenario has grown too complex to walk someone through cleanly on its own.
Why you need this
A screen can look perfectly reasonable in isolation and still fail the moment it's actually used, one-handed in a parking lot, glanced at mid-conversation, squinted at in bright sun. A storyboard puts the whole scene in view, the person, the place, the moment, so a concept gets judged against how it will really be used, not just how it looks sitting still.
Low-fidelity prototypes
Rough, fast sketches of a possible solution, often in quantity over quality. Minimal detail, no visual design, built to capture a concept quickly enough that a dozen different honest answers to the same question can exist side by side, not narrowed to one yet.
Why you need this
The earliest version of an idea is the cheapest one to get wrong. A spread of rough sketches shows the real range of how a solution could work, before a single hour goes into building anything, which is exactly when a bad direction is easiest to walk away from.
Mid-fidelity prototypes
The first version a person can actually click through. Structure and interaction logic are real, built to show whether a flow makes sense and whether an action does what someone expects. Content is represented as affordances, placeholders that show what kind of content a screen needs and roughly how much space it takes, not the content itself.
Why you need this
Whether something looks good and whether it works are two different questions, and testing them together hides which one actually failed. A mid-fidelity prototype answers "does this work" on its own, cheaply, before visual polish or final content has a chance to paper over a flow that never made sense.
High-fidelity prototypes
Used when the question being tested needs more visual or interaction detail than a mid-fidelity prototype can show, iconography, wayfinding, how a label lands, how a micro-interaction actually feels. Draft visual design and directional content, refined interactions, usually applied to a handful of key pages or moments rather than the whole solution end to end.
Why you need this
Some questions can't be answered by structure alone. Whether an icon reads clearly, whether a label actually orients someone, whether a transition feels right, all need enough visual and interaction detail to judge honestly, and testing that with anything rougher won't get a reliable answer. Focusing that detail on the specific pages the test actually needs, rather than the whole product, gets you a real answer without expanding scope on pages that were never in question.
Pilot-ready prototype
Before a prototype can be piloted, every screen it touches needs a finished design and a copy deck of real, approved content, not the content affordances used earlier, and not just the handful of key pages already resolved in high-fidelity. We work from an existing design system, or from newly designed screens and that copy deck. From there, we use AI-assisted development to translate the design and content directly into working code, a functional, hosted build a person can actually use, which keeps this step fast and affordable without sacrificing quality.
Why you need this
Confidence built on a design-tool prototype only goes so far, and a prototype full of placeholder content can't be honestly piloted, real people need real content to react to. A pilot-ready build is the only version that lets you validate with the exact people, and the exact assistive technology, your solution actually has to work for, before it's a live system anyone depends on.
Design system
The patterns that held up through testing, made consistent and reusable. This is a foundational design system, not a complete one: colors, typography, core components, and the interaction patterns proven out through Mid and High-fidelity prototyping, enough for a team to build from consistently, not a fully engineered, production-ready component library.
Why you need this
Without this, every new screen becomes its own decision, and small inconsistencies compound fast across a real product. A foundational system means the patterns that were actually tested are the ones that get reused, so consistency comes from evidence, not from whoever built the last screen. It's also the starting point a fuller, engineering-grade system can grow from later, not a replacement for one.
User stories
A short, plain-language description of what someone needs and why, written in the format development teams already use: as a [type of person], I want [a goal], so that [the reason]. Because these come from what testing actually confirmed, they slot directly into your team's agile backlog, ready to prioritize and build against, not rewritten later once someone discovers the assumption behind them was wrong.
Why you need this
Agile teams run on user stories, they're the standard unit most teams already plan sprints around. Stories written before anything's been tested are usually just guesses in a familiar format. These arrive already validated, so your team moves straight into planning and building from what's proven, instead of finding out mid-sprint that a story was based on an assumption nobody checked.
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.