We design systems with the people who'll live inside them.

Why we co-design

Most enterprise software is delivered to people. Requirements get gathered, decks get presented, a system arrives, and the people who do the actual work are left to adapt around it. That produces the familiar shape of modern operations, with tools no one trusts, workarounds in spreadsheets, and the quiet resignation of "that's just how it works here."

We don't think that's an inevitability. It's a choice about who gets to author the system, and we make a different one.

Co-design, for us, means the people who will use the system are present while it's being thought through, not interviewed at arm's length or surveyed after the fact. Their judgment, their edge cases, their shortcuts and frustrations are part of the material we build from, instead of signals to be translated by someone else and handed back as a specification.

This is also where the human expert in the loop starts. It's the posture we begin with, not a feature we bolt on later.

What good co-design looks like to us

• The people who do the work are in the room. Not their managers' interpretation of the work. The work itself.
• We sketch in the medium of the actual system, working surfaces, real data, narrow slices, not in the medium of slides.
• Disagreement is useful. When an operator and a director see a process differently, that gap is the design problem; we don't paper over it.
• We design for the day after launch, not for the demo. If a flow only holds up under ideal conditions, it isn't designed yet.
• We name what's tacit. Most of what makes an organization work is unwritten. Surfacing it carefully is half the job.
• We change our minds in public. If something we proposed last week doesn't survive contact with the work, we say so and move.

What we refuse to do

• Workshops as theater. Sticky notes on a wall, a photo for the deck, no shift in what gets built. We've seen it. We won't run it.
• Decks as deliverables. A slide isn't a system, and we don't bill for artifacts that can't be used after the meeting ends.
• Discovery as a sales funnel. We don't run "discovery" whose real purpose is to manufacture scope. If we're discovering, we're discovering.
• Designing around the loudest voice. Seniority in a room is not the same as expertise in the work. We listen for both, and we say so when they diverge.
• Pretending the org chart is the process. It rarely is. We follow the actual path the work takes.
• Outsourcing judgment to the model. AI is in the loop here, but it doesn't get the final word on how someone's day is shaped.

Who this is for

This way of working fits organizations that already suspect their problems aren't going to be solved by another procurement cycle. Leaders who are willing to put their best operators in the room and let them speak. Teams that would rather hear an uncomfortable observation early than a polished one late.

If the goal is a system that the people inside it want to use, and that holds up when the work gets strange, we're a good match.

For the capability framing of this work, what we build and what gets delivered, see /co-design.