Part 1: Figmality = Figma + Fatality 💀
There was a funny case, one of the dev team members accidentally said “Figmality” at grooming, trying to describe another round of changes we needed to face and deliver. For a long time it meant only one thing: a mix of Figma and Fatality. In short: new designer –> new layouts –> frontend is dead.
Over 2 years of full‑stack development on the project:
- 3 designers
- 3 redesigns
- 7 shades of blue color
- 5 versions of the same button.
UI components seemed to have the following shape:
CSS turned into a layered Napoleon cake with lots of legacy layers:
Each frontend redesign:
- did not improve but replaced,
- did not explain but erased,
- added more code.
The issue was not the designers, they did a great job, each of them tried their best and we were thankful to all the efforts. The problem was about the approach. The root cause was that the interface had no rules.
Part 2: How Figmality Stopped Being a Fatality 😉
Figmality = Figma + Reality
We didn't hire the "perfect" designer.
Instead, we redefined Figmality: collaborated with our designer to identify key components, built each one using our existing UI kit strictly, and created stories for every state. Btw, you can assemble components in different ways, e.g. starting big and breaking them down, or vice versa. It's up to you to decide what fits best.
Now it's truly:
Figma + Reality
Figma is no longer just a picture.
Paired with Storybook, it forms the "contract" between the dev team and designers.
One button.
All states.
One implementation.
No more dozens of custom values - instead, fixed rules in Storybook:
Components are now redesign-proof:
Design changes → Rules update.
Code (business logic, behavior) stays untouched.
Results:
- 0 frontend rewrites
- 1 design system
- New dev onboarding takes 2 days
- Redesigns are no longer resets
- Redesigns = contract updates. Otherwise, they just brutally kill the time!
