Designing the Solution: Structure, Wireframes, and UI

Lesson 2 finished the first diamond with a sharp problem statement. Now comes the second diamond, "develop and deliver", where a UX designer explores and shapes solutions. This is the part people picture when they imagine design work, but notice it comes after understanding the user and defining the problem, which is what keeps it from being decoration.

Designing a solution proceeds from structure to detail, deliberately, and rushing to visuals is the classic beginner mistake:

• Information architecture and flows: how content and features are organized, and the paths users take through them. The skeleton.
• Wireframes: low-detail layouts of each screen, defining structure and priority before any styling.
• Prototypes: interactive versions used to test the design with users before it is built.
• UI (visual design): the layout, type, color, and components that make it clear and appealing, applied on top of a sound structure.

The order matters because each layer depends on the one before. Beautiful visuals on a confusing structure still confuse; a slick screen that solves the wrong flow still fails. So designers work outside-in: get the structure and flow right, validate the interaction, then apply visual craft. This lesson walks that sequence, giving a career switcher a concrete picture of what "doing design" actually involves, and why the discipline of structure-before-style is what separates real UX from just pushing pixels.

Before designing any screen, a UX designer decides how the product's content and features are organized, which is information architecture (IA). IA is the structure: what the main sections are, how things are grouped and labeled, and how they nest. Think of it as the site map or the org chart of the product.

Good IA is what lets users find things and know where they are. If the structure matches how users think, navigation feels obvious; if it is organized around the company's internal logic instead, users get lost even when every screen is pretty. A classic technique for getting IA right is card sorting: give users the pieces of content and see how they group and label them, so the structure reflects users' mental models rather than yours, a direct application of user-centered design.

Closely related are user flows: the step-by-step paths a user takes to complete a task, for example, the screens and decisions from "open app" to "invoice sent." Mapping the flow forces you to think through the whole task, every step, decision, and dead end, before designing screens.

Start -> Dashboard -> New Invoice -> Fill Details -> Review -> Send -> Confirmation

Why do this first: a smooth flow with too many steps, confusing branches, or missing paths creates frustration no amount of visual polish fixes. Designing the flow before the screens ensures the journey works, and it directly attacks the pain points found in the journey maps from Lesson 2. IA and flows are the skeleton the rest of the design hangs on.

With flows mapped, the designer lays out individual screens as wireframes: deliberately low-fidelity sketches that show what goes where and what matters most, without colors, fonts, or images. Boxes for content, lines for text, simple labels for buttons, gray and plain on purpose.

Why strip out the visuals? Because wireframes are about structure and priority, not looks:

• They focus attention on what matters early: layout, hierarchy, and content, is the primary action prominent, is the information in a sensible order, is anything missing? Adding color and polish too soon pulls the conversation to "I don't like that blue" instead of "is this the right structure?"
• They are fast and cheap to change. A wireframe takes minutes and is easy to throw away, so you can explore many layouts quickly, exactly the divergent "develop" phase. Nobody grows too attached to a gray box, which keeps ideas flowing.
• They force prioritization. With no styling to hide behind, you must decide what is most important on each screen and lay it out accordingly, the essence of good screen design.

Wireframes make the crucial distinction of the whole lesson concrete: structure first, style later. By deciding layout and hierarchy in cheap gray boxes, you get the foundation right before investing in visual detail, and you keep stakeholders focused on whether the screen works before debating how it looks. They are the bridge from the abstract flow to a concrete, testable design.

A wireframe or a visual design is static. A prototype makes it interactive, screens linked so a user can click through and actually experience the flow, without a single line of real code. Prototypes range in fidelity: a low-fi prototype links wireframes with clickable hotspots; a high-fi prototype looks and behaves close to the finished product.

The purpose of a prototype is captured in one word: test. It lets you put a realistic experience in front of real users and watch them try to complete tasks, before engineers build anything. This is the single biggest reason UX saves money: catching a confusing flow or a misunderstood button in a prototype costs an afternoon to fix; catching it after it is built costs a rewrite.

