Robinhood Design Systems.

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.

Uncovering a problem

The Bento Exercise

For onboarding, the Bento team had interns create a handful of core screens using Bento components. This was my first introduction to using Bento.

Creating core screens using Bento components
A pain point – duplicate components!

After completion, I learned that I had accidentally recreated a couple of components, thus creating broken component instances.

My broken insance and the actual News Row component I should've used

Reflecting on why I had never found the correct components, I was able to pin-point a potential reason.

The reason – difficult wayfinding

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.

Bento library organization

Both our Bento Mobile and Bento Web files are comprised of 12 pages that each hold a subset of that file's components.

How our Bento libraries are organized

Check out our Bento Mobile file in Figma to try it out!

Vast pages = getting lost!

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.

Within the Rows page, the News Row had been hidden among 12 other components!

Validating the problem

The hypothesis

I hypothesized that I wasn't the only one struggling to navigate our Bento libraries and wondered if there was evidence to support this.

Interviewing the Bento team

After talking to all 3 Bento Designers, I found that, indeed, it was quite common for designers to create broken components in their designs.

Maybe a quarter of the files I review have issues with duplicated components.

Bento lead designer

New hires affected the most

These issues impact new hires who are just getting started with Bento disproportionately.

Issues with hand-off

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.

As Bento scales and we onboard more designers, these problems will only scale and increase in frequency.

Having validated the problem, I was ready to dive into the workflows of designers using Bento to answer: why are components getting lost?


Research and Ideation

Conducting qualitative research, synthesizing findings, ideating solutions.

Research phase

After creating interview guides, I met with 7 designers to understand how they wayfind through Bento and find components and documentation.

My final affinity map of all quotes

Several patterns emerged from my qualitative research.

Component-search is suboptimal

There are around 3 steps in the search flow that make up a disjointed and inefficient process.

Searching in Assets Panel

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 side panel oftentimes doesn't solve the search problem
Hunting in Bento pages

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.


When hunting for components, the biggest thing is getting to the right page and knowing that it's in that page in the first place

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.

How might we quickly let designers know what components exist in the page they're hunting in?

Pinging a teammate

Asking teammates (including those on the Bento team) about components is a last resort for some.


Poor search experience = duplicated components

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.

Poor search experience = more overhead

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.

Usage documentation is low-priority

First, what is usage documentation?

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.

Usage documentation for our Info Banner component
Usage documentation is rarely used!

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.

With this finding, there might be benefit from removing usage documentation for the sake of component-search.

At this point, I was equipped with a robust understanding of the user painpoints from which to design for.

Ideation phase

Defining the core problem

I aligned on a concrete goal around which to design:

Improving component searchability within Figma.

Jamming on solutions

I harnessed my qualitative findings to brainstorm with teammates.

How might we reduce documentation to sift through?

Extracting usage documentation.

What if we extracted the usage documentation into a separate page altogether?

First concept: extracting usage documentation

As I learned, usage documentation serves only as a tertiary use-case and thus impedes the component-search process.

How might we quickly let designers know what components exist in what pages?

One main catalog of components.

Second concept: one catalog of components

This could be a compelling replacement for the "Searching in Assets Panel" step in the search workflow.

A catalog of components within pages themselves.

Third concept: within pages, a catalog of it's components

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.


Early Iterations

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.

User needs

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.

Extracting Usage

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.

First iteration: extracting usage documentation

Second iteration: extracting usage documentation
Linking navigation

Harnessing Figma's linking feature to navigate from component pages to their usage documentation page.

Hero images

Enlarging main components for better recognition / visual hierarchy.

To show the variants or not?

I explored removing the variants altogether to reduce 'fluff' (designers had mentioned feeling overwhelmed searching through variants for complex components).

Feedback from the team

Much cleaner to hunt through

The reduced documentation and the focus on the visuals creates a much more streamlined navigation experience within the component page.

Do we want to hide the variants?

We want to promote the "Go to Main Component" interaction throughout our files, so this gets broken once we hide the variants.

Do we want to bury the usage documentation?

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.

I realized that solving the component search problem wasn't as simple as reducing 'fluff', because doing so might have effects that are counterproductive to the Bento team's goals.

I needed to lean into simplicity and avoid complicating the conventional interactions integral to Bento.

