Wireframing with Figma

Why PMs Need to Understand Wireframes

A PM is rarely the one polishing pixels, but a PM who can sketch a rough layout communicates ten times faster than one who only writes paragraphs. Whether you work at a bank like Access Bank redesigning an internal ops tool, or a startup like Konga rethinking its checkout flow, the fastest way to align a room full of stakeholders is to put a rough picture in front of them.

Figma has become the industry-standard design tool -- used by teams at Google, Airbnb, and most Nigerian and global product companies -- because it lets PMs, designers, and engineers collaborate on the same file in real time, with comments, versioning, and developer handoff built in.

---

Lo-Fi vs Hi-Fi: Two Very Different Jobs

A common mistake is jumping straight to hi-fi. If the CEO or engineering lead debates font choices before anyone has agreed on whether the flow even has 3 steps or 5, the team has wasted a design cycle. Lo-fi first, always.

A PM's lo-fi wireframe checklist

• Does every screen have a clear primary action?
• Is the number of steps to complete the task obvious?
• Are error states and empty states represented, even roughly?
• Does the flow match the acceptance criteria in the user story?

---

A Simple Figma Workflow for PMs

1. Frame the screen. Create a frame at a standard size (e.g. 375x812 for mobile, matching an iPhone).
2. Block out structure with rectangles and text. Do not worry about colour -- grey boxes are fine.
3. Link screens together with prototyping. Figma lets you draw an arrow from a button on one frame to another frame, so stakeholders can click through a working flow instead of imagining it.
4. Comment directly on the file. Instead of a separate feedback doc, tag teammates with @mentions on specific elements.
5. Hand off to design for hi-fi. Once the flow is agreed, a designer takes the lo-fi skeleton and turns it into a polished, branded screen.

---

Handing Off to Engineering

Once a design is finalised, engineers need more than a picture -- they need exact specifications. Figma's Dev Mode (previously "Inspect" panel) lets engineers:

• Click any element to see its exact spacing, colour hex code, and font size
• Export assets (icons, images) in the right format and resolution
• View auto-generated CSS/iOS/Android code snippets for a given element
• See design tokens and components mapped to a shared library

What a PM should confirm before handoff

• All states are designed: default, loading, error, empty, success
• Copy is final -- no more "Lorem ipsum" or placeholder text like "TBD"
• Responsive behaviour is at least described, even if only for mobile and desktop
• The linked PRD or ticket references the exact Figma frame, not just "see designs"

A poor handoff looks like: "Here's the Figma link, build this." A good handoff looks like: "Here's the Figma link (frame: Checkout v3). Acceptance criteria are in Jira ticket PROJ-482. The error state for failed card payments is on frame 'Checkout - Error'."

---

Real-World Example: Redesigning a Transfer Confirmation Screen

Imagine a PM at a payments company like Paystack wants to reduce failed transfer confirmations. The process might look like:

1. Lo-fi in Figma: Three boxes -- "Enter amount," "Confirm recipient," "Success/Error." Shared with engineering and support in a 15-minute review.
2. Feedback: Support flags that users often mistype account numbers. PM adds a "verify account name" step to the lo-fi flow.
3. Hi-fi by design: A designer builds the final screens with Paystack's brand colours, using components from the shared design library.
4. Dev Mode handoff: Engineers inspect exact spacing and pull the confirmation icon as an SVG asset directly from Figma.
5. Prototype testing: Before writing code, the team clicks through the Figma prototype with five real users to catch confusion early -- far cheaper than finding the same issue after launch.

---

Common Mistakes PMs Make with Wireframes

1. Skipping wireframes entirely and jumping to a verbal description, which different engineers interpret differently.
2. Over-designing lo-fi wireframes, wasting time perfecting a throwaway sketch.
3. Not linking the Figma file in the PRD or ticket, forcing engineers to hunt for the "latest" version across Slack messages.
4. Ignoring edge states (errors, empty states, loading) until QA finds the gaps late in development.

Wireframing is not about becoming a designer -- it is about giving the team a shared, editable picture of the plan before code gets written, so misunderstandings are caught while they still cost minutes instead of sprints.