5.1 UX foundations¶

Overview and motivation¶

User experience (UX) is about understanding people (their goals, their contexts, their constraints) and then shaping software so it helps them succeed with the least friction. It is not decoration you apply at the end. It is a way of working that begins before the first line of code and continues well after release. This chapter covers the research, modeling, and design-thinking practices that let a large organization make product decisions from evidence rather than from guesses.

For large teams, UX is a coordination problem as much as a craft. When dozens of squads ship into one shared product, mismatched mental models, duplicated flows, and contradictory terminology pile up into a confusing whole that no single team owns. A shared UX foundation, built from common personas, agreed journey maps, and a documented information architecture, gives every team the same map of the user, so their separate decisions add up to a coherent experience. Without it, each team optimizes locally and the product as a whole makes no sense.

Enterprise and government raise the stakes. Enterprise software often has captive users who cannot walk away, so bad UX gets paid for in training, support tickets, errors, and lost productivity rather than in people leaving. Government services often reach the entire public, including people in crisis, on old devices, with low digital confidence, or with no alternative provider. Here UX quality is a matter of equity and civic trust: a poorly designed benefits application can deny someone food or housing, not because they are ineligible, but because they could not finish the form.

Key principles¶

• Design for real people doing real tasks in real conditions, not for an idealized user on a fast connection with full attention.
• Research reduces risk. The cheapest time to discover a wrong assumption is before you have built on top of it.
• Users cannot reliably tell you what they will do; observe behavior, not just stated preference.
• Focus on the job the user is trying to get done, not the feature you want to ship.
• Consistency is a feature: a coherent mental model across the product lowers cognitive load.
• Accessibility and inclusion are part of good UX from the start, not a later compliance pass.
• Qualitative and quantitative methods answer different questions; use both.
• Small, frequent research beats rare, heavyweight studies.

Recommendations¶

Establish continuous, mixed-method research¶

Aim for a lightweight but continuous research practice rather than occasional big studies. Interviews reveal motivations and mental models. Usability testing reveals where designs break down; five to eight participants per round surfaces most of the severe issues. Surveys measure attitudes at scale but cannot explain the "why." Analytics and instrumentation show what people actually do across the whole population. Pair a qualitative method (why) with a quantitative one (how many), so findings are both explained and sized. And keep a research repository, so insights stay searchable and reusable across teams instead of getting lost in one squad's slides.

Model users with personas, journey maps, and jobs-to-be-done¶

Build a small set of evidence-based personas that capture goals, contexts, and constraints, not demographic caricatures. Frame needs as jobs-to-be-done, the underlying outcome a user is trying to achieve rather than a feature ("when I lose my job, I want to quickly understand what support I qualify for, so I can keep paying rent"). This keeps the focus on outcomes rather than features. Journey maps chart the whole experience across channels and over time, exposing gaps and handoffs that no single screen reveals. For services with heavy back-stage operations (call centers, caseworkers, fulfillment), use service blueprints to connect the front-stage experience to the systems and staff behind it.

Design the information architecture deliberately¶

Information architecture (IA) is how content, features, and navigation are structured and labeled. Use card sorting and tree testing to derive that structure from users' mental models rather than from your org chart. A common failure in large organizations is exposing internal departmental boundaries as top-level navigation. Establish a controlled vocabulary so the same concept has the same name everywhere. Interaction design then defines the moment-to-moment behavior: states, feedback, error recovery, and the flow between steps.

Apply design thinking pragmatically¶

The double-diamond model (diverge then converge to define the right problem, then diverge and converge to design the right solution) is a useful frame. Treat it as a mindset, though, not a rigid gated process. In practice, run tight loops: frame a hypothesis, sketch, test with a handful of users, and learn within days. Save the heavier discovery for genuinely novel or high-risk problems. And watch out for "innovation theater," where workshops produce sticky notes but no shipped change.

Integrate UX into delivery¶

Embed designers and researchers in delivery teams rather than running a separate "UX department" that hands off specs over a wall. Make research findings a standing input to prioritization. Put UX quality gates, such as usability benchmarks and accessibility checks, in the definition of done. And track outcome metrics (task success, time on task, error rate, satisfaction) right alongside your delivery metrics.

Trade-offs: pros and cons¶

Every organization balances research investment against delivery speed. The mistake is treating this as either-or. The productive stance is proportional: spend more discovery on decisions that are expensive to reverse (core IA, primary flows, platform choices), and less on details you can easily change later. The cost of research is almost always small next to the cost of building the wrong thing well.

Examples¶

Startup. A four-person startup building a scheduling tool for small clinics had strong opinions about what receptionists needed, but no evidence. Before writing more features, the founders sat beside five receptionists for an afternoon each and watched them work. They learned that the real pain was not booking speed but double-bookings caused by a confusing calendar view, something no one had thought to mention in earlier sales calls. Reframing the product around that one job, and sketching and testing fixes with the same five people over a week, turned a stalling trial into their first paying customers.

Enterprise. A multinational bank consolidated seven regional internal loan-origination tools into one platform. Rather than merging feature sets, the team ran journey mapping and service blueprinting with underwriters across regions. They found that the "regional differences" everyone assumed were mostly inconsistent terminology and screen order, not genuine process differences. A unified IA and shared vocabulary cut underwriter training time substantially and reduced processing errors, because staff now shared one mental model.

Government. A national tax authority redesigning its online filing service ran moderated usability testing with taxpayers spanning ages, devices, and digital-confidence levels, plus assisted-digital observation of people who normally rely on help. Testing revealed that jargon-laden section headings caused people to abandon or misfile. Reframing content around taxpayers' jobs-to-be-done, and restructuring the IA around life events rather than internal tax codes, increased successful self-service completion and reduced call-center volume, directly lowering cost to serve while improving equity of access.

Business case: motivations, ROI, and TCO¶

The return on UX comes from three levers: more success (more users complete valuable tasks), lower cost to serve (fewer support contacts, less training, fewer errors), and less rework (catching wrong directions before they are built). In enterprise settings where users are captive, the payoff shows up as productivity and fewer errors rather than conversion; a few seconds saved per transaction, across thousands of employees, compounds into large annual savings.

Total cost of ownership has to weigh the cost of adopting against the cost of not adopting. The adoption costs are easy to see: researchers and designers, recruiting and incentives for participants, tooling, and time in the schedule. The cost of not adopting is larger but harder to spot: abandoned transactions, support and training overhead, expensive late redesigns, failed launches, and reputational or legal exposure when public services exclude people. Because these costs are spread across support, training, and operations budgets rather than the product line, leadership often underestimates them.

To make the case to leadership, tie UX to metrics executives already track: completion and conversion rates, cost per transaction, support ticket volume, training days, and error and rework rates. Run a small, instrumented pilot that shows a measurable before-and-after, then extrapolate across the portfolio. Framing research as risk reduction on irreversible decisions tends to resonate with finance and governance stakeholders.

Anti-patterns and pitfalls¶

• HiPPO-driven design: decisions made by the highest-paid person's opinion instead of evidence.
• Research theater: studies run to justify decisions already made, findings ignored.
• Personas as fiction: invented profiles never validated against real users, used to win arguments.
• Org chart as IA: navigation that mirrors internal departments rather than user tasks.
• Big-bang research: rare, expensive studies that arrive too late to change anything.
• Testing only the happy path: ignoring error states, edge cases, and users under stress.
• Design as a final coat of paint: bringing UX in only to make a finished build "look nice."
• Ignoring assisted and non-digital users: designing only for confident, connected users.

Maturity model¶

Level 1: Initial. No dedicated UX practice. Decisions made by opinion. Research, if any, is ad hoc. Inconsistent flows and terminology across teams.

Level 2: Repeatable. Some designers and occasional usability testing. Personas may exist but are not maintained. UX is a phase, not a continuous practice, and often bypassed under schedule pressure.

Level 3: Defined. Continuous mixed-method research feeds prioritization. Shared personas, journey maps, and IA are maintained and used across teams. UX quality gates exist in the definition of done. A research repository is searchable.

Level 4: Optimizing. Research is continuous and outcome-linked. UX metrics are tracked alongside business metrics and inform strategy. The organization runs controlled experiments, closes the loop from insight to shipped change to measured effect, and continuously refines its models of users.

Ideas for discussion¶

• How much discovery is "enough" before committing to a direction, and who decides?
• How do you keep personas and journey maps alive rather than letting them become stale artifacts?
• When quantitative analytics and qualitative research disagree, which do you trust and why?
• How should a large organization balance a central UX standard with each team's autonomy?
• What is the right way to research services used by people in crisis without adding to their burden?
• How do you measure the ROI of research that prevents a mistake you therefore never made?

Key takeaways¶

• UX is a way of working from the start, not decoration at the end.
• Combine qualitative methods (why) with quantitative methods (how many).
• Model users with evidence-based personas, journey maps, jobs-to-be-done, and service blueprints.
• Structure information around users' mental models, not the org chart.
• Treat design thinking as a pragmatic mindset with tight learning loops, not a rigid process.
• The cost of research is small compared with the cost of building the wrong thing.
• In enterprise and government, UX quality translates directly into productivity, cost to serve, and equity of access.

References and further reading¶

• Don Norman, The Design of Everyday Things
• Steve Krug, Don't Make Me Think
• Erika Hall, Just Enough Research
• Kim Goodwin, Designing for the Digital Age
• Louis Rosenfeld, Peter Morville, and Jorge Arango, Information Architecture: For the Web and Beyond
• Clayton Christensen et al., Competing Against Luck (jobs-to-be-done)
• Alan Cooper, The Inmates Are Running the Asylum
• Jakob Nielsen, Usability Engineering
• UK Government Digital Service, Service Manual and Design Principles
• U.S. General Services Administration, 18F Methods and the U.S. Web Design System research guidance
• Nielsen Norman Group, research method articles and reports