Exploring Inconsistencies To Provide Component Guidelines
TIMELINE
May - June 2026
ROLE
Product Designer Intern
STATUS
Handed Off
TEAM
3 Product Designer Interns
2 Senior Product Designers
TOOLS
Figma
Figma Make
Box
Slack
Copilot
TIMELINE
May - June 2026
STATUS
Handed Off
TOOLS
Figma
Figma Make
Box
Slack
Copilot
ROLE
Product Designer Intern
TEAM
3 Product Designer Interns
2 Senior Product Designers
OVERVIEW
As Apptio moved onto IBM's Carbon, the two systems drifted apart across the product. I found where, and wrote the guidance to close it.
CONTEXT
Two teams, two answers, same component.
Designers and developers were both guessing which pattern was correct, and picking differently. Users felt it as a product that didn't quite hang together.
Specs get ignored because the details get lost.
Documentation that runs long loses people before the part that matters lands. Whatever we wrote had to survive being skimmed.
PROBLEM
How might we help designers and developers agree on which pattern is right, without either of them guessing?
SOLUTIONS
Specs built for developers and designers to actually use, not just admire.
Documenting and auditing
Every inconsistency, cross-referenced against Carbon, in a shared sheet developers could file Jira tickets straight from.
Writing and designing specifications
Spacing, usage, variants, and edge cases per component, so behavior is never a question.
Concept: Internal Tool to make reading specs more fun, interactive, and engaging
I noticed most specs weren't being followed, not because people didn't care, but because the small details got lost. Long, dense documentation made it easy to lose focus before the important parts landed. To fix that, I experimented with an internal tool to help people actually adopt these practices, not just read about them.
OUTCOME
40+ screens audited, 600+ inconsistencies logged, designed/documented 2+ new components. Developer handoff ready.
Handed off to the Cloudability engineering team in 2026. The migration is on their roadmap rather than in active development, so the work is queued, not shipped.
Because of that gap, I wrote the handoff to survive a delay: every component came with written descriptions and documented edge cases, so whoever picks it up months from now can implement it without me in the room.
AI could help spot the problem, but not fully solve it.
Reading and judging drift across dozens of screens still needed a person, which is what pushed me toward building internal tooling to speed that up. That one's still in progress.
Check out my other works!
Exploring Inconsistencies To Provide Component Guidelines
TIMELINE
May - June 2026
ROLE
Product Designer Intern
STATUS
Handed Off
TEAM
3 Product Designer Interns
2 Senior Product Designers
TOOLS
Figma
Figma Make
Box
Slack
Copilot
TIMELINE
May - June 2026
STATUS
Handed Off
TOOLS
Figma
Figma Make
Box
Slack
Copilot
ROLE
Product Designer Intern
TEAM
3 Product Designer Interns
2 Senior Product Designers
OVERVIEW
As Apptio moved onto IBM's Carbon, the two systems drifted apart across the product. I found where, and wrote the guidance to close it.
CONTEXT
Two teams, two answers, same component.
Designers and developers were both guessing which pattern was correct, and picking differently. Users felt it as a product that didn't quite hang together.
Specs get ignored because the details get lost.
Documentation that runs long loses people before the part that matters lands. Whatever we wrote had to survive being skimmed.
PROBLEM
How might we help designers and developers agree on which pattern is right, without either of them guessing?
SOLUTIONS
Specs built for developers and designers to actually use, not just admire.
Documenting and auditing
Every inconsistency, cross-referenced against Carbon, in a shared sheet developers could file Jira tickets straight from.
Writing and designing specifications
Spacing, usage, variants, and edge cases per component, so behavior is never a question.
Concept: Internal Tool to make reading specs more fun, interactive, and engaging
I noticed most specs weren't being followed, not because people didn't care, but because the small details got lost. Long, dense documentation made it easy to lose focus before the important parts landed. To fix that, I experimented with an internal tool to help people actually adopt these practices, not just read about them.
OUTCOME
40+ screens audited, 600+ inconsistencies logged, designed/documented 2+ new components. Developer handoff ready.
Handed off to the Cloudability engineering team in 2026. The migration is on their roadmap rather than in active development, so the work is queued, not shipped.
Because of that gap, I wrote the handoff to survive a delay: every component came with written descriptions and documented edge cases, so whoever picks it up months from now can implement it without me in the room.
AI could help spot the problem, but not fully solve it.
Reading and judging drift across dozens of screens still needed a person, which is what pushed me toward building internal tooling to speed that up. That one's still in progress.
Check out my other works!
Doodled with love @ Jerry Chen 2026