Product sketching is the fastest path from abstract idea to concrete, discussable thing. Before you write requirements documents or brief designers, sketch. The act of sketching reveals whether you actually understand the problem well enough to propose a solution.
Why sketching before wireframing
A wireframe is a structured representation of a digital interface — a schematic showing where content, UI elements, and interaction flows will live. But before you draw a wireframe, you need to have thought through the concept.
A sketch on paper is not a deliverable. It is thinking. It takes five minutes and reveals whether your idea is coherent. A wireframe takes longer and implies a level of structure that locks in assumptions prematurely.
The process: sketch → wireframe → mockup → prototype. Each stage adds more detail and more investment. Moving too fast to mockups or prototypes before the concept is clear wastes time.
What a good wireframe captures
A wireframe must represent:
User goals and business goals at the interface level: What does the user want to accomplish by interacting with this page or screen? What does the business want the user to do? If these conflict, the wireframe should reflect a considered resolution, not ignore the tension.
For example: a user goal on an e-commerce site might be "find and evaluate products quickly." The business goal is "convert to purchase." Amazon's design choice to put the cart in the top right corner on every page is a wireframe decision that serves both — users can always add and check progress, the business conversion path is always visible.
Content organization: Where content lives and how it is prioritized. A/B testing is often used to optimize this because the right organization is not obvious from reasoning alone. Users have mental models that differ from designers' mental models.
Logo and primary message placement: What does your brand stand for, and where does that identity appear? The logo and headline communicate value immediately on first impression. Every screen has real estate priorities — the wireframe must reflect them.
Call to action: What do you want users to do? Shop, check out, register, read more, contact sales. The CTA needs to be explicit in the wireframe — not left to later stages.
User expectations: What do users expect when they arrive at this screen? Meeting expectations reduces friction; violating them creates confusion. Understanding this requires user research, but it must be reflected in the wireframe.
The progression
Wireframe: Low fidelity. Placeholders for content, buttons, images. No visual design. Shows structure and hierarchy. The goal is to communicate layout and flow, not visual appearance.
Tools: Balsamiq, Figma (low-fidelity mode), even pen and paper.
Mockup: Higher fidelity. Actual content, text, some visual treatment. Formed from iterating on the wireframe. Two to three screens of mockup are enough to communicate an idea to an investor or stakeholder. No interactivity yet — but it is close enough to the final product to evaluate whether the design communicates the intended value.
Prototype: Interactive. Users can click through flows and experience the product as if it were real. Tools like Figma (interactive mode) or InVision allow linked screens to simulate product behavior. Even light coding can produce basic user flows.
Prototypes are used for: user testing (does the flow make sense?), investor demos (showing the product vision in action), and engineering handoff (replacing ambiguous written specifications with demonstrated behavior).
A worked example
Problem identified: when people go out with friends and family, they have difficulty locating washrooms nearby.
Sketch: Draw the core screen — a map view with nearby washroom markers and a search bar. That is it. Do it in five minutes. Does the idea make sense? Can a user understand from this sketch what the app does?
Wireframe: Create the screen with labeled placeholders. Map placeholder in the center. Top bar with search input. List of nearby results below the map. Filter button. Each element labeled with its purpose, not its visual treatment.
Mockup: Add the map (still placeholder, but sized correctly). Add two or three search results with name, distance, and a rating icon. Add a "Get directions" button.
Prototype: Link the list item tap to a directions screen. Link the filter button to a filter panel. Now a user can tap through and experience the core flow.
The investment at each stage is proportional to the confidence required. For internal alignment, a wireframe is often enough. For user testing, you need a mockup at minimum. For investor demos or sales conversations, a prototype pays for itself.
Pick one feature you are working on — or one you wish existed in a product you use.
Take a piece of paper and sketch the primary screen. Not a wireframe, not a mockup — a rough sketch. Include: the main content area, the key action the user takes, and the primary information they need to take that action.
When you are done, show it to someone who does not know the context. Do they understand what the screen does? If not, what was missing?
The things that are missing from your sketch are usually the things that are missing from your product thinking.