Hi, I’m Jingjing.Product designer / Systems thinker

A systems mind.
An eye for detail.

I design systems and complex B2B products — from global platforms to specialized workflows. I connect shared foundations with thoughtful details that help teams navigate complexity and work effectively.

Selected work01—04

Thinking at scale, down to the details.

01 / DiDi International / Shared foundations pebble.
Design foundations / Component guidance
OverviewFoundationsComponentsInternationalizationAccessibility
Components / Data display

Patterns with purpose.

Foundations, anatomy and behavior — brought together.

Data tablePrimary action
RecordOwnerStatus
[Record 01][Role A]In review
[Record 02][Role B]In review
[Record 03][Role A]Complete
Foundations / Color
[Actual token hierarchy]
01 / DiDi International · Sketch

Pebble design system

A shared foundation with tiered tokens, a documentation website, and internationalization, accessibility and content guidance. Used across all B2B products in three international product lines.

Explore the case study ↗
download
02 / Complex B2B

Redesign of DIVE

Untangling complex business processes and translating them into clear, cohesive workflows.

Read the product story ↗
Light
[Component]
Dark
[Component]
03 / security design systemFigma · Design library

Two themes. A focused library.

A recent Figma component library with light and dark themes, currently used across a smaller product scope.

See the craft supplement ↗
04 / Product Framing

Security Brain AI

Bringing urgent signals, investigation, and resolution into one clear operator journey.

View brief ↗

Across the full lifecycle
of design systems.

Setting direction, shaping the details
helping teams put into practice.

01 / Direction

Choose what to standardize.

Align teams on what should be shared, where flexibility matters, and how the system can support different product needs.

02 / Detail

Make the rules usable.

Translate principles into clear tokens, components, states, and guidance that make implementation consistent and unambiguous.

03 / Adoption

Help teams use the system.

Support teams through documentation, collaboration, and iteration, so the system becomes part of how products are built.

A little about how I think

Big-picture thinking.
Hands-on making.

I start with the goal and work backward—breaking it into practical steps, bringing people together, and anticipating risks with contingencies in place. In design, I care about the reasoning behind each decision, connecting system-level thinking with the details that make an experience work. I value clear, efficient, and transparent communication, so teams can align and move toward a shared outcome.

Experience

China Telecom Cybersecurity · Design Engineer · 2023 till now DiDi · Principal Designer · 2020-2023
Li-Fung · Product Designer · 2019-2020 Oracle · Senior UX Designer · 2016-2019 Hecom · Senior Interaction Designer · 2015-2016 Yonyou · Interaction Designer · 2014-2015

Contact

zjjustb@gmail.com
https://www.linkedin.com/in/joycezhi/

← All selected work
01 / DiDi · Flagship design system

One shared system.
Three product lines.

An end-to-end design system spanning foundations, ways of working, reusable resources, and UX evaluation — creating a shared framework for designing, building, and measuring experiences across three international B2B product lines.

My contributionProject owner, design lead
Team / partners7 Designers, 8 frontend developers
Timeline2020-2023
Tools / reachSketch · System website
3 international product lines
01 / The system in its context

Three product lines.
One end-to-end system.

Pebble was a shared design system spanning Mobility, Food Delivery, and Financial Services. Its scope covered foundations, design methods, reusable design and development resources, documentation, adoption, and UX measurement. It supported two established back-office platforms—Magellan and Gattaran—with nearly 100 products combined, while the Financial Services platform was developed alongside the system from the ground up.

PEBBLE DESIGN SYSTEM Foundations · Methods · Resources · Documentation · Adoption · Evaluation
MobilityMagellan platform with 30+ products
Food deliveryGattaran platform with 50+ products
Financial servicesPlatform/products developed alongside the system

I personally owned

As a project owner, I defined the vision, scope, and roadmap for Pebble; aligned design, product, and engineering teams across three product lines; prioritized shared and product-specific needs; reviewed all the deliverables, and drove the system from foundations and reusable resources through rollout, adoption, and evaluation.

We built together

Two component designers to define the styles and interaction states of the components. Two visual designers to define the visual system (colours, shadows etc.), design the icons, system logo and website cover. Two business designers to collect the requirements from business lines and integrated into the system design and guidelines.

02 / Direction & tradeoffs

A system starts
with choices.

[Explain how priorities were set: why this system, why then, what you standardized first, and what stayed local.]

Standardize first

[Highest-cost shared problem]

[Actual evidence → prioritization reason → expected value.]

