State of ShopBack Design Systems

What is ShopBack design system [SBDS]?

Our design system consists of three components:

1. Design Token – Store foundational design decisions such as colours, font size, spacing, and border-radius.
2. Mobile Library – iOS and Android library used for ShopBack mobile app.
3. Web React Library – Web library used to create ShopBack consumer and internal tools.

What is the problem(s) we are trying to solve with design system?

There are two main areas we are trying to solve with our design system:

Speed and Efficiency

Design systems can help speed up the design and development process by providing a library of pre-built components and design assets. Teams can spend less time creating new designs or code from scratch, and more time focusing on innovative solutions and user experience improvements.

Scalability

Components are designed to be scalable so that they can grow and evolve with organisation and product needs over time. Existing components can be updated anytime with minimal risk and effort.

A year about stabilising, adapting, and planting seeds for a more sustainable future.

2025 was a pivotal year for the Design Systems team. After the high of widespread adoption in previous years, we faced a natural decline in system consistency due to decentralised governance and organisational changes.

Rather than viewing this as a setback, we used it as an opportunity to reinforce the foundation of our design systems. We re-established governance, aligning more closely with company-wide shifts such as the introduction of WebView and our unique font ShopBack Sans, and explored how AI can support system scalability.

Last year in view

Governance reset after peak adoption

Decentralised governance led to inconsistent implementation and detached ownership across teams. As key contributors moved on, new members lacked the necessary guidance, leading to increased component fragmentation and duplication.

We reassembled a dedicated core Design Systems team responsible for governance, tooling, and team education. Regular engagement rituals, such as Design Systems office hours and design audits, were reinstated to promote consistency and ensure ongoing collaboration. We also undertook a systematic audit to consolidate redundant or snowflake components.

Aligning with rapid product growth and experimentation

The rise of WebView enabled faster product experiments but introduced new complexity. Teams began combining native and web elements within the same surfaces, creating visual and functional inconsistencies. Due to a lack of focus on the web in the past two years, the web library is almost non-existent.

To manage this shift, we merged web and mobile libraries into a single unified Figma kit. We implemented clear guidance to help teams decide when to use native versus webview components. Additionally, the new ShopBack font was officially rolled out and applied across all design tokens to ensure a consistent visual identity across different ShopBack products.

AI-powered DS operations

Maintaining documentation and onboarding new team members continued to be a resource-intensive process. Teams frequently encountered barriers when trying to understand or implement design system components.

We integrated CustomGPT into our workflow to automatically generate and maintain up-to-date component documentation. We also launched AskPD, an AI-powered assistant enabling stakeholders to self-serve common design system queries.

Current state of SBDS

• Mobile adoption and engineering support – Mobile native components remain healthy with proper governance and continued support from their respective engineering teams. Commonly used components have already transitioned to Swift and Jetpack Compose, ensuring future scalability and performance.
• Cross-platform library consolidation – Web and native libraries are now consolidated under a single Figma file with shared tokens for type, spacing, and layout. Agnostic components can now be easily used across mobile and web surfaces, reducing duplication and increasing alignment.
• Documentation with AI acceleration – Instead of increasing raw documentation output, we've taken deliberate steps to cut down documentation creation time by up to 80% through AI-assisted tools. This has helped free up design and engineering bandwidth.
• Team engagement and contribution – Team engagement has strengthened with a clearer backlog, more structured async discussions, and improved onboarding processes. This has enabled teams to contribute more confidently to SBDS.

What are we doing in the remaining FY25’26?

Our focus is to enhance the scalability and clarity of design systems across all product surfaces. We aim to make all components MCP-ready to support the company’s modular commerce platform initiative. By strengthening cross-platform architecture and improving token consistency, we plan to reduce technical debt and boost implementation confidence. We also aim to push the boundaries of tooling, exploring design-tech solutions beyond Figma that support code-native workflows and enable faster delivery. Finally, we are committed to rebuilding our internal design system to help operational teams move faster with fewer dependencies.

Focus areas:

• Ensure component readiness in meeting MCP guidelines and modular specs.
• Redesign and launch a refreshed internal DS library optimised for internal tool development.
• Pilot new tooling (e.g. Lovable, Bolt or Build.io) and evaluate feasibility for integration into our stack.
• Continue to refine DS contribution and governance workflows to support distributed ownership better.
• Continue leveraging AI to automate documentation and support design decision-making at scale.

A year marked by successful adoption and maturity