Worries about overhead

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?

Main catalog

Simultaneously, I was prototyping a main catalog page, the one-stop-shop to view all of the Bento components.

The first 2 iterations for the Catalog page
One page for all components

Viewers can view all of the main components for Bento (Mobile) in one page.

Linking to documentation

From each component, the user can click the text link and navigate to the main documentation for that component.

Linking to documentation from each component on the Catalog

Feedback from the team

Great for browsing!

This solution offers a unique opportunity to get an overview of our Bento library – great for new designers.

Visual focus makes component search streamlined

The visuals of a component are highly emphasized which speeds up component recognition – this catalog is a visual tool.

Still need to zoom in a lot!

The visual focus is great for comprehension, but need to zoom out and in repeatedly to get a gauge of the components.

Moving forward with the Catalog

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's net new!

Also – it was net new, and wouldn’t require any overlapping overhead with the Bento team’s Figma files.

Still open questions to solve

There were several open questions, including what layout and visual style works best, what other content to show in the catalog etc.


Higher Fidelity Designs

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.

Design principles

My design principles, ranked

Testing with designers

I brought a variety of hypothetical scenarios, layout variations, UI variations, and questions to 5 designers to test my open questions.

First, tightened visuals and typography

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.

Now we can digest both category titles and component visuals without having to zoom!
New button that directs to the main documentation

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.

The best layout

I presented 5 potential variations of the catalog layout with designers to see what felt easiest to skim through.

The 5 different layouts I ran by designers
First, how do designers search through the catalog?

When searching the catalog for a component, all designers followed the same discretized sequence:

Scan through categories

Eye skims through categories to find a relevant category where the component might exist.


Scan through components

Upon happening upon a possible category, gaze then moves across components within that category for a match.


The vertical layout felt best

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.

Complementary content

I presented several variations prototyping other content that might be helpful for designers to see adjacent to the components.

The 5 different variations I ran by designers
First, what is the designers' mental model of the catalog?

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?").

Name change – "Directory"

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.

Simplest is best!

In harmony with the interviewees’ mental model, the simplest version was the most compelling! It created the clearest separation between overview and documentation.

Keep it simple – focus on components! Contrast this with the complexity of the documentation, or else value is lost.

Interviewee #4

Another pro aligning with my design principles – low overhead!

Optimizing copy

I shared a series of copy choices for the button that sends to main documentation.

Copy choices that I explored
"Documentation" is most accurate

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.

The final button

I decided to incorporate Figma's icon to alleviate these worries.

Potential to improve our visuals

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.

As I scan over the Catalog, the components seem to be the last thing that I see… this tool feels like it’s meant to be visual, but visuals are sitting back a little.

Interviewee #2

How might we increase visual prominence and contrast of our components?

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.

Getting into the visuals

Increasing visual prominence

I shared some protoypes exploring different visual treatments in an effort to emphasize the visuals of the components themselves.

Visual variations that I explored

What did the team have to say?

Titles feel better on artboards

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.

Dark mode is misleading

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.

While I was focused solely on visual prominence, the Bento team also wanted to make sure I'm being accurate in my representation of components.

The Catalog doesn’t just hold components, it also suggests how they should be used.

Deciding on the fill color

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?

Introducing, the clipboard

In the Catalog, components are represented within "clipboards".

The clipboards in the Catalog
Consistent size + child alignment

Keeping the clipboards consistent allows for optimized visual scanning in a straight line.

Copying and pasting

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.

Clipboards currently used in Bento
What is the fill color?

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.

My goals for determining the fill
A Bento-first solution

With my goals laid out, I harnessed our contrast-checked base light mode colors for the foundation of my rules.

Accuracy first...

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.


...then contrast.

Otherwise, if the component does not contrast with our default fill, use our $BG2 light mode color.


Examples showing these rules put into action

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.

The README for hand-off


Final Designs

Figma embeds and hero images for Web and Mobile designs.

Bento Mobile

The Directory has officially been added to our Bento Mobile file!

Final Mobile design – check it out!

The Bento Mobile Directory

Bento Web

The Directory for Web is ready for merging and will be officially added shortly!

Final Web design – check it out!

The Bento Web Directory
Now, an integral part of Bento

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?".

Thanks for visiting.


Carta Dark Mode