Lesson 02C / UX Process
Wireframing For Responsive Interfaces
Use low-fidelity wireframes to plan content hierarchy, layout behavior, and interface states before visual design or production code.
Course Role
Studio Support
Best during work sessions, critique, debugging, project planning, or final polish.
Teacher Notes / In-Class Use
Demo Live
- Sketch one screen at mobile width first, then expand it into desktop while narrating what stacks, wraps, or moves.
- Point to each wireframe region and name the likely HTML element or landmark.
Try In Class
- Have students produce mobile and desktop wireframes for one task.
- Ask students to annotate responsive behavior and write a matching HTML outline beside the wireframe.
Submit Or Check
- Wireframes should include realistic content, primary action, navigation, states, and responsive notes.
- Students should avoid visual polish until structure and hierarchy are clear.
Watch For
- Desktop-only wireframes that become impossible to adapt later.
- Pretty grayscale mockups that still do not explain content order or user action.
Learning Goals
- Create wireframes that show structure, hierarchy, and task flow without over-polishing.
- Plan mobile, tablet, and desktop layout changes around content needs.
- Use wireframes to test navigation, forms, lists, details, and states.
- Translate a wireframe into semantic HTML regions and responsive CSS decisions.
Wireframes Are Thinking Tools
A wireframe is not a worse version of a finished design. It is a fast way to decide what belongs on a screen, what order it should appear in, and how a user moves through the interface.
Good wireframes reduce expensive guessing later. They let you critique structure before color, type, images, and animation make weak decisions look more finished than they are.
What A Wireframe Should Show
- The page or screen purpose.
- The primary user action.
- Major content groups and their order.
- Navigation and wayfinding.
- Form fields, labels, and feedback areas.
- Lists, cards, tables, or detail views.
- Important states such as empty, loading, error, and success.
- Responsive behavior across widths.
Low Fidelity vs. High Fidelity
| Level | Best For | Avoid |
|---|---|---|
| Sketch | Fast options, early critique, comparing layouts. | Spending time on perfect spacing. |
| Low-fidelity Figma | Structure, hierarchy, content order, responsive frames. | Final color, branding, and decorative details. |
| Mid-fidelity | Component placement, real content, states, and flow review. | Pretending the design is final before testing. |
| High-fidelity | Final visual direction, handoff, portfolio presentation. | Using polish to hide unclear structure. |
Responsive Wireframe Strategy
Responsive design is not a desktop design squeezed onto a phone. Start with the smallest practical layout, then add space, columns, and supporting details as the viewport grows.
| Question | What To Decide |
|---|---|
| What must be visible first? | The strongest heading, context, and primary action. |
| What can stack? | Cards, form groups, media/text pairs, and secondary content. |
| What can move later? | Related links, filters, sidebars, metadata, and supporting notes. |
| What needs stable controls? | Navigation, search, submit buttons, close buttons, and form actions. |
| What needs a max width? | Paragraphs, forms, cards, and dense content areas. |
Wireframe Common Interface Patterns
| Pattern | Wireframe Concern |
|---|---|
| Landing page | Hierarchy, CTA, section order, proof, and responsive image behavior. |
| Dashboard | Priority, scanning, filters, empty states, and repeated cards or rows. |
| Listing/detail | Card information, filters, detail hierarchy, back paths, and related items. |
| Form flow | Label clarity, grouping, validation, progress, and confirmation. |
| Portfolio case study | Project story, process evidence, screenshots, role, result, and links. |
Wireframe To HTML Outline
Every major rectangle in a wireframe should eventually become a meaningful piece of markup, not a random div. Naming those regions early makes implementation easier.
<body>
<header>
<nav aria-label="Primary navigation">...</nav>
</header>
<main>
<section aria-labelledby="page-title">
<h1 id="page-title">...</h1>
<p>...</p>
<a href="..." class="button">Primary action</a>
</section>
<section aria-labelledby="featured-list-title">
<h2 id="featured-list-title">...</h2>
<ul class="card-grid">...</ul>
</section>
</main>
</body> Studio Activity: Three Widths, One Task
- Choose one screen from a user flow.
- Sketch the mobile version first using only boxes, labels, and notes.
- Create a tablet or medium-width version that shows what changes when more space is available.
- Create a desktop version that adds layout clarity without adding unrelated content.
- Label the primary action, secondary actions, and feedback areas.
- Write the HTML outline and the CSS layout strategy beside the wireframes.
Common Mistakes
| Mistake | Better Move |
|---|---|
| Starting with desktop only | Start mobile-first, then expand. |
| Using decorative detail too early | Use labels and hierarchy before visual polish. |
| Making every screen unique | Reuse patterns so the project is easier to build. |
| Ignoring real content length | Wireframe with realistic headings, labels, and card text. |
| Forgetting states | Add empty, loading, error, and success areas before code. |
Submission Checklist
- The wireframe names the user task and primary action.
- Mobile and desktop versions are both planned.
- Content groups have clear labels.
- Navigation and feedback areas are visible.
- The layout can be translated into semantic HTML.
- Responsive changes are annotated instead of left to guesswork.
Checkpoint
Before moving on, make sure these feel true.
- I can wireframe a screen around content hierarchy and task flow.
- I can plan mobile and desktop layout behavior before visual polish.
- I can translate wireframe regions into semantic HTML and responsive CSS decisions.
Project Connection