AMDE 355 · Advanced Web Design · Week 07
Design Systems & Reusable Components.
Move from styling individual pages to building a visual system. This week, you’ll define reusable design tokens, create consistent interface components, and use variants and states to make a design easier to maintain as it grows.
01 / What is a design system?
A design system is a shared set of visual rules, reusable interface patterns, and guidance for using them. It helps a website feel coherent across pages while making future changes more efficient.
Foundations
Color, typography, spacing, borders, shadows, and layout rules establish the visual language.
Components
Buttons, cards, navigation, form controls, and other repeated patterns turn the foundations into interface elements.
Guidelines
Usage rules explain when a component belongs, how it behaves, and which variations are appropriate.
02 / Create design tokens
Tokens are named values for decisions you repeat. CSS custom properties make these values easier to reuse and revise without hunting through every selector.
03 / Build a reusable component
A component packages a repeated pattern into a named rule. Start with a basic card and make its structure and spacing consistent before adding variations.
One base component
Define the shared structure, spacing, border, and type treatment.
Meaningful variants
Add a variant only when the difference has a clear purpose, such as featured, compact, or muted.
Predictable states
Consider default, hover, focus, active, disabled, or error states when the component needs them.
04 / Variants and interaction states
Variants communicate a meaningful difference in role. States communicate what is happening during an interaction. Keep both consistent and make keyboard focus visible.
05 / In-class assignment — build a mini design system
Use the visual direction and composition developed in Weeks 4–6. Create a small system that could support a consistent portfolio or project website.
Define your foundations
Create tokens for at least three colors, three spacing values, a type scale, and one border radius.
Build three components
Create a navigation or link style, a button, and a project card using your shared tokens.
Add a useful variation
Give one component a purposeful variant and define its hover and keyboard-focus behavior.
Test consistency
Place the components together on one page. Check spacing, type, contrast, and responsive behavior.
06 / Critique & self-check
Consistency
Do the components look like members of the same visual family?
Reuse
Can a shared token change a value across multiple components?
Usability
Are interactive states visible, understandable, and keyboard accessible?
- Color, spacing, typography, and shape tokens are defined.
- At least three components use the shared system.
- A variant has a clear purpose rather than being decorative only.
- Hover and keyboard-focus states are visibly defined.
- Text and interface contrast are checked.
- The components remain coherent at smaller screen widths.
Instructor-only material · Remove before publishing to students
Instructor Layout Code — Step by Step
This is a live-coding walkthrough, not just a discussion guide. Build the system from a blank file, explain each decision, and show how one token change updates multiple components. The examples below are deliberately complete enough to type, test, and modify during class.
Step 1 — Build the HTML structure
Start with a small project listing. Point out that the HTML describes content and meaning; the CSS will define the reusable visual system.
Ask students: Which parts of this HTML repeat? Which class names suggest a reusable component, and which describe a specific page section?
Step 2 — Define the design tokens
Add the tokens before styling individual components. Explain that the names communicate intent; --space-large is easier to understand than remembering the same raw pixel value in multiple places.
Live test: change --color-accent to a different color. Later, apply that token to a badge, button, and featured card so students can see how one value coordinates multiple parts of the interface.
Step 3 — Apply the system-wide base styles
Use a small number of base rules for typography, page width, and predictable box sizing. Avoid repeating these values inside every component.
Step 4 — Build the navigation and button components
Style the shared structure first. Then use modifier classes for variants. The double-hyphen naming pattern is a common convention: .button--primary is a variation of .button, not a separate unrelated component.
Demonstrate: switch the HTML class from button--primary to button--secondary. The element keeps the base button behavior while changing only the intended variant styling.
Step 5 — Create the project card and its featured variant
Show how one base component can support multiple pieces of content. The featured card changes its visual emphasis but still uses the same component rules.
Step 6 — Add responsive behavior and accessibility checks
Test the layout at narrower widths. Components should adapt without losing their hierarchy or making navigation difficult to use.
Step 7 — Run a system audit
- Change a token and confirm more than one component updates.
- Confirm every button has a clear purpose and a visible focus indicator.
- Check the featured card: it should be different for a reason, not just different.
- Test navigation with a keyboard and check the order of focus.
- Resize the browser to mobile width and inspect wrapping, spacing, and overflow.
- Check text/background contrast and verify the page remains usable with reduced motion.