Business workflows as design problems

The thing nobody calls a design problem

Walk into any functioning business and ask where things go wrong. You will hear about people, about communication, about tools that don't connect. You will rarely hear someone describe a broken workflow as a design failure. That framing tends to be reserved for interfaces: the button in the wrong place, the form that asks for too much, the onboarding screen that loses half its users in the first thirty seconds.

But the workflow that drops leads after the discovery call? The one where a quote takes five days to leave the building? The one that relies on one person's memory to hold together three handoffs? Those are also design failures. They are just harder to see because they don't sit inside a product. They sit inside a business, distributed across tools, habits, and assumptions about who does what when.

The useful reframe in April 2019 is this: every broken workflow is a design problem waiting to be solved. The question is whether you solve it with discipline and intention, or leave it to accumulate friction until it becomes someone's full-time job to manage the mess.

Friction as signal

Friction in a workflow is almost never random. It concentrates. It repeats. It clusters around specific transitions: the handoff between sales and fulfilment, the gap between a decision and its documentation, the point where one person's output needs to become another person's input.

When you see the same friction repeat across different businesses, across different industries, you begin to understand it not as a problem peculiar to that team but as a structural problem with a pattern. The structure is what matters. The specific names and tools are almost incidental.

This is what working across multiple environments through TUXX makes visible. The custom systems work, the integrations, the internal tools, the process automation, exposes these patterns at a rate that pure product development cannot match. You are inside real operating environments, touching real workflows, watching where momentum actually breaks down. Not where people say it breaks down. Where it actually does.

And what the patterns reveal, consistently, is that most operational problems are not fundamentally operational. They are structural. They emerge from workflows that were never properly designed, grown instead from accumulated habit, patched with workarounds, and eventually handed to new people who inherit the patches without understanding why they exist.

What designing a workflow actually means

Workflow design is not process mapping. Process mapping is documentation. It records what exists. Workflow design is something else: it is asking what ought to exist, and building toward that.

The questions are design questions: Where does information need to be at each stage? Who holds accountability for each transition? What should the system remember so people don't have to? Where is speed the wrong optimisation, and where is speed the only thing that matters?

These are not operations questions. They are questions about form, about function, about the relationship between the two. They require the same disposition as interface design: the willingness to hold a user's experience in mind across a sequence of interactions, to protect them from unnecessary complexity, to make the next step obvious without being prescriptive about how they take it.

The difference is that in workflow design, the "user" is often the entire organisation. The experience being designed is weeks or months long, not seconds. The interface is a combination of software, expectations, standards, and human judgement. That makes it harder to test and harder to iterate. But the underlying discipline is the same.

The commercial execution problem specifically

What we are most interested in, the set of problems that Orbit is being built to address, sits in the commercial execution layer of a business. The stretch from first contact with a prospect to a launched, delivered, operational product or service.

This stretch is almost universally underdesigned. Most businesses have something for capturing leads at one end and something for delivering work at the other, but the middle, namely the qualification, the proposal, the agreement, the resourcing, and the handoff into delivery, is held together by spreadsheets, email threads, and conversations that should have been written down somewhere.

The result is that commercial velocity depends disproportionately on individual expertise. The founder who knows how to close. The account manager who knows where the bodies are buried. The delivery lead who keeps the client calm. When those people are available, things move. When they're not, things stall or fail.

This is not a people problem. It is a design problem. The workflow has not been made legible enough for anyone else to navigate it without that individual expertise. The institutional knowledge is not in the system. It is in a handful of people's heads.

Designing this properly means building a system in which the workflow itself carries the intelligence: where the right information is surfaced at the right moment, where the next action is clear without requiring someone to brief it from scratch, where accountability is visible and progress is not lost when a person is out of the room.

Why the operating surface matters

The instinct when confronted with a broken workflow is to add a tool. A better CRM. A project management platform. A communication layer. The tool rarely solves the problem because the problem is not the absence of a tool: it is the absence of a designed workflow to place the tool inside.

Tools are only as useful as the structure they serve. A CRM in the middle of a structurally broken sales workflow does not fix the workflow. It adds a new category of data that has to be maintained, updated, and relied upon within a workflow that still doesn't know what it's doing.

What is needed is not more tooling. It is a proper operating surface: a single environment in which the workflow is the product. Where the stages are defined, the transitions are intentional, the information is where it needs to be, and the whole thing can be observed, measured, and improved without requiring someone to pull data from five different places to understand what's happening.

That is what Orbit is being built toward. Not a CRM. Not a project tool. Not a pipeline visualiser. An operating surface: a place where commercial execution, from lead to launched product, has been designed as a coherent whole rather than assembled from parts.

The honest difficulty

None of this is straightforward to build. Designing a workflow well requires enough exposure to real operating environments to understand what actually breaks, and why, and which category of fix addresses the root rather than the symptom. It requires the patience to distinguish between friction that is incidental and friction that is load-bearing, where the apparent inefficiency is actually doing something useful that a cleaner system would accidentally remove.

It also requires the discipline not to over-design. Workflows that are too rigid break differently than workflows that are too loose. The goal is not to eliminate human judgement: it is to make good judgement easier to exercise by removing the administrative weight that tends to bury it.

Getting this balance right is partly a product problem and partly an experience problem. The TUXX client work earns the experience. The Orbit product work turns it into something transferable. That relationship between the two is not a coincidence of the portfolio: it is the logic of how useful products get built when the problem space is genuinely complex.

Where we are

The observation we keep returning to in April 2019 is this: businesses are spending enormous energy managing the symptoms of workflow problems that are, at their root, design problems. The energy goes into chasing updates, reconciling information across systems, re-briefing people on context that should have been captured and retained, compensating for handoffs that were never designed to succeed.

This is recoverable. The friction has a shape. The shape reveals itself if you sit inside enough real environments and pay enough attention to where the same things keep going wrong.

The work right now is to understand that shape clearly enough to design against it. To build the operating surface that makes commercial execution something a business can practice deliberately, not just survive through individual effort and institutional habit.

That is the product question. It is also, at its core, a design question. And treating it as one changes everything about how you approach the answer.