UI/UX design that starts with the task.

• Choose UI/UX design when the experience is the problem.

  Traffic arrives and leaves, a form is abandoned, a workflow takes too many steps, or nobody can find the thing they came for. That is a structure and interface problem, and rebuilding without designing it first reproduces it.

• Choose design systems when consistency is the problem.

  Where the screens are individually fine but collectively five different products, the deliverable is tokens, components and usage rules rather than another set of screens.

• Commission design on its own when you already have developers.

  An in-house team with capacity does not need a build partner. It needs architecture, flows, screens and specifications precise enough to work from, which is exactly what this service delivers.

They are usually one engagement, because neither works alone. Interface design without structural design produces attractive screens in an unusable sequence. Structural design without interface design produces a sound plan nobody can read. What varies is the balance: a data-dense product needs more structural work, a marketing site more interface work.

The distinction is worth understanding anyway, because it tells you what to ask for. If people cannot find things or complete tasks, the problem is upstream in the structure, and no amount of visual polish will move it. If people find things but misread the screen, miss the action or cannot see the text, the problem is in the interface and the structure is sound.

So we diagnose which of the two is costing you before quoting either. The answer changes the shape of the project rather than only its length.

A user journey is the sequence a person moves through to finish one task, described as steps rather than as screens. Designing it exposes the steps that exist only because of how the system was built, the points where somebody has to leave and come back, and the moments where nothing confirms that anything happened.

The reason to map it in steps rather than in pages is that a task rarely matches a page. Deciding to buy something spans a search result, a service page, a comparison, a form and a confirmation, and the weakest link in that chain sets the conversion rate for the whole of it. Designing page by page improves links individually and leaves the chain untouched.

• A website journey: arrive, orient, explore, compare, decide, make contact.
• An application journey: sign in, orient, locate the record, act on it, confirm, move on.
• The entry points, because somebody arriving from a search result is mid-journey already.
• The exit points, and whether each one is a completion or an abandonment.
• The steps that exist only because a system needs them rather than because a person does.
• What confirms that each step worked, and what is shown on the step that failed.

A wireframe is a layout without visual style: boxes, headings, real copy and the sequence of interaction. It exists so that structural decisions get reviewed on their merits. Once color, imagery and type are present, review moves to taste, and the structural questions underneath stop being asked at all.

There is a practical argument as well as a diplomatic one. Structure is the most expensive thing to change late and the cheapest thing to change early, so it is settled while it costs nothing. Wireframes also force content to exist: a box labeled as a headline cannot be filled with a placeholder paragraph and quietly approved.

As a set of design constraints rather than a later audit. Contrast pairings, focus order, target sizes, heading structure, visible labels and status that never relies on color alone are decided while the screens are drawn. Remediating those after a build is consistently more expensive and compromises more of the design.

The criteria are not invented per project. WCAG 2.2, the standard the designs are checked against, sets them at three conformance levels, and the ones that constrain design are specific: text contrast, non-text contrast, target size, focus visibility, focus order, consistent help and accessible authentication.

The same structure an assistive technology depends on — real headings in order, real buttons and links, real labels, real tables — is also what an answer engine reads when it extracts content from a page. Accessibility and extraction are one specification seen from two directions.

• Keyboard traversal in a logical order, with a visible focus indicator on every interactive element.
• Text contrast that meets the WCAG 2.2 thresholds, verified against the actual background rather than assumed.
• Touch and pointer targets large enough to hit, with spacing between adjacent actions.
• Labels that stay visible rather than disappearing into placeholder text once typing starts.
• Error messages that name the field, say what is wrong, and never signal it with color alone.
• Heading levels that describe the structure of the page and never skip a level.
• Motion that respects a reduced-motion preference, with every element landing in its final state.
• Layouts that stay usable at 200 percent zoom without clipping content or scrolling sideways.

• User interface design
• User experience design
• Wireframing
• Prototyping
• Usability review

Design is frequently described as the last step before a build, which gets the sequence exactly backwards. It is the chain that connects a commercial objective to a person finishing a task, and every link in it is a decision somebody has to make.

• The structure is decided while it is still cheap

  Changing a user flow in a wireframe costs an afternoon. Changing it after the data model, the routes and the screens are built costs a rebuild of all three.

• Every state is accounted for

  Empty, loading, error, permission-denied and long-content states are designed rather than discovered in production, which is where most interfaces visibly break.

• Accessible by design, not by remediation

  Contrast, focus order, target size and non-color status are settled while the screens are drawn. Retrofitting them after a build costs more and compromises more.

• Developers stop guessing

  A specification that states behavior, not just appearance, removes the interpretation gap where consistency is normally lost — whether your team builds it or ours does.

• A website that gets traffic and no inquiries

  The visits are already paid for. Restructuring the journey, the hierarchy and the conversion path is a smaller job than earning more traffic, and usually the one worth doing first.

• An application built feature by feature

  Each addition was reasonable and the total is incoherent. The work is to find the underlying model, rebuild the navigation around it, and design the states that were never designed.

• A build about to start with an in-house team

  Your developers have the capacity to build and no design to build from. Architecture, flows, screens and specifications arrive as a package they can work through.

• Structure before surface: information architecture and flows are agreed before any interface design begins.
• Design decisions are made as tokens — type scale, spacing, color roles, radius, motion — so they are reused rather than re-decided per screen.
• Every screen is designed at the narrow width first and given the extra space as the viewport grows, which is the opposite of shrinking a desktop layout.
• Accessibility criteria from WCAG 2.2 are applied at design time: contrast pairings, focus order, target size, and status that never depends on color alone.
• Interaction is specified in writing next to the screen it belongs to, so behavior survives the handover.