UX Engineering · Internship
Aero Design System
Closing the gaps between Figma, code, and documentation at Relativity
Aero was Relativity's internal design system, already mature and well-maintained. My work came from their backlog — maintenance tickets, lower in priority — which gave me room to focus and learn the craft of Figma hygiene from scratch.
01 — Notification Component
The notification matrix was incomplete. I was the one to fix it.
My main responsibility over the summer was the notification component. I was brought in to add specific properties: content type (short/long form or bullet points), title, close button, CTA button, and link button. In working through the additions, I saw that the existing 32 variants didn't cover all possible combinations of those five properties. I expanded the matrix to 128 to close that gap, a decision I made on my own after identifying the omission.
The harder problem was scalability: the component needed buttons to go from inline to stacked depending on width. Figma had just shipped Autolayout Wrapping, which handled exactly this.
02 — Tokens & Documentation
The last mile: tokens and documentation
I also aligned token properties across Figma and the codebase, and linked Aero's web documentation to the relevant components. Neither is glamorous, but both matter for a file someone else has to maintain.
03 — Outcomes
What shipped
- 9 tickets completed across Figma and GitHub
- Notification component: 32 → 128 variants, scalable across all digital contexts
- Toast component: moved from one-off reference to a reusable Figma component
- Token properties aligned across Figma and codebase
- Web documentation linked to corresponding Figma components
04 — Reflection
What I took away
This was my first real exposure to production design system work. The biggest things I took away were craft-level — Figma hygiene habits that are easy to skip when no one's checking: consistent layer naming, autolayout, keeping the canvas organized. Working on a mature system meant good examples were everywhere. It was easier to learn when I could see what "right" looked like.
If I were doing it again, I'd think earlier about which backlog tickets would be highest-leverage for the team, not just most interesting to me. The work I picked gave me a lot to learn from, and I'm glad I went deep on execution, but I'd want to connect my choices to real team needs more deliberately.