Sometimes the hardest design problem is not a user-facing flow. It is creating the path from a well-researched insight to something other people can understand, support, and help make real.
2022 · Airspace Acting director, research + product design
A product idea can be sound and still fail to move. The problem is not always that people disagree with it. Sometimes they simply cannot see enough of it at once to know what they are being asked to support.
That was the shape of a systemic change I helped lead at Airspace, a logistics company that moves time-critical shipments, surgical kits, aircraft parts, anything that cannot be late. At the time I was acting as Airspace’s director of research and product design, leading a practice I’d grown from just the two of us to a team of ten. Research across the roles who run that work kept pointing at the same pattern: the services we offered, the attributes that described a shipment, and the tasks people performed to move it were welded together, so every new customer need became a one-off, custom build. A more flexible model, where services, attributes, and tasks are separate pieces that combine, could change that. But the evidence lived in separate interviews, workflows, prototypes, and feature conversations. No one artifact made the whole system feel like a single, coherent investment.
The first design problem was not the system. It was the room.
It is tempting to describe this gap as a need for “buy-in,” as if people should simply be persuaded. That framing misses something important. The people responsible for a decision have their own questions, context, constraints, and risks. They are users of the idea, too.
So we turned the gap into a design question: what would someone need to see, understand, and believe before they could support a larger investment? The goal was not to make the work sound grander. It was to make it sound simple and reproducible.
System model / communicating a flexible product modelA shared picture before the detailed work
Make it easy to hold the whole thing at once.
I asked our lead UX researcher and a senior product designer to design the ideal way into SATS, and we ran a focused sprint on the communication itself. The output was not a prettier deck. It was a set of ways into the system: simple diagrams that connected different user problems, a conceptual story that let someone follow a few meaningful paths through the model, and supporting research ready for the practical questions that would inevitably follow.
A name mattered, too. We started calling the model SATS, for services, attributes, and tasks. The short label gave a sprawling collection of capabilities a single handle. Once the idea had a shared shape and language, it became easier for people to refer to it, challenge it, and remember why the parts belonged together.
01 / Name the pattern
Give separate parts a form people can point to.
A clear model and a simple name help a systemic idea read as one thing, rather than a pile of unrelated requests.
02 / Simplify, not flatten
Show the route through the complexity.
A good story does not hide the hard parts. It gives people enough structure to understand why they connect and where they lead.
03 / Bring the evidence
Let the idea answer real questions.
Research, examples, and working models make the story durable when the conversation moves from potential to tradeoffs.
Working model / one scenario
When does a one-off stop being cheap?
Say your team ships four custom builds a year. Building them costs about twelve weeks, every year, steady. Once a build is live it needs a little upkeep forever after, about two weeks a year per build, and that bill only grows.
Which year does keeping the old ones alive cost as much as building new ones?
Year 2Year 15
Arithmetic on your estimates, not a measurement, and it assumes a one-off keeps costing after it ships and rarely gets retired, which is the assumption most teams get wrong in the optimistic direction. Ship half as often and the wall barely moves: its date is set by build time against upkeep, not by how many you ship. A composable model is not free either. It just stops charging rent per customer.
Test the story before you ask it to travel.
The first audience was a senior technical leader who had seen several of the pieces, the prototypes and some of the research, but had never seen them as one system worth championing. The new material created enough shared context for the idea to click. From there, the work had an advocate who could carry it to the people responsible for setting priorities.
This is not a trick for manufacturing consensus. It is a way to find out whether the connection you see is actually understandable to someone who does not have your accumulated context. If they cannot carry the idea forward accurately, the work is not done.
The work after yes is to keep the system real.
Once the system was prioritized, the job changed. A shared story had to become working architecture, smaller releases, and an adoption process people could use responsibly. The idea needed to survive contact with engineering decisions, operational exceptions, and the ordinary pressure of a roadmap.
That is the part I keep returning to: the artifact that earns alignment is not separate from the product work. For a systemic idea, it is the beginning of the product. It gives people a common frame for building, debating, and improving the thing together.
