How I build design tools - and why process is the product...
I recently spent a day building a structured AI tool for Apple platform design. What surprised me wasn't the outcome, but the ease of decision making along the way.
The tool is called Keen EyeOS. It helps developers and designers make better choices when building apps for iOS, macOS and iPadOS. It has five sub-skills, a tiered component reference, and an onboarding flow that adapts to the user's level.
But the process of building it turned out to be a fairly precise portrait of how I work.
Start with the friction, not the solution.
The tool didn't start with a feature list. It started with a specific problem: developers who knew their framework but reached for the wrong component. Designers with good instincts who didn't know what was technically possible. Product people who couldn't bridge the two. That precise frustration - not a generalised brief — drove every subsequent decision.
Name things so they stick.
I pushed back on generic labels. We landed on Keen Vision, Keen Feature, Keen Polish, Keen Signal, Keen Stage. Each name signals its purpose immediately. Shared language is shared thinking — and in a design team, naming is not an administrative act, it's a design act.
Clarify output upfront.
Midway through, I moved the output selection to the beginning of the flow. If you know you're producing a developer spec, the whole session should be shaped toward that. Misaligned expectations about deliverable format are the most common source of wasted work I've seen — in agencies, in product teams, in internal bureaus.
Respect people's time.
Four onboarding steps is the right depth for a complex session - but for a simple question it's the wrong path entirely. We added a fast path: an intent check at the top that skips setup when it isn't needed. A small decision that signals something important: don't apply more structure than the situation requires.
Make tradeoffs visible.
Every choice in the flow got a short note explaining what it loads, what it skips, and what it costs. Not because users needed to manage technical overhead - but because informed choices are better choices. That's the same approach I take with stakeholders: recommend a direction, but make sure they understand what we're optimising for and what we're accepting as a cost.
Keen EyeOS is open source.
The full skill - all sub-skills, component guides, and output templates - is available on GitHub. Fork it, adapt it, or use it as a starting point for your own Apple platform projects.