Overview
- The problem
- Saphyte and E-Afghans need reusable interface foundations without losing their own brand expression or the meaning of component states.
- My contribution
- I created and adapted the complete shared library, including brand tokens, typography choices, component families, product-specific examples, and usage documentation, with Chakra UI as the underlying foundation.
- The outcome
- A Figma library that connects global and semantic colors, size and typography tokens, configurable components, branded examples, and documented usage patterns.
Problem
The source library includes global and semantic tokens, typography and size choices, component states, branded examples, and usage guidance. It documents the system I created and adapted, not authorship of Chakra UI.
My Role
- Company / product context
- Saphyte · Saphyte & E-Afghans shared design system
- Users
- Designers and engineers working on Saphyte and E-Afghans product interfaces, and the people who use their forms and actions.
- My role & scope
- I created and adapted the complete shared library, including brand tokens, typography choices, component families, product-specific examples, and usage documentation, with Chakra UI as the underlying foundation.
- Evidence available
- Original library exports and public documentation. The source Figma library remains private.
Process
Brand examples and component configurations make alternative appearances and states inspectable. The archive does not include a chronological test log or a measured comparison of separate libraries against the shared approach.
A shared foundation with room for identity
I organized the library around Global Color, Semantic Color, Size, and Typography collections. Light and dark semantic modes resolve shared roles to different foundation values. Brand-specific roles then connect those foundations to Saphyte and E-Afghan components.
The source contains a Saphyte palette and three E-Afghan palette families. The reviewed solid buttons use brand/saphyte/solid and brand/eafghan-1/solid for their fills, with matching contrast roles for their labels. Their shared structure coexists with product-specific color and corner-token choices.
Source fill relationship in the reviewed solid buttons| Product | Component fill role | Global primitive |
|---|
| Saphyte | brand/saphyte/solid | brand/saphyte/600 |
|---|
| E-Afghans | brand/eafghan-1/solid | brand/eafghan-1/600 |
|---|
These solid roles resolve to the same listed primitive in both source color modes. Other roles, such as foreground and subtle surfaces, change their referenced shade between light and dark.
Source typography modes| Mode | Heading family | Body family |
|---|
| Inter | Inter | Inter |
|---|
| Geist | Geist | Geist |
|---|
| Eafghans | NewsReader | Inter |
|---|
Typography is also configurable: the source has Inter, Geist, and Eafghans modes. The Eafghans mode assigns NewsReader to headings and Inter to body text. These are explicit design-variable choices, not a claim that application code automatically changes fonts or synchronizes every token.
Exact source component exports at native size. The control selects a design state; it does not run the source button.The same medium solid-button structure with the E-Afghan brand role and corner choice.Key Decisions
A shared foundation needs room for two identities without changing the meaning of controls. Chakra UI supplies the underlying foundation; the authored work connects brand tokens, components, product examples, and guidance. Accessibility remains an implementation responsibility as well as a design consideration.
Key design decisions
Keep shared roles separate from brand values
Global palettes supply semantic roles, while Saphyte and E-Afghan palettes and typography choices preserve product identity. Reuse does not require every product to look identical.
Trace the source relationshipsModel content and behavior together
Buttons and inputs expose sizes, visual variants, interaction states, labels, helpers, and optional content. The component model describes more than a resting appearance.
Inspect the original examplesDocument choices, not only parts
Action hierarchy, field usage, and upload contexts sit alongside the components. Their usefulness depends on staying aligned with the evolving source model.
Explore the usage guidance
Final Solution
The final library connects tokens to configurable actions, forms, branded compositions, and usage documentation. Product links show where the system meets actual design tasks.
Behavior belongs in the component model
The Button family supports Solid, Subtle, Surface, Outline, Ghost, and Plain styles, seven sizes, optional leading/trailing icons, and editable labels. Product palettes sit alongside neutral and semantic choices rather than being hard-coded into separate unrelated button designs.
The source makes the available styles and their intended hierarchy visible.The current component model includes Default, Hover, and Disabled state options. However, not every palette/state combination is present in the reviewed set. A state property alone should not be read as proof of a complete combinatorial matrix.
Inputs combine visual variants and sizes with default, focus, and disabled states, invalid and filled flags, optional labels/helpers, and left or right content. Those options allow the same family to support a simple field, an error explanation, or a context-specific addon.
Original state examples connect field appearance to feedback and entered content.The source treats label, helper, error, and addon content as parts of the field pattern. This gives a designer a place to explain what is expected and what needs correction, rather than relying only on an outline color.
Usage examples show how the component participates in a larger task.FileUpload extends the same idea to a different input task. The library includes Button, Dropzone, Input, Clearable, and Paste forms. Its documentation distinguishes a small secondary upload action from a prominent document-import task and from a file field embedded in a longer form.
Five documented interaction surfaces, with selection context kept explicit.The source explicitly separates the selection surface from upload logic. It documents accepted-format hints, selection feedback, validation, and keyboard access as implementation expectations; it does not establish that a production upload service or accessibility audit has been completed.
Guidance is part of the deliverable
I included component documentation for action hierarchy, size choices, semantic versus categorical color use, icon slots, form states, upload contexts, and interaction expectations. The aim is to help someone choose the appropriate pattern, not merely locate a component with the right name.
Guidance records what an implementation needs to consider; it is not verification of those behaviors.The library also shows why maintenance matters. Button documentation describes two static states while the current model includes Disabled. The documentation’s palette inventory differs from the current set, and InputElement guidance lists four types while the component also offers a Forgot password type.
I would treat those differences as a reconciliation task: review the component model and examples together, update usage guidance, and check interaction requirements against the implementation. Documentation should describe the current library, not preserve an older snapshot as an unquestioned rule.
Connect the system to product work
The same design practice extends into my E-Afghan work: a public service-discovery experience and an account-based citizen workspace. Those case studies make the product questions visible alongside this library’s foundation and component decisions.
The shared library’s E-Afghan palettes, typography mode, and branded input/button examples provide the system context. The links below show the product work; they do not by themselves prove instance adoption, production-code parity, or measured efficiency.
Outcomes
The deliverable is the complete adapted design library and its guidance. No adoption total, accessibility certification, production-code parity, or efficiency uplift is claimed.
Evidence & limitations
This case documents my design-system work, not authorship of Chakra UI itself. Source examples, labels, dates, and values are design content. Adoption, shipped-code parity, accessibility conformance, research results, and measured impact have not been established here.
Design coverage is not evidence of consistent product implementation or verified accessibility.
What I would validate next
- Token and component behavior across product palettes and light/dark modes.
- Gaps in valid state, size, palette, and content combinations.
- Keyboard, focus, contrast, and target-sizing behavior in the implementation.
- Whether designers can select the right form or upload pattern from the guidance.
- Actual library use, detachment, code divergence, and the effort required to evolve a shared pattern.
Learnings
- What worked in the design
- Brand identity and component behavior are described at different levels of the system.
- What I would change next
- Review components in real Saphyte and E-Afghans workflows, document exceptions, and test the implemented themes with keyboard and assistive technology.
Delivery and reflection
The delivered design library combines a credited framework foundation with product-specific identity, component behavior, and documentation. My contribution spans that adaptation, not a claim to have invented the underlying Chakra UI framework.
- Shared semantic roles can support distinct product identities.
- Reusable components need content and state models, not only visual variants.
- Usage examples should explain the task and the trade-off behind a choice.
- Documentation and component coverage need to evolve together.
