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.
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;
@endThe 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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Youzan Coder
Official Youzan tech channel, delivering technical insights and occasional daily updates from the Youzan tech team.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
