FLEXIBLE COMPONENTS
a design systems project for Angi (2023-2024)
Understanding the problem
A modal is a modal is a modal
For much of my time at Angi, our design system contained a fixed set of modals as a response to designers having to create bespoke ones for every feature. For a while, designers appreciated the ability to drag and drop simple modals, but the limited styling options caused a lot of exceptions to be made, which created a lot of extra work.
Additionally, while inspecting the design system for the first time, one colleague remarked “a modal is a modal is a modal, right? Why do we have so many different modals?” Upon hearing this, it occurred to me that decision fatigue might be as much of a problem for these components as inflexibility.
Modals weren’t the only component with this problem, either — Lists, Cards, and Hero Sections also fell victim to style limitations, no matter how adjustable they may have been.
Original selection of modals in our design system
Testing the waters
Designers prefer to compose, not assemble
In order to get to the root of the problem and find a solution, I ran usability tests on five other designers. In this test, participants would be asked to recreate an example modal/card in three different ways: once using our existing system, once using a “template” modal whose contents were controlled by props and variants, and once using free slots that designers could drag other components into (as seen in Nathan Curtis’ recent talk on Subcomponents). During each test, I’d be measuring completion + time to task as well ask asking for subjective input.
When attempting use our existing system, participants’ first instinct was to quickly grab something in the ballpark of the example, then immediately break it and mold it into the final product. The reason given for this each time was “I know I need to use the design system, but I work best when I can quickly get ideas straight from my brain onto paper instead of searching for options.”
Because it’s so visuals-forward and compositional, all test participants preferred and performed better using the drag-and-drop method as compared to the variants + props method. None preferred the existing library’s offerings.
Collaborating with engineers
Design components as API contracts
Given the results of my tests, it was decided that making Modals and Hero Images flexible using content slots was a worthy ergonomic improvement in advance of a slew of impactful feature work. However, I realized quickly that attempting to capture every single state as one would with a more traditional component spec was a fool’s errand.
Instead (based on a suggestion from a colleague), I determined that it made more sense to write specs for every container + element in a component individually in the style of an API data contract. In this case, this also includes what data is allowed in each container, what properties apply to each, and any potential logic that might apply. This method of sharing specs not only provides richer information, but also allows for designers and engineers to work simultaneously and create parity in their final products.
These data contracts were communicated using rough pseudocode, presented visually in a way that can be parsed more easily than a normal JSON API contract. Once our data contracts were finalized, design created the unstyled “HTML” of the component in line with the data contract, which was then used as a canvas for style variants; while this is a fairly standard way to build components using Figma’s Auto Layout, working procedurally in this way ensures that design builds as closely as possible to engineering.
How it turned out
Components as fast as our designers
Flexible Modals and Lists were both designed in a focused two-week period, and are currently in development. These components will be used going forward, not as something to retrofit older features with.
Though they weren’t formally part of the test, both the concept of flexible components and using data contracts as specs were a hit with engineers when consulted on their use. We’ll be using them going forward when building complex components, or anything with subcomponents or variable data.
Finally, as part of assembling the visual layer, I consulted with feature teams related to both components to ensure they included enough variability to meet their needs, and stress tested the new Modals by attempting to recreate some of the more elaborate ones we’ve used in the past, such as signup forms and checkout flows.