This year marks a new milestone for our Design Systems in ShopBack. We've moved beyond chasing feature team adoption, and now embark on a new maturity. We're grateful for the support of all feature teams that helped usher in this milestone.

Let’s review what we have committed last year:

• Stronger adoption starting with new pages
• Enhancement of existing components
• Better documentation
• Build a feedback loop for component improvements

Last year in view

Stronger adoption starting with new pages

Previously, widespread adoption of our design system presented a hurdle for feature teams juggling limited resources. But in Q3'23, we made it a team-level objective (TLO) to achieve 80% adoption, elevating it beyond a mere side project. Shoutout to all feature teams that supported this initiative.

Enhancement of existing components

Last year, we shifted our focus from making new components to relentlessly refining existing ones. It's not just about efficiency, it's a commitment to rewarding our early adopters who championed the Design System. Over the last few quarters, we have tackled various improvements on complicated components such as – Top app bar and Bottomsheet.

The Design System team has also gone beyond creating commonly used assets to supporting the feature team in reducing their implementation time. To highlight a few examples: icon library, date & time formatter and currency formatter.

Better documentation

Following a comprehensive internal retrospective involving both designers and engineers, we have identified a critical need to restructure our current design system documentation approach. The primary concern lies in the disjointed nature of design and engineering documentation, presenting significant challenges for users seeking relevant information in a seamless manner.

To address this fragmented landscape across multiple platforms, we have implemented a unified solution: consolidating all design system-related documentation under a single, comprehensive platform. The new confluence space – Design Systems (SBDS) has a standardised way for both design and engineering documentation.

Better feedback workflow

Recognising the importance of continuous feedback in enhancing our design system, we have implemented a streamlined feedback workflow. Previously, the lack of a centralised platform for design and technical insights could lead to potential miscommunication and inefficiencies. This new approach addresses these concerns by establishing a centralised feedback hub within the #design-systems channel on Slack.

Current state of SBDS

Mobile focused

Design system will continue to be Mobile focused. We will readjust our priority accordingly when web becomes a priority again in the product roadmap.

56 components 17 design pattern

As of today, our engineering library holds a collection of 56 components with over 3000 total insertions. Recognising the need for comprehensive guidance beyond individual components, the design team has also begun crafting design patterns or guidelines for commonly used and potentially ambiguous elements, such as dialog vs bottom sheet or bottom sheet vs full screen.

Maintaining 80% adoption

Maintaining a minimum 80% adoption rate for all features remains a core objective in ensuring the design system's progress and effectiveness. Whatever is adopted, should stay adopted.

Quality and standards

To guarantee component quality and consistency, all newly developed components will include comprehensive documentation. Additionally, we are committed to minimising design system related incidents reported through Dogfood with less than five per quarter.

This year, our SUS scored 75.58%, exceeding the Good benchmark. We are actively working towards surpassing the Excellent threshold of 80.3% in the coming year.

What are we doing next in 2024?

Design System as a service

Our design system is not merely a temporary initiative; it is the established paradigm for crafting high-quality products within our organisation. As we move beyond mere adoption, the design system team is dedicated to maintaining its relevance to the company's strategic direction and maximising its impact. We envision a future where design systems actively partner with feature teams, not only enhancing product quality but also proactively anticipating future needs across the breadth of our offerings.

SwiftUI and Jetpack Compose

For engineers, we acknowledge that our current component library does not encompass both SwiftUI and Jetpack Compose, two increasingly popular mobile UI toolkits. The platform team is actively formulating a comprehensive transition plan to address this gap.

Design Standards

For designers, establishing clarity and consistency is paramount. We will continue to eliminate ambiguity in usage guidelines by developing principles and guidelines that govern design decisions. This ongoing effort will yield invaluable, long-lasting building blocks for long term design cohesiveness and consistency.

80:20 Rules

Pursuing 100% adoption is not our ultimate objective. We recognise that each feature may have unique requirements and characteristics that necessitate deviation from the standard design system. Therefore, the design system team will remain vigilant in monitoring this "unique 20%," readily prepared to integrate recurrent elements into the library as they gain wider adoption by multiple features.

A year dedicated to pitching and building organization-wide support

Rebranding with new colours, icons and illustrations

During the rebranding exercise, we leveraged design tokens to change our primary colour from orange to black throughout the app. As part of this process, the team also took the opportunity to refactor the codebase by remapping 468 colour nodes. Additionally, to align with our new branding, the team also recreated a whole new set of icons and illustrations.

Font standardisation for iOS and Android

Font styles have not been scalable with utilisation of native system font. To resolve this issue, we redefined the font styles with clear standards and created a font component for future scalability.

