Inclusion Engineering.
We design around the conditions technology must survive, including power, bandwidth, language, data, cost and access.
Most systems are designed for an idealised user on an idealised network. Inclusion Engineering starts from the real one.
It asks whether a solution stays usable when power, connectivity, language, data, accessibility or budget becomes the constraint. If it does not, the design is not finished. That applies to a data pipeline for a bank as much as to a sensor in a cold room.
Asked at the start of every project, and again before it ships.
- 01
Context
Who will use this, where, and under what conditions of power, network, language and cost?
- 02
Intelligence
What is the least complex response that solves the problem: analysis, software, AI, hardware, training, or a mix?
- 03
Inclusion
Does it still work for the person with the oldest phone, the weakest signal and the least time?
- 04
Responsibility
What data does it touch, who is accountable for it, and what happens when it fails?
Five steps, in this order.
- Step 01
Understand the setting
Users, workflows, infrastructure, data, constraints, risks and what success means.
- Step 02
Frame the engineering problem
Separate symptoms from causes, then choose a response in proportion to the problem.
- Step 03
Design and build
The analysis, architecture, workflow, prototype or system the project actually needs. Nothing extra.
- Step 04
Test against reality
With the people who will run and maintain it. We write down the limits as well as the results.
- Step 05
Improve or scale
Expand only when performance, ownership and operating conditions justify it.
The line between what is proven and what is possible.
Every project we show carries its stage: blueprint, prototype, pilot, live or delivered. Every figure carries its source. Where a result is not yet measured, we say so.
Discuss a project