Framework

The previous post argued that service patterns - the repeatable structures of work that users perform across multiple products - need to be understood before the components that implement them can be...

A few months into building components for the design system, I keep returning to a question that predates the code: what are these components actually for? Components are for building interfaces, but...

The previous post identified four orientations that public sector programmes tend toward - risk, efficiency, provider, and demand - and showed how each orientation shapes which failures become...

If services are fundamentally promise-based systems - where capabilities promise performance and resources promise affordance - what happens when promises break? And more troublingly: what happens...

The design systems framework I have been developing includes events as one of eight core elements, defined following Gärdenfors (2017) as atomic cause-effect triggers with a force vector and a result...

Duncan Stephen's recent post, "Services are verbs combined with nouns", addresses the nouns, verbs best way to describe service ontologies problem, and which I also wrote about in states and services...

Building a design systems framework for data platform products, I keep running into the same architectural decision: should the framework distinguish products from services - and if so, how?