01 / Set the framework
Clarify the problem and scope, acceptable cost, and the principal needs and concerns.
DESIGN SYSTEMS & COLLABORATION · SHIMO
Turning design knowledge into shared team assets.
From preserving and evolving design files to maintaining and reviewing components, help a small team support multiple product lines.
- My role
- Design leadership, systems & product experience
- Team
- Led a team of 3–4 designers
The original framework includes the wider management system. This case focuses on assets, delivery standards, libraries and collaboration.
Design asset management
Keep the decisions, not just the screens.
Ideas, research, proposals and review records need to be organized alongside design files, so the team can retrieve the reasoning behind a color choice or a piece of copy.
01
Find the source
Organize files by product and functional module, rather than scattering them across requests.
02
Keep the process
Retain research, proposals and review records with the context behind design choices.
03
Continue the work
Evolve the same assets so new team members can understand and continue the work.
Turn experience into usable guidance.
Some files used screenshots in place of editable source designs, and artboards lacked a consistent structure. I documented a standard process that asks designers and interns to clarify scope, relationships and maintenance when creating files.
This shows the standards cover already included in the original portfolio; the full internal asset directory is not reproduced.
Standardizing design output
Let file structure follow product logic.
Each functional module has one File that continues through later iterations. Work spanning modules updates each source file before being assembled for handoff. Pages distinguish delivery, current and earlier versions, process work and components.
A source file that others can continue to use.
Naming and organization require designers to identify the function they are working on and its relationships to other features. Every handoff retains editable source designs while keeping earlier versions and process work accessible.
Make logic, states and iterations visible.
The original work translates these rules into artboard organization: group screens by logic and state, iterate in version pages, then copy confirmed changes to the handoff page while preserving history and analysis.
Building distributed libraries
Shared rules need room for product differences.
With multiple product lines and limited design resources, a designer may support several products at once. The library needs to maintain shared visual and interaction rules while accommodating each product’s needs.
Understand why designers work around components.
Team discussions identified difficult discovery, unclear naming and rigid layouts. Some designers detached components to fit their work, losing the synchronization that the library was intended to provide.
Six issues from team feedback
- Too many components and colors make selection difficult.
- Some component names are unclear.
- Rigid layouts and margins do not adapt to context.
- Some styles have become outdated.
- The breadth of components and depth of properties need balancing.
- Frequently used product combinations do not all belong in the shared library.
More choices can make selection harder.
The original review describes a menu with 128 color choices. Product-specific combinations also did not all belong in the shared library. I used these findings to clarify ownership boundaries and keep every product variation from expanding the shared library.
The count of 128 comes from the original problem statement; this image shows one palette excerpt.
Shared foundations, product-owned extensions.
The shared library focuses on atomic, molecular and cross-product components. Product libraries maintain their own controls, panels and combinations without redefining shared rules. Components with wider reuse potential enter a pending area, then are reviewed by the team for inclusion in the shared library.
An actionable design decision process
Review the problem, rationale and trade-offs.
Reviews establish a common framework, explore reasoning, then compare and converge on proposals. Each stage has explicit questions, keeping the discussion grounded in the design decision.
02 / Explain the reasoning
Examine the original rationale, explore directions without constraints first, then propose concrete solutions and document their trade-offs.
03 / Converge on a proposal
Remove proposals outside the framework, compare resources and impact, prioritize trade-offs, and select primary and secondary options.
The three stages are organized from the original; each source remains available to view.
Communication within the team
Make discussions clear and easier to respond to.
The team values both the ideas being expressed and how they are communicated. The guidelines emphasize concrete observations, clear scope, concise references and precise terminology, while avoiding rhetorical questions.
- Describe the specific problem rather than relying on vague adjectives.
- Clarify the scope and address one question per paragraph.
- Use references to describe complex objects concisely.
- Avoid technical terms that cannot be defined precisely.
- Do not use rhetorical questions to ask or answer.
Adoption and reflection
Bring standards into recurring work.
I drove the standards overhaul and standardized every control in the Project Sheet product line. The value lies in whether later design and adaptation can build on a common foundation, beyond the number of documents or components.
Project A · before the overhaul
Arabic UI localization
1.5 person-months
Front-end effort included repeated, detail-by-detail UI adjustments to client requirements.
Project B · after standardization
Comparable UI customization
7 person-days
The adaptation used the standardized Project Sheet controls. Company leadership recognized the result.
Projects A and B are anonymized. Labor inputs come from my project retrospective, comparing similar workloads across different projects while retaining the original units.
Leadership and team outcomes
I owned all brand and product experience design at Shimo, leading a team of 3–4 designers. Even with reduced staffing, we delivered design outcomes beyond expectations.
A design system should give the team more room to think.
Assets, standards, libraries and reviews work together to reduce aimless searching and repeated organization, returning attention to ideas, product logic and design judgment.
Continue exploring
AI design thinkingFrom shared design knowledge to working with AI.