Amica.com Design System
Component structure, responsive decisions, and design handoff for a rebuild across AEM and React.
- Client
- Amica
- Role
- Associate Design Director
- Agency
- Razorfish
- Year
- 2026
- Scope
-
- Design-team direction and review
- Component architecture across AEM and React
- Responsive refinement and handoff
The problem
Amica.com’s rebuild brought a new brand direction into interfaces across AEM and React. The team already had brand foundations and a component library, but needed clearer rules for what belonged in a component, how larger sections reused it, and which files development should follow.
The decision
I organized the system around Foundations, Components, and Sections, used properties to contain variations within component families, and separated work in progress from the material we shared for implementation.
My contribution
I joined mid-project as design lead. I shaped the system structure and component decisions, delegated refinement and documentation, set review priorities, and guided responsive fixes. Collaborating designers developed and documented components; I directed that work and reviewed it across the system.
Connect foundations, components, and page sections
I developed the system’s structure while the team continued designing pages. Amica’s brand foundations and an existing component library gave us a starting point. I challenged categories such as Utility and Media & Content because they blurred the distinction between an individual component and a larger page section. I organized the library around Foundations, Components, and Sections, with templates showing how those parts came together.
I refined that structure through the page work. In the Topic Hub, I updated the header components and separated them into a stack so the team could update each part more easily. When a treatment appeared across templates, I asked the team to make the change in the shared component. That kept page-level decisions connected to the library we were developing.
Extending the system into React also meant mapping colors by purpose. A green used for a link needed an action token, even when a success color looked closer. We documented the source color, its shared value, and its intended role together so the mapping explained the decision as well as the appearance.
Define the states, not just the default
Within a component family, I kept the name simple and used properties for type, size, state, layout, and media. The quote-flow audit showed why this mattered: products reused many of the same forms, but the AEM and React libraries differed in focus, processing, validation, and responsive states. Matching the default appearance covered only part of the work.
I also moved repeated decisions into shared rules. Buttons and links had different hand-entered values for disabled opacity. I tied them to the Core UI Kit’s disabled token so they inherited the same rule. Future changes could then start at that shared value.
Keep the handoff tied to the component
I separated published libraries, reference documentation, internal working files, and client-facing material. Finished work moved into the client share. When developers started building from that file, they could also see the team’s internal notes, so I pushed for a separate dev handoff file as the source of truth. The dev team had access the next day.
I organized the work into component refinement, migration and connection, documentation, and review. Collaborating designers owned focused parts of that work; I set priorities, assigned component builds, and had three designers audit my library branch before we published it.
Copied specifications could name a valid token that the component did not use. We generated specifications from the actual bindings, then checked the assembled page examples for clipped labels, missing content, and responsive behavior. The library, documentation, and pages all needed to agree. The site launched on October 2, 2026.
Name the tokens each component uses
The documentation lists each state’s size, padding, gap, radius, fill, and label tokens, so development reads the same values the component carries.
Check shared components in a complete section
The Product Bundle Hero combines selection cards, ZIP entry, and a quote action. These desktop and mobile examples show composition and responsive arrangement.
Trade field width to fit the full product name
In the product-dropdown exploration, the Wedding & Event label clipped. I presented the existing layout as Option A, a wider-field layout with the action underneath as Option B, and a wider dropdown with a narrower ZIP field and inline action as Option C. Amica selected C. I traded space between the inputs so the full product name could fit while the quote action stayed beside them.
The team confirmed that the arrangement should hold through 1024px. That kept the solution within the agreed responsive behavior instead of adding a breakpoint for this layout. The selected option shipped.
I led this refinement within the agency’s visual-reskin scope. Amica’s in-house team owned the broader Quote Start redesign.
Lessons from component reuse and handoff
On the next project, I would agree on the component structure, shared rules, and development reference at kickoff. I would also bring representative pages into review earlier, with realistic content, narrow layouts, and interaction states. Those examples expose what an isolated component can miss. Amica taught me to treat reuse and handoff as ongoing design work, with every shared change checked where the team actually uses it.