Tolerance-Oriented Futures

On Prototyping the Conditions and Why Clarity is the Deliverable

In May 2026, I sat in a room outside Amsterdam at the Hatch Leadership Atelier and listened to Giulio Frigieri give a talk called Prototyping the Conditions: Design as Governance. I had hypotheses going in and I left with confirmation I should keep exploring my theories in this direction.

The assertion which the group seemed to hear loudest: the AI prototype proves what is possible. It proves nothing about what is viable. And then, less splashy but more consequential: what sits upstream is the design of their surrounding conditions.

I’ve been thinking about conditions ever since, as a word for something I’d been doing without the right language.

The Less-Examined Question

Giulio asked: What must design do for AI? What must design do around AI?

The first is getting all the attention. Prompting, prototyping, shipping faster, building fluency with tools that didn’t exist two years ago. The second is less examined and more important: what conditions must be designed before AI models, tools, and agents are allowed to act inside real workflows?

His answer: the organisational conditions (workflows, data pathways, decision rights, accountability structures) sit upstream of everything else. The prototype is downstream. The interface is downstream. Even the model is downstream.

I’ll extend that argument one level further. The futures we choose to build toward are upstream of the organisational conditions. Before you design the conditions, you need to know which future you’re designing to bring into being. And most organisations don’t. They have visions, if we are lucky. If they are behind the times they have roadmaps. Or they have AI strategies that amount to attaching a new capability to an operating model designed entirely for human action. We can’t vibe code our way to intentional and innovative futures.

Giulio illustrates his productivity paradox using history: factories electrified in the 1880s, and profit and loss ratios barely moved for forty years. Productivity exploded in the 1920s not because the technology changed, but because new conditions were designed. Machines rearranged in the order work actually flowed exploded producetivity. The technology was the same, but the conditions were new.

We are in the 1880s of AI. The prototypes work, yet the operating context is untouched. Design as governance and designing with tolerances in mind will unleash the potential we were promised. 

UX Scotland

I’ve presented Transit Lines & Touchpoints three times to developer audiences over the past year at iOSKonf, SwiftCraft, and PragmaConf. The framework made sense, developers were enthusiastic that it names the parity trap on mobile vs web, but something about the framing wasn’t landing the way I wanted it to. 

After Amsterdam, I went back to my talk and reframed it. For the first time, I presented it to a design audience at UX Scotland in June 2026, as Transit Lines & Touchpoints: A Narrative Framework for Multi-device UX. 

Transit Lines & Touchpoints maps the device ecosystem a product lives in as a transit system: web and mobile platforms should function like different transit modes in a unified system the way high-speed trains and light rail serve distinct needs within one connected network. Touchpoints function as the key moments of interaction that carry the most weight, giving product teams narrative scaffolding underneath their user journeys rather than another map on top of them. At Trello, the strategic conversations it enabled moved team effectiveness from 45% to 89% and drove 91% CSAT. 

I added two arguments I already believed but had not articulated.

Clarity is design’s deliverable

This was inspired by Sophia Prater’s OOUX Masterclass, which reoriented how I think about what design actually produces. Everyone in the room at UX Scotland was wrestling with the same existential questions: do we code, do we prompt, do we use Figma, does Figma use us? I argued that the process question is a distraction. Clarity is the deliverable, however we choose to achieve it most effectively in our organisation. The maps, the artefacts, and the prototypes are means. The end is shared understanding of what we’re building and why to give teams the agency they need to build the right thing at speed.

Design is strategy

The conceptual model of a transit system wasn’t a deliverable. It was scaffolding for driving conversations in the right direction, earlier than they usually happen, before the implementation debates begin. Calling designers builders and shipping code is the downstream portion of our process. It’s also the part most easily optimised, automated, and eventually replaced. The part hardest to replace is the upstream work: the clarity work, the strategic scaffolding, the conversations about WHY and WHAT before anyone argues about HOW.

A Framework or a Philosophy?

After my talk, Sara Wachter-Boettcher, whose keynote on burnout had opened the conference, told me I was onto something. I see design’s opportunity today as upstream from optimising implementation, in the strategic layer where the real decisions get made. Giulio’s talk said the same thing from a different angle. Independent confirmation from two people I respect enormously has me more excited than ever about my hypotheses.

I think Transit Lines & Touchpoints was always a low-fidelity form of conditions prototype. I just didn’t have that language yet to describe it that way.

It didn’t produce a service design map. It produced a shared understanding of what operating conditions existed across a service journey: where friction lived, what the system could absorb, where intervention would create the most structural change. It acknowledged constraints on prioritisation without letting those constraints shrink the vision. It held the future state at full ambition while designing for the tolerance of what was actually true on the ground.

That’s not a UX framework. That’s a philosophy of futures work in the software space which dreams while confronting constraint.

To Coin a Term…

I’ve spent the last academic year studying Narrative Futures at the Edinburgh Futures Institute. It’s a rich and necessary field; concerned with the stories through which humans perceive and remake the world, planetary in scope, critical in orientation. But it operates at altitude. It’s the sky.

What I do is closer to the ground, finding new ways to give software teams agency.

Most software product teams either dream without conditions or plan without vision. The dreamers produce futures that inspire but don’t survive contact with organisational reality. The planners produce roadmaps that execute efficiently toward the wrong destination. The vibe coders prototype what is possible, but not viable, to paraphrase Giulio.

I’m currently hammering out what my MSc project will focus on. In my experience as a design leader, conditions, constraints, and tolerances are forms of data which are routinely ignored in the product vision process in the software space. Once a hand-wavy dream of a vision has been put together with animations and sparkles then research is kicked off to validate the direction. Middle managers have been the ones to help teams connect the aspirational to the deliverable but those roles are being eliminated at an unprecedented rate.

We can do better. I am exploring what a data-informed yet creative futures visioning process can look like. I’m not finding the terms I need yet, if you know of them point me in the direction of research, please!

In the meantime, I am defining Tolerance-Oriented Futures as my philosophy that we can design for absolute constraints while pursuing ambitious visions, finding the inflection point where bold futures become executable as software products.

The term may shift as my thinking evolves, but the word tolerance is a deliberate choice. In engineering, tolerance isn’t limitation. It’s the precisely defined zone within which something still works perfectly. A vision with good tolerance can flex under pressure, absorb variation, and survive contact with reality without losing its shape. Designing for tolerance isn’t designing down. It’s designing with structural integrity.

This is not planning. Planning assumes you know the destination. Tolerance-Oriented Futures assumes you don’t have certainty, that you’re computing forward from what you know, holding the vision steady, designing for system conditions you’ve evaluated honestly using OOUX rather than wishing away the complexities of the real world.

Giulio Frigieri’s Design as Governance asks: what conditions must be designed before AI can deliver value at scale?
Sophia Prater’s OOUX asks: what are the objects of a system, and their relationships, before we design around them?
Tolerance-Oriented Futures asks: what are a system’s absolute and relative conditions before we envision the desired futures beyond them?

A paper I’m presenting at TU Dublin in March 2027, City Planning for Digital Products: Object-Oriented UX as a Tolerance Specification Method, argues that urban planning governance logic is exactly the right model for the next wave of digital product design. A city plan is a vision, a narrative of a chosen future, made actionable through governance, tolerances, and structural integrity. So is a product strategy. So is a desired future.

Where Thoughtful Apes Lives

I started Thoughtful Apes because I kept finding myself in the space between abstract futures thinking and execution-focused product delivery. Too strategic for the builders. Too grounded for the futurists. Too few people seem to be working in the middle distance: where bold visions meet real conditions and clarity is the deliverable.