The dominant tool for this today is Figma, which lets designers create screens and wire them into clickable prototypes (other tools do the same). Learning a tool like Figma is a practical must for the job, but it is a means, the thinking is what matters.

The workflow this enables is the heart of modern UX: design, prototype, test, refine, repeat. You do not design once and hand off; you build a testable version, learn from real users, and iterate, the double diamond's "deliver" phase in action, and the same build-measure-learn logic seen across product work. A prototype is essentially a cheap experiment, and running those experiments before committing to code is what makes design a process of validated improvement rather than expensive guessing.

Once the structure and flow are validated, the designer applies UI (visual) design, the layer that makes a product clear, usable, and appealing. Good UI is not decoration; it uses visual choices to guide the eye and make the interface effortless. A few fundamentals do most of the work.

• Visual hierarchy. Guide attention to what matters most using size, weight, color, and position. The most important element (a primary action, a headline) should be the most prominent; secondary things recede. Users should instantly see what to look at first.
• Layout and spacing. Alignment, grids, and generous whitespace create order and let the eye rest. Grouping related items and separating unrelated ones (a Gestalt principle: things near each other are seen as related) makes structure visible at a glance.
• Typography. Readable type sizes, limited font choices, and clear text hierarchy (headings vs body) make content easy to scan and read, a huge share of most interfaces is text.
• Color. Used purposefully: a consistent palette, an accent color to draw attention to key actions, and enough contrast for legibility (which also serves accessibility, Lesson 4). Color should signal meaning, not just decorate.
• Consistency. Buttons, icons, and patterns should look and behave the same everywhere. Consistency lets users transfer what they learned on one screen to the next, reducing effort and building trust; inconsistency quietly makes a product feel confusing and unreliable.

These fundamentals are learnable craft, and together they turn a sound structure into an interface that feels clear and professional. UI expresses the UX: the visual layer, done well, makes the good structure underneath effortless to use.

See the second diamond in action on the invoicing problem from Lesson 2: "busy owners need to send invoices quickly from their phone."

1. Information architecture: decide the app's structure, a simple bottom navigation of Dashboard, Invoices, Clients, so the core tasks are one tap away, validated against how users grouped tasks.
2. User flow: map the invoice-sending path, Dashboard, tap New Invoice, pick client, add items, review, send, confirmation, checking it is as short as possible since speed is the whole point.
3. Wireframes: sketch each screen in gray boxes, ensuring the primary action (New Invoice, then Send) is prominent and the fields are minimal and in a sensible order. Iterate on layout cheaply here.
4. Prototype and test: wire the wireframes into a clickable Figma prototype and watch five real small-business owners try to send an invoice. Two get confused at the client-selection step, so it is redesigned, a fix that costs an hour, not a rebuild.
5. UI design: apply visual design, clear hierarchy putting Send front and center, readable type, a calm palette with one accent color on primary actions, consistent buttons throughout, and strong contrast for outdoor phone use.

The result is a mobile invoicing flow that is genuinely fast and clear, because it was structured around the real task, validated with users before building, and then given visual craft. Every layer built on the one before, which is exactly how professional design work moves from a problem to a solution worth building.

Here is the solution-design toolkit in one view, in the order you use it.

The throughline for a career switcher: design is a disciplined progression from structure to style, validated with users along the way. The most important habit is resisting the urge to jump to pretty screens, doing IA and flows first, wireframing before styling, and prototyping to test before building. This structure-first discipline, more than any tool skill, is what marks a real UX designer.

Two practical notes. First, learn a tool like Figma, it is the practical language of the job, but remember the tool serves the thinking, not the reverse. Second, this is where craft and evidence meet: the visual fundamentals are learnable skills, and the testing keeps the craft honest, ensuring what you make actually works for users, not just looks good in a portfolio.

With a solution designed and prototyped, one question remains: is it actually good, does it work for real users, is it accessible to everyone, does it meet the standards of the field? Evaluating and refining the design, and turning all of this into a career, is Lesson 4.

Solution design moves from structure to style: organize content with information architecture, map the user flow, lay out wireframes without styling, wire them into a prototype to test with users, then apply UI visual design, looping back to the prototype whenever testing reveals problems.