This is post #6 in the How It Works series. We are building a task management app (simplified Trello) as our running example. In the previous post on Planning, we defined what we are building and why. Now it is time to figure out what it looks like before writing a single line of code.
A wireframe is a low-fidelity visual blueprint of your application. It defines the layout and user flow of each screen — no colors, no fonts, no pixel-perfect polish. Think of it as the architectural blueprint you review before the construction crew shows up.
A wireframe answers three questions:
Wireframes are intentionally ugly. If you are picking shades of blue, you have wandered into design. That comes later.
Many developers skip wireframing because they think it is a designer’s job. That is a mistake. Wireframes prevent the most expensive pattern in software: building, then redesigning. Without a shared visual plan, three things go wrong:
Wireframing is cheap. Refactoring is not.
| Type | Fidelity | Tools | When to Use |
|---|---|---|---|
| Low-fidelity | Boxes, lines, labels | Pen & paper, whiteboard | Early brainstorming, first 30 minutes of a project |
| Mid-fidelity | Structured layouts with placeholder text | Balsamiq, Figma wireframe mode | Sprint planning, stakeholder reviews |
| High-fidelity | Near-final look with realistic content | Figma, Sketch, Adobe XD | Final design approval before implementation |
Start low, go higher. Begin with pen and paper. If the idea survives that conversation, move to a mid-fidelity tool. High-fidelity wireframes are worth it only when you need stakeholder sign-off before committing to code.
Let us wireframe the four core screens of our simplified Trello clone.
A centered card on a blank background. The card contains a logo placeholder at the top, an email input field, a password input field, a “Log In” button spanning the full width of the card, and a “Sign Up” link below it. No sidebar, no navigation bar. The user has one job: authenticate.
The main screen after login. A top navbar spans full width — app name on the left, user avatar dropdown on the right. Below it, three vertical columns represent statuses: To Do, In Progress, and Done. Each column contains stacked task cards (title + assignee avatar) with an “+ Add Task” button at the bottom. Classic Kanban layout.
Clicking a task card opens a modal overlay. Editable title at top, description text area below, and a right sidebar showing metadata: assignee, due date, priority, status dropdown. Comments section at the bottom. The dashboard stays dimmed behind the modal so the user retains spatial context.
Standard settings layout. Left sidebar lists setting categories: Profile, Notifications, Team Members, Integrations. The right content area changes based on the selected category. The Profile section shows avatar upload, name, and email fields. The Notifications section shows toggle switches. Keep it simple — settings pages rarely need creative layouts.
Every screen in your wireframe maps to a route, a controller method, and a template. When the wireframe is done, your routing structure writes itself.
Here is the route structure for our task app in Spring Boot (Java):
@Controller
public class TaskAppController {
@GetMapping("/login")
public String loginPage() {
// Wireframe: Login Page - centered card, email/password fields
return "login";
}
@GetMapping("/dashboard")
public String dashboard(Model model) {
// Wireframe: Board View - three columns (To Do, In Progress, Done)
List<Task> tasks = taskService.getAllTasksForUser();
model.addAttribute("tasks", tasks);
return "dashboard";
}
@GetMapping("/tasks/{id}")
public String taskDetail(@PathVariable Long id, Model model) {
// Wireframe: Task Detail Modal - title, description, metadata sidebar
Task task = taskService.getTaskById(id);
model.addAttribute("task", task);
return "task-detail";
}
@GetMapping("/settings")
public String settings() {
// Wireframe: Settings Page - sidebar categories, right content area
return "settings";
}
@GetMapping("/settings/{section}")
public String settingsSection(@PathVariable String section, Model model) {
// Wireframe: Settings subsections - profile, notifications, team, integrations
model.addAttribute("section", section);
return "settings";
}
}
And the same structure in Flask (Python):
from flask import Flask, render_template, redirect, url_for
from services import task_service
app = Flask(__name__)
@app.route("/login")
def login_page():
"""Wireframe: Login Page - centered card, email/password fields"""
return render_template("login.html")
@app.route("/dashboard")
def dashboard():
"""Wireframe: Board View - three columns (To Do, In Progress, Done)"""
tasks = task_service.get_all_tasks_for_user()
return render_template("dashboard.html", tasks=tasks)
@app.route("/tasks/<int:task_id>")
def task_detail(task_id):
"""Wireframe: Task Detail Modal - title, description, metadata sidebar"""
task = task_service.get_task_by_id(task_id)
return render_template("task_detail.html", task=task)
@app.route("/settings")
@app.route("/settings/<section>")
def settings(section="profile"):
"""Wireframe: Settings Page - sidebar categories, right content area"""
return render_template("settings.html", section=section)
if __name__ == "__main__":
app.run(debug=True)
Every route maps to a wireframe screen. Every template name matches a wireframe label. No guessing about what pages the app needs — the wireframe already defined them. This is why wireframing matters for developers: it turns vague requirements into a concrete routing table before you write any business logic.
The tool matters far less than the habit. A napkin sketch beats no wireframe every time.
Show wireframes to real users early. Not after polishing. Not after development starts. Show the rough sketch and watch what happens. Where they squint, you have a clarity problem. Where they ask “how do I get back,” you have a navigation problem. Where they ignore a section, you might not need it.
Their confusion is your UX debt — cheaper to fix now by erasing a box than later by refactoring components and rewriting endpoints.
Also: wireframe the unhappy paths. What does the screen look like with zero tasks? What happens when the API fails? If you only wireframe the golden path, you will discover edge cases in production.
With our wireframes defined and our route structure mapped, the next step in the series is Designing and Prototyping — where we take these skeletal layouts and add the visual layer: color, typography, spacing, and interaction design. The wireframe tells us what goes where. The design tells us how it looks and feels.