Design Governs What Integration Makes Visible

Integration can join two systems perfectly behind the scenes and still fail the person who needs to find and use that connection during ordinary work, which is a technical success of a particularly unhelpful kind.

I think design is a core integration function because the interface determines whether someone can browse connected resources and use what they find in the actual workflow. Design is not the attractive surface applied after the technical work; it governs behavior by deciding which relationships a person can perceive, follow, and eventually trust.

Hypertext theory provides a useful language for this. In its original conception, hypertext was not only about clicking links. It was about associative networks that mirror human thought. A well-integrated system creates practical hypertext when it makes the connections among information objects visible and navigable. A person can follow a question, encounter a relevant resource they did not know existed, and understand why the system placed it on the route.

Consider a service handoff. A project team completes a decision and records it in one system. Another team receives the next task through a different system. The receiving person needs to understand the decision, the source material behind it, the conditions that limit it, and any related guidance for the next stage. If the integration merely copies a status field, the handoff is technically present and practically weak. The person may have to search several collections, ask a colleague, or reconstruct the relationship from memory.

Design can change that sequence. The handoff view can show the current task alongside the relevant decision record, its source documents, its owner, its date, and the related work that follows. It can offer a route back to the full record without pretending that a summary is the source. It can use classifications that match the terms people use in the task, while allowing a user to see related material described differently by another team. These choices shape what the receiving person notices before making the next decision.

The classifications matter because they determine what becomes adjacent. If a system groups resources according to an administrative structure that has no relation to the user’s work, useful connections remain hidden. If it collapses distinct concepts into one friendly label, it can produce false relationships. Information architecture is therefore an interpretive act with operational consequences. It should be tested against real questions and real paths, not only against a diagram of database entities.

The interface also needs to respect discovery. A person may arrive with a known destination, such as a project number or a client name. Another may arrive with a partial clue, a visual condition, a previous decision, or a question that does not yet have the correct term. Practical hypertext offers multiple legitimate entries while preserving enough provenance that a user can see what they have found and why it connects.

This does not mean that every relation should be exposed at once. An interface crowded with every possible link creates a different kind of obscurity. Design decides which routes are primary for the workflow, which related records deserve a visible invitation, and which connections belong one step deeper. The test is not whether the system can display more relationships. It is whether a user can follow the relationship needed for the next piece of work without losing the source or the task.

Design therefore belongs at the start of integration work. It asks who is moving through the service journey, what they are trying to decide, what they already know, what context they lack, and what relationship would change their next action. Those questions can change the integration itself. A new presentation cannot repair the wrong build.

The result is practical hypertext, or at least the version of it I care about here: integrated resources becoming usable because routes, classifications, and interface give a person a way to perceive the relation that the technical connection made possible. If the relation exists only in the architecture diagram, it has not yet reached the work.