Currently, only 15%* of our component has adopted the new font styles, but the standardisation has already started to create a positive impact with latest adoption in CP components in Q4’22.

• Number includes all legacy code. Data source filter with sbdslabel and sbdstextview

Components preview available on app

Testing our app internally took a different turn last year with company-wide adoption of the dogfooding app. This applies similarly to having a preview for design system components. Today, it is mandatory for all designers to install it on their devices.

Proper handover process between Figma → Confluence → Code

Adoption of design system components should always start from the design phase. Today, we have proper processes and documentation on how to hand over design to implementation. Engineers are encouraged to use design system components whenever possible.

By having the design system UI checker both as an app and a figma component, I am able to know if a component is built in the design system. Previously, I had to keep clarifying with the design systems lead and various engineers if we have any reusable components to use in a project. By having these checkers, it has helped us to reduce effort in re-designing and rebuilding existing components, and be more consistent throughout our designs in our app today

Better quality for new components

With a focus on scalable design, the team has delivered better components with clearer guidelines and component APIs. Last year, we shipped seven new components (Top App Bar, Bottom Sheet, Dialog, Snackbar, Tag, Callout and Tabs) with proper guidelines and technical documentation.

Using design system component can cut down my effort by 50%. I don’t need to worry about interaction details and frontend logic.

The app typography is much clearer to me today. Previously, I had a lot of confusion regarding when to use certain types of typography. However, with the new guidelines, I have a clearer idea of when to apply certain font styles.

Measuring adoption rate with design system dashboard

Measuring the adoption rate was not there a few quarters ago. Today we have set up a baseline to understand where we are with our Dashboard. With this, we are able to plan better and predict our next steps.

As of today, this is the adoption rate of design system components across different features.

Current state of SBDS

Mobile-only

Today the design effort has only been focusing on mobile app where, as web component has been neglected. The is also reflected in the feature gap between mobile and web.

One quarter build, one quarter adopt

Over the past few quarters, we have taken the approach of prioritising frequently used components. We ship components one quarter ahead so the feature teams have time to plan for adoption. However, as of today, we have received a lot of pushback from features unwilling to spend additional effort to adopt design system components.

22 components available in mobile engineering library

As of today, we have a collection of 22 components available in engineering library. This means that we use at least two design system components for every page.

In particular, the new Tag component which we did an overhaul has a very healthy adoption. It has been used 72 times on iOS and 85 times on Android since released. On average this requires one day effort to develop from scratch with reusing this component we have saved an average of 114.5 days of effort not remaking the same component.

Documentation as part of the process

We doubled down on component documentation as the team started to scale. In 2022, we produced a total of 10, compared to 2021, which had close to zero. This improved the foundational and component guidelines amongst the design team.

An average of 50%* adoption across BU

In total, we have an adoption of around 50% crossed different BU with content platform team having the highest adoption, which is close to 100%. This is understandable because content platform components are used across different parts of the app.

Why should you use or adopt SBDS?

Reduce effort to implement design

Design system components help reduce the effort required on front-end development by 50%, allowing teams to focus on front-end logic and more critical areas. Not only that we also eliminate QA effort on component that comes from the library.

Get API updates instantly

As there are dedicated teams focusing on governing and maintaining the components, we constantly review and update them based on the product’s needs. Using design system components allows us to make design changes at scale. When a new API is added to a component, adopter will also receive these updates automatically.

Reduce UI redundancy at scale

Changing the primary colour or base font size should be easy and hassle-free with design system components. You don't need to worry about another rebrand or UI overhaul if we are updating an existing component. This allows for less refactoring effort in your development team.

What are we doing next for Q2’23?

Stronger adoption starting with new pages

We understand there are other priorities and it’s hard to accomplish everything with limited resources. For next quarter we will continue to support adoption. We highly encourage everyone to start using design system with all the new pages moving forward. If you need any support at any point in time feel free to reach out to us. Kudos to the team that has given the adoption a shot.

Enhancement of existing components

To give appreciation to our adopters we will focus a lot more on improving existing components. These improvements can be on interactions or component architecture to better support adopters' needs.

Better documentation

Many components still lack design guidelines, which can result in inconsistent design decisions. As we are slowing down from creating new components, we want to take this opportunity to make comprehensive documentation available to the wider team.

Build a feedback loop for component improvements

Aside from the areas we have identified, we also encourage adopters to provide constant feedback on our design system. This can include things like proposals or updates to guidelines or standards so that we can constantly review and refine our design system.