UI/UX design courses: from a user problem to a testable prototype

UI, UX and product design: what each one solves

UX covers the whole experience of trying to achieve a goal: what a person understands before arriving, how they find information, what causes uncertainty and what follows an action. UI is the visible, interactive layer—layout, typography, controls, states, messages and hierarchy.

A polished visual layer cannot rescue a broken structure, while sound structure can still fail when controls and feedback are ambiguous. A credible course brings both disciplines together in one project instead of isolating them in separate theory decks.

Before the mock-up: frame the task and the evidence

‘Make the website more modern’ is not an actionable problem. Describe the situation, the user’s goal, the observed obstacle and the evidence. Evidence might be recurring support questions, search data, a funnel drop at a known step, an interview or usability observation. One metric without context does not explain the cause.

When [a specific user] tries to [complete a task] in [a context],

they encounter [an observed barrier], supported by [evidence].

We will test [a change] by observing [a behaviour] alongside [a quality guardrail].

The complete UI/UX workflow

Design the flow, including the non-ideal states

Portfolio galleries often show only the perfect starting state. Products also live in empty, loading, error, completed, unavailable and success states. If a form rejects an entry, a person needs to know what failed, where to fix it and whether the rest of their work remains intact.

Map the flow before drawing high-fidelity screens. For every step, record the user’s question, required information, action, system response and recovery path. This exposes missing content and unhandled exceptions early, when changes are inexpensive.

• Entry and return point
• Primary action and intelligible result
• Empty, loading, error and success states
• Cancellation, back navigation and data preservation
• Mobile layout and long translated copy

Figma is a workspace; a prototype is a question

Figma supports components, variants, auto layout and clickable prototypes. Component count is not a measure of design quality. Before prototyping, state the question: can a participant find the price, understand the next step, notice an error or compare options? Include only enough screens to test that question.

Document the default, hover, focus, active, disabled, loading and error states when relevant. Handoff becomes safer when a design communicates behaviour and constraints, not only a static arrangement of pixels.

Accessibility as a design baseline, not a final audit

WCAG 2.2 adds criteria related to focus visibility, dragging alternatives, minimum target size, redundant entry and accessible authentication. Designers can prevent many failures before development by addressing structure, colour, component states, instructions and error messages.

Contrast is not only a text issue: controls, focus indicators and meaningful graphical parts also need to be perceivable. Colour alone should not carry an error or status. Keyboard order and semantics require implementation checks, but the design must anticipate them.

• Clear heading and content order
• Readable text and meaningful interface contrast
• Visible focus state
• Adequately sized and separated action targets
• Labels and errors that do not rely on colour alone
• Layouts that retain content when enlarged and on small screens

Test the task and pair conversion with a quality guardrail

In a usability session, do not demonstrate the correct path. Give the participant a situation and goal, then observe where they pause, misinterpret something or expect a different response. A handful of observations is not statistical proof about an entire market, but it can expose recurring structural problems to revise and test again.

Pair a conversion metric with a guardrail. If a shorter form increases submissions, also watch the proportion of qualified enquiries, correction rate, cancellations or support contacts. Otherwise an apparent optimisation may simply move work and frustration to the next team.

How to compare a UI/UX course and build an honest portfolio case

A strong case study shows more than final screens: the initial question, evidence, important trade-offs, a prototype test, the revision and what remains unknown. You do not need invented user counts or unsupported conversion lifts. A candid description of limitations is more professional than an impressive but unverifiable result.

• Does the work begin with problem framing and content?
• Must you design error and other non-ideal states?
• Will the prototype be tested with a task rather than simply presented?
• Will feedback address decisions and accessibility?
• Can the process be shown without exposing confidential data?

Hexa Academy lesson format

Lessons are available one-to-one or in a small group, in Rīga or online. A 60-minute individual lesson is €50 + VAT; a small-group lesson is €30 + VAT per person. The programme can centre on your own site—from problem framing and flow to a prototype, test plan and explicit next step.