**Human-Centric Interfaces — building intuitive digital journeys and seamless user experiences.** The interface is where every architectural choice meets every customer; the work that happens here has to look effortless to be effortless. This page describes how we approach frontend frameworks, user experience design, and the broader customer journey that begins long before a user touches a screen and continues long after they close it.
Three layers, often confused, with very different stakes. The UI is the surface — the components, the pixels, the framework that renders them. The UX is the behaviour — the flows, the affordances, the laws of perception that make a surface feel intuitive or obstructive. The CX is the whole journey — the moments before, during, and after a session, across every channel the customer encounters. A team that conflates these layers builds a UI that ships, a UX nobody planned, and a CX that emerges accidentally from whichever channel team shipped last.
Treating them as distinct disciplines — staffed differently, measured differently, governed differently — is what separates an interface that works in a demo from a journey that retains customers. The frameworks (React, Angular, Vue) matter; the design system that scales them matters more; the customer journey that gives them meaning matters most.
React, Angular, Vue, and Svelte each carry different ecosystems, hiring profiles, and architectural fits. The choice locks in component libraries, state management patterns, testing tooling, build pipelines, and the talent market the team will hire from for the next half-decade. Picking by team enthusiasm or framework popularity is choosing by criteria that will not matter in three years; the criteria that will matter are ecosystem maturity, enterprise support, the team's current depth, and the integration cost with the rest of the stack.
State of JS Survey — annual industry telemetry on framework adoption, satisfaction, and trajectories that informs the long-horizon view.
A design system with disciplined component boundaries multiplies a team's velocity; a component soup divides it. The architectural property is not "we have a Storybook"; it is that every component has a single responsibility, a documented contract, predictable composition, and version semantics that allow it to evolve without breaking everything that consumes it. Without this, every new feature pays a tax to navigate, copy, modify, and integrate the existing code; with it, new features compose from existing pieces.
Storybook — the canonical tool for isolating, documenting, and testing component contracts; the discipline it enforces is more important than the tool itself.
Fitts's Law (target acquisition time depends on size and distance), Hick's Law (decision time grows with choice count), Miller's Law (working memory holds about seven items), Jakob's Law (users prefer your site to work like sites they already use) — these are predictions about user behaviour, not aesthetic guidelines. Designs that ignore them produce friction in measurable ways: longer task time, higher error rates, lower completion. Designs that respect them feel "obvious," which is the highest compliment a UX can receive.
Laws of UX — the canonical catalogue of cognitive and behavioural laws relevant to interface design, with citations to the original research.
Largest Contentful Paint above 2.5 seconds, Interaction-to-Next-Paint above 200ms, Cumulative Layout Shift above 0.1 — these are not abstract numbers; they are user perceptions of "the site is broken." Core Web Vitals are now Google ranking factors, conversion-rate predictors, and the closest objective measure of UX quality. Treating performance as a feature with its own product owner, budget, and release gate is the difference between a fast site and a site whose performance erodes one PR at a time.
Web Vitals — web.dev — Google's authoritative reference for the metrics, thresholds, and measurement methodology; informs almost every modern frontend performance practice.
A customer journey rarely happens on one screen, in one session, or on one device. It begins with an ad, continues through a search, picks up in an app, pauses at a phone call, resumes in a chat, and concludes with an email. Treating each channel as a separate product produces a fragmented experience where the customer has to re-explain themselves at every boundary. Treating the journey as the unit of design — with handoff semantics, state continuity, and consistent identity across channels — produces a CX that feels like one company instead of seven.
Forrester — Customer Journey Mapping — the canonical industry treatment of journey analytics as a discipline that crosses channel and team boundaries.
The instinct to build "an omnichannel experience" by adding more channels produces an explosion of duplicated content, divergent presentation logic, and brittle integrations. The architectural answer is to invert the structure: a single source of truth for content, products, prices, and rules, with each channel rendering that source contextually. The channels become views, not sources — and the channel team's job becomes optimising rendering, not reconciling data. Headless CMS, federated commerce, and content APIs are the patterns; the discipline is committing to them before the channel count gets out of hand.
MACH Alliance — the industry consortium that articulates the Microservices, API-first, Cloud-native, Headless architectural pattern under which modern omnichannel platforms are built.
The diagram below shows the canonical UI/UX/CX architecture: a design system feeding multiple channel renderers; a customer state service that all channels read from and write to; an analytics layer that measures the journey across channels; and a content-and-data backbone that decouples the rendering from the source of truth.
Picking a framework and treating its conventions as the entire architecture. Component boundaries, state shape, and API conventions are inherited from tutorials rather than designed for the product. Three years later, every framework upgrade is a partial rewrite.
The framework is a tool; the architecture is a separate decision. Component boundaries, state shape, and integration patterns are designed for the product and documented independently of framework specifics.
A "design system" that is a Figma file plus a Storybook, with neither one canonical and both diverging from production. Designers ship in Figma; developers ship in Storybook; production ships somewhere else. The system has the appearance of consistency without the property.
The design system is one source of truth, in code, used in production. Figma references the production tokens; Storybook is the documentation of what's deployed; design and engineering ship from the same artefact.
Performance work happens in the last sprint before launch, when most performance debt has accumulated and is expensive to remove. Wins are localised, regressions return quickly, and the team's perception is "performance is a one-time fix" rather than a continuous discipline.
Performance budgets are enforced in CI from day one. Each PR is judged against the budget; regressions are reverted, not negotiated. Performance work is continuous and small, not occasional and large.
Each channel has its own UX team, its own design language, its own state model. The customer experiences the seams; the company experiences the cost of duplicated work. New customer scenarios that span channels are slow to ship because every channel's team has its own backlog.
Journey-centric design with channel-specific delivery. The customer state, terminology, and core flows are owned at the journey level; the channel teams optimise their rendering and channel-specific adaptations within those boundaries.
Adding channels by aggregating per-channel content produces a maintenance burden that grows quadratically. Each new channel multiplies the integration matrix; each content change requires updates in N places.
Invert: a single content source, channel-specific renderers. The channel matrix grows linearly because each new channel adds rendering, not data plumbing.
Long-horizon criteria — ecosystem, talent, enterprise support, integration — drive the decision; the choice is defensible to a CTO joining in three years.
Single source of truth across design and engineering; visual regression testing in CI; component contracts that survive refactors.
Friction is named (Fitts distance, Hick choice count, Miller chunk size); decisions are testable; pattern libraries embed the laws so they don't get reinvented per screen.
Bundle, image weight, time-to-interactive thresholds; PRs that breach budget are reverted; regressions are caught at merge, not at customer report.
Lab benchmarks lie about real-user experience; RUM at p75 reveals what actual customers see and is the basis for SLO and regression detection.
One source of identity, preferences, and in-flight context; channels read from it, never silently fork it; handoffs preserve the context the customer just established.
Cross-channel paths are visible; questions like "how often does an in-app session escalate to a call?" have answers backed by data.
Headless content, federated commerce, channel-specific renderers; new channels cost rendering effort, not data integration effort.
Components ship accessible by default; audits are part of CI; the legal, ethical, and growth arguments for accessibility are taken as given rather than rediscovered annually.
Clear accountability for the cross-cutting concerns that have no natural home; without an owner, all three quietly degrade between releases.
Other substantive pages in the library that link here: