[
Content
Nativebase Design System
Design system is a set of standards to manage design at scale by reducing redundancy while creating a shared library and visual consistency across different pages and platforms.
Role
UI/UX Designer
Deliverables
Design library
Component guideline
Tools
Figma
Year
2021-22
Challenge
Every new project or project phase required designing from the ground up, including setting up a fresh component library. This approach often led to:
Repetitive work, as the same components were redesigned repeatedly.
Inconsistent styles and functionality across projects due to the lack of standardization.
We needed to:Recreate old components
Gather all old use cases and create use cases for each component rewrite considering design system challenge
Discover
To understand the core challenges and needs of its users. This involved conducting extensive research with product teams, developers, and designers to identify pain points like inconsistent UI across platforms (Android, iOS, and Web), redundant custom components, and accessibility gaps. Stakeholder interviews provided valuable insights into workflows and expectations, while a competitive analysis of leading design systems like Material Design and Ant Design helped benchmark best practices and identify opportunities for differentiation. Simultaneously, an audit of the existing NativeBase library mapped current components, revealing areas needing modernization and enhancement.
Define
The vision was set to create an accessible, utility-first design system that ensured consistency and streamlined collaboration between developers and designers. User personas were developed to align the system with the needs of its primary users, emphasizing flexibility for developers and scalability for designers. Components were categorized into foundational (colors, typography, spacing), atomic (buttons, inputs), and molecular (cards, modals) levels, with a prioritized roadmap for incremental delivery. A collaborative framework was established to facilitate seamless communication between teams, supported by tools like Figma. This structured approach ensured that the NativeBase Design System was not only functional and scalable but also a critical enabler of cross-platform consistency and efficiency.
The Approach
We began by utilizing an existing style guide as the foundation for our system and Our focus was on implementing any necessary updates or new elements into the system while seamlessly integrating them with the existing style guide.
The component library consists of
Component Name
A specific and unique UI component name, to avoid miscommunication between designers and developers. This needed to be clear so that the components would work as they were supposed to without error.
Note making
Page annotations and descriptions to understand what component you were looking at.
State changes
Recommended defaults and the subsequent changes in appearance.
Breakpoints
Any size indication and breakpoints for the developers.
Execution
Building a design system is much like constructing a house I need a solid foundation. In design systems, that foundation is your spacing and grid system. These elements, though often overlooked, play a critical role in defining the look and feel of a design. For this project, I adopted an 8pt grid system, incorporating a 12-column layout and an 8px baseline grid.
When working on the NativeBase Design System, I followed a similar approach by leveraging a utility-first grid and spacing system to provide consistent alignment across platforms like Android, iOS, and Web. Both systems underscore the importance of responsive foundations, allowing for scalable, pixel-perfect designs across various screen sizes. These principles ensure flexibility, accessibility, and a polished user experience.
Each component included clearly defined variants, each appropriately named to ensure clarity. This approach made it straightforward to understand state changes and customize components by toggling specific features on or off, streamlining the publishing process and ensuring ease of use.
Overview
The process of building the NativeBase Design System was structured around a double-diamond approach, ensuring a thorough and iterative development process. Initially, I focused on identifying key challenges by conducting in-depth research and engaging directly with product teams to understand their pain points and requirements. Once a clear understanding was established, I developed a comprehensive execution plan, outlining the structure of the design system and a phased timeline for delivering components at the utility, atomic, and molecule levels. Components were released incrementally, with an emphasis on encouraging feedback and fostering collaboration across teams. This iterative approach ensured that the system addressed evolving needs and maintained consistency across Android, iOS, and web platforms.
Interview with all product design teams Research on old "design system", components implementation and company brand guidelineConfirm requirements from managersResearch on other industry-standard design system.
Research
Document and collect all the feedback from the teams.
List out all the painpoints and possible issues
Research findings
Define the right problem.
Summarize and categorize all the research findings
HMW questions
Explore the ways we structure design system
Draft design components with all the possible variations
Consider factors of different viewports, product natures and etc
Solutions
Documentation
Documentation is always included on the same page as the component this was to explain any use cases that were created. This consisted of:
A clear explanation for what this element is and how it is typically used, occasionally accompanied by dos and don’ts for context and clarification.
Picture examples so that it was clear what we were talking about
Rules of when to use the component and how to use the component
Challenge
Keeping the design consistent across Android, iOS, and Web was tricky due to different platform standards. The system had to work well for both developers, who needed flexibility, and designers, who wanted consistency and simplicity. Planning for future growth without overcomplicating the system was a big task, as was ensuring accessibility for all users. Gathering feedback from various teams and updating old components without breaking things added to the complexity. Creating clear documentation to help teams adopt the system was also essential.
The style guide consisted of:
In-page annotations (how we document and layout each component within the library)
Branding (colours, typography)
Spacing guidelines
Layout grids
Icon pack
Border radius guidelines
Creating all components library