Three tools, one sunset, and a bet on Figma.
Design operations is the part of the job nobody puts on a poster: the tools, the intake, the process. It's also where a design team's ceiling gets set. When one of our three core tools was acquired and sunset, our stack — Sketch for design, InVision for prototyping, Trunk for version control — stopped being merely awkward and became untenable.
I'd been watching Figma for two years, waiting for it to be robust enough to win me over — and by then its feature pace had changed. Rather than jump on instinct, the other product designer and I ran a fair evaluation: InVision's roadmap (Studio, DSM, versioning promises) against Figma's shipping reality, including field reports from teams who had already migrated their design systems. The InVision column kept filling with 'planned'; the Figma column with 'works today'.
I evangelized the switch, and made the case in the language the business cares about: workflow — designers, PMs, and engineers finally in one live source of truth — and cost, because one Figma seat undercut the multi-tier stack it replaced. The migration paid for itself in both currencies.
Tool decisions are organizational decisions. The deliverable isn't the license — it's the workflow everyone stops fighting.
Feedback is only valuable if you can find the pattern.
Our idea tracker had become a dumping ground: pasted chat logs, title-only entries, categories chosen at random. The cost wasn't messiness — it was that patterns became invisible, and patterns are the entire point of collecting feedback. I redesigned the intake around a simple principle: the tracker is a succinct log for spotting signals; the deep research happens beyond it.
- A structured intake form asking what task the user was trying to accomplish, what wasn't working, and what workarounds they'd invented — questions about jobs, not solutions.
- Categories over tags — a deliberately short, product-aligned taxonomy, because a tag list grows until it means nothing.
- Only two top-level product categories exposed to submitters; classifying deeper is the product team's job, not the customer's.
- Integration questions settled up front — how Salesforce and Zendesk sync with the intake — so the process survived contact with the org's real systems.
- A demo day to the whole company: why the change, what's in it for each team, and an honest note on what closing-the-loop work still remained.
Codifying how problems get defined.
The most durable operations work was writing down how we think. I codified problem-definition guides for the team: Jobs-to-be-Done — 'I want a document library' is a feature; 'I need a way to share slide decks with attendees' is a problem, and job stories keep the difference honest. The 5 Whys — asking why of a feature request until the root motivation surfaces. And a standing rule about assumptions: know when your design is being informed by evidence, and when it's merely being informed by confidence.