Executive Design Leader
Head of Design Task
PART 1
Impactful Achievement
In no more than 2 pages, please describe one career achievement that you believe best represents the impact you could have as Head of Design at Orbital.
You may choose any example from your career, but ideally one where your design leadership played a meaningful role in a step-change in product quality, user adoption, or business growth
PART 2
Orbital’s Next 12 Months
We’ve recently landed a $60M Series B, expanded into the US a year ago, and are growing the impact of our Product and Design organisation over the next year both with people and tokens.
We’d like to understand how you think about AI innovation and how you’d lead Orbital through this next phase of growth.
The most valuable thing a platform business can spot is its customers using the product for something it was never explicitly built to do. At Monday.com, we saw exactly that.
IT teams inside our customer base were quietly turning the platform into a service desk. They were using our built-in forms to let colleagues log tickets, wiring up automations so requests flowed in from Slack and email, and then — manually — reading, triaging and routing every one of those tickets themselves. Nobody had designed Monday to be an IT service management tool. Customers had built it themselves, out of the parts we gave them.
That pattern was the opportunity. Service desk is a large, well-understood category, and it's a natural wedge into exactly the enterprise accounts Monday wanted to grow into. The pain was just as clear: the manual triage layer these teams had built was a bottleneck. Every ticket waited on a human to look at it before anything happened. Solving that was worth real money to the customer, and a credible new product line for the business at a moment when we needed to show we could expand beyond the flagship.
AI had just become good enough to be the first responder, not just an assistant to one.
Most "AI for support" thinking at the time stopped at suggestion — draft a reply, surface a similar ticket, help the human go faster. We made a stronger bet: AI was now mature enough to be the first line of response and diagnosis itself. Triage, classify, diagnose, and resolve the straightforward cases before a human ever opened the queue. That reframed Service from a feature inside WorkManagement into something we could package and sell as a standalone product — this was move that justified an enterprise price point.
The second insight was architectural, and it came from approaching the problem from first principles. We didn't need to touch the underlying platform infrastructure at all. The boards, forms, automations and data model already worked. What we needed was a new AI layer that sat on top of the existing platform — using everything that was already there, adding intelligence above it. That decision is what made the product fast to build and safe to ship.
We validated the bet two ways. First, the usage data itself — we already had real customers running real service workflows on the platform, so we weren't guessing at the use case, we were instrumenting one that already existed. We anchored on the metrics those teams already cared about, resolution time chief among them. Second, we dogfooded it hard internally — more on that below — which gave us a brutally honest signal long before launch.
The design approach followed one principle: go from the familiar to the new. Enterprise buyers are rightly wary of AI-native tools. So the product had to feel like something they already understood — a service desk, with queues, tickets and SLAs — while the AI layer quietly did the heavy lifting underneath. Familiar surface, new engine. That meant enterprises felt comfortable from day one and could see the efficiency gain immediately, rather than being asked to take a leap of faith.
To make the value undeniable, we instrumented the product around the metrics we'd identified from those original customer use cases — resolution time above all. The product didn't just resolve tickets faster; it showed the IT team it was doing so, in their language, which is what justified adoption and the price tag.
Alongside the customer work, we ran the build through what I called the "wine-tasting" initiative — a step beyond dogfooding. Dogfooding tells you whether the product works; wine-tasting is about the finer details that separate good from exceptional. Our own IT and support teams were among the most critical users we could ask for, and their feedback shaped the product before a single external customer saw it
I owned the design strategy and design execution for Service end to end — the "familiar to the new" principle, the information architecture, the interaction model for the AI layer, and the design team building it. I co-owned the product strategy with the PM and CPO: the decision to package Service as a standalone product, the enterprise positioning, and the metric framing were shared calls. Feature-level execution sat with the design team I'd staffed and directed.
The trade-off I made deliberately: we deliberately constrained what the AI was allowed to resolve autonomously at launch, even though it was technically capable of more. Trust had to be earned. The path I rejected was the tempting one — leading with the AI, making it the headline, a chat-first "ask our AI" experience. That would have impressed in a demo and failed in an enterprise procurement review.
A new standalone product, AI-native from day one — Service launched as part of a new-product push that, alongside Dev, accounted for $40m ARR within six months, from a zero baseline.
For users: the manual triage bottleneck went from "every ticket waits on a human" to AI handling first response and diagnosis automatically — a measurable reduction (from extreme cases of days, to seconds) in resolution time for the IT teams adopting it, against their own pre-Service baseline.
Strategically: Service gave Monday a credible wedge into enterprise, turning an unmonetised usage pattern into a packaged, upmarket product line.
Culturally: it proved a model the whole org could repeat — watch how customers bend the platform, then build the AI-native product they're already asking for. "Familiar to the new" became a principle other teams reached for.
If I had another run at it, I'd build the AI feedback loops in from day one rather than retrofitting them. By that I mean the discipline of capturing where the AI gets it wrong in the real world, feeding that back into prompts, guardrails and patterns, and shipping the improvement on a tight cycle. We treated the launch as the finish line for too long; an AI-native product is never finished — it gets better or worse depending on the loops you build around it. I'd also formalise the wine-tasting feedback earlier, so the finer-detail signal was structured rather than ad hoc.
The deeper lesson, and the one that shapes how I lead today: AI doesn't change what design is for — it changes what design has to continue to lead. The job is to hold the line on user trust and on craft quality, and balance the organisational pull to make the AI the headline, but rather the value to users. Lead with the familiar, let the AI earn its place, and prove the value in the customer's own metrics. That's the lens I'd bring to Orbital.
The shift in my thinking over the past year isn't that I've become more bullish on AI. It's that I've become more disciplined about not offloading critical thinking to it.
A common dynamic I observe with AI: it feels most impressive when you don’t know much about the subject, don’t care about the result or don’t have a clear idea of what you want.
This applies across design, code, legal etc.. If for example I don’t know code very well, every piece of code it writes feels very impressive because I don’t have knowledge to evaluate the output. Once you know what is good and exceptional, what something should feel or look like, it becomes very hard to guide AI there. And you definitely can’t one-shot prompt it.
Judgment and taste are as important as they've ever been — maybe more so, even though they're getting squeezed by the speed everything else now moves at. The temptation in an AI-first environment is to prompt your way to an answer that looks plausible and ship it. That's the failure mode I'm watching for, in myself and in the teams I lead.
Here's the tension I keep coming back to: LLMs are probabilistic. Design is deterministic. Two opposing mental models, fighting each other every time you try to ship. Most teams gloss over the friction and end up with features that feel bolted on, ill conceived, and mediocre at best. The actual work is figuring out where the two models align and where you have to protect the deterministic part. (You can mitigate some of it through tooling - design.md files, access to design NPM packages, repos, Figma MCP and even sites such as Mobbin for reference. This gives you a consistency baseline, and it's genuinely useful - but it can be the fastest way to mediocrity and standard.)
But here's where I continue to land: prompting your way through design isn't enough to get to 'exceptional'. You actually have to feel it and deeply investigate what goes beyond the expected. Designers will always need direct manipulation of the element and interaction, for example: Fine-tuning the curve of a transition, watching motion guide someone through a state change so they understand what just happened in the system. That's not decoration — it's functional. Motion exists to educate the user, not to delight them. Transition design exists to make complexity legible. None of that comes from a prompt; it comes from craft and judgment, applied in the prototype with live data and real users in front of you.
This is how I've always run design teams: if a picture paints a thousand words, a prototype saves a thousand meetings. The most mature teams I've worked with get this instinctively — they stop debating what users will think and get it in front of them. Less mature teams have to be encouraged and shown the way. Either way, the discipline is the same: get out of the deck, into the prototype, in front of real customers to learn.
What this means at Orbital over the next 12 months: I'd use AI aggressively for the commodity work (component generation, layout exploration, content synthesis, feedback triage) and ringfence the time it buys to invest harder in prototyping with live customer data. For lawyers especially, this matters. They will not tolerate AI theatre. They will tolerate — and trust — software that demonstrably removes complexity from their day. That's only knowable by putting it in their hands and watching what happens.
What separates an AI-native designer from a strong traditional designer isn't tooling fluency — that's table stakes. It's three things, and I'd hire and lead for all three:
First, first-principles thinking. The biggest risk with AI tooling is that designers offload the thinking. They prompt their way to a solution that looks right, ship it, and never interrogate whether it actually solves the problem. AI-native designers use AI as a thinking partner, not a substitute for thinking. They still ask why are we doing this, and does this remove complexity for the user, or just reorganise it. When I hire, I look for evidence of pushback — designers who can show me where they rejected the obvious AI answer because it wasn't the right one.
Second, the feedback loop instinct. They use AI to synthesise user feedback at speed — but they don't let synthesis become a substitute for direct contact. They still want to watch users struggle. They feed the synthesis back into iterative design and use the time AI saves them to run more prototypes, not fewer. The instinct I'm looking for: every output is an input to the next loop.
Third, building the guardrails. AI-native designers don't just understand that model outputs are probabilistic — they proactively build the skills, design standards, evals and reusable patterns that stop the team falling into prompting blackholes. You know the failure mode: a designer spends two days prompting their way around the same problem because there's no guardrail in place. The AI-native instinct is to invest in the loops and tooling that make the next attempt better than the last, so the whole team gets faster together rather than each designer reinventing the wheel.
On rituals and culture: I'd run weekly prototype reviews with live data, not static screens. I'd make eval-writing (in both senses — AI evals and design-standard evals) part of every review. I'd invest in the team's coding skills — not because designers need to ship production code, but because the round trip from design to code and back is where speed actually lives. I'd protect critical thinking explicitly — make space for first-principles questions in every kick-off, so the team doesn't drift into prompt-and-ship mode.
And one thing I'd hold the line on: the human signal. I've experimented quite a bit with AI-generated imagery, avatars and text-to-speech video, including some of what's on tem.energy. It's powerful, but I'm increasingly concerned about users' relationship with content they know is purely generated. It strips out the sense that there are real humans behind the product, and that sense matters — especially for trust-critical software. So I'd have the team using AI to accelerate, not to replace the human signature on what we ship.
What can be augmented or automated today: component generation, design system maintenance, content variants, research synthesis at first pass, layout exploration, accessibility checks, copy iteration. This is the commodity layer, and AI is genuinely good at it.
What can't be automated — and I don't think will be any time soon — is the work of deciding what to build and making sure it's designed right. That's the actual craft, and it's three things AI can't do on its own:
Trust calibration with expert users. Lawyers, traders, doctors, engineers — they don't trust AI by default, and they shouldn't. Designing interfaces that earn their trust requires watching them use it, listening to where it breaks down, and making judgment calls about when to show confidence and when to defer to the human. That's craft. It's not promptable.
Complex information architecture. Especially in a domain like real estate law, where the structure of the information is the product. Getting that right requires deep domain immersion, not just pattern matching. AI can suggest structures; it can't tell you which one will actually hold up in practice.
Removing complexity rather than organising it. This is the test I apply to my own work. AI is great at organising complexity — but it's surprisingly bad at removing it. Removing complexity requires understanding what the user is actually trying to do and aggressively cutting everything else. That's a judgment call rooted in taste, first-principles thinking, and time spent with users.
For thinking, Claude is my default — research synthesis, briefings, prompt design, structured exploration of options — with ChatGPT alongside it for variety. I build my own workflows and skills and use them to upskill the people around me.
For design, I treat the new generation of tools as a constant testing surface, not a novelty. I'm anchored in Figma, but I prototype and pressure-test ideas across:
Product / UI generation: v0, Lovable, Bolt, Cursor to name a few — for getting from an idea to something real and clickable in code, fast. Each has a different sweet spot: v0 and Bolt for quick UI exploration, Lovable for polished design-led prototypes, Cursor when generated code needs proper refinement.
Creative and content production: generative tooling for imagery and video - MidJourney, Runway, Descript, ElevenLabs (also dipping into making my own agents) — some of which is live on tem.energy. Powerful, but it needs a discerning eye; this is exactly where taste and the human signal matter most.
The point of working this way isn't speed for its own sake. It's that prototyping in real code, with live data, is the fastest honest answer to "does this actually work?" — which is the question that matters.
The honest gap — and it's a gap inside companies, not just my own practice — is the full pipeline from design straight through to production. The round trip is still broken in most organisations: design files drift from the codebase, there's no shared source of truth, and the handoff leaks judgment at every step. I've been closing that loop myself by building native Mac apps end to end — one of them a live-transcription tool for my deaf friends that turns audio into simplified-English subtitles. Building it taught me something a slide never would: it needs to run on a local LLM, because the round-trip latency and cost of calling a hosted model for continuous parsing simply doesn't work for a real-time experience. That kind of constraint — latency, cost, where the model actually has to live — is a design problem, and you only really learn it by building the whole thing.
To be clear, though: shipping the code isn't where the craft lives. The craft is in deciding what to build and design it right. Code is the mechanism, not the magic — but owning the whole pipeline is how you make sure the judgment survives all the way to what the user actually touches.