Leave room for

[Product-specific decisions]

[What you deliberately did not standardize and why.]

download2
DS-01 / Audit or prioritization
[Before: one shared problem across products]Upload 2–3 comparable examples. Label the inconsistency, user/team cost, and why it mattered.

The decision I stand behind

We considered standardizing every layer across product lines or building a shared core with product-owned extensions. I recommended the latter because it focused investment on repeated, high-cost problems while preserving domain expertise. We accepted slower convergence in business-specific workflows. Evidence: component restyling was estimated to consume nearly 50% of a request’s development cycle, while specialized patterns varied significantly by product line.

03 / Foundations & token hierarchy

One hierarchy.
Multiple product expressions.

Pebble used a three-level token structure—foundation, global, and component—to create a shared design language without forcing every product to look the same. Product variation was handled through theme mappings, while components continued to follow one consistent structure.

System decision

We chose this hierarchy to make variation explicit and change predictable. Foundation tokens held raw scales; global tokens assigned shared roles and theme mappings; component tokens applied those roles to individual controls and states. A change to a shared value propagated through its references, allowing teams to update a theme centrally while preserving consistent component behavior.

Implementation boundary

In Sketch, the design library and token table defined the hierarchy, naming, and intended mappings. Pebble library implemented the corresponding values and component behavior in code. Design and front-end engineering reviewed mappings together, while engineering owned package implementation and releases. This was a coordinated design-to-code contract, not an automated synchronization pipeline.

download3
DS-02 / Actual token structure
[Token map + one real reference chain]Use a legible crop of the actual specification or reconstruct and label it as a retrospective diagram.
04 / One component, examined closely

Standardize the behavior.
Let the content adapt.

The Option list separates selection behavior from item content. The system standardizes focus, states, keyboard interaction, and commit behavior; products define the information users need to compare.

download4
DS-03 / Component anatomy
[Anatomy + states + usage rules]One large component, 3–5 numbered annotations. Explain structure, state behavior, content limits and an implementation decision.
Decision layerShow the ruleShow the consequence
StructureSelection was applied to the shared list-item foundation rather than bound to a fixed option anatomy. The system defined the selectable row, focus boundary, selection control, and optional list regions such as search, grouping, and footer actions. Products composed the item content, while every item within one list followed the same template and alignment. A simple label, an image-supported choice, or an information-rich business object could use the same selection model. Teams could provide the context their users needed without creating a separate dropdown component for every content combination.
Behavior / statesDefault, hover, focus, selected, indeterminate, and disabled states applied to the entire row, regardless of its internal content. The list also defined loading, empty, error, and no-result states. Single-select committed immediately and closed the list. Multi-select maintained a draft selection and used an explicit Done action. When secondary actions were needed, they used defined trailing regions and separate interaction rules, so they did not compete with or accidentally trigger row selection.Users encountered the same selection and keyboard model across products, even when the visible content differed. Richer items did not introduce ambiguous click targets, inconsistent states, or unexpected commit behavior.
Content / i18nThe product template owned its information hierarchy, media, metadata, content density, and wrapping or truncation rules. The system required one consistent template within each list and ensured that selection controls, focus behavior, and interaction priority remained stable. Templates also had to accommodate longer translations and RTL layouts. When content introduced independent actions or required image-first comparison, we switched to a table, card picker, or dedicated browser instead of stretching the Option list beyond its intended role. Products could surface the domain-specific information users needed to make a decision without creating locale-specific or content-specific component variants. The pattern remained adaptable without becoming visually or behaviorally ungoverned.
AccessibilityThe entire item remained one focusable option. Arrow keys moved between options; Enter or Space selected; Escape dismissed the list; and focus returned to the trigger when it closed. Each product template supplied one accessible name—and an optional description—from the minimum information needed to distinguish the option. Decorative or redundant media was hidden from assistive technology. Single-select used a leading checkmark, while multi-select used checked and mixed control marks. These visual cues were paired with programmatic states rather than relying on color alone.Keyboard and screen-reader users could navigate one predictable selection model, even when an item contained rich information. Internal content did not become a collection of separate focus targets or repetitive announcements.

The edge case that changed the design

Single-select options initially relied on the selected-row treatment to indicate the current value. This depended too heavily on color. There were many systems using a checkmark at the end of the list item for single-select. However, adding a checkmark on the right created another problem: that region might already contain metadata, secondary actions, or a child indicator. We thus introduced a reserved leading selection-indicator region. Unselected items kept the space empty, while the active option displayed a checkmark. This preserved content and trailing alignment while making the selected state identifiable without color alone.

