Time to competence reduced from roughly 12 months to 3 months

Executive summary. I led the redesign of DocBoss, an industrial document-control platform whose growing feature set had become difficult for new users to understand. Research with 106 people across EPC firms and suppliers exposed the same workflow from both sides. We rebuilt the information architecture around daily actions, project status, and administrative work. Time for a new document controller to become effective fell from roughly twelve months to three.

A powerful product had become hard to learn

DocBoss was built in 2010 by Brad Bowyer, who was running inside sales at an instrumentation supplier and got tired of watching his team burn hours on clerical work. The first version was hacked together over a Christmas break. By 2016 it was the tool of choice for process equipment suppliers, and it had grown the way successful software does: features added because they made technical sense, layered onto an interface that had stopped making sense to anyone new.

The symptom was onboarding. A new document controller needed roughly a year to become genuinely effective. That meant sustained training cost for the client, a steady load of support calls, and a sales cycle throttled by how long a prospect took to see value.

Paperwork decides when suppliers get paid

A supplier of valves, pumps, compressors, or pressure vessels does not just ship equipment. They ship the documentation that proves it meets specification, formatted exactly the way each engineering firm demands, with its own numbering, cover pages, transmittals, material test reports, and a final databook.

Payment is tied to that paperwork. When documents are rejected or held back for an error or a compliance failure, the milestone slips and the payment slips with it. Holdbacks disrupt cash flow, strain client relationships, and damage a supplier’s reputation for reliability.

Before DocBoss, most of this ran on Excel and SharePoint, neither of which was designed to merge previously released documents, generate a databook, or track where anything is. A document controller was standing between their company and getting paid, managing hundreds of documents across several projects with no reliable view of any of them.

Research exposed the cost of hidden complexity

We surveyed 106 people: 61 from EPC firms and 45 from supplier organizations, including 19 existing customers, at companies ranging from under 50 employees to over 500. DocBoss published the results.

Daryl, supplier. The primary user. He maps document codes to real documents, takes exception to requirements that are irrelevant or impossible, negotiates requirements that arrive after the purchase order is already signed, and assembles databooks and cover sheets.

John, EPC engineer. The customer his work is judged by. Runs projects from design through procurement to construction against specification, budget, schedule, and quality. His hardest problems came back as numbers: meeting schedule and communicating changes to it, 70%. Aligning Supplier Document Requirements List codes to what suppliers actually submitted, 61%.

The survey’s most useful result was not a pain point. It was that each side finally saw the other’s version of the same process. EPCs said the thing they care about most is accuracy and format, and named their frustrations as missed deliverable timelines, unclear submission protocols, and unusable scans. Suppliers were trying to hit specifications that differed for every customer and sometimes changed mid-project. Neither group had seen that written down before.

Rebuilding the product around users’ goals

The first move was information architecture. We mapped how information was actually accessed, shared, and changed against what people were trying to do, then rebuilt the structure around goals rather than around the technical shape of the system.

Three parts came out of it. Home opens into three role-based views: an actions dashboard tracking what collaborators owe you, a projects dashboard showing status, and a general project list. Project switches between projects or starts a new one. Account, admin, and settings collects everything used at project setup and rarely after, kept out of the daily path.

The structure also left room for modules to be added by subscription plan and integration, so navigation could absorb growth rather than be deformed by it again.

Two dashboards made missing work visible

Two dashboards, because two roles need opposite things.

The actions dashboard serves the document controller: what is coming due, due, and overdue, sorted by criticality. Operational. What do I do next.

The project dashboard serves the manager running several projects at once. Each project is a card, basic view showing completion and due date, expanded view breaking down progress by due date and document location. Location matters more than it sounds: it tracks who currently holds a file, whether that is internal staff, a sub-supplier, or the customer.

Both resolve to the same thing, which is the documents nobody can account for. Off-track, overdue, not submitted, or status unknown. That is where holdbacks come from.

Honest research required a safer room

We ran the first interviews with document controllers while their managers were in the room.

Nobody arranged it maliciously. It was convenience, and it was how the sessions had been booked. But a document controller is not going to admit, in front of the person who evaluates them, that after a year they still do not understand parts of the software they are paid to operate. So they did not. They described workflows they had actually abandoned, skipped past the features they avoided, and made the product sound more learnable than it was.

We had built our early understanding on answers people could not afford to give honestly. Onboarding was the exact thing we were there to fix, and the confusion we needed to see was the thing the room made unsayable.

The research changed when we recognized ↘Go down the rabbit holewhy the first interviews looked too clean

We caught it in time. The interviews were re-run one to one, and what came back was worse and far more useful: the specific places where people got lost, and the workarounds they had invented instead of asking. The information architecture and the two dashboards came out of that second round, not the first.

The lesson was not about interview technique. It was about who is in the room and what their presence costs. I now check who holds power over a participant before I check anything about the script. It is also why I have since pushed research toward channels where people are already talking without an audience, which at Income Access meant training support agents to run lightweight tests during calls they were making anyway.

A durable architecture cut onboarding by nine months

Onboarding fell from roughly one year to three months. The client saved substantially on training and support calls, and the shorter time to competence shortened the sales cycle.

The architecture has held. DocBoss is still running on it nine years on.

The product kept evolving, but the underlying model endured. ↘Go down the rabbit holeWhat the architecture was designed to preserve