From engineer to product designer, on the same product.
Rebuilding the design foundations of an AI contract review SaaS while shifting my role from front-end engineer to product designer + PdM — five years and counting on the same team.
A product with real customers was reaching the limits of its first UI.
Lisse is a LegalTech startup building AI-assisted contract review for legal teams in Japan. By the time I joined, the product had real customers and real complexity, but the UI had grown organically and the Vue codebase was harder to evolve than to add to.
I joined as a front-end engineer, but within a year it was clear the bigger lever sat further upstream — in how the team shaped UI and product decisions. That pulled my role into product design and PdM.
Screen-by-screen fixes would not give the team its speed back.
On the surface the product worked. Underneath, four things kept slowing the team down:
- Vue codebase, no shared component layer. Each feature shipped its own variant of "the same" button, modal, or table.
- Design and code drifted apart. Figma reflected a months-old state; engineers held a different mental model of what a "primary button" was.
- No token system. Colors and spacing were hardcoded, so theme changes touched dozens of files.
- AI surface kept expanding. Each new capability needed a UI pattern, but there was no shared vocabulary for "AI suggestion," "review state," or "confidence."
Rebuild the shared vocabulary and UI stack while the product keeps shipping.
Stopping to "rewrite everything" was never an option. Every step had to leave the product more shippable than before.
Introduced Atomic Design as a shared language
Before any code change, the team needed a common way to talk about UI. I introduced Atomic Design not as a religion but as a vocabulary. Atoms, molecules, organisms gave designers and engineers the same nouns, and the existing UI sorted itself into reusable parts quickly.
Built a Raw → Semantic token layer
A two-layer token system: raw tokens capture brand primitives (hex / px values), and semantic tokens express intent. Components consume only semantic tokens, so dark/light mode, brand tweaks, and accessibility passes happen at one layer.
Anchored the Vue → Next.js migration in the design system
The migration ran in phases that always shipped: new features in Next.js, legacy Vue moved screen by screen behind feature flags. Shared UI primitives lived in internal packages so both stacks consumed the same components during the transition. The design system, not the framework, was the migration's anchor.
Now leading product design, not feature code
As the foundations stabilized, the bottleneck shifted from "how do we build it" to "what do we build, and why." I moved into a product designer + PdM role for new surfaces — owning requirements, Figma design, design system operations, and stewardship through implementation. I rarely write feature code today, but the engineering background still shapes every design decision: at the right granularity for components, states, and tokens, so Figma translates cleanly into shippable code in someone else's hands.
Foundation work became product design work.
- Designers and engineers share a vocabulary. Conversations moved from "this looks off" to specific atoms and tokens.
- Theme and brand changes are a one-layer edit. Dark mode, accent tweaks, and accessibility passes no longer touch every component.
- The surface keeps expanding — including new AI workflows — without proportionally expanding maintenance load.
Make Figma ready to enter implementation conversations.
Since this project, I do not judge design quality by the screen alone. Component granularity, state modeling, token names, and how much ambiguity remains for implementation are part of the design. My engineering background is not just for translating design into code; it helps me design in structures that can become code from the beginning.