How UI Standardization Transformed Youzan Retail’s Mobile Apps

This article details the background, challenges, and step‑by‑step solution for standardizing UI across Youzan Retail’s iOS and Android apps, covering designer and developer perspectives, the creation of a shared style library, component architecture, resource management, delivery outcomes, pitfalls, and future automation plans.

Youzan Coder
Youzan Coder
Youzan Coder
How UI Standardization Transformed Youzan Retail’s Mobile Apps

Background

Youzan Retail was launched in August 2017. After a year of rapid development the product accumulated significant technical debt, especially inconsistent UI styles and low design‑to‑code fidelity.

Solution Overview

UI standardization was tackled from both the designer and developer perspectives. Designers use Sketch Text Styles, Layer Styles and Symbols to build a shared library. Developers map those Sketch styles to code equivalents (e.g., UIAppearance for styles, component factories for symbols).

In Sketch a Text Style defines reusable text properties, a Layer Style stores visual attributes, and a Symbol encapsulates a reusable component.

Designer’s Perspective

Each designer maintains a personal asset library. By unifying the library through Sketch Text Styles, Layer Styles and Symbols, a single Library can be distributed to all designers.

Developer’s Perspective

Developers create a one‑to‑one mapping between Sketch styles and code. For example, the Border_DSB4 layer style is defined as:

border-color: #1989FA;
border-radius: 2;
border-width: 1;
background-color: #FFFFFF;

A corresponding style configuration library is maintained in code, eliminating duplicated definitions.

UI Standardization Practice

3.1 Style Implementation

Only Color and Font are centralized in a Library. For iOS colors are exposed as properties:

#pragma mark - DeepSkyBlue
@property (nonatomic, assign) UIColor *yz_DSB1Color;

Android follows a similar pattern, focusing on contrast and maintainability.

3.2 Component Implementation

Components are built on a core layer that provides factories for UI elements. Business code creates components without handling styling.

@interface YZLabel : UILabel
/** default padding (0,0,0,0) */
@property (nonatomic, assign) UIEdgeInsets contentEdgeInsets UI_APPEARANCE_SELECTOR;
@end
@interface YZButton : UIButton
@property (nonatomic, assign) YZButtonImagePosition imagePosition; // default left
@property (nonatomic, assign) CGFloat spacingBetweenImageAndTitle; // default 0
@property (nonatomic, copy, nullable) YZButtonAction buttonAction; // click handler
- (void)setBackgroundColor:(UIColor *_Nullable)fillColor forState:(UIControlState)state;
@end

The core layer exposes only the necessary APIs; all visual configuration is performed internally.

3.3 Presentation Layer (Pad & Phone)

The presentation layer is split by platform (Pad vs. Phone) rather than by product. Platform‑specific tweaks such as corner radius, colors and margins are applied via UIAppearance:

YZNotifyHUD *appearance = [YZNotifyHUD appearance];
appearance.textFont = [UIFont yz_regularFontWithFontStyle:YZRetailStyleFontT5];
appearance.bezelCornerRadius = 5;
appearance.bezelViewColor = [[UIColor yz_colorWithStyleName:YZUIStyleColorN8] colorWithAlphaComponent:0.88];
appearance.contentEdgeInsets = UIEdgeInsetsMake(9,12,9,12);
appearance.margin = UIEdgeInsetsMake(40,40,40,40);

3.4 Dynamic Resource Configuration

When different products share the same platform but require distinct primary colors, a “skin” approach is used: product‑specific resource files are externalized, keeping the core library unchanged.

Delivery

Delivered artifacts include:

UI component library (iOS/Android)

API documentation

Design language specification

During integration the ColorStyle API was enhanced to provide both color keys and raw RGB values, simplifying usage for developers.

Results

Reduced color palette from hundreds to ~40.

Developers focus on business logic, accelerating development.

Higher design fidelity and faster designer acceptance.

Consistent UI across multiple apps.

Pitfalls & Lessons Learned

Repeated rework caused by mismatched expectations.

UI standardization is not the same as component creation; over‑exposing configuration breaks the standard.

Close collaboration with design‑language teams is essential.

Incremental delivery and agile practices help gather early feedback.

Component replacement should be carefully planned to avoid massive churn.

Future Work

Planned automation includes design‑to‑code conversion using Sketch sketchtool and custom CocoaScript plugins, as well as dynamic configuration files and broader tool integration.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Mobile DevelopmentiOSAndroidstandardizationComponent LibraryUI designdesign systemSketch
Youzan Coder
Written by

Youzan Coder

Official Youzan tech channel, delivering technical insights and occasional daily updates from the Youzan tech team.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.