Design an interface people can understand

A user interface (UI) is the visible and manipulable part of a product: structure, copy, controls, colors, motion and system responses. It is not judged by appearance alone. A good interface reduces the guessing between an intention and an action.

Starting question — What must the person understand and do now, and how will they know the system received the action?

This sheet follows one example: a person opens a flashcard review session, answers a card and resumes the session after an interruption. Each principle becomes an observable decision.

UI and UX: two angles on one problem

UX (user experience): the problem, context, expectations, journey, emotions, constraints and result of use.
UI (user interface): the elements that make that journey visible and manipulable.

The distinction helps frame questions, but should not split the work. A poorly named navigation is an information architecture and microcopy problem; a button that cannot be reached by keyboard is both an interface and experience problem.

Mental model before visual style

A person arrives with a representation of what they think they can do. They look for cues, predict, act and compare the result with their expectation. An interface is clear when these four moments connect without unnecessary surprise:

Orientation: where am I and what is this screen for?
Choice: what can I do, and which action is primary?
Action: how does the element show its use?
Feedback: what changed, and what can I do next?

The designer’s job is not to guess private thoughts. It is to make cues, states and rules observable enough for behaviour to be understood.

A hierarchy that guides the eye

Visual hierarchy is the reading order suggested by composition. It comes from consistent relationships, not an isolated effect.

Position puts goal and related action on the same reading path.
Size and weight distinguish real levels of content.
Space groups what belongs to one decision and separates different ones.
Color and shape signal action or state; they should not decorate every element until priorities disappear.
Repetition gives the same role the same appearance and behaviour.

If everything is large, colorful and elevated, nothing is primary. Remove noise before adding style.

Layout: a map, not a maze

Start with a readable container, a grid, groups and regular spacing. A grid is not a graphic prison; it prevents every screen from inventing its own distances.

page
├── navigation and location
├── screen goal
├── main content
│   ├── question or information
│   ├── primary action
│   └── help, state or result
└── secondary actions and return

Extra columns are useful when they reduce back-and-forth, not when they merely fill the available width. Keep reading lines short enough for the eye to hold the sentence.

Typography: copy is interaction

Typography should answer four questions:

Can the person read without fighting the background or zooming immediately?
Can they distinguish heading, explanation, help and error?
Are lines and spacing comfortable enough to follow the idea?
Do labels describe the result of the action?

A small scale is often enough: heading, subheading, body, label and help. Put sizes, line heights and weights in tokens. Do not use capitalization, italics or low opacity as the only state signal.

“Save answer” is more useful than “OK” because it announces the result. Copy is part of UI: it explains a rule, reduces hesitation and offers recovery after an error.

Color and contrast: signal without excluding

Color can reinforce a message but should never carry it alone. A “correct” state can combine explicit text, a stable icon or shape, a consistent border or position and verified contrast. Separate colors by intent: accent, information, success, warning and error. Check text, controls, focus and non-text elements in their real states.

Components are contracts

A component is more than a reusable rectangle. Its specification says:

which problem it solves and which action it represents;
which HTML element naturally expresses that role;
which properties are required and which are forbidden;
which states exist: idle, hover, focus, pressed, loading, success, error, empty and disabled;
which accessible name and feedback it exposes;
how it behaves at 320 px, with long copy and with a keyboard.

If a variant has no identifiable intention, it is probably decoration in disguise.

Design states, not only the ideal screen

State	What the person needs to understand	Useful exit
Idle	The question and available action	Reveal or answer
Loading	The action was received	Wait without duplicate submit
Success	The answer was saved and the session moved on	Continue or review
Empty	No card matches the filter	Change filter or create a card
Input error	What needs correction	Return to the field
Network error	The server did not respond	Keep draft and retry
Access denied	A session or permission is missing	Sign in without losing input

An error message names the problem in task language, points to its location and offers an action. “Something went wrong” does none of those things.

Forms: reduce hesitation

Use a <form> and button type="submit" for a group of submitted fields.
Associate every field with a visible label; a placeholder is not a label.
Explain predictable constraints before submit.
Validate at the right time: do not punish composition, but do not hide a known error until after a long sequence.
Move focus to the first error and connect the message to the field.
Keep input during a network error or sign-in flow.
Disable repeated submit during a request and announce what is happening.

Responsive: change priority, not only size

At a smaller width, decide what stays visible, what can be grouped and what can wait. Prefer one readable column to two compressed ones. Keep primary actions reachable, space touch targets, preserve essential information outside hover and test at 320 px, 200% zoom, larger text and with longer translations.

Applied example: the current card

Before: a quiet heading, a centred card, four indistinguishable buttons and an unlabeled progress bar.

After:

<main aria-labelledby="session-title">
  <h1 id="session-title">Review session</h1>
  <p>Card 3 of 10 · 4 minutes left</p>
  <article aria-labelledby="question-title">
    <h2 id="question-title">What is a mental model?</h2>
    <button type="button" aria-controls="answer" aria-expanded="false">
      Reveal answer
    </button>
    <p id="answer" hidden aria-live="polite">
      A representation that helps predict how a system works.
    </p>
  </article>
  <p role="status" aria-live="polite"></p>
</main>

The structure carries meaning: page heading, card heading, native button, control-to-answer relationship and result announcement. CSS makes the hierarchy visible without replacing these relationships.

FlashLearning workshop

Before reading the answer, explain in your own words:

What is the screen’s primary goal?
Which information supports the choice?
How does the person know the action succeeded?
What can they do if the network fails?

Compare with a strong answer

The goal is to answer the current card. The question, card number and named button sit in the same reading path. Visible and announced feedback confirms the save. If the network fails, the input remains and “Retry” recovers the state without starting over.

UI delivery checklist

Reference sources

Practise the decisions in the interactive UI/UX path. For implementation, see CSS for an interface, design systems and accessibility.

UI and UX: two angles on one problem​

Mental model before visual style​

A hierarchy that guides the eye​

Layout: a map, not a maze​

Typography: copy is interaction​

Color and contrast: signal without excluding​

Components are contracts​

Design states, not only the ideal screen​

Forms: reduce hesitation​

Responsive: change priority, not only size​

Applied example: the current card​

FlashLearning workshop​

UI delivery checklist​

Reference sources​