05 / Guidance for international products

Turn global constraints
into product rules.

Internationalization

Design for various text lengths.

Longer translations exposed the limits of horizontal labels and fixed positioning. We moved labels above fields, allowed content to grow vertically, and separated actions from variable-length text. The same structure remained readable across languages without creating locale-specific layouts.

Accessibility

Make state legible beyond color.

Focus and selection could not depend on orange alone. We paired color with a visible focus outline and explicit state marks: a leading check for single-select and checked or mixed controls for multi-select. The states remained distinguishable when color was removed.

pebble-global-guidance-applied
DS-04 / Guidance applied
[Guideline excerpt beside its product application]Pair the rule you wrote with a legible example of how the rule affected an interface.

06 / The design system website

A shared front door
for design and development.

I contributed to the information architecture, page design, and guidance content of the Pebble website. We organized it at two levels: an overview that made the scope of the system easy to navigate, and detailed guidance that helped teams apply individual components and patterns. At the overview level, the website connected design principles, methods, reusable resources, development guidance, and measurement. At the detail level, each page translated a resource into actionable guidance through anatomy, usage rules, examples, layout constraints, and links to implementation documentation.

SITE ARCHITECTURE
Principle and methods
Tokens & common styles
Basic components
Advanced components
Page templates
Interaction patterns
EXAMPLE / COMPONENT GUIDANCE

CARD

WHENUse cards to group related information into a single, scannable unit—particularly when items need to be compared or arranged responsively.
HOWThe guidance defined component anatomy, content hierarchy, spacing, image behavior, usage examples, and rules for fixed and adaptive layouts.
CHECKConsider content length, responsive behavior, localization, image alternatives, and relevant accessibility requirements.
OWNERMaintained by the Pebble design-system team, with implementation links and contribution routes for design and engineering teams.
pebble-website-real-screens
DS-05 / Website design & writing
[Website overview + one article you wrote]Show the navigation and a readable content detail. Mark your own page design, writing, and collaboration contribution.

07 / Collaboration & adoption

From shared resources
to shipped products.

Pebble adoption grew through product delivery rather than a one-time handoff. As project owner, I coordinated design, front-end, and product teams to package reusable resources, apply them in Gattaran, measure adoption, and feed product needs back into the system.

PACKAGEBuild a practical starting point. Basic components, Pro Components, page templates, development standards, and guidance gave teams reusable resources at different levels of complexity.
EMBEDApply the system in real delivery. We introduced the system through the Gattaran homepage redesign and Gattaran CRM, using active product work to validate components, patterns, and documentation.
MEASURETrack scope, reach, and depth separately. Within the Gattaran rollout, the basic component library was used in 15 projects and across 52 pages, representing 16.51% page coverage. Adoption reached 100% among newly initiated Gattaran projects; portfolio-wide adoption across all projects reached 50% within three months.
SUSTAINKeep the system connected to teams. Designated system contacts and a user feedback group gave teams a route for questions, requests, and updates. Findings informed continued rollout in Gattaran and future co-creation of React components and best practices.

COLLABORATION MODEL

As project owner, I coordinated the roadmap and priorities across design, front-end, and product contributors. Real product delivery became the review mechanism: recurring needs were turned into shared resources, while implementation feedback informed subsequent iterations.

WHAT THE NUMBERS REVEALED

In the measured Gattaran rollout, 100% of newly initiated projects adopted the basic component library, while it appeared on 16.51% of pages. The gap showed that project-level adoption did not yet equal implementation depth—shaping the next rollout around deeper page coverage, richer reusable patterns, and ongoing team support.

pebble-adoption-evidence
DS-06 / Adoption evidence
[One pattern reused across the three product lines]Three real examples, with shared and local parts labeled. Optional: review note, change notice, or guideline update.
08 / Outcomes & reflection

The system was measured
by what teams shipped.

50%

Portfolio-wide adoption in three months

Half of all projects across the three international product lines had adopted Pebble.

−10%

Average project duration

Average project duration decreased from the 2021 baseline of 65.78 person-days to 59.2 person-days.

