From Fragmented UI to Structure: Grasshopper’s Design System Journey
From Fragmented UI to Structure: Grasshopper’s Design System Journey
Solo UI/UX Designer
November 2022–January 2023
Cross-functional
Establishing a scalable design system to streamline collaboration across teams.
Overview
Typically, my product manager assigns me a task to modify an existing UX feature. Although these issues require me to establish layout sizes, color values, and other visual properties, I began to ask myself… What am I even basing these decisions off of?
I began to realize that without a reference on how UI was being established, the product runs a risk of visual inconsistency. I decided to establish the first design system that tackles all these issues.
Overview
Typically, my product manager assigns me a task to modify an existing UX feature. Although these issues require me to establish layout sizes, color values, and other visual properties, I began to ask myself… What am I even basing these decisions off of?
I began to realize that without a reference on how UI was being established, the product runs a risk of visual inconsistency. I decided to establish the first design system that tackles all these issues.
Overview
Typically, my product manager assigns me a task to modify an existing UX feature. Although these issues require me to establish layout sizes, color values, and other visual properties, I began to ask myself… What am I even basing these decisions off of?
I began to realize that without a reference on how UI was being established, the product runs a risk of visual inconsistency. I decided to establish the first design system that tackles all these issues.
The Challenge
Research
Even though this Design System feels intended to only be used by the designer (me), to truly get the full benefits of a design system, all people on my team should use this file as a resource in their own role.
With that in mind, my main priority was creating a Figma file that:
Details the behavior and intended use of all components
Specs out values (i.e. color, layout, sizing) for developers to implement
Is interactive so any viewer can navigate with ease
Breaks down the hierarchy of components used within each other
Finding Inspiration
Since Grasshopper would be available on Android devices and it is a product under Google, applying several components from Material Design felt had many applications to the product.
Still, there were several of native app components that had to be defined. The Material Design website breaks down each component by defining their behaviors, use cases, and how they should be interacted with. With these in mind, I began to pick apart the Grasshopper app to unfold the building blocks that make up the product.
Branching Out to a Solution
With that last point in mind, I felt that the best way to convey an overwhelming amount of information that has many interconnecting parts was through an organizational chart, also known as a tree diagram. This data visualization breaks down the inherited properties children components have when used in different contexts.
Take, for instance, the similarities and differences among all bottom sheet modals here:
Notice that these bottom sheets generally share a heading, a body textbox, and a button. Although various bottom sheets behave identically with one another, the visual style is inconsistent.
These bottom sheets are likely to use a heading text box, a body text box, and a button. To ensure that the layouts of these components are consistent throughout all Bottom Sheet components, we have to define sub-components within components. Though this can get complicated and overwhelming with information, breaking them down into a tree was the best way to get a visual on how these components are interconnected with each other.
The Challenge
Research
Even though this Design System feels intended to only be used by the designer (me), to truly get the full benefits of a design system, all people on my team should use this file as a resource in their own role.
With that in mind, my main priority was creating a Figma file that:
Details the behavior and intended use of all components
Specs out values (i.e. color, layout, sizing) for developers to implement
Is interactive so any viewer can navigate with ease
Breaks down the hierarchy of components used within each other
Finding Inspiration
Since Grasshopper would be available on Android devices and it is a product under Google, applying several components from Material Design felt had many applications to the product.
Still, there were several of native app components that had to be defined. The Material Design website breaks down each component by defining their behaviors, use cases, and how they should be interacted with. With these in mind, I began to pick apart the Grasshopper app to unfold the building blocks that make up the product.
Branching Out to a Solution
With that last point in mind, I felt that the best way to convey an overwhelming amount of information that has many interconnecting parts was through an organizational chart, also known as a tree diagram. This data visualization breaks down the inherited properties children components have when used in different contexts.
Take, for instance, the similarities and differences among all bottom sheet modals here:
Notice that these bottom sheets generally share a heading, a body textbox, and a button. Although various bottom sheets behave identically with one another, the visual style is inconsistent.
These bottom sheets are likely to use a heading text box, a body text box, and a button. To ensure that the layouts of these components are consistent throughout all Bottom Sheet components, we have to define sub-components within components. Though this can get complicated and overwhelming with information, breaking them down into a tree was the best way to get a visual on how these components are interconnected with each other.
The Challenge
Research
Even though this Design System feels intended to only be used by the designer (me), to truly get the full benefits of a design system, all people on my team should use this file as a resource in their own role.
With that in mind, my main priority was creating a Figma file that:
Details the behavior and intended use of all components
Specs out values (i.e. color, layout, sizing) for developers to implement
Is interactive so any viewer can navigate with ease
Breaks down the hierarchy of components used within each other
Finding Inspiration
Since Grasshopper would be available on Android devices and it is a product under Google, applying several components from Material Design felt had many applications to the product.
Still, there were several of native app components that had to be defined. The Material Design website breaks down each component by defining their behaviors, use cases, and how they should be interacted with. With these in mind, I began to pick apart the Grasshopper app to unfold the building blocks that make up the product.
Branching Out to a Solution
With that last point in mind, I felt that the best way to convey an overwhelming amount of information that has many interconnecting parts was through an organizational chart, also known as a tree diagram. This data visualization breaks down the inherited properties children components have when used in different contexts.
Take, for instance, the similarities and differences among all bottom sheet modals here:
Notice that these bottom sheets generally share a heading, a body textbox, and a button. Although various bottom sheets behave identically with one another, the visual style is inconsistent.
These bottom sheets are likely to use a heading text box, a body text box, and a button. To ensure that the layouts of these components are consistent throughout all Bottom Sheet components, we have to define sub-components within components. Though this can get complicated and overwhelming with information, breaking them down into a tree was the best way to get a visual on how these components are interconnected with each other.
My Approach
I went through the entire app which I found comprised of the following pages:
Login/Sign Up Page
Onboarding
Course List
Lesson Page
Account Page
Settings
Concepts Unlocked
These pages generally made up more than 90% of the pages available on the app, but the primary usage is seen in the Course List, Lesson Page, and Account Page. I focused primarily on covering all components there first. If I wanted to be meticulous, creating a component for every single scrutinized component regardless of its purpose, I would cover less ground in the same matter of time.
Doing the most prevalent components paved the way for establishing how the remaining components would be spec’d out.
My Approach
I went through the entire app which I found comprised of the following pages:
Login/Sign Up Page
Onboarding
Course List
Lesson Page
Account Page
Settings
Concepts Unlocked
These pages generally made up more than 90% of the pages available on the app, but the primary usage is seen in the Course List, Lesson Page, and Account Page. I focused primarily on covering all components there first. If I wanted to be meticulous, creating a component for every single scrutinized component regardless of its purpose, I would cover less ground in the same matter of time.
Doing the most prevalent components paved the way for establishing how the remaining components would be spec’d out.
My Approach
I went through the entire app which I found comprised of the following pages:
Login/Sign Up Page
Onboarding
Course List
Lesson Page
Account Page
Settings
Concepts Unlocked
These pages generally made up more than 90% of the pages available on the app, but the primary usage is seen in the Course List, Lesson Page, and Account Page. I focused primarily on covering all components there first. If I wanted to be meticulous, creating a component for every single scrutinized component regardless of its purpose, I would cover less ground in the same matter of time.
Doing the most prevalent components paved the way for establishing how the remaining components would be spec’d out.
Outcomes and Impact
By transforming the design system into a comprehensive and interactive Figma file, I created a resource that extended beyond design and into the workflows of the entire team. The system detailed the behavior and intended use of each component, documented key specs such as color, layout, and sizing for developers, and introduced interactive navigation that made it intuitive for anyone to explore. Using tree diagrams to map out component hierarchies, I provided a clear visualization of how sub-components connected, which made otherwise complex relationships easy to understand.
This structured approach ensured consistency across commonly used components, such as bottom sheet modals, which previously lacked visual alignment. By prioritizing the most frequently used screens—Course List, Lesson Page, and Account Page—I established a scalable foundation that set the standard for all remaining components without slowing down production. Working by categories instead of isolated components increased efficiency, while also reinforcing consistency across the system.
Ultimately, the design system evolved from being a designer-only tool into a shared reference point that could be used by the entire team. Developers could build with greater accuracy, designers had a clear framework for iteration, and the team as a whole gained a unified source of truth. This not only streamlined collaboration but also reduced redundancies, ensuring that the product could scale with clarity and cohesion.
Outcomes and Impact
By transforming the design system into a comprehensive and interactive Figma file, I created a resource that extended beyond design and into the workflows of the entire team. The system detailed the behavior and intended use of each component, documented key specs such as color, layout, and sizing for developers, and introduced interactive navigation that made it intuitive for anyone to explore. Using tree diagrams to map out component hierarchies, I provided a clear visualization of how sub-components connected, which made otherwise complex relationships easy to understand.
This structured approach ensured consistency across commonly used components, such as bottom sheet modals, which previously lacked visual alignment. By prioritizing the most frequently used screens—Course List, Lesson Page, and Account Page—I established a scalable foundation that set the standard for all remaining components without slowing down production. Working by categories instead of isolated components increased efficiency, while also reinforcing consistency across the system.
Ultimately, the design system evolved from being a designer-only tool into a shared reference point that could be used by the entire team. Developers could build with greater accuracy, designers had a clear framework for iteration, and the team as a whole gained a unified source of truth. This not only streamlined collaboration but also reduced redundancies, ensuring that the product could scale with clarity and cohesion.
Outcomes and Impact
By transforming the design system into a comprehensive and interactive Figma file, I created a resource that extended beyond design and into the workflows of the entire team. The system detailed the behavior and intended use of each component, documented key specs such as color, layout, and sizing for developers, and introduced interactive navigation that made it intuitive for anyone to explore. Using tree diagrams to map out component hierarchies, I provided a clear visualization of how sub-components connected, which made otherwise complex relationships easy to understand.
This structured approach ensured consistency across commonly used components, such as bottom sheet modals, which previously lacked visual alignment. By prioritizing the most frequently used screens—Course List, Lesson Page, and Account Page—I established a scalable foundation that set the standard for all remaining components without slowing down production. Working by categories instead of isolated components increased efficiency, while also reinforcing consistency across the system.
Ultimately, the design system evolved from being a designer-only tool into a shared reference point that could be used by the entire team. Developers could build with greater accuracy, designers had a clear framework for iteration, and the team as a whole gained a unified source of truth. This not only streamlined collaboration but also reduced redundancies, ensuring that the product could scale with clarity and cohesion.
Reflection
Brainstorming ideas of how to approach this project entailed multiple sheets of paper with preliminary drafts, but it soon transformed into a functional design file. This was my second opportunity of creating a design system for a product, and I’ve grown much more comfortable with building one from scratch.
Reflection
Brainstorming ideas of how to approach this project entailed multiple sheets of paper with preliminary drafts, but it soon transformed into a functional design file. This was my second opportunity of creating a design system for a product, and I’ve grown much more comfortable with building one from scratch.
Reflection
Brainstorming ideas of how to approach this project entailed multiple sheets of paper with preliminary drafts, but it soon transformed into a functional design file. This was my second opportunity of creating a design system for a product, and I’ve grown much more comfortable with building one from scratch.
Similar Case Studies
