AI in the design pipeline
The frame I use: I think about AI's contribution to design in three layers, research synthesis, early-stage exploration, and final visual / interaction decisions. Each layer asks a different question, the maturity of the tooling is different, and the right operating posture is different.
Treating "AI for design" as one thing is the first move that gets you stuck.
Research synthesis: large productivity gain, used carefully. Synthesizing transcripts, clustering qualitative responses, surfacing patterns across studies, this is where I see the biggest practical lift today and the lowest implementation risk. The trade-off is calibration: a model that's "mostly right" about a user's pain point is the most dangerous output the design organization can act on, because the synthesis looks confident and the underlying error is invisible. The mitigation is structural: pair AI synthesis with human verification on the next step in the chain (typically the researcher who collected the data), and never act on a single-model synthesis as ground truth. At Oodrive this is the layer I'm piloting first (lowest risk, highest gain), and the pattern I'm building is: AI synthesis is a draft, human review is the lock.
Early-stage exploration: genuinely useful. For ideation, comparative variant generation, "show me twelve versions of this concept", AI is now a meaningful productivity multiplier for a designer who already has a clear point of view about the problem. The risk here isn't quality of output, it's substitution: a junior designer using AI to skip the part where they form their own opinion about the problem will produce polished work without the underlying judgment. So the operating rule for my teams is: AI in exploration after the designer has written down their own framing of the problem, not before. The output is better, and the discipline-building is preserved.
Final visual and interaction decisions: still human, for at least the next 18 months. Here I hold the line. The output of design is not just the artifact; it's the accumulated set of judgments encoded in that artifact, and those judgments are what design organizations get paid to make. Letting AI make final-pass visual and interaction decisions removes the moment where the designer's accumulated taste actually intervenes. There are interesting tools in this layer: I treat them as collaborators for the first 60% of a screen and human intervention for the last 40%, not the reverse.
What would change my mind on the final-decisions claim: a generation of tools where the underlying design judgments are inspectable and editable as primitives, not just regenerable as prompts. I'm watching for that. When it arrives, the 18-month window collapses.
What I'm watching now: granular tools for design-system maintenance (token-drift detection, component-usage analytics with automated suggestions); evaluation frameworks for design-AI outputs that go beyond "looks right"; and the regulatory layer in Europe specifically, where the AI Act starts to define what's allowed in product surfaces touching sensitive data, directly relevant at Oodrive.
Why I track this carefully. I got the IBM Artificial Intelligence Fundamentals certification in late 2024 specifically to make sure I'm building my mental model on something other than vibes. At Director+ level, design leaders who are confidently wrong about AI in their pipeline are about to make decisions that hurt their organizations for years. I'd rather be a year slow and right than a quarter early and wrong.
Design measurement at the business table
If your design team isn't measuring, it isn't credible at the business table.
I said this in How I Lead and I'll repeat it here because most design organizations still treat measurement as something the analytics team owns. It isn't.
The framework I run: SUS and CES first (mature, cheap, easy to operationalize), then dashboards segmented by surface and persona, then a north-star metric for the design organization itself: usually something like "share of releases that meet the design quality bar at first ship." Three layers, each answering a different question. SUS and CES answer "are we trending in the right direction on the surfaces we own." Dashboards answer "where specifically." The north-star answers "are we operating as a discipline at the level we claim."
A few things I won't do:
- Conflate satisfaction with success. They correlate, they don't equate. A team that ships nothing has high satisfaction.
- Optimize for a metric the team that owns the surface can game. Most design teams own the metric they're optimizing on. This is a problem nobody talks about loudly enough.
- Run quantitative without qualitative pairing. A number without a story is a target, not a measurement.
What I'm doing at Oodrive right now is exactly this: the year-one foundational work I describe on the home page. SUS and CES deploying first; dashboards next; the north-star metric for the design organization in flight. I expect to know within twelve months whether the design organization is operating at the level the suite needs.
The harder question I'm sitting with: how do you measure design quality at the suite level, when the suite is composed of multiple products with different vintages and different maturity curves? The instinctive answer (measure each product, aggregate) loses the suite-coherence dimension entirely. I don't have a clean answer to this yet. If you do, I want to hear it.
Accessibility as discipline-level commitment, not shared responsibility
Anything that's everyone's responsibility is nobody's.
The phrase that's misled more design organizations than any other in the last decade is "accessibility is everyone's responsibility." It sounds correct. It's wrong in practice. The organizations that took that frame seriously discovered they had accessibility on no roadmap, on no calibration rubric, and on no hiring loop.
The shift I made at GoTo and would make again anywhere: stand up a dedicated Accessibility Lead role at the discipline level, not a working group, not a champion network, a real seat with a roadmap, a budget, and calibration responsibility for the rest of the team. That role is the unlock. Once it exists, accessibility moves from "we should think about this" to "this is the bar we hold each other to," and the rest of the design organization absorbs the standard within two quarters.
The argument I'd make to anyone considering it: a dedicated Accessibility Lead is the cheapest org-design move that compounds. The cost is one headcount you might have spent elsewhere. The compound return is a design organization that ships accessible work as the default, not as a special-case workstream when legal flags something. At Director+ level this is exactly the kind of trade-off you should be opinionated about, because it's a decision with multi-year consequences and most design organizations make it badly.
What I'm watching: the maturity curve of automated accessibility tooling. The current generation catches obvious violations and misses the interesting ones: modal focus traps, dynamic content updates, multi-step flows. The next generation should change the cost structure of catching these, but until it does, the human-and-role-based approach holds.
Where I'm still chewing
Three topics I'm thinking about but don't have publishable POVs on yet:
- Design ops across very different company stages. I've now restanded rituals at three very different sizes (GoTo at 14, the transition period at zero, Oodrive at smaller-than-GoTo) and the lessons aren't generalizable yet. When they are, I'll write about it.
- The design-engineering bridge. The UX Engineer hire at GoTo taught me what works at one stage. What I don't yet know is what the right ratio of UX Engineers to product designers should be at different company sizes, or how the role's scope should evolve as the design system matures.
- Calibration as a craft. There's a strong version of this I could write, but I'd rather practice it through a second cycle at Oodrive before I commit to a public stance.
If any of these are the conversation you'd like to have, reach out. I'd rather think out loud with someone who's working on the same problem than publish prematurely.