EvidenceWhat changedAttribution / limit
Adoption / reachPebble reached 50% of all projects across Mobility, Food, and Finance within three months.This is the portfolio-wide adoption rate. The separate 100% figure refers only to newly initiated Gattaran projects during the measured rollout—not the full project portfolio.
Team / deliveryAverage project duration decreased by 10%, from 65.78 to 59.2 person-days.Measured against the 2021 baseline. Reusable resources and clearer defaults reduced repeated design and implementation decisions, although other delivery changes may also have contributed.
Team confidence
In an internal 1–5 benchmark where Ant Design / Element was anchored at 3, Pebble received a rating of 3.4 from designers and 3.3 from developers.This was an early internal pulse rather than a user-outcome measure. The result should be reported with the respondent count and survey wording if available.
REFLECTION I would keep the co-creation model and the distinction between project reach and page-level depth. What I would change is to treat implementation, rollout, and measurement as part of the system from day one. I would develop the React components alongside the design resources earlier, assign clearer ownership for migration and maintenance, and define metrics for reach, depth, delivery efficiency, and interface quality before launch. I would also complement internal adoption data with direct evidence of consistency and user outcomes. The project taught me that adoption is an early signal, not the finish line. A design system earns trust when it improves both what teams ship and how confidently they can maintain it.

Historical DiDi work was designed in Sketch. It demonstrates architecture, documentation and adoption at scale. The recent Figma library is a separate project demonstrating light/dark component design within a smaller product scope. Retrospective diagrams should be labeled as reconstructions.

Next / Complex product design

Redesign of DIVE

Untangling complex business processes and translating them into clear, cohesive workflows.

↗
← All selected work
02 / Complex B2B · Evolution

A clearer way to manage driver incentive campaigns.

DIVE (Driver Incentive and Value Engine) helps operations teams browse existing campaigns and create new ones. I redesigned the campaign overview and turned complex targeting, conditions, and reward rules into a guided creation flow.

RoleProduct designer · workflow analysis, interaction/UI design
Team / timeline2022 · 1 product manager, 1 designer, 4 engineers
ProductDIVE, an internal tool within DiDi Magellan
ScopeCampaign browsing and details; guided campaign creation
01 / Context & scope

From campaign oversight
to configuration.

Operations teams use it to inspect existing campaigns and configure new ones across markets, product lines, driver groups, and reward types. This case study focuses on two connected tasks: browsing and reviewing campaigns, and creating one through a guided flow.

Set upDefine the campaign type, market, product line, and timing.
Target Select driver groups and any control or experiment groups.
ConfigureSet participation conditions and reward rules.
CompletePrepare messages, review the setup, and submit the campaign.
dive-01-business-workflow
UX-01 / Scope & boundaries
[A local workflow map with product connections]Label user roles, start/end, input/output, dependencies and what was outside your ownership.
02 / Complexity

Make the campaign logic visible.

ComplexityActual constraintDesign implication
Campaign contextCity, product line, scenario, strategy, and driver group could vary by campaign.Keep this context visible as operators move through configuration.
Time and statusCampaigns overlap in time and move through different lifecycle states.Use the calendar for timing, the list for scanning status, and detail views for state-specific actions.
Reward logicDriver groups could have different conditions and reward methods.Group related rules and show the resulting setup where it can be checked.
Existing structureDense tables were hard to scan, while the creation form followed system functions more closely than operator decisions.Reorganize information around the tasks operators need to complete.
dive-02-before-evidence
UX-02 / Before + problem evidence
[The old workflow, with specific friction marked]Show observation, support feedback or research detail. Label hypothesis if not validated.
03 / The decisions that mattered

Three decisions
shaped the redesign.

01
One campaign set, two overview views. Calendar supports scanning timing and overlap; list supports scanning names and status.
Both views need to stay consistent as filters and campaign data change.
02
A persistent five-step creation path. Basic info → Target group → Conditions → Rules → Messages.
t adds navigation, but lets operators focus on one group of decisions at a time while retaining campaign context.
03
Detail organized around lifecycle state. Campaign information, driver groups, messages, reward preview, and available actions sit together.
More states require more design specifications, but operators see information and actions relevant to the current state.
dive-03-design-decisions
UX-03 / After + interaction detail
[Final workflow with numbered callouts]Pair each callout with one of the three decisions. Include one exception or recovery state.
04 / Review & learning

Positive feedback, with clear next questions.

Early feedback

PM, developers, and internal users responded positively to the redesigned interface and shared design patterns. Their feedback supported the design direction. The task efficiency improved roughly 28.3% in the user test and error reduction reduced by 38.4%.

Design outcome

