During the Summer of 2021, I launched an internal research initiative and designed two “Directories” to streamline component search within Robinhood’s design system, Bento.
In June 2021, I joined Robinhood as a design intern on both the Growth team and Design Systems (hereby referred to as “Bento”) team.
For various reasons, it was quickly determined that my planned project for the Bento team wasn’t going to drive much impact, so I poked around for problems to design for.
For onboarding, the Bento team had interns create a handful of core screens using Bento components. This was my first introduction to using Bento.
After completion, I learned that I had accidentally recreated a couple of components, thus creating broken component instances.
Reflecting on why I had never found the correct components, I was able to pin-point a potential reason.
Navigating around the Bento files during the exercise, I often times felt lost, and it was tough to determine if some components existed or not.
Both our Bento Mobile and Bento Web files are comprised of 12 pages that each hold a subset of that file's components.
Check out our Bento Mobile file in Figma to try it out!
Many of our pages has more than 5 components, and comprehensive documentation guidelines sits next to each component. While navigating within some pages, it's easy to get lost.
I hypothesized that I wasn't the only one struggling to navigate our Bento libraries and wondered if there was evidence to support this.
After talking to all 3 Bento Designers, I found that, indeed, it was quite common for designers to create broken components in their designs.
– Bento lead designer
These issues impact new hires who are just getting started with Bento disproportionately.
Due to the Bento team's finite bandwidth to review designs, it's very possible file to make it into production with broken components that were never resolved.
Having validated the problem, I was ready to dive into the workflows of designers using Bento to answer: why are components getting lost?
Conducting qualitative research, synthesizing findings, ideating solutions.
After creating interview guides, I met with 7 designers to understand how they wayfind through Bento and find components and documentation.
Several patterns emerged from my qualitative research.
There are around 3 steps in the search flow that make up a disjointed and inefficient process.
In some cases, designers may, from their own working file, search for a component on the Assets Panel. However, the often-cluttered experience of search might not be enough to gauge component existence.
The most commonly used step, a designer will then hunt through the Bento pages, scrolling around each page to see if they can find the component.
– Interviewee #4
While designers are hunting, it's sometimes hard to know if a component exists or not. This issue is most prominent within larger pages like the Rows page. More documentation, or 'fluff', to sift through = more difficulty hunting.
Asking teammates (including those on the Bento team) about components is a last resort for some.
Research showed that designers rarely follow all 3 steps in the search flow thoroughly. As a result, it's common for designers to prematurely assume a component doesn't exist, and decide to create their own broken component instead.
We realize that suboptimal search creates another issue: workflow inefficiences for both the designers struggling to find components, as well as the overhead placed on teammates responding to teammates inquiring about component existence/location.
For each component, usage documentation answers FAQ's about that component (i.e., placement, edge cases) and details engineering-specific specs like spacing and resizing.
While our usage documentation is helpful when FAQ’s arise, designers don’t rely on usage documentation a lot because they serve as edge-cases in their work-flow. Most designers mentioned that they rarely referenced usage content.
At this point, I was equipped with a robust understanding of the user painpoints from which to design for.
I aligned on a concrete goal around which to design:
I harnessed my qualitative findings to brainstorm with teammates.
What if we extracted the usage documentation into a separate page altogether?
As I learned, usage documentation serves only as a tertiary use-case and thus impedes the component-search process.
This could be a compelling replacement for the "Searching in Assets Panel" step in the search workflow.
This would be most compelling for larger pages.
I decided to move on from this concept because it would only increase documentation in already documentation-dense pages and thus add to hunting difficulty.
Defining user needs, iterating design concepts, deciding on concept.
At this point, I wanted to understand the user goals of what I was designing to frame my designs and maintain a user-centric focus throughout.
As a designer looking for components in Bento, I need to be able to...
quickly understand if a component exists or not.
easily find components that exist.
Compelled by the idea of reducing documentation to sift through, I iterated through a couple of prototypes exploring the "Extracting usage documentation" concept further.
I iterated through 2 versions of the Extracting Usage concept, bringing my designs back to the team frequently for feedback.
Harnessing Figma's linking feature to navigate from component pages to their usage documentation page.
Enlarging main components for better recognition / visual hierarchy.
I explored removing the variants altogether to reduce 'fluff' (designers had mentioned feeling overwhelmed searching through variants for complex components).
The reduced documentation and the focus on the visuals creates a much more streamlined navigation experience within the component page.
We want to promote the "Go to Main Component" interaction throughout our files, so this gets broken once we hide the variants.
By extracting the usage documentation behind another click, we reduce its discoverability and the ability for designers to get their usage questions answered. My Bento teammates were most cautious of this approach.
Another worry never explicitly mentioned – pushing the changes proposed in these designs would necessitate refactoring every single component page in our Bento files. Is the juice worth the squeeze?
Simultaneously, I was prototyping a main catalog page, the one-stop-shop to view all of the Bento components.
Viewers can view all of the main components for Bento (Mobile) in one page.
From each component, the user can click the text link and navigate to the main documentation for that component.
This solution offers a unique opportunity to get an overview of our Bento library – great for new designers.
The visuals of a component are highly emphasized which speeds up component recognition – this catalog is a visual tool.
The visual focus is great for comprehension, but need to zoom out and in repeatedly to get a gauge of the components.
The team was confident that the catalog was a great solution for our component search issues.
If designed well, we can say goodbye to hunting aimlessly in Figma files!
Also – it was net new, and wouldn’t require any overlapping overhead with the Bento team’s Figma files.
There were several open questions, including what layout and visual style works best, what other content to show in the catalog etc.
Defining design principles, launching user tests, finalizing the visuals.
Before iterating the catalog, I wanted to align with a set of design principles to guide my iterations.
I’d learned in the “extracting usage documentation” designs that keeping P0 goals like reducing overhead and maximizing simplicity top of mind can save time in the iteration process.
I brought a variety of hypothetical scenarios, layout variations, UI variations, and questions to 5 designers to test my open questions.
I'd learned that users had to repeatedly zoom out and in to read the category titles and then see the components. I reduced my font sizes and tightened the component clipboards to flatten the visual hierarchy.
Using our internal DS component to align with our Bento visual style, I overrode stroke and fill colors to reduce the button's visual weight and avoid visual competition with the components.
I presented 5 potential variations of the catalog layout with designers to see what felt easiest to skim through.
When searching the catalog for a component, all designers followed the same discretized sequence:
Eye skims through categories to find a relevant category where the component might exist.
Upon happening upon a possible category, gaze then moves across components within that category for a match.
The vertical layout supported this flow the best – it allowed smooth scanning in one-line through the categories. Then, by placing the components adjacent to themselves in a row, it allowed for super quick comparison of the components in a category.
I presented several variations prototyping other content that might be helpful for designers to see adjacent to the components.
Throughout testing, designers expressed that they see the Catalog as a directory of Bento's components, a *simple overview* ("what is in Bento?"), whereas the main Bento documentation is for *in-depth learning and analysis* ("what should I use and how?").
This mental model later inspired us, just before merging, to change the name from "Catalog" to "Directory". We wanted to enforce the mental model that this was only an overview of what Bento has to offer, and in doing so emphasize the importance of using Bento's main documentation.
In harmony with the interviewees’ mental model, the simplest version was the most compelling! It created the clearest separation between overview and documentation.
– Interviewee #4
Another pro aligning with my design principles – low overhead!
I shared a series of copy choices for the button that sends to main documentation.
Most designers agreed that "Documentation" matched their mental models most accurately.
However, some designers, worried that, especially for web components, this might send them to documentation that lives outside of Figma.
I decided to incorporate Figma's icon to alleviate these worries.
Designers appeared, in accordance with their associating the catalog as a visual tool, to skim through the visuals of each component as opposed to their titles.
– Interviewee #2
At this point, I was confident in the layout, copy, and structure of my components. I know I wanted to tune the visuals to maximize scanning for our components.
I shared some protoypes exploring different visual treatments in an effort to emphasize the visuals of the components themselves.
What did the team have to say?
Category titles and the components within that category should all live in the same container, or artboard. Otherwise, we lose an accurate visual metaphor and slow comprehension.
While the dark mode directions certainly bring the components to the forefront, placing our light mode components on a dark mode surface creates dissonance. We want to display the components accurately, as they would look on in-app.
We decided that "Light / Titles on artboards" was the best direction.
Now that I knew the larger visual direction for the category artboards, the iteration process moved naturally too the only remaining open question for visual prominence – what is the background fill?
In the Catalog, components are represented within "clipboards".
Keeping the clipboards consistent allows for optimized visual scanning in a straight line.
The dashed lines afford copying the component directly from the artboard. This aligns with my P1 design principle, "Speed of action", and is a visual/interactive convention designers are already familiar with throughout Bento.
Up until this point, I had used an arbitrarily-chosen warm grey HEX. I needed a more robust approach to align with.
Taking my learnings from my previous feedback on my iterations to maximize visual prominence, I drafted goals to guide my decision.
With my goals laid out, I harnessed our contrast-checked base light mode colors for the foundation of my rules.
If the component needs to sit on a particular color to convey correct usage (i.e., our charts), use that color. The default fill is our $BG1 light mode color.
Otherwise, if the component does not contrast with our default fill, use our $BG2 light mode color.
Aligning with my design principle of 'Ease of scaling', I enumerated these rules in a README. This would be the source of truth for future additions to the catalog that designers could leverage for consistency and ease.
Figma embeds and hero images for Web and Mobile designs.
The Directory has officially been added to our Bento Mobile file!
The Directory for Web is ready for merging and will be officially added shortly!
To promote this feature and advocate for appropriate use, I crafted a presentation and shared it with the design org.
Feedback has been great – garnering an average response of 5 to a survey: "1-10, how much value does this add in your workflow?".