The 16x frame

The 16x frame is 4×4 matrix organizing into a design puzzle the 16 elements found in every service. Solving the puzzle results in the system-level design of a service, in the format of a strategic narrative – an executable script for orchestrating operations across the enterprise, to produce outcomes and experiences customers are most willing to pay for.

The designing of services is more important than ever. We depend more than ever on more services. Too small to notice or too big to fail, they have far reaching consequences. We have to be more prescient about the risks of systemic failures. And less innocent about why services fail despite the efforts that go into designing them.

Services fail because of gaps and conflicts in their designs.

Designs have gaps: missing elements of design that become visible only from the failures they cause. This has little to do with ‘lack of empathy’ for users, or not enough UX. It has a lot with the lack of fuller representations of services as dynamical systems. Unlike in manufacturing, the designs of services don’t have digital twins.

Designs have conflicts of interests: between customers and users, and providers and agents. What’s good for one group may not be good enough for another. Good designs produce higher values for both sides at the lowest possible cost. In essence, they are beautiful contracts that reduce conflict, reward cooperation, and reject compromise.

But even ‘good services’ aren’t good enough when customer needs change, competition becomes more compelling, or do-it-yourself more attractive. Designing services is hard enough. Making changes is harder. Changes can be disruptive because the designs are live, or in operation. Changes from one side require cooperation from the other. Changes may create new gaps and conflicts, and thus new kinds of failures, invisible on maps and blueprints, and waiting to happen.

Some failures are so far removed from the changes that ultimately cause them, the ‘undo button’ is out of clicks.

Thus the designing of services requires the collective intelligence of many disciplines, and a dialogic process that makes the designs free of gaps and conflicts. But that is difficult because every discipline has its own way of thinking, because as John Kay says, they prefer to understand and interpret things through their own ‘best and most helpful’ models – ones that make them smart and efficient.

Therefore, to make the design process more inclusive, we should store designs in an open format, so everyone can read or write, analyze or interpret, and criticize or correct a design. Regardless of their function or discipline, training or education, culture or background.

A story format.

It is through stories that we best absorb arguments and make sense of a complex world. We prefer to tell stories than to use analytic models, and the best and most helpful models are, at their root, narratives.

~ John Kay

Design is for implementation. Therefore, to be suitable for ‘storing designs’, our stories should be like ‘scripts’. Clear, concise, and complete. They should have multiple threads, to avoid gaps and conflicts, woven together into a single coherent narrative.

The 16x Frame
The 16x frame is a 4×4 matrix that organizes the 16 elements of design found in every service. It is a thinking tool for developing strategic narratives. Each narrative has 16 sentences. Each sentence is a declarative statement, communicating strategy through that particular element of design. Teams implementing the strategy, interpret statements within the context of their own work.

Working on a strategic narrative for the service that clothes and equips soldiers.

Each narrative is woven from eight story threads: one each for the eight perspectives from which to design a service. Each thread has four sentences in a who-why-how-what sequence. The threads are interwoven in a pattern that ensures every sentence of the strategic narrative, appears in two different threads. This allows teams to work independently with autonomy and power, without the usual risks.

The 16x is a design puzzle. A Sudoku of statements, as some call it. 16 declarative statements that define the who, why, how, what of a service, within a window of opportunity (when and where). Solving the puzzle is in effect an act of design at a structural level. And it’s hard.

Why make it hard? It forces you to consider the design from eight different perspectives. Only by solving the puzzle you get the 16x narrative. Think of this as “proof of work”. It creates confidence in execution.

This proof of work aspect is endearing to those who are tired or disillusioned by the superficiality of the ‘user story’ and the ‘burgeoning backlogs’. No surprise that early adopters of the 16x framework have been largely in government, aerospace & defense, and healthcare.

The 16x frame as a design puzzle implements the following tenets:

  1. An embedded logic that guides thinking and corrects it.
  2. Work with incomplete or imperfect information, and use critical reasoning (deductive, abductive, etc.) to fill the gaps and resolve conflicts.
  3. Always design from multiple perspectives.

Every function/discipline has its own biases and blind spots. The frame has eight interlocking loops or threads thus solving for 16x helps cancel biases and cover blind spots, with arguments and counter-arguments. Dialectic process.

Keep in mind we’re working at a structural, architectural, or macro level. That each statement adds up from, or unpacks into, detailed design. The 16x narrative is hypertext, pointing to documents and discussions that explain design decisions, elaborate or substantiate.

Thus the 16x narrative is not just some story with a dramatic arc, but an executable script that is clear, concise and complete — a reduced set of instructions for the enterprise (instead of a machine). Thus we go from idea to concept, from concept to code (see slidedoc).

16x frame standardizes service definitions in an object-oriented manner. If we define every service as a set of four promises (in terms of who, why, how, what, when, where), we can systematically construct an ecosystem of services that talk to each other. Think in terms of API.

The vision behind this entire approach is to be able to encode and express policy and strategy through design-as-code. This may lead to smarter, shorter product backlogs. With 16 tags for encoding. Not just for development, but also for procurement.