The final design connected calendar and list views of the same campaigns with a five-step creation flow. It brought target groups, conditions, incentive rules, and messages into a guided process, with campaign details and available actions changing by role and status.

What remained unresolved

The redesign focused on DIVE’s campaign workflow. With limited time and visibility into other Magellan modules, how these patterns should work across the wider platform remained an open question. The related workflows should also be reviewed to identify which patterns should become shared standards.

PRODUCT DESIGN / SECURITY OPERATIONS

Security Brain AI

Bringing urgent signals, investigation, and resolution into one clear operator journey.

↗
← All selected work
03 / SECURITY DESIGN SYSTEM · FIGMA

A quieter foundation for critical signals.

For Security Brain AI, I led a Figma design system built around restrained neutrals, so severity, alerts, and feedback could carry clear meaning across light and dark themes.

My roleDesign system owner · end to end
ScopeSecurity Brain AI · used in product design
ToolFigma variables and components
StatusProduct developed · coded component library not yet built
01 / Structure

Give color a clear job.

The existing admin design system used accent colors for many general interface elements. In security workflows, those colors competed with the signals needed to distinguish severity and alerts. I built a restrained neutral foundation, then mapped primitive colors to semantic roles in Figma. Light and Dark modes give each role its own value; components and templates reuse those roles rather than choosing colors screen by screen.

security-system-structure-with-handoff
FG-01 / Figma implementation
[Actual library structure / properties / theme setup]Use a readable screenshot of the relevant Figma setup. Make the mechanism and your decisions visible.
02 / Visual and component detail

Keep severity clear
in both themes.

security-event-table-light
FG-02 / Light
[Real light-theme example]Match component, content and state to the dark example.
security-event-table-dark
FG-03 / Dark
[Real dark-theme example]Annotate hierarchy, borders, semantic color and state choices.

Keeping severity meaningful across themes

In a dense event table, color should answer one question first: how urgent is the alert? I used neutral rows and labeled severity badges so unrelated UI accents would not compete with the risk signal. In Figma, each severity level has separate background, text, and border values for Light and Dark. Critical, for example, changes from pale red with dark text to deep red with light text. Its meaning remains clear across both themes.

03 / Scope & learning

From design use
to code implementation.

What exists today

I own the Figma system end to end: foundations, Light/Dark semantic variables, atomic and composite components, templates, iconography, and a changelog. The library has been used in the design of Security Brain AI, and the product itself has been developed.

What comes next

The component library has not yet been built as reusable code. I would work with engineers to map semantic variables to code tokens, define component APIs and states, and verify theme and severity behavior in the product. A shared release and maintenance process would make future updates easier to adopt.

Flagship / System at scale

One shared system. Three product lines.

Architecture, documentation and adoption in context.

↗
← All selected work
04 / PRODUCT DESIGN · SECURITY OPERATIONS

Make incident response the starting point.

In early interviews, security operators described moving among asset, alert, and incident lists to find a problem and decide what to do next. For Security Brain AI, I proposed which existing backend capabilities to bring into the AI platform, aligned the scope with the PM and Tech Lead, and designed a clearer incident path from urgency to resolution.

RoleProduct design owner · scope proposals, IA, key workflows, and UI
COLLABORATIONPM · Tech Lead · Engineering
StageDeveloped product · outcome validation pending
EvidenceOperator interviews · IA exploration · product design screens
01 / Framing

From resource lists to the operator’s next step.

An early navigation option carried familiar backend categories into the AI platform. Operator interviews exposed its limitation: people could find assets, alerts, and incidents, but still had to assemble the response path themselves. I proposed an entry view focused on urgent work and a dedicated incident journey, then worked through the feature boundaries with the PM and Tech Lead.

First workflow focus

A situational overview of alert severity, open incidents, and SLA urgency; an incident case bringing stages, activity, linked alerts, affected assets, recommendations, operator actions, and closure together.

Explored for later scope

Dedicated asset and tenant navigation, a compliance center, and deeper agent autonomy remained broader platform directions.

02 / First complete journey

One incident,
from first signal to closure.

security-brain-ai-portfolio-combined
Z-01 / First-release journey
[Three to five screens, one end-to-end task]Show onboarding/input → core action → meaningful output. Include a key failure state.

Make the AI-to-operator handoff explicit

Agent activity and operator actions use distinct markers in the incident timeline, making the source of each step visible. The agent’s recommendation appears at the point of action, while the operator explicitly decides whether to apply it. After resolution, action controls disappear and the timeline becomes a read-only record.