UX: the whole thing, not just the screens.

User Experience is the most misused term in product. Walk into any team and ask three people what UX is and you'll get three different answers: "the screens", "the wireframes", "the bit Figma does". And all three are wrong. UX is not the visible surface of the product. UX is everything the user feels while interacting with your organisation, from the moment they hear your name in a Slack channel to the moment they leave a one-star review after uninstalling. The screens are a small subset. A consequential subset, but small.

The canonical definition comes from Don Norman and Jakob Nielsen, the two people most responsible for the term existing in the first place. "User experience encompasses all aspects of the end-user's interaction with the company, its services, and its products." Note the order. Company first. Services second. Products third. The product is one channel among several. If your support is slow, your billing emails are confusing, or your sales team oversells, your UX is bad, even if the product itself is gorgeous.

The full scope.

The UX surface area runs from before the user has installed the product to after they've uninstalled it. Eight stages, roughly, and a competent UX function thinks about all of them:

• Discovery. How does the user hear about you? What's the first impression? Does the landing page tell the truth about what the product does? Most "UX problems" diagnosed in-app actually originate in this stage. The user arrived with the wrong expectations.
• Acquisition. The sign-up flow, the pricing page, the conversion path. The point at which the user decides to invest time. UX here is usually owned by growth, but it's still UX.
• Install / first run. Onboarding. The first ninety seconds. The empty state. The single most important UX moment in any product and the most consistently neglected.
• Ongoing use. The bit most teams call "UX". The daily, weekly, monthly interaction. Where features live.
• Support. What happens when something breaks. The help docs, the chat widget, the time-to-response. Heavily under-invested-in by most product teams.
• Billing and renewal. Invoices, payment failures, plan changes. The least sexy UX surface and the one where bad design loses you the most money fastest.
• The churn moment. The cancellation flow. The exit interview. The data export. Dark patterns here are a one-way ticket to a bad reputation.
• The return moment. Win-back, reactivation, the cold-start problem when a lapsed user comes back. Almost nobody designs for this stage and it's where some of the highest-LTV cohorts get created or lost.

An organisation that calls itself "UX-led" but only invests in stages 3 and 4 is not UX-led. It's UI-led. There's nothing wrong with being UI-led, but it should be named honestly.

The honeycomb — seven dimensions.

Peter Morville's UX honeycomb, written in 2004, is still the best one-page model of what "useful UX" actually contains. Seven facets, with Useful at the centre and the other six surrounding. The point of arranging them as a honeycomb rather than a checklist is that no single facet is sufficient. The design has to land on all of them at once, and most products land on three or four out of seven.

Diagram · Morville's UX Honeycomb — the seven dimensions

Morville's honeycomb. Useful sits at the centre: the foundational test. The six surrounding facets are all required for the design to actually deliver. Most teams ship having hit three of the seven and call it shipped.

Useful sits at the centre because everything else is wasted if the product doesn't serve a real user need. A beautiful, accessible, findable, credible product that doesn't do anything useful is a portfolio piece, not a product. Useful is the foundational test and the one that gets skipped most often, because by the time the team is in the design phase the assumption that the product is useful has been baked in and is no longer interrogated.

Usable is the one most people mistake the whole honeycomb for. Easy to operate, predictable, minimal friction. This is Nielsen's home territory and the most heavily researched of the seven. It's also the easiest to test. Usability testing exists as a discipline because of this facet.

Findable covers navigation, search, information architecture, sitemap, breadcrumbs. The user can locate what they need without an outsized cognitive load. A product can be perfectly usable in isolation per feature but unfindable as a whole. Most enterprise software falls into that hole.

Credible is whether the user trusts the product. Brand consistency, polish, the absence of bugs and the absence of dark patterns, the presence of social proof and transparent pricing. Credibility is what separates the products users recommend from the ones they tolerate.

Accessible means usable by people with disabilities, but more broadly, usable by everyone, including users on slow connections, small screens, in difficult contexts. The legal floor in most markets is WCAG 2.2 AA. The ethical floor is higher. The commercial floor is that accessible products serve more users.

Desirable is the emotional facet: does the user want to use this? Brand, voice, visual identity, the feel of the interactions. Desirability is what makes Apple Apple. Most B2B products under-invest in this facet because they assume their users have no choice. That assumption ages badly.

Valuable is the business facet — does the product deliver value to the organisation building it as well as the user? Morville added this seventh facet later, and it's the one product teams forget at their peril. A product that is useful, usable, findable, credible, accessible and desirable but unprofitable is a product that won't exist in eighteen months.

Why most "UX" job postings are UI jobs.

Open LinkedIn. Search "UX Designer". Read the responsibilities. "Design wireframes, prototypes, and high-fidelity mockups in Figma. Maintain the design system. Hand off to engineering." That is a UI job. It might include some thin research ("conduct usability testing as needed"), but the centre of gravity is the surface, not the experience. The hiring company has confused the two terms, because the visible deliverable of "UX work" is screens.

This matters because the person you hire to do UI cannot also do UX research, service design, journey mapping, support flow analysis, churn-loop investigation, and acquisition-funnel friction work. Those are different jobs with different skill sets. Hiring a UI designer and asking them to also own UX strategy produces a designer who is overwhelmed and a UX strategy that is shallow. Name the role honestly and you'll hire the right person.

UX as three jobs in one title.

What people call "UX" in shorthand is actually three distinct disciplines bundled together:

• Research. User interviews, usability testing, ethnographic study, surveys, analytics interpretation. The job of understanding what's true about how users behave and what they need. Most often delivered by a UX Researcher.
• Design. Information architecture, interaction design, prototyping, the visible surface. The job of shaping how the user moves through the product. Delivered by a UX/UI Designer or, increasingly, a Product Designer.
• Validation. Testing, instrumentation, qualitative-and-quantitative loop closure. The job of finding out whether the design actually delivered the intended outcome once it shipped. Often falls between Design and Product Analytics with neither side claiming it.

One person can do two of the three competently. Almost nobody does all three at senior level. If your team has one UX hire and you expect them to do all three, you'll get the one they're strongest at and the other two will be theatre. Decide which one matters most, hire for that, and supplement the others with the PM Piece or a freelance specialist.

When to hire UX vs UI vs Service Designer.

Hire a UX Researcher when the team's biggest risk is that you don't know what users actually want or do. Greenfield products, expanding into new markets, products with high churn whose cause isn't yet diagnosed.

Hire a UI Designer (or Product Designer) when the team's biggest risk is shipping inconsistent, ugly, or hard-to-use screens. Established product, clear roadmap, design debt mounting.

Hire a Service Designer when the team's biggest risk crosses channels. The user touches your product, your support team, your billing system, your salesforce, and the experience is fractured. Service design owns the cross-channel arc that UX-in-the-narrow-sense can't see.

Most product teams genuinely need all three over time, in that order: research first to know what to build, design second to build it well, service third to make the whole organisation feel coherent. The mistake is hiring in reverse.

UX research is the most-skipped step.

If I had to name one thing that distinguishes products that ship usefully from products that ship beautifully-but-uselessly, it would be the presence of recurring UX research as part of the team's rhythm. Not "we did some research at the start". That's discovery, and it ages out in months. Recurring research: a user interview every two weeks, a usability test every release, an analytics-led behaviour deep-dive every quarter. Teams that don't do this are designing into the void and finding out at retention metrics what they should have known at sketching.

The pattern in failing products is consistent: beautiful design, healthy roadmap, broken assumptions about what the user actually wants. The fix isn't more design ceremony. It's research that closes the loop between assumption and reality. Without it, UX is decoration on a building nobody's sure has a customer.

How we use this at Product Pieces.

UX shows up across our diagnostic in two ways. First, when a team says "we have UX problems" we always check which stage of the eight they actually mean. Eight times out of ten the team thinks they have an in-app UX problem when they actually have a Discovery or Onboarding problem. The user arrived expecting one thing and got another. Solving the wrong stage costs months.

Second, the honeycomb is a useful frame for the Diagnostic conversation. Walking a product through the seven facets surfaces which ones the team has under-invested in. The common gap is Accessible (treated as a tickbox not a discipline), Findable (sacrificed to feature growth), and Valuable (the team has stopped asking whether the work justifies its cost). Naming the gap is the start of the fix.

Next issue: N°21, UI. The surface of UX.