Role: Lead Product Designer, Upland Software · Duration: May 2026, ongoing · Focus: AI-assisted design tooling, verification standards, cross-environment enablement
The Challenge
By early 2026, AI tools had become a normal part of the design process at Upland: generating prototypes, drafting specs, exploring directions. But normal use isn’t the same as trustworthy use. AI output looks confident and finished whether or not it’s actually correct, and a design workflow built around it needed real safeguards, not just enthusiasm.
The question I set out to answer wasn’t “how do we use AI more.” It was “how do we use it without quietly shipping its mistakes.”
Building the System
I formalised a task-routing model rather than a blanket policy: Claude for the substantive design work across all five phases of the process, a lighter desktop agent for execution tasks, Microsoft Copilot for simple rewrites and meeting notes. Different tools for different jobs, not one tool for everything.
On top of that, I built six custom Claude Code skills covering design discovery, prototyping, dev-handoff specs, and QA review, along with five Figma-side skills for applying the design system consistently. And I built in a rule that mattered as much as any of the tooling: a mandatory three-concept ideation gate, requiring at least three distinct directions before any evaluation step, specifically to stop the AI (and the process) from anchoring on the first idea it produced.
Three Failures That Shaped the Guardrails
The most useful part of this system wasn’t the tooling itself. It was what I built in response to real failures.
A bug that passed every check because none of the checks actually ran the code. A broken drag-and-drop interaction shipped straight through a Babel transpile check, a brace-balance check, and a token cross-check, all green, while the feature itself didn’t work. None of those checks executed the rendered output; they only checked that it looked structurally sound. I introduced jsdom-based interaction testing as a standing step from that point on: verify the behaviour, not just the syntax.
The same wrong answer, confidently repeated in three different places. A Button font-weight error had been independently baked into the design files, the design tokens, and the shipped CSS, three separate AI-assisted outputs, all agreeing with each other, all wrong. Nothing had forced a check against a real source of truth, so the error just kept propagating. I wrote “Figma is the only source of truth” into standing practice as a direct result, and used the same audit method to check RightAnswers for the identical defect, which it also had.
A junior designer who didn’t have the same tools I did. One of my reports works entirely in Claude Desktop, without filesystem or MCP access, so none of my Claude Code skills would simply transfer over. Rather than leave him under-equipped or hand him a diminished version quietly, I built a full translation of the system into his environment: project instructions, a working prompt cheat sheet, a verification-first kickoff prompt, and an explicit, honest list of exactly what didn’t survive the translation (automatic skill-routing, live file edits, persistent logs). Being upfront about the gaps mattered more than pretending the two setups were equivalent.
What This Isn’t (Yet)
I want to be precise about the actual evidence here rather than overstate it. This system is well-built and genuinely used across my own work. What I can’t yet claim is that it’s been adopted as a standard beyond my immediate team, there’s no record of anyone outside my own reports picking it up independently, and I don’t have a hard, measured time-saved number to point to. What I do have is a documented pattern of catching real AI failure modes and closing them systematically, which is arguably the more useful signal: not “AI made us faster,” but “we built the checks that keep AI honest.”
Outcome
The workflow now includes a working skill library, a mandatory ideation gate, a verified-not-just-trusted testing standard, and a fully translated version for a team member in a different tool environment, each one built in direct response to a real failure rather than assembled speculatively in advance.
Some specifics in this case study are generalised in line with the confidentiality of Upland Software’s internal tooling and process documentation.
