By the end of this lesson you can
- Identify the core components most products need.
- Design components that are flexible but consistent.
- Prioritise which components to build first.
The idea
Most interfaces are built from a surprisingly small set of components. A typical core set includes:
- Actions: buttons, links, icon buttons.
- Inputs: text fields, text areas, selects, checkboxes, radios, toggles, date pickers.
- Navigation: header, tabs, side navigation, breadcrumbs, pagination.
- Feedback: alerts, banners, toasts, inline errors, progress indicators.
- Containers: cards, modals, sheets, accordions.
- Data display: lists, tables, tags, avatars, badges.
What makes a good component
It solves one job well, has clear options (variants and properties) for real needs, handles long and missing content, includes all states and is accessible. It should be flexible enough to reuse but not so flexible that every use looks different.
Build in order of use
Audit existing screens and count how often each element appears. Start with the most used and most inconsistent components, usually buttons, inputs and typography, then expand.
Why it matters in real projects
A solid core set covers most screens and makes design and development much faster. Focusing first on the components used everywhere gives the biggest gain in consistency and quality with the least effort. Knowing the core set also helps you read any product quickly.
A realistic example
A small startup wants a design system but has limited time. The designer audits 40 screens and finds 11 button styles, 6 input styles and 4 kinds of alert, while date pickers appear only twice.
They build buttons, text inputs, selects, checkboxes, alerts and cards first, with all states. Within a month these cover about 80% of interface elements on new screens. Date pickers wait until a feature needs them.
Step by step
Audit screens
Screenshot every unique button, input, alert and so on.
Count and group
Group similar elements and count variants.
Prioritise
Rank by frequency and inconsistency.
Define each component
Write its job, options, states and content rules.
Build and test
Build the component and test it with real content.
Replace old versions
Swap old elements for the new component.
Common mistakes
Mistake Building rare components first.
Instead Start with the most used ones.
Mistake Endless options for every edge case.
Instead Support real needs; say no to one-offs.
Mistake Testing only with short sample text.
Instead Test with long, missing and translated content.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h
Component audit
Audit an existing app or website and plan a core component set.
Steps
- Screenshot all buttons, inputs, alerts and cards on 10 screens.
- Group and count the variations.
- Prioritise the five components to build first.
- Write a one-paragraph definition for each.
Deliverable
An audit board and a prioritised component list.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- A small set of components builds most interfaces.
- Good components do one job, handle content and include all states.
- Audit and prioritise by frequency.
- Avoid options for one-off cases.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
Your notes
Marking complete updates your course and roadmap progress.