How Hema Built a Unified Cross‑Platform Design System for Backend Operations

Hello, I am Jing Zhuang from Alibaba Hema Experience Technology Department. I will share the theme "Exploring Hema's Cross‑Platform Solution for Middle‑Back Office" and discuss our thoughts and progress on cross‑platform development.

Before we start, let's look at industry trends in mobile work and multi‑platform design. With mature wireless networks and cloud infrastructure, mobile devices have exploded, and more enterprise products are embracing multi‑platform design.

Huawei launched HarmonyOS in 2019 to enable seamless experiences across devices, allowing a single app to be deployed on multiple terminals. Apple introduced Hand‑Off in iOS 8 for cross‑device task collaboration. SAP’s SaaS products support cross‑platform use with the Fiori design system, though it remains closed.

In the context of retail digitalization, Hema faces new B‑to‑B experience challenges. For consumers we aim for precise product‑person matching; for operators we build digital workflows with various smart devices to provide simple, efficient task experiences. This forces us to rethink the boundaries of middle‑back office experiences.

Hema's middle‑back office includes headquarters operations, store management, delivery and warehousing, all benefiting from digital work systems and various smart devices (screens, printers, notifications, positioning, etc.). Workers increasingly rely on coordinated smart devices to complete tasks.

The core workbench, "Hema Workbench," acts as a large new‑retail operating system, providing different capabilities (warehouse, logistics, CRM, etc.) for various roles. Our experience team must enable simple, efficient, consistent task completion across all roles.

We face two design‑delivery options: separate solutions per platform (higher cost, lower efficiency) or a unified solution (requires handling differences but yields consistent experience and higher efficiency). Considering cross‑platform collaboration needs, we chose the unified approach.

We identified three major problems to solve for a unified solution:

How to support device and scenario differences with a single design system.

How to support cross‑platform component reuse with a single component architecture.

How to enable cross‑device interaction with a single application architecture.

From this we aim for a "one code, many platforms" consistent middle‑back experience.

Problem 1: How to support device and scenario differences with a single design system

Traditional design systems target a single device; AntD and Fusion provide separate PC and mobile systems, leading to high development cost and fragmented experiences. In Hema's diverse work environments (stores, delivery stations, warehouses) factors like screen size, viewing distance, lighting, and posture vary, so a unified UI cannot meet all needs. We need a design system that considers environmental variables.

Example: In store operations, the 11‑inch operation Pad and the 11‑inch POS have the same resolution but different UI element sizes because the POS is used from a farther viewing distance (70‑80 cm) and requires larger touch targets.

Similarly, delivery station call‑screens have varying lighting and viewing distances, affecting readability. By analyzing space, lighting, and distance, we can provide adjustable layouts, grid sizes, font scales, and color modes for different stations.

We derived environment variables (device type, screen size, viewing distance, information density, lighting, humidity) and mapped them to design tokens via formulas, digitizing designers' experience.

We built a cross‑platform Design Token configuration and generation system where users input device parameters to obtain token values and preview component changes.

Problem 2: How to support cross‑platform component reuse with a single component architecture

Middle‑back office scenarios involve a wide range of devices—from 1.5‑inch watches to 55‑inch TVs—making component adaptation more complex than typical mobile apps. We therefore need a component architecture that is extensible across many device types.

Interaction patterns differ: on keyboards/mice a selector may be a dropdown, while on touch devices it becomes a full‑screen modal with swipe gestures. Thus components must adapt their interaction model per device.

We decompose components into three layers: view‑style layer (structure & appearance), behavior‑logic layer (event handling), and state‑logic layer (shared state). The state layer remains consistent across platforms, while view and behavior adapt.

We propose a model‑centric implementation: split a component into hooks such as useStyleProps (styles), useSelectState (state), useDevice (device detection), and useSelect (behavior). The component then returns a responsive view.

For responsive view we extend HTML Elements with System Elements, a set of atomic UI primitives based on design tokens, enabling on‑demand CSS generation without class‑name conflicts.

SystemProvider (ThemeProvider, DeviceProvider, ColorModeProvider) supplies theme, device context, and color mode to the application, allowing developers to control cross‑platform behavior easily.

In summary, reusable components consist of view + behavior + state; we provide System Elements for responsive view, behavior hooks (e.g., usePress) to abstract event differences, and state hooks (e.g., useListState) for shared logic.

Problem 3: How to achieve cross‑device interaction with a single application architecture

New work scenarios require applications to run on multiple devices (PC, phone, RF scanner) and keep their state synchronized. For example, store staff may enter data on a PC, approve on a phone, and pick items with an RF device.

We split the application into three layers: an application container layer (unified API), a data‑model layer (business services, state management, remote persistence), and a cross‑platform view layer (device‑specific UI). This enables shared data models, cross‑device view reuse, and synchronized state.

The data‑model layer supports remote state persistence via App.sync, allowing multiple device views to stay in sync without backend draft storage.

Routing adapts to device size: on PC a detail view may slide in from the side, while on mobile it stacks. Developers declare responsive routing arrays where the first element applies to small breakpoints and the second to larger ones.

Conclusion

The internal product name for Hema's middle‑back cross‑platform solution is ReX Design For OS . Version 1.0 launched in September 2018 with multiple platform solutions. Version 2.0 released in June 2020 added cross‑platform components for PC/Pad/Pos/Phone and a unified application/container framework. An upgraded solution with one‑code‑many‑platform components and applications is planned for March 2021, and we intend to open‑source the core solution in June 2021.

The solution includes environment‑aware design token generation, model‑view‑behavior layered components, and an application architecture that shares data models, synchronizes state remotely, and provides supporting infrastructure such as multi‑device containers, message centers, and a cross‑platform experience brain.