The Rize Design System (RDS) is a set of tools and instructions that facilitate cross-team workflow.
Year
2022
Role
Design Ops
Background
In order to operate most effectively, a cross-functional team needs a structurally sound foundation at its core. A properly built design system walks a fine line. It needs to provide necessary parameters without hindering the exploration of new concepts. Creating the Rize Design System from scratch gave me the opportunity to build a custom and intuitive structure. Maintaining it for 2 years allowed me to test it with rounds of feedback to further improve it.
Purpose
The RDS was made for three different reasons:
1. Document the internal design process.
2. Provide a standardized & modular library of components for designers to utilize.
3. Facilitate the handoff process between engineering and design.
Internal Design Process
The internal design process laid out how the design team should be receiving, designing, testing, and documenting design work.
Some key improvements:
1. We created a proposal funnel with a simple Google docs template which lowered the barrier to entry.
2. In order to standardize JIRA workflow, we introduced a ticket template that included detailed documentation of project progression.
3. We simplified the process by reducing the number of programs involved.
Figma Structure
Migrating into Figma was a great opportunity to centralize and restructure our asset library. You can either love or hate Figma’s multiplayer feature. Whichever side you’re on, I think we can all agree that if your design team is greater than one, it needs to have a system in place to allow everyone to effectively utilize the software.
In order to achieve this, I created an intuitive, and scalable system that fosters creativity while improving collaboration between design, product and engineering teams.
The Figma Structure was organized using different projects with respective master, handoff, playground, and archival files. All these sections are linked to a design pattern library which houses over 200 custom variable components.
Accessible & Responsive
The RDS introduced standard, accessible, and responsive guidelines across the Rize products.
Proposing a new color palette and increasing the size of the typeface allowed us to meet WCAG2 AA+ standards.
Making the admin system truly responsive was not possible, since it was built as a desktop only web app. Instead of rebuilding it, I created a set of content-stacking rules which allowed the viewport to be semi-responsive. This allowed us to be able to support smaller viewports and tablets.
Step 1: Empathize, Brainstorm & Document
We set up an initial brainstorming session where we discussed our likes and pain points of the current process, as well as the larger scope of this initiative. I spent a significant amount of time researching how other design teams organize their workflow in order to guide our thinking. This helped the team get the dialogue started by prompting us to compare the market research to our case.
I created a shared doc with key takeaways from our initial brainstorming session. Before diving into the next step, I left the doc open for a few days, to allow people to process our conversation and add any lingering thoughts.
Step 2: Distilling The Discoveries
Taking some time away from the task gave us much needed space to process everything. It helped put our takeaways in perspective: some pain points became more apparent, while others turned out to be less significant. I synthesized the brainstorm doc into list of action items, which were then categorized into groups with a common theme or solution.
All of this boiled down to 3 principles that make up the RDS:
• Modular: As we grow, the system should easily be updated to evolve with the team’s needs. Due to its Lego-like nature, the system will easily change avoid future problems.
• Empowering: Every feature should empower the user, rather than limit them.
• Autonomous: The system promotes individual work and allows team members to independently explore concepts.
Step 3: Decrease Scope & Rollout
One of the slightly disappointing aspects of this project were the structural limitations we encountered. As a small startup, we did not have the means to test and implement all the features we dreamed up.
We decided to scope down the system’s features and only include the most crucial ones. These features would be a solid foundation for the system to continue growing in the future.
RDS 1.0 features:
• Internal Design Process
• Figma Structure
• Accessibility and Viewport Guidelines
When building out RDS 1.0, I relied heavily on system architecture flowcharts and wireframes to convey my ideas in feedback sessions with the team. Once a solution was designed and materialized, it was rolled out to design, product, and engineering. As this process went on, I continued to critically assess how I myself was using the RDS 1.0, while also taking note of data I was collecting in feedback sessions.
The RDS could be seen as a living organism that evolves over time. RDS 1.0 provided the right tools to promote creativity without hindering efficiency. I like to think it brought the design and engineering teams closer by allowing them to speak the same language.