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, 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 (a la 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.”
For this very reason, the drag-and-drop method was unanimously preferred and won out by a landslide. None preferred the existing library’s offerings.
Collaborating with engineers
Design components as API contracts
Drag-and-drop flexible modals introduced a whole new paradigm of components that was brand new to Angi; collections of containers instead of tweakable but fully-formed. In order to make this type of component break out of Figma into code, I had to make handoff specs that account for the amount of flexibility that these new modals demand.
Thus (based on a suggestion from a colleague), I included component data contracts in my otherwise-standard specs that lay out each container’s logic, restrictions, behaviors, and data sources. In addition to that specificity, these data contracts also help keep architecture and naming aligned between design and code, and improve efficiency by letting design and engineering work simultaneously instead of waiting for final UI to hand off.
Data contracts at Angi are expressed using rough pseudocode, broken out in a way that can be parsed more easily than a normal JSON API contract. Engineers seemed to appreciate the added specificity.
How it turned out
Components as fast as our designers
Flexible Modals were designed and documented in a focused two-week period, and committed to code across web, iOS, and Android shortly afterwards, then launched everywhere simultaneously. The old set of modals have been archived to push adoption along.
Before any code was written, I used the new Modal to recreate some more complex custom Modals that already existed in our products and reviewed my results with other designers to quadruple-check that they address proven needs.
Upon launch, designers immediately started not only using the modals, but pushing them to the end of their capabilities; lots of positive feedback came through in live design reviews. Since this project wrapped up, more components with flexible containers have been devised, which signals to me that the philosophy our modals are based around is truly useful to Angi.
