Lesson 02C / UX Process

Wireframing For Responsive Interfaces

Time
33 min
Type
Reading + Practice
Level
Intermediate
Use
Studio Support

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

LevelBest ForAvoid
SketchFast options, early critique, comparing layouts.Spending time on perfect spacing.
Low-fidelity FigmaStructure, hierarchy, content order, responsive frames.Final color, branding, and decorative details.
Mid-fidelityComponent placement, real content, states, and flow review.Pretending the design is final before testing.
High-fidelityFinal 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.

QuestionWhat 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

PatternWireframe Concern
Landing pageHierarchy, CTA, section order, proof, and responsive image behavior.
DashboardPriority, scanning, filters, empty states, and repeated cards or rows.
Listing/detailCard information, filters, detail hierarchy, back paths, and related items.
Form flowLabel clarity, grouping, validation, progress, and confirmation.
Portfolio case studyProject 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

MistakeBetter Move
Starting with desktop onlyStart mobile-first, then expand.
Using decorative detail too earlyUse labels and hierarchy before visual polish.
Making every screen uniqueReuse patterns so the project is easier to build.
Ignoring real content lengthWireframe with realistic headings, labels, and card text.
Forgetting statesAdd 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

This lesson supports current class projects.

Practice

Resources