Loading…
Design Anatomy
A design practice has to hold nine capabilities. Which of them sit centrally and which sit with the teams is a choice — and the Framework is deliberate about not making it for you. The Design Architecture Office is defined by architectural responsibility rather than organizational hierarchy, which is another way of saying the capability is required and the shape is yours.
UX
The interface. Research, flows, states, components — real craft, real scope.
All of it downstream of decisions made somewhere else.
Enterprise Design
What a person actually gets — assembled from the policy, the data, the handoff, the wait, and the exception nobody wrote a rule for.
Some of that renders on a screen. Most of it never does.
Everything that never renders sits outside the narrower word, so it belongs to nobody — not because anyone refused it, but because the word stopped reaching that far. You cannot staff a role your vocabulary does not describe.
Arrangement
One architectural function holds memory, patterns and standards. Coherence is the default and has to be actively given up.
The tension. The seams between the centre and the work get longer. Distance from delivery is the thing that quietly erodes judgment, because judgment develops through consequence.
Person
Discernment. No method or model can supply it.
Practice
The three domains an architect designs across, simultaneously.
Enterprise
What turns one team’s learning into the organisation’s capability.
Choose a capability to see what it owns, what it explicitly does not, and how it comes to exist. The boundaries matter more than the mandates — a practice that claims everything owns nothing in particular.
Who owns the rest
Every function below owns its domain completely and legitimately. None of them owns the relationships between the domains — and those seams appear on no one’s job description. That space is the practice.
UX
The interface, and how it is researched and composed
Blind to: The part of the experience that never renders
ML engineering
The models — development, training, performance
Blind to: Whether the output arrives inside a decision someone may make
Software engineering
Implementation, and whether the code runs correctly
Blind to: Whether a person and an agent can share the work without confusion
Product
Priorities and what the organisation chooses to build
Blind to: Whether the pieces compose into a capability
Legal, compliance, risk
Policy — the rules and the tolerance
Blind to: The conditions under which behaviour can be observed against them
Operations
The execution of the work itself
Blind to: Who is accountable when the work is shared with a system