Design System: Building a shared design system for Bitcoin education
- Company
Plan ₿ Network- Role
- Senior Product Designer
- Timeline
- 3 months
- Scope
- Design system, navigation patterns
- Status
- Shipped product work
The redesigned course library, showing shared navigation, filters and course cards as a foundation for a unified product experience.
As Plan ₿ Network grew from a course catalogue into an education platform, its interface had to support more roles, journeys and product states. Inconsistent page structures and navigation made the need for shared rules clear. I built a design-system foundation with a clear goal: a coherent, unified experience for teachers, students and course admins. Shared visual rules and interaction patterns will connect all three experiences while supporting the tasks specific to each role.
The system had to support an evolving product and remain practical for a small team to implement. Shared components needed to accommodate different roles, screen sizes and interaction states, while staying aligned with the existing Tailwind frontend.
Start with recurring product needs, define the foundations in a vocabulary shared by design and code, then build components with explicit variants and states. Keep the library small enough to maintain and extend it when a pattern repeats.
One system, three connected experiences
Shared patterns for teaching and course operations.
Clear paths to discover courses and keep learning.
Familiar controls for managing courses and administration.
How I built the system
Collaboration: Founder, CTO, growth, engineering and content stakeholders
- 1
Audited page structures and navigation to identify patterns the system needed to support.
- 2
Defined color, typography and spacing foundations with mappings to frontend tokens.
- 3
Designed reusable navigation, form controls, metadata and learning-feedback components.
- 4
Specified component variants and interaction states to support a unified experience for teachers, students and course admins.
- 5
Documented interaction and content rules to guide consistent implementation.
What informed the direction
An interface audit exposed inconsistent page structures and navigation behaviors that needed shared rules.
Learner, teacher and reviewer workflows supplied the role-specific requirements for component variants.
Course discovery, learning and certification provided concrete uses for filters, metadata, controls and feedback.
The existing Tailwind frontend shaped how color, typography and spacing could map from design to code.
Key decisions
Build the library around recurring product needs
I used navigation and page hierarchy to establish where shared patterns belonged. Headers needed role and viewport variants; course discovery needed repeatable filters and metadata. These product needs gave the component library a concrete scope.
Give design and code the same foundations
I documented color scales, typography and an 8-point spacing system with Tailwind mappings. This gave the team a shared vocabulary for implementing the foundations and making consistent choices across components. The system stayed deliberately small; edge-case components were not promoted until patterns repeated.
Make one system serve every product role
Teachers, students and course admins have distinct tasks, but their experiences should feel like parts of the same platform. I designed shared components with explicit role-based variants, including navigation that adapts to each audience. As the system is applied across these experiences, common visual rules and interaction patterns will keep them coherent and unified while preserving the tools each role needs.
Define behavior alongside appearance
I defined selection, focus and disabled states for controls, and brought labels, helper text and validation together in form compositions. The documentation covered how components behave and combine, giving implementation guidance beyond the default visual state.
From foundations to reusable components
The library connects individual controls to larger product patterns. Forms combine inputs, guidance and validation; navigation adapts to roles and screen sizes; tags and feedback components support learning and certification. The boards below show the variants and states defined for each.
What changed
-
Created a shared foundation of color, typography and spacing with mappings to frontend implementation.
-
Built a component library covering navigation, forms, course metadata, learning feedback and certificates.
-
Documented reusable variants and interaction states across roles and screen sizes.
-
Established common design rules that will unify the teacher, student and course admin experiences as the system is adopted.
What I would carry into the next problem
A component library is a foundation; its value depends on how the team uses it. This work reinforced the importance of grounding components in real product needs, documenting behavior and keeping the scope maintainable. The next step is to evaluate adoption in the frontend, identify where teams still need custom solutions, and measure whether the system makes new work easier to deliver.
