Wireframing and Low-Fidelity Design

Create text-based wireframes, layout structures, and information architecture documents. Plan page structure, content hierarchy, and user flows before investing in high-fidelity design.

Workflow

Step 1: Define the Page or Flow

Clarify before wireframing:

1. What is this page/screen for? Primary purpose and user goal.
2. Who is the primary user? Persona or segment.
3. What content exists? Data, text, media, actions available.
4. What is the primary action? The one thing the user should do.
5. What patterns exist? Related pages in the product, industry conventions.

Step 2: Establish Information Architecture

Define the content hierarchy before layout:

### Content Hierarchy: [Page Name]

**Level 1 (Primary)**: [What the user must see/do immediately]
- [Element]: [Purpose]

**Level 2 (Secondary)**: [Supporting information and actions]
- [Element]: [Purpose]

**Level 3 (Tertiary)**: [Nice-to-have, discoverable content]
- [Element]: [Purpose]

**Navigation Context**:
- Where does the user come from? [Previous page/entry point]
- Where do they go next? [Next page/action]
- How do they leave? [Back, close, navigate away]

Step 3: Create the Wireframe

Use ASCII/text-based wireframes for rapid iteration:

### Wireframe: [Page Name]

+--------------------------------------------------+
|  [Logo]          [Nav Item] [Nav Item]   [Avatar] |
+--------------------------------------------------+
|                                                    |
|  Page Title                          [Action Btn]  |
|  Subtitle / description text                       |
|                                                    |
|  +-------------+ +-------------+ +-------------+  |
|  | Card         | | Card         | | Card         |  |
|  | [Image]      | | [Image]      | | [Image]      |  |
|  | Title        | | Title        | | Title        |  |
|  | Description  | | Description  | | Description  |  |
|  | [CTA]        | | [CTA]        | | [CTA]        |  |
|  +-------------+ +-------------+ +-------------+  |
|                                                    |
|  +----------------------------------------------+  |
|  | Section Title                                 |  |
|  | +------------------+ +---------------------+  |  |
|  | | List Item         | | Detail Panel         |  |  |
|  | | List Item         | |                      |  |  |
|  | | List Item (sel)   | | [Content]            |  |  |
|  | | List Item         | |                      |  |  |
|  | +------------------+ +---------------------+  |  |
|  +----------------------------------------------+  |
|                                                    |
+--------------------------------------------------+
|  [Footer links]                    [Legal] [Help] |
+--------------------------------------------------+

Step 4: Annotate the Wireframe

Add notes for each major element:

### Annotations

1. **Header**: Fixed position, 64px height. Logo links to dashboard.
   Navigation: max 5 items, active state indicator.

2. **Page Title Area**: Title is the primary heading (h1).
   Action button is the primary CTA for this page.
   Subtitle provides context, max 2 lines.

3. **Card Grid**: 3 columns on desktop, 2 on tablet, 1 on mobile.
   Cards are clickable (entire card is the hit target).
   Max 12 cards before pagination.

4. **List + Detail**: Master-detail pattern.
   List shows 10 items with infinite scroll.
   Selecting an item loads detail in the right panel.
   On mobile: list and detail are separate screens.

5. **Footer**: Sticky to bottom when content is short.
   Contains legal links and help access.

Step 5: Explore Layout Alternatives

For key decisions, present 2-3 layout options with pros and cons for each (e.g., card grid vs. table/list vs. hybrid). Include a recommendation with rationale for which option best serves the user's primary task.

Step 6: Define User Flows

Map how screens connect:

### User Flow: [Task Name]

[Entry Point]
    |
    v
[Screen 1: Browse]
    |
    +---> [Screen 1a: Filter/Search]
    |         |
    |         v (results update in place)
    |
    v (select item)
[Screen 2: Detail]
    |
    +---> [Screen 2a: Edit] ---> [Success Toast] ---> [Back to Detail]
    |
    +---> [Screen 2b: Delete] ---> [Confirmation Dialog]
              |                         |
              +--- Cancel ------------->+
              +--- Confirm ---> [Redirect to Browse]

Step 7: Compile the Wireframe Document

Assemble a wireframe document containing: purpose, user and goal, information architecture, wireframes with annotations, layout alternatives considered, user flow, responsive notes, content requirements, and open questions.

Include content requirements (element, type, source, max length) and open questions with next steps.

Examples

Example 1: Dashboard

User: "Wireframe a dashboard for project managers." Response: Information architecture: Key metrics (top), project list (main), recent activity (sidebar). Wireframe with KPI cards at top, project table with status/progress/owner columns, and a collapsible activity feed. Annotate filtering and sorting behavior.

Example 2: Settings Page

User: "Wireframe the account settings page." Response: Left navigation with setting categories (Profile, Security, Notifications, Billing, Team). Right content area with the active category's form. Each category has save/cancel at the bottom. Note mobile behavior: nav becomes a dropdown or back-navigable stack.

Example 3: Onboarding Flow

User: "Wireframe a 4-step onboarding flow." Response: Define the 4 steps with content for each. Wireframe the step layout: progress indicator, step title, form/content area, next/back/skip buttons. Show the completion screen. Note what data is collected at each step and why.

Best Practices

1. Content first, layout second. Know what content needs to appear before deciding how to arrange it. Wireframing without content produces pretty but useless layouts.
2. One primary action per screen. Every screen should have one thing the user is most likely to do. Make it visually dominant.
3. Use real content. "Lorem ipsum" hides problems. Use realistic text lengths, data volumes, and edge cases in wireframes.
4. Low fidelity on purpose. Wireframes should look rough so feedback focuses on structure and flow, not colors and fonts.
5. Annotate assumptions. Every wireframe contains assumptions about behavior, data, and constraints. Write them down so they can be validated.
6. Test the flow, not the screen. Individual screens may look fine but the flow between them may be confusing. Always map the user journey across screens.
7. Consider empty and full states. What does this page look like with zero items? With 500 items? Wireframe both extremes.
8. Iterate fast. Wireframes are cheap to change. Explore multiple options before committing to one direction.