Shared by Design: Building UK Services Around the Household, Not the Individual

Most product teams begin with a persona: a named individual with goals, frustrations and a device in hand. That model remains useful, but in the UK it is often incomplete. Energy accounts are managed by one partner and paid by another. Bank accounts are joint, delegated or monitored by carers. NHS appointments are booked on behalf of children and older relatives. Streaming subscriptions are shared across families and flatshares, sometimes across several postcodes. The household, not the individual, is frequently the real unit of decision-making.

This is not a marginal edge case. It is a mainstream design gap. A household-centred approach does not mean abandoning individual accounts. It means recognising that many services are used in a social context, with uneven knowledge, authority and risk. The design task is to make that context visible and governable.

The single-user assumption

Most digital services still assume that one login equals one person. Billing, notifications, consent and data visibility are built around that assumption. When reality diverges, households improvise. Passwords are shared. Screenshots are sent. One person becomes the unofficial administrator for Everyone else. These workarounds are common, but they are also fragile. They obscure who did what, weaken security and make it difficult to withdraw access when circumstances change.

The single-user assumption is particularly awkward in UK services where responsibility is distributed. An energy account may have a bill payer who is not the account holder. A banking app may be used by a carer who manages day-to-day spending but should not see savings. A streaming service may be paid by one household member and used by several, including children with different content permissions. Designing for the individual alone forces these relationships into private, unmanaged channels.

Map roles before permissions

A household-centred paradigm starts with roles, not features. Product teams should identify the distinct responsibilities that exist around a service: account holder, payer, administrator, viewer, carer, dependent and guest are useful starting points. These roles should be scoped by task, time and data sensitivity rather than by a single access level.

In energy, the person who pays the bill may not be the person who reads the smart meter or adjusts heating schedules. In banking, a carer may need transaction alerts but not the ability to move money. In healthcare, a parent may manage a child's appointments while an adult sibling handles transport. A permission matrix that reflects these distinctions is more useful than a binary choice between owner and guest.

Roles should also be time-bound. Delegated access for a carer might need to last for a recovery period, not indefinitely. A guest role for a flatshare might end when a tenancy ends. Designing expiry and review into permissions reduces the risk of stale access and makes the household model easier to maintain.

Make shared visibility deliberate

Households need shared views, but they also need privacy boundaries. A shared dashboard that exposes every transaction, appointment or viewing history is not neutral. It can create pressure, surveillance or conflict. The design challenge is to offer shared visibility without collapsing individual privacy.

One pattern is a household summary that shows aggregate activity and exceptions rather than raw detail. Another is a private zone within a shared account, where individual data remains visible only to the person concerned unless they choose to share it. A third is purpose-limited sharing: a carer might see medication reminders but not clinical notes; a partner might see the energy balance but not detailed usage by room.

These choices should be explained in plain language. UK users are accustomed to privacy notices, but they rarely see how visibility works in practice. A short, contextual explanation at the point of sharing is more useful than a long policy document. It also helps households agree on what should be shared before a problem arises.

Consent as a living agreement

Consent in household services is rarely a one-off checkbox. It is an ongoing negotiation. A person may agree to share data while a care arrangement is in place, then withdraw that agreement later. A couple may jointly manage an account, then separate. A child may gain more control over their own data as they grow older.

Product teams should treat consent as a living agreement with review points. Delegated access should have an expiry date, a visible record of who granted it and a simple route to revoke it. Consent receipts, activity logs and periodic review prompts can help households keep the agreement current. Under UK GDPR, consent must be freely given, specific and withdrawable; household design should make those principles tangible rather than abstract.

This is especially important in health and care settings. NHS login and proxy access have made progress in allowing relatives to act on behalf of others, but the user experience still needs to handle changing capacity, temporary delegation and disputes. A household-centred design approach can make those transitions clearer for both patients and carers.

Design for disagreement and exit

Households disagree. They disagree about spending, subscriptions, heating, care decisions and screen time. A service that assumes harmony will fail at the point of conflict. Designers should test for disagreement as a normal scenario, not an exception.

Useful patterns include two-person approval for high-risk actions, such as large payments or changes to care arrangements. A pause and request approval flow can prevent one household member from making irreversible changes without discussion. Activity logs can show what changed and who changed it. A handover process can transfer administration cleanly when circumstances change. An exit route should allow a household member to leave a shared arrangement without losing their own data or being locked out of essential services.

Conflict resolution is not about adding bureaucracy. It is about making the social contract of the service visible. When a household can see the rules, the roles and the records, disagreements are less likely to become support tickets or security incidents.

What UK teams should do next

Household-centred design does not require a complete rebuild. It starts with research that includes households rather than isolated users. Teams should observe how decisions are actually made, who holds the password, who pays, who needs to know and who is excluded. They should map roles and permissions before designing screens, and test with conflict scenarios as well as happy paths.

UK services already operate in a regulated environment that recognises shared responsibility. Ofgem rules, FCA expectations, NHS proxy access and CMA subscription protections all point towards clearer household arrangements. Product teams can align with those frameworks by designing permissions, visibility and consent as first-class features.

The household is not a edge case. It is a design paradigm. For UK product teams, the opportunity is to build services that reflect how people actually live: together, unevenly and with changing responsibilities.