Crafting a List item component on Figma
If you are a Product Designer, you know what I mean. List items is one the most complicated component to create for one main reason: its duplicity. It has to be generic to be used in any situation, but it has to be precise to fit all the various use cases encountered by Product Designers.
But first, what is a list item?
This component is quite self-explanatory: A list item is an element of a group composed of similar elements.
List items are primordial to create structure in many part of our product, and can be composed of text, title, icons, avatars, tags or interactive components (like checkboxes), basically… all the atomic elements that you can encountered while browsing on any Design System.
List items in Doctolib products
At Doctolib, we’re obviously needing lots of list items, each of them with different specifications. Just to mention some major ones, it could be:
- a list of documents (with recipients, dates, sharing settings, patient name…)
- a list of conversations (with timestamp, notification badge…)
- a list of appointments (with practitioner name, date, visit motives, date…)
- a list of patients or contacts (avatar, name, birthdate, phone number…)
To answer to this need we created this component as first iteration, to try to cover all the needs.
On the tech side, we’re also dealing with lot a legacy components or custom code, as our Design System is really recent regarding the age of our product. Thus, you can find on our codebase:
- Components with similar usage but visually totally different
- Components similar to the one in the Design System, but created before the Design System and never migrated
- Components from the Design System that has been tweaked to fit a specific need.
Our Figma component
One step back: first list item iteration
Usually, when we’re crafting a new component we’re tending to create the maximum variants to address all use cases. That’s exactly what we did with the first iteration of this list item component (above screenshot). Few months later, and thanks to the help of Figma analytics we discovered the usage of these variants. 👇
As you can see on the scheme above, results are indisputable:
- More than 50% of the variants are not used at all. 😱
- On the other hand, 5 variants are representing 85% of List items instances (less than 6%)
- 1 only variant is responsible for half the insertions of List items in our files.
It’s legit to ask ourselves if there is a real interest of creating these kind of all-encompassing components covering all use cases, even those that may never happen... It brings more complexity to the component, needs more time to be developed, add extra-work in terms of maintenance, and also add more risks of having dissimilarities between Figma and the developed component.
The approach
As we had few improvements requested by the Product Designers to this List items component, we totally rethink the way we craft it. And for good reason, among these improvements we add to offer the possibility to remove left and right padding, and to set a vertical alignment. This means our numbers of variants would have jumped from 76 to more than 300…
On the other hand, we all agree to say “less is more”, but we can’t stick to the top 5 inserted variants. So, we chose to offer the same range of options but creating a more smart and easy to maintain component, simply just applying the atomic logic.
Our new component is based on 5 inner blocks, with only one mandatory (content). All the other inner blocks can be deactivated through the properties. It terms of structure, List item component has three “layers”, each one having dedicated properties:
- Master Component, on which the Designer can act on the vertical alignment, and adding or not left/right padding, and selecting the state -default, hover and active are the same (8 variants)
- The “5 Inner blocks” block (Select / Visual / Content / Rich Text / Action). Designer can activate/deactivated one by one these blocks with boolean properties (14 variants)
- Standalone Inner block, that are individually having their own properties.
Overall view of the component
Just under are all the nested components useful to create our Master component. We’re using the underscore sign ( _ ) to exclude the nested components of our shared library. Thus when a designer is importing the List Item component, only one is appearing (less is finally more 😉).
It has been necessary to created two _select components to ensure a good alignment of checkbox/radio with the content, depending on the vertical alignment of the List Item master component.
Designer’s Benefits
Creating the List Item this way allow us to offer a lot of variations:
- facilitating the workflow of the designer. Only one List item can be found in the library, and then the Designer just have to select first level properties (padding + vertical alignment + state), then the required inner blocks
- without having to update tens of variants each time an improvement is required
- without overloading our library
Conclusion
As Figma true believers, we are always trying to push the limits of Figma and using the maximum the features such as Auto-Layout and constraints, and trying to create powerful components. But the real challenge of creating such a component is to find the right balance between creating massive components with many variants, keeping it to easy to maintain and update, thinking to the ease for designers to use it, and without forgetting to keep in mind the way it will be developed.
One last point I really want to highlight, if you’re lucky enough to be on Organisation Plan with Figma, deep dive in the Figma Analytics, you’ll learn lot of things about the usage of the components, and it really helps refining and adapting your components you’ll offer to your users.
