UX/UI and product design fundamentals

UX is the decision about what the product does and in what order a person does it; UI is the decision about what that looks like and how it responds to touch. The reason the distinction matters practically is that they fail differently and are fixed by different people. A beautiful screen that asks for information the user does not have is a UX failure, and no amount of restyling repairs it. A well-sequenced flow rendered with unreadable contrast and inconsistent spacing is a UI failure, and it is repairable in an afternoon. Interviewers ask this because candidates who conflate the two tend to describe visual work when asked about outcomes.

How content and functions are organised, labelled and related, independent of how any screen looks. It is the answer to where a thing lives, what it is called, and what sits alongside it. The reason it is a separate discipline from screen design is that navigation problems are almost never solvable at the screen level: if a user cannot form a mental model of the categories, a better menu component does not help. The cost of getting it wrong compounds, because URLs, search, analytics event names and the sitemap all encode the structure, so a late reorganisation is a migration rather than a redesign.

To make structural argument cheap. A wireframe deliberately strips colour, imagery and finished typography so the conversation is about what is on the screen, its priority and its sequence, rather than about whether the blue is right. That constraint is the whole value: stakeholders reviewing a polished mock discuss the polish. The cost is that a wireframe cannot answer anything about feel, timing or perceived performance, so it is the wrong artefact for a gesture-heavy interaction. Teams that have good component libraries increasingly skip wireframes for routine screens and reserve them for genuinely novel structure.

A segment is a group defined by attributes you can query — plan tier, region, tenure — so it is measurable and shows up in your analytics. A persona is a narrative composite standing in for a behaviour pattern, with goals, context and constraints attached, and it exists to make design trade-offs arguable in a room. The failure mode is a persona built from imagination rather than research, which becomes a device for laundering the team's assumptions into a document with a stock photograph on it. A persona should be traceable to interviews you can name.

A flow diagram shows the states a user can be in and the transitions between them, which is a description of your product. A journey map shows the whole arc of getting something done, including the parts that happen outside your product — the email they were reading, the phone call to support, the two-day wait for an approval — with what the person is trying to achieve and how frustrated they are at each stage. That off-product context is where most of the real improvement sits, and it is invisible to a flow diagram because your system never observed it.

An affordance is what an object makes possible: a surface affords pressing whether or not it looks pressable. A signifier is the perceptible cue that tells a person the affordance is there — the shadow, the underline, the label. Software gets this wrong in one specific direction: flat visual styles removed signifiers while keeping affordances, so elements remained clickable but stopped looking clickable. Keeping the words distinct lets you diagnose precisely, because "they did not know they could tap it" and "they tapped it and nothing happened" are different bugs with different fixes.

Naming them in sequence is the fastest way to show you have worked on a real product rather than read about the process.

artefact              answers                          who consumes it
--------------------  -------------------------------  ---------------------
research findings     what problem, for whom           PM, design, leadership
journey map           where the pain sits, end to end  PM, support, design
IA / sitemap          where things live, what they are engineering, SEO, content
user flow             which states and transitions     engineering, QA
wireframe             what is on the screen, priority  stakeholders, PM
high-fidelity design  exact appearance and states      engineering
prototype             feel, timing, sequencing         research participants
spec / redlines       tokens, breakpoints, edge states engineering, QA
usability findings    what broke when people used it   whole team

Read the right-hand column rather than the left, because the interview question underneath this is who the artefact is for. An artefact with no consumer is process theatre, and the most commonly produced example is a fully redlined static design handed to a team that already has the component library the design was drawn from.

The second thing to notice is that the list is not a waterfall even though it reads as one. Research findings and usability findings are the same activity at two points in the loop, and the interesting version of this answer says which artefacts you skip on a small change. A copy change needs none of them; a new onboarding flow needs most.

The artefact candidates most often omit is the spec, and it is the one engineering actually needs. A high-fidelity design shows one state at one width. The spec says what happens at 360px, what the disabled state looks like, which token the border uses, what the field does with a 200-character input, and what appears while the request is in flight. Everything omitted there gets decided by an engineer at speed, which is how a consistent design becomes an inconsistent product.