Attitudes
An attitude is a disposition, not an activity. You cannot tell whether a team holds one by asking; you can tell by watching what happens when holding it is inconvenient.
Three of them, and the third follows from the first two rather than standing beside them.
The person who has to use the thing is a first-class input — at inception, and still while it is being built.
The test: can a user need send a story back, the way a cost estimate can? If the answer is “we would note it for later”, the user is a stakeholder to be informed, not an input to the decision.
Every boundary is written down and agreed before it is implemented, and the agreement is checkable by a machine. The boundary between design and code is a boundary like any other.
The test: does something fail when the contract is breached? A design system that nobody generates from is a document two teams politely disagree with.
The second test, and the one this hub keeps returning to: is the contract an input to your sessions, or an output of them? A team that designs its buttons inside a story does not have a contract yet.
Given both contracts, the visual is largely settled and the remaining risk is whether a person can get through. So the testing effort goes on the journey, and pixel comparison is demoted to a change detector.
The test: when the suite is slow, what gets deleted first? A team that deletes journey tests to keep screenshots is not journey-first, whatever the strategy document says.
How they compose
Section titled “How they compose”They are not independent, and the order is a dependency rather than a preference.
| Produces | Depends on | |
|---|---|---|
| User-first | The journey, the states, the cost of getting it wrong | Nothing — it is the input |
| Contract-first | An established design system and core component library, maintained by change request | User-first, or you write down the wrong agreement precisely |
| Journey-first | Where the test budget goes | Contract-first, or the pixels really are still risky |
Running them out of order produces the recognisable failures. Contract-first without user-first gives a beautiful design system for a product nobody can use. Journey-first without contract-first gives a thin journey suite over an interface where every screen invents its own button — and then the screenshots really were load-bearing.
The relationship to dev-hub
Section titled “The relationship to dev-hub”These are the interface-facing members of a larger family. dev-hub holds test-first, contract-first and API-first for the software behind the interface, and the contract-first entry here is the same disposition applied to a different boundary. The two hubs are meant to be read together.