Explore

Version 3

Abbreviations

STEM : Name of our design system UI : User Interface UX : User experience

Reason to Move from v2 to v3

With v2 of STEM in place, it was time to transition to v3, addressing key limitations and ensuring a more scalable, efficient, and well-documented design system.

The v2 of STEM was essentially a direct Figma adaptation of v1, which originally existed in Adobe XD. However, several issues and gaps remained, making it necessary to refine and evolve the system further.

Key Issues in v2 That Led to v3

Oversized components

Components in v2 were unnecessarily large, leading to inefficiencies:

Padding was excessive, making elements take up more space than required.

Font sizes were too large, reducing readability and scalability.

Inconsistent icons across components

Icons used in various components lacked uniformity, creating visual inconsistencies in the product.

Essential components were missing from the Design System

Many commonly used components were not part of STEM.

This happened because designers, needing components on-demand, often created them independently instead of contributing to the design system.

Lack of well-defined component states

Due to missing components, state definitions were unclear, leading to confusion for both designers and developers.

As a result, implementation often varied across different parts of the product.

Insufficient documentation

There was no structured documentation outlining:

Proper usage guidelines for components.

Best practices and do’s and don’ts for implementation.

This often led to misuse or inconsistencies across teams.

Why v3?

The transition from v2 to v3 aimed to fix these foundational issues by introducing:

Optimized components with better spacing and sizing.

Standardized icons across all UI elements.

A more comprehensive component library, reducing one-off designs.

Well-defined states for all components, ensuring design-to-development consistency.

Detailed documentation to improve adoption and usage clarity.

With v3 of STEM, we set out to build a mature, structured, and scalable design system, making it a single source of truth for all design and development efforts.

Steps followed to move from v2 to v3

To address the issues identified in v2, we followed a structured component redesign process. This approach ensured consistency, scalability, and efficiency across the STEM design system while aligning design and development efforts.

1. Listing of components

The design team conducted a detailed audit of all components to identify:

Components requiring enhancements (padding, size, responsiveness).

Components missing from the design system but widely used in the product.

Once listed, we tackled one component at a time, moving it to the next stage of refinement.

2. Brainstorming and ideation

The team engaged in brainstorming sessions to refine each component:

Identifying use cases

Listed all possible use cases of the component across our products.

Referencing other Design Systems

Studied established systems like

Atlassian Design System⁠

and

ANT Design System⁠

to analyze best practices.

Defining variants and states

Documented all necessary variants (e.g., with icon, without icon).

Defined all component states (default, hover, selected, focused, disabled).

Setting usage guidelines

Established do’s and don’ts to prevent inconsistencies.

3. Creating component

With a clear component structure, the design team began building the components while ensuring:

Logical grouping and layer naming

All relevant layers were properly grouped and named for clarity.

Auto-layout and constraints

Components were designed using auto-layout for flexibility.

Min/max width & height were set for scalability.

Consistent padding and spacing

Defined horizontal and vertical padding across all components.

Maintained consistent spacing between elements.

Component properties and variants

Included all necessary properties to make the component functional.

Ensured all required variants and states were created.

Internal prototyping (if required)

Components were prototyped internally for better usability testi

⁠

(Fig 1 : Padding and gap defined for a component)

(Fig 1 : Padding and gap defined for a component)

⁠

(Fig 2 : Properties set for BUTTON component)

(Fig 2 : Properties set for BUTTON component)

⁠

4. Testing of component

Once a component was created, we tested it on different screen types to evaluate its usability:

Testing across 3 screen types:

Data-Heavy Screens (Common in our B2B product)

Checked if the component fit well within space constraints.

Ensured it could handle large sets of information effectively.

Medium-Data Screens

Verified that the component was not overly compact or too large.

Ensured that the screen maintained visual clarity.

Less-Data Screens

Ensured that the component was clearly visible and easy to interact with.

Avoided a "floating" effect where the component looked out of place.

After testing, the team iterated on necessary adjustments, ensuring every component was fully optimized before documentation.

5. Documentation

Why is documentation important? A well-documented component saves time and ensures proper usage. Our documentation included:

Component purpose – What the component does and why it was created.

Size & measurements – Defined width, height, padding, and spacing.

Variants & states – Default, hover, focused, disabled, etc.

Usage guidelines – When and how to use the component.

Do’s and dont’s – Best practices to prevent misapplication.

How documentation helps teams

For Developers:

Provides all required measurements for implementation.

Helps them create variants and states accurately.

Saves time by eliminating redundant component creation.

For Designers:

Ensures consistent usage across different products.

Helps new team members quickly understand component usage.

Prevents inconsistency across multiple designers working on the same system.

Post the documentation is ready, process of handoff of a component to devs is started,

6. Handoff Process

Once the documentation was finalized, the next step was handoff to developers, ensuring that components were built pixel-perfect and aligned with the design specifications.

What is handoff? Handoff is the process of passing all necessary design specifications and guidelines to developers, enabling them to accurately implement components in code.

At Attentive, we followed a simple yet effective handoff process:

Figma walkthrough for developers

Conducted a detailed walkthrough in Figma, explaining:

The component’s structure

Its variants and states

Expected behavior and interactions

This initial session helped clarify any potential doubts upfront.

Sharing documentation & resources

Developers were provided with:

A Figma link to the component for reference.

The component documentation, outlining:

Sizing and spacing

Variants and states

Usage guidelines and best practices

Post-handoff support

After documentation was shared, a follow-up session was scheduled to address any additional queries.

Even after the formal handoff, designers remained available to assist developers whenever needed.

By maintaining clear communication and collaboration, we ensured a seamless transition from design to development, reducing inconsistencies and speeding up the implementation process.

Learning

Transitioning from v2 to v3 of STEM provided valuable insights into design system evolution, scalability, and collaboration between design and development teams. Here are some of the key takeaways:

A design system is never truly "Complete"

v2 was functional, but as the product and design needs grew, gaps became more evident.

A design system must evolve continuously to accommodate new requirements, usability improvements, and industry best practices.

Component consistency is critical

Inconsistent iconography, padding, and font sizes in v2 led to inefficiencies.

Standardizing these elements in v3 improved scalability and usability, making the system more predictable for both designers and developers.

Documentation is as important as the components

The lack of proper documentation in v2 caused confusion and inconsistent component usage.

With detailed documentation in v3, designers and developers could:

Easily reference best practices.

Ensure consistency across different teams and screens.

Save time by reducing back-and-forth discussions.

Collaboration between design and development is key

The handoff process in v3 was significantly improved compared to v2, ensuring:

Clear communication of component behavior.

Proper walkthroughs to eliminate developer confusion.

Consistent implementation across different modules.

Testing in real scenarios is non-negotiable

v2 components often looked fine in isolation but didn’t perform well in data-heavy screens.

v3 components were tested on real product screens before finalization, ensuring:

Scalability in dense UIs.

Proper spacing and alignment across different layouts.

Moving from v2 to v3 of STEM reinforced the idea that a design system is an evolving entity, requiring constant iteration, collaboration, and refinement. The improvements made in v3 enhanced usability, consistency, and efficiency, laying the foundation for a more scalable and mature design system.