Lesson 07B / Interface Design
UI Patterns And Affordances
Choose familiar interface patterns and make controls visually, semantically, and behaviorally understandable.
Course Role
Studio Support
Best during work sessions, critique, debugging, project planning, or final polish.
Teacher Notes / In-Class Use
Demo Live
- Compare two controls that look similar but behave differently, such as a link and a button.
- Audit one project screen for affordance, signifier, feedback, and semantic markup.
Try In Class
- Have students inventory the interactive patterns on one current project screen.
- Ask students to fix one confusing pattern and add missing focus or feedback states.
Submit Or Check
- Every control should have a clear purpose, semantic element, label, and visible state.
- Students should be able to explain why a pattern fits the task.
Watch For
- Clickable-looking elements that are not keyboard accessible.
- Buttons used for navigation or links used for actions without a deliberate reason.
Learning Goals
- Identify common UI patterns and the user problems they solve.
- Choose patterns based on task needs instead of visual preference alone.
- Design affordances that communicate what is clickable, editable, expandable, or selected.
- Check patterns for keyboard access, state clarity, and responsive behavior.
Interactive Demo
How to use this demo.
Use the demo as a small lab. Change one thing, observe the result, then connect it back to your own project.
What To Try
- Choose a user need such as navigating, filtering, revealing content, or comparing items.
- Compare the recommended pattern, preview, semantic HTML, and checklist.
What Changes
- The suggested pattern changes based on what the user is trying to do.
- The code sample shifts between links, buttons, forms, details, radios, checkboxes, and card lists.
What To Notice
- Visual style comes after the semantic choice.
- Each pattern needs visible states and accessibility checks.
Apply It
- Audit one control in your project and confirm the pattern matches the task.
Interactive Demo
UI Pattern Selector
Choose what the user needs to do and compare the pattern, semantic element, states, and accessibility checks.
Action
Button
Use a button when the user triggers an action on the current page.
Checks
<button type="button">Save project</button> This demo uses extra JavaScript for teaching. The code sample shows the pattern to practice. View full demo source.
Patterns Are Promises
A UI pattern sets an expectation. A button promises an action. A link promises navigation. A tab promises a switch between related panels. A filter promises that the visible list will change.
When a pattern looks familiar but behaves differently, users have to slow down. Good interface design uses familiar patterns where they help and only breaks expectations for a clear reason.
Affordance, Signifier, Feedback
| Concept | Meaning | Example |
|---|---|---|
| Affordance | What an element can do. | A button can be pressed. |
| Signifier | The visible clue that tells the user what can happen. | Button shape, label, icon, hover state, or underline. |
| Feedback | The response after the user acts. | Pressed state, loading message, error, success, or changed content. |
Common Patterns And When To Use Them
| Pattern | Use It For | Watch For |
|---|---|---|
| Button | Triggering an action on the current page. | Do not use a button for normal navigation unless JavaScript behavior requires it. |
| Link | Moving to another page, section, document, or external resource. | Make link text meaningful out of context. |
| Card | Grouping repeated content that can be scanned. | Do not make the whole card clickable if internal controls also need clicks. |
| Tabs | Switching between related panels at the same level. | Do not use tabs as primary site navigation without a reason. |
| Accordion | Progressive disclosure for optional supporting content. | Keep essential content visible. |
| Modal | Focused interruption for a short task or confirmation. | Provide close controls, focus management, and escape paths. |
| Filter | Narrowing a collection while staying in context. | Show selected filters and a way to clear them. |
| Search | Finding a known or likely item. | Provide useful empty and no-results states. |
| Stepper | Breaking a complex task into ordered steps. | Show progress and preserve entered information. |
Pattern Selection Questions
- What task is the user trying to complete?
- Is the user navigating, changing state, entering data, choosing options, or reviewing information?
- Does the pattern need to work with keyboard only?
- What feedback should appear after the action?
- What happens when the content is empty, long, loading, or invalid?
- Will the pattern still make sense on a small screen?
- Is there a simpler pattern that solves the same problem?
States Every Pattern Needs
| Element | Minimum States |
|---|---|
| Button | Default, hover, focus, active, loading, disabled. |
| Link | Default, hover, focus, visited or current when useful. |
| Input | Default, focus, filled, required, error, disabled. |
| Card | Default, hover or focus when clickable, selected when applicable. |
| Menu | Closed, open, current item, focus, empty or unavailable items. |
| Filter | Unselected, selected, changed results, no results, cleared. |
Semantic Pattern Choices
Visual similarity does not make two elements the same. Choose markup based on what the element does, then style it to fit the interface.
| Need | Use |
|---|---|
| Navigate somewhere | <a href="..."> |
| Submit a form | <button type="submit"> |
| Trigger JavaScript behavior | <button type="button"> |
| Choose one option from a small set | Radio buttons or segmented controls. |
| Choose many options | Checkboxes. |
| Choose from many options | Select, combobox, search, or filter pattern. |
| Reveal optional content | Button-controlled disclosure or <details>. |
Studio Activity: Pattern Audit
- Choose one project screen or page.
- List every interactive element on the screen.
- Name the pattern each element is using.
- Confirm the markup matches the behavior.
- Add missing hover, focus, active, disabled, loading, empty, error, or success states.
- Replace one confusing pattern with a simpler or more familiar choice.
Submission Checklist
- Every interactive element has a clear purpose.
- Buttons and links are used for the right kind of behavior.
- Patterns have visible signifiers and feedback.
- Keyboard focus is visible and reachable.
- Important states are designed and named.
- Responsive behavior has been checked for cramped or hidden controls.
Checkpoint
Before moving on, make sure these feel true.
- I can choose common UI patterns based on task needs.
- I can explain how affordance, signifier, and feedback work in an interface.
- I can match visual controls with correct semantic HTML and accessible states.
Project Connection