04 / Design Systems & Collaboration
Turning design knowledge into shared team assets.
Supporting multiple product lines calls for standards that accommodate both shared patterns and distinct needs. I organized design assets through layered component libraries, documentation, and review practices so they could be found, maintained, and reused.
Explore the systemFind
Design indexes & documentation
Reuse
Shared foundations & product libraries
Continue
Review decisions & delivery standards
Case synthesis based on the original work breakdown.
01 — Knowledge & retrieval
Make design knowledge retrievable.
Teams need access to research, proposals, and review decisions as well as final screens. I organized these materials through design indexes and document categories, creating a retrievable record of the work.
Business / need
Start with the question.
Design index
Locate the relevant proposal.
Proposal & record
Read the decisions behind the screen.
Research
Questions & observations
Proposals
Explorations & rationale
Reviews
Trade-offs & next steps
Delivery
Scope & usage notes
02 — Shared rules, distinct needs
Separate the foundations from the variations.
I separated shared foundations from product-specific libraries. The shared library maintains basic and cross-product patterns; product libraries hold specialized controls, panels, and compositions. Components with broader reuse potential can be reviewed for inclusion in the shared library.
Shared library
Basic components & cross-product patterns
Document library
Specialized controls, panels & compositions
Sheet library
Specialized controls, panels & compositions
Other product libraries
Specialized controls, panels & compositions
Product compositions
Use shared rules, retain the context of each product.
Let product needs remain specific.
Product designers maintain specialized controls, panels, and combinations. Shared rules are inherited; components with broader value can be proposed for the shared library.
The original library structure
Shared and product libraries, linked through review.
Product examples from the original form design; shown to illustrate controls and compositions.
Consistency depends on clear ownership boundaries.
Placing every variation in the shared library weakens its stability, while isolated copies make knowledge harder to share.
03 — A review that moves work forward
Make reviews about explicit trade-offs.
Reviews begin with the problem, scope, and acceptable cost, then examine the rationale and compare trade-offs. Communication guidelines emphasize concrete observations, a clear scope, and precise language, helping discussion lead to action.
- I
Set the frame
What are we solving?
- Clarify the problem and scope.
- Establish acceptable cost.
- Identify the main needs and concerns.
- II
Explain the rationale
Why this direction?
- Explain the existing proposal.
- Explore possibilities, then form proposals.
- Record the trade-offs.
- III
Converge on a proposal
What do we do next?
- Remove options outside the frame.
- Compare resources and impact.
- Choose primary and secondary options.
Reorganized from Frame 28. Shift the discussion toward the problem a proposal solves and the cost it carries.
04 — A record others can continue
Preserve context in the handoff.
Asset organization, documentation standards, and review practices work together. They help people retrieve earlier decisions, understand component boundaries, and use that knowledge in new work.
- 01
Problem record
What needs to change
- 02
Design proposal
The direction and its rationale
- 03
Review record
The decisions and trade-offs
- 04
Component / delivery
The scope and usage context
The file should explain the work.
Documentation and a clear organization help the next reader understand where a proposal belongs and how it relates to the rest of the product.
05 — Deliverables & reflection
Build something the team can carry forward.
The work established an asset organization structure, layered libraries and a contribution review process, with shared delivery and review standards. My focus extended beyond individual components to whether the team could understand, maintain, and continue using them.
Make repeated adaptation follow shared standards.
Before I introduced the new design standards, front-end engineers on Project A spent substantial time adjusting individual UI details to client requirements for Arabic localization. I drove the standards overhaul and standardized all controls in the Project Sheet product line; Project B then handled comparable customization work with a much smaller labor input.
Arabic UI localization
1.5person-monthsFront-end effort included repeated, detail-by-detail UI adjustments to client requirements.
Comparable UI customization
7person-daysThe work followed the standardized Project Sheet controls. Company leadership recognized the result.
Maintain output with a smaller team.
Alongside the standards work, we reduced the number of design-review meetings by 30%, with fewer staff and the same design-output requirements, improving team communication efficiency.
DESIGN DELIVERABLES
- Asset indexes & document organization
- Layered libraries & contribution review
- Review & delivery standards
Continue exploring
AI design thinkingFrom shared design knowledge to working with AI.
Back to selected work