DESIGN SYSTEMS
WISE CITIES STARTUP
2023
Building a Design System
for a Rapidly Growing Startup
OVERVIEW
WISE Cities is a startup dedicated to creating accessible technical solutions for older adults . I worked as one of the founding designers to establish a design system that can improve design & development workflow, and communication between teams, collaborating directly with the co-founder and a team of developers.
Aug 2023 - Jan 2024
6 Months
A team of 2
Me and Kat Close
(design head/co-founder)
Design systems Designer
Design system foundations, components, and documentation
DURATION
TEAM
ROLE
SKILLS
PROBLEM
Existing design system was resulting in longer onboarding and handoff sessions
The existing design system lacked consistency and accessibility, leading to inconsistent designs and causing delays in the design work schedule. There were longer onboarding and handoff sessions due to a non-comprehensive design system, unable to communicate efficiently.
CHALLENGE
How do we re-build the design system to improve design & development workflow?
RESULTS
Design system leveled up, for better.
Before
Basic style guide, instead of standard foundations.
After
A set of established foundations, at par with new industry patterns of design tokens and variables
No comprehensive documentation for effective communication
Comprehensive documentation including anatomy, variants, usage notes, skeleton and accessibility considerations
RESULTS
Key impacts and learnings
We as a team of 2, managed to roll out the new design system in just 6 months, keeping pace with the fast-moving startup environment.
6 Months
We managed to build 50+ components along with established foundations and Figma variables/design tokens.
50+ Components
A standard design system made it easier to communicate among teams and made design work faster.
Faster work
LET'S SEE HOW I DID IT.
PROCESS MODEL
I planned my steps to align with the continuous sprint cycles.
12 Bi-Weekly Sprints - 6 Months
First Sprint
Second sprint
Third Fourth Fifth Sixth Sprint
Initial Research
Setting Foundations
Building & Documenting Components
Following Sprints
Getting feedback from stakeholders
&
Iterating.....Iterating....Iterating.....
INITIAL RESEARCH
INITIAL RESEARCH
I Audited the existing design system to find areas of improvement
The problems with the existing system included lack of consistency, insufficient variant options for components, and inefficient structure and documentation of components. Lastly, there were no accessibility considerations mentioned.
Inconsistencies
The foundations were missing some of the styles used across app design, which resulted in designs being inconsistent.
Colors had no specification of semantic use and accessibility.
The type layout didn't have guidelines for responsive device usage.
Inefficiencies
The existing components were inconsistent in terms of foundations and were not optimized by using amazing Figma features like variant properties, instance swap properties, and layer toggles.
All icon buttons were made into separate components rather than having a placeholder for instance swap.
Buttons had no variants for including icons and were not given responsive device breakdown.
PROBLEM IDENTIFICATION
Inefficiencies and inconsistencies in the design system were the primary communication issues leading to delays and inconsistencies in design work.
POTENTIAL USERS
Student Designers and Developers would be the main users
As a student-led startup at the University of Maryland, most team members can be considered beginners. therefore, we aimed to build a design system that is easily comprehensible for them.
IDENTIFIED CONSTRAINTS
I strategically targeted constraints to get the most out of what was available
Given that this startup is in its early stages and relies primarily on student volunteers for product development, we encountered various constraints while establishing the design system.
Not having a premium version of figma
Build and document whole design system on one Figma page
Most of the current users of this design system are beginners
Document components in detail and necessary guidance
Necessity to ship it faster
Include only necessarydetails in the documentation
SETTING FOUNDATIONS
DESIGN SYSTEM CREATION
We collaborated with developers, ensuring unified naming conventions and component organization that worked for both designers using Figma and developers using Storybook.
COLORS
Colors system with semantic tokens
Considerations for developers: Documented token names and color codes in all format
Considerations for Designers: Tokens with functional names, established variables in Figma and a guide for use cases & accessibility
In our color palette, we categorized colors into primary and secondary groups based on their usage. We also created two types of tokens: semantic tokens and component tokens. This thoughtful categorization and token system enhanced the clarity and versatility of our color palette within the design system.
TYPOGRAPHY
Responsive Typography with One Typescale
Considerations for developers: Ease of implementation of responsiveness
Considerations for Designers: Functional names, guide for use cases & accessibility
We organized our typography into functional categories, specifically display, heading, and body text. To simplify our approach, we adopted a single-type scale instead of managing three for different breakpoints, prioritizing ease of implementation.
OTHER FOUNDATIONS
Icons, Spacing and Grids
For components, we utilized icon placeholders to implement icon swap properties, to cater to various use cases seamlessly. all the icons were made available to swap through an icon library.
Our spacing scale incorporated the most frequently used spacings in our existing designs, coded as variables in figma to ensure consistent application across different design elements.
Additionally, our device grids were strategically aligned with screen sizes within the responsive spectrum, enhancing the adaptability and coherence of our design system.
BUILDING & DOCUMENTING COMPONENTS
COMPONENTS
Component documentation included anatomy, variants, skeleton, notes and accessibility considerations
Consistency across breakpoints was a top priority for us, ensuring that components remained uniform. Changes in spacing and text sizes were only made when necessary across different sizes.
During the component creation process, our focus was on accessibility, simplicity, and maintaining consistency, aligning with specific insights found from our research with elderly users.
Anatomy of the component including different variants and properties
Variants of the component
Skeleton of different default components of different sizes.
Notes for designers and developers
Accessibility considerations along with WCAG reference and supporting materials
IMPACT & LEARNINGS
IMPACT
The improved design system benefitted both designers and developers, positively impacting our product and users
DEVELOPMENT
The improved design system streamlined the developers' workflow, allowing efficient communication with the design team during implementation discussions. As the foundational elements are established now, we could prioritize discussing features rather than delving into low-level UI details such as color values, spacing, small components, interactions, states, etc.
DESIGN
Having a pre-built library of components streamlined the process of creating high-fidelity interfaces, reducing the time required for designing interfaces from days to just a couple of hours.
PRODUCT
The design system enabled rapid prototyping, facilitating the testing of more ideas, quick evaluation of hypotheses, and the creation of additional variations for A/B testing. These benefits could significantly contribute to the success of the product.
USERS
The things improved within the company will eventually help make our users' experience better.
LEARNING AND TAKEAWAYS
I learned the value of collaboration to make the design system actually work
I learned that the most crucial thing while creating a design system is collaboration. Making sure to include both designers' and developers' perspectives, and finding a middle ground to make it easier for both parties is very important.
If the design system doesn't work for their users. then it can cause a lot of conflicts and delays in the design and implementations work.
I discovered that conventional design system practices may not necessarily align with the needs of your team.
I went through a lot of standard design systems to learn the best practices. However, some of those practices still did not work for our team, and I had to find a suitable way to customize the system for our specific needs.
WHAT COULD HAVE BEEN DONE DIFFERENTLY?
I would have liked to add usage guidelines for foundations and components
Given time constraints, I focused on essential categories for comprehensive documentation. However, with more time, I would prioritize adding usage guidelines, including Dos and Don'ts for each component and foundations. This addition aims to enhance the efficiency of implementing the design system by providing clear guidance on best practices and potential pitfalls.
I would have liked to implement a different typography system that is easier for designers to use for consistency
During the implementation of the typography scale, I initially envisioned having three distinct type scales tailored for three different breakpoints. This approach aimed to provide designers with greater consistency and ease of modification in the implementation when necessary. However, after multiple discussions with developers, the decision was made to implement a single type scale for all three breakpoints. This required designers to assess and adapt sizes while designing.
