Flexibility: Product vs Service Design — With a 2024 Addendum on AI

Originally published September 2018. Addendum added December 2024.

2024 Addendum: The AI Layer as a Third Option

When I wrote this piece six years ago, I framed flexibility as a tradeoff between two layers: the product and the service. You could build flexibility into the interface—at the cost of usability—or push it up to the service layer, where human processes could absorb the complexity.

That framing still holds. But something fundamental has changed.

AI has emerged as a third layer where flexibility can live. Not as a feature bolted onto products, but as a genuinely different place to locate the burden of adaptation.

What makes the AI layer different

Traditional product flexibility asks users to understand their options and choose correctly. Service flexibility asks organisations to staff and train for exceptions. AI flexibility asks neither—or rather, it asks the system itself to bear the interpretive load.

Consider a document submission flow. The 2018 approach gave users choices: upload a file, take a photo, fill out a PDF. Each option added interface complexity. The service approach handled edge cases manually: a staff member would call users whose submissions were unclear.

An AI-mediated approach does something else entirely. It accepts whatever the user provides and figures out what to do with it. Blurry photo? Enhance it or extract what's legible. Wrong form? Map the fields to the right one. Missing information? Ask for just what's needed, conversationally, rather than rejecting the whole submission.

The flexibility still exists—the system handles tremendous variation in input—but it's invisible to the user. The interface stays simple because the intelligence sits behind it.

The new tradeoff: predictability

This isn't a free lunch. Each layer trades one kind of cost for another:

Product flexibility costs usability. Users must navigate complexity.
Service flexibility costs efficiency. Humans must handle exceptions.
AI flexibility costs predictability. The system's behaviour becomes harder to guarantee.

For some domains, unpredictability is unacceptable. Financial transactions, medical decisions, legal processes—these need deterministic behaviour that users and auditors can verify. Product and service flexibility remain the right choices here, even with their costs.

But for many other domains—onboarding flows, support interactions, content creation, search—some unpredictability is tolerable, even welcome, if it means users don't have to think about the system's constraints.

Choosing where flexibility lives

The question is no longer just "product or service?" It's now a three-way decision:

Put flexibility in the product when:

Users need direct control and visibility
The domain requires auditability
Variations are finite and well-understood

Put flexibility in the service when:

Exceptions require human judgment
Stakes are high and errors costly
Personal relationships matter

Put flexibility in the AI layer when:

Input variation is high but intent is clear
Speed matters more than perfect accuracy
Users shouldn't need to know the system's constraints

Most systems will use all three. The art is in knowing which variations belong where.

What this means for design practice

For product designers, the implication is significant: you may no longer need to expose every option in the interface. If AI can infer intent from behaviour or context, explicit controls become unnecessary. The skill shifts from designing comprehensive option sets to designing appropriate feedback—helping users understand what the AI understood and correct it when needed.

For service designers, AI changes the economics of exception handling. Many exceptions that once required human intervention can now be resolved automatically. This doesn't eliminate the service layer; it refocuses it on cases where human judgment genuinely adds value.

The core insight from the original piece—that usability should never be compromised, and flexibility should be traded elsewhere when it threatens usability—remains true. We simply have more places to trade it now.

The Original Piece (2018)

What is product flexibility?

Can't do forms online? Fill out a PDF and upload. Can't upload a photo? Take a photo using the device camera. Giving choice at the product level brings robustness and flexibility into the system. Users find this "easy to use" and there's a much higher chance of them completing their journeys.

For power users, the same principle applies differently. Your system might allow bulk actions, navigational shortcuts, contextual menus, additional options, permission systems, audit logs. Flexible systems serve more users in more situations. But flexible systems are usually complex.

Lidwell's flexibility-usability tradeoff

William Lidwell's Universal Principles of Design describes a flexibility-usability tradeoff: the more flexible something is, the less usable it tends to be.

There's nothing inherently unusable about flexible systems. The issue is what flexibility demands from users. Flexible systems require users to be more aware of their working context. Users need to understand their options at various stages, know the consequences of their actions, carry more cognitive load, maintain bigger working memory.

With flexibility comes complexity. We're simply asking users for more—more attention, more effort, more responsibility.

This tradeoff seems inevitable if we stay within the boundaries of the product. But the product is rarely the whole picture.

Trading flexibility up to the service layer

Services are bigger than products. Their surface area covers not just a system's internal processes, but the physical spaces, the human touchpoints, the offline-online boundaries. This wider scope gives services greater capacity to absorb complexity.

A service designer can distribute complexity elsewhere so that the product ends up simple.

Consider a government application process. A product-centric approach might build extensive validation, multiple document upload options, branching logic for different applicant types—all the flexibility needed to handle variation, all surfaced in the interface.

A service-centric approach might simplify the product to a single happy path, then create processes for handling variations: a triage team that reviews incomplete applications, a phone callback for complex cases, an in-person option for those who can't use digital channels at all.

The total system complexity might be similar. But the product complexity—what users experience—is dramatically reduced.

Service designers can advocate for modularity, breaking monolithic systems into focused components with limited responsibility. They can create handoff points where human judgment takes over from automated processes. They can design feedback loops that let exceptions inform future product improvements.

Product-service flexibility is the real tradeoff

The flexibility-usability tradeoff isn't wrong, but it's incomplete. It assumes flexibility must live in the product. Once we recognise that flexibility can migrate between product and service layers, a different tradeoff emerges: where should flexibility live?

One thing we should never compromise on is usability. When usability suffers, we should look back and ask why so much capability ended up in the product. Can this flexibility be traded up to the service level?

Sometimes the answer is no—the service organisation lacks capacity, or latency requirements rule out human intervention, or the edge cases are too frequent to handle manually. These are real constraints.

But often the answer is yes, it's just that nobody asked. Product and service design happen in silos. Product teams build flexibility into interfaces because that's what they control. Service teams deal with whatever products emerge.

Breaking that pattern might require a difficult conversation with a service owner. It might require changes to staffing or training. It might require a systems architect to rethink handoff points.

It's worth trying. Users shouldn't bear complexity that belongs elsewhere.