Role | Product Designer — Design System |
Duration | 6 weeks |
Platform | Web and mobile |
Team | Product, engineering, and design |
Scope | Audit, foundations, tokens, reusable components, documentation, and adoption |
Tools | Figma and FigJam |
HMDS was not a component library exercise. It was a product infrastructure project: turning repeated interface decisions into a shared system that teams could trust.
Designing the shared foundation that helped Hello Mentor scale product quality
Hello Mentor was expanding across web and mobile with new dashboards, onboarding flows, mock tests, counselling journeys, AI interactions, and internal tools. Each release solved real user problems, but it also introduced new interface decisions.
As the product grew, those decisions became harder to keep consistent. Similar interactions were being designed in different ways, component behavior varied across surfaces, and designers and engineers were spending time interpreting patterns that should have already been shared.
I initiated HMDS — the Hello Mentor Design System — to create a reusable foundation for product teams. My goal was not to redesign the product visually. It was to redesign how product design decisions were made, documented, reused, and handed off.
My role
I led the design system work from discovery to first release. I audited existing product surfaces, identified repeated patterns, defined the system architecture, created the first set of foundations and components, documented usage guidance, and aligned decisions with product and engineering needs.
Because this was a scaling product environment, I had to balance consistency with flexibility. The system needed to reduce ambiguity without slowing teams down or over-standardizing product-specific workflows.
The problem
The product was scaling faster than the interface language
Hello Mentor had reached a point where consistency could no longer depend on individual designers remembering previous decisions. The product needed a shared source of truth for common UI patterns, states, spacing, typography, color usage, and interaction behavior.
The issue was not that the product looked broken. The issue was that repeated decisions had no reusable foundation. Every new feature carried the risk of adding more design debt.
The design debt showed up in four places
Product: similar flows used slightly different interaction patterns.
Design: common UI elements were recreated instead of reused.
Engineering: implementation depended on interpreting inconsistent specifications.
User experience: visual and behavioral details drifted between web and mobile surfaces.
The opportunity was not to make the interface prettier. It was to make product decisions easier to repeat, understand, and scale.
The audit
I looked for repeated decisions, not just repeated UI
I reviewed product experiences across dashboards, onboarding, mock tests, counselling flows, profile management, AI interactions, and supporting tools. Instead of judging screens one by one, I mapped recurring decisions across the product.
This helped move the work away from surface-level inconsistency and toward the root problem: teams were repeatedly solving the same design decisions without a shared language.
What I evaluated
Frequency — did the pattern appear across multiple product areas?
Consistency — was the same problem being solved in different ways?
Scalability — would solving this once reduce future effort?
Reusability — could another designer use this without redesigning it?
Implementation clarity — would this reduce ambiguity for engineering?
The audit showed that HMDS did not need to start as a large library. It needed to start with the decisions teams used every day.
Prioritizing the first release
Not every pattern deserved a component
One of the most important decisions was choosing what not to include. A design system can become heavy quickly if every product-specific variation becomes a reusable component.
I prioritized foundations and high-frequency patterns first, then intentionally deferred complex product-specific components until real usage made their requirements clearer.
The first version focused on adoption
Foundations before complex components.
Semantic naming before visual naming.
Useful documentation before exhaustive documentation.
Configurable variants before duplicated components.
Design-engineering clarity before visual completeness.
A successful design system is not measured by how many components it contains. It is measured by how much ambiguity it removes.
System foundations
Creating a single source of truth
Before building components, I defined the foundations those components would depend on. Colors, typography, spacing, radius, elevation, and interaction decisions were organized into reusable layers instead of being applied directly to individual components.
This separation helped the system express intent rather than implementation. For example, a primary action did not reference a raw blue value; it referenced the semantic role of a primary action. That made future theming, maintenance, and product expansion easier.
The foundation included
Primitive values for base colors, type scales, spacing, radius, and elevation.
Semantic tokens for product roles such as surface, text, border, accent, feedback, and action states.
Component-level decisions for buttons, inputs, cards, feedback, and navigation patterns.
State definitions for hover, focus, disabled, loading, selected, error, and success behavior.
Naming conventions that designers and engineers could understand consistently.
Supporting multiple experiences
Hello Mentor served different product experiences across web and mobile, so HMDS needed to support consistency without forcing every interface to look identical. The token architecture allowed shared components to inherit the same foundation while still adapting to different contexts.
This made the system maintainable: product teams could extend the experience without breaking the underlying language.
Component system
Components were the outcome of repeated decisions
Once the foundations were clear, I translated the most repeated decisions into reusable components. I focused on patterns that appeared often, affected user interaction, or created frequent handoff ambiguity.
Examples of component decisions
Buttons — hierarchy, size, icon placement, loading, disabled, hover, and focus states.
Forms and inputs — labels, helper text, error messaging, validation states, and spacing rules.
Cards — content hierarchy, actions, metadata, spacing, and responsive behavior.
Feedback patterns — success, error, warning, empty, and loading states.
Navigation patterns — predictable structure for repeated product areas across web and mobile.
Each component was designed with anatomy, variants, states, and usage guidance. Instead of creating separate components for every scenario, I used properties and variants to make components configurable while keeping their behavior predictable.
Anatomy came before variants
Before defining visual variations, I broke each component into its core anatomy: container, label, icon, supporting text, state indicator, interaction area, and spacing rules. This created consistency before customization.
That structure helped designers understand how to use each component and helped engineers understand which parts were fixed, which parts were configurable, and which states needed implementation support.
A component is not reusable because it exists. It is reusable because everyone understands when, why, and how to use it.
Documentation and adoption
Documentation was treated as part of the product
For HMDS to work, components needed more than polished visuals. They needed guidance. I documented usage rules, variant behavior, state expectations, naming logic, and when not to use a component.
This reduced the need for repeated explanations during handoff and gave designers a clearer starting point when creating new product experiences.
The system became a starting point for new interfaces
HMDS began supporting new product work across dashboards, onboarding, AI tools, mock tests, and counselling workflows. Instead of beginning from blank screens or copying previous files, teams could start from shared foundations and adapt them to the specific product context.
Impact
The first release of HMDS created a shared language for product design and implementation. It helped teams move from one-off interface decisions to reusable standards that could scale with the product.
What improved
Designers had clearer starting points for new product surfaces.
Common UI patterns became easier to reuse instead of recreate.
Design reviews could focus more on product behavior and less on repeated visual decisions.
Engineering handoff became clearer because states, naming, and component behavior were documented.
The product had a stronger foundation for future features, themes, and platform expansion.
Even without treating HMDS as a finished system, the first release reduced ambiguity and gave Hello Mentor a foundation that could continue evolving with the product.
Tradeoffs and reflection
Biggest challenge
The biggest challenge was deciding what should become part of the system and what should remain flexible. Standardizing too little would not solve the problem. Standardizing too much would slow teams down and make the system feel restrictive.
Hardest decision
The hardest decision was resisting the urge to build everything upfront. I chose to focus on foundations, naming, high-frequency patterns, and documentation first so HMDS could become useful quickly and evolve through real product usage.
What I would improve next
If I were starting again, I would involve engineering even earlier in defining token names, component APIs, and documentation structure. The system was designed with implementation in mind, but earlier technical collaboration would have made adoption even smoother.
Next version
The next evolution of HMDS is focused on adoption rather than expansion.
As more Hello Mentor products are designed, the priority is to validate the system through real product usage, strengthen documentation, introduce contribution workflows, connect tokens more closely with engineering, and continuously refine components based on actual product needs rather than assumptions.
This is where the project stands today.
Final reflection
Building HMDS changed how I think about product design.
I started this project believing a design system was a collection of reusable components. I finished it realizing it is actually a framework for making consistent decisions. Components, tokens, and documentation are only valuable because they help teams solve familiar problems in familiar ways.
That shift — from designing interfaces to designing systems — is the biggest lesson I will carry into every product I build.
Building HMDS taught me that consistency is not created by reusable components alone. It is created by reusable decisions that product teams can understand, trust, and extend.
