Making a document-heavy procurement workflow feel lightweight

Most construction procurement still runs on documents. Tenders, scopes of work, bills of quantities, meeting minutes and orders all get passed around by email and signed offline. C-Link set out to pull that entire process into one platform, with main contractors on one side and subcontractors on the other. The first version they had live worked, but it carried the weight of the industry it digitised, with dense screens, document-heavy flows, and steps that still spilled outside the system.

I came onto the project leading UI and shaping the UX across the whole web app. C-Link's marketing director worked closely with me, and he owned the product requirements and brought deep industry knowledge of construction procurement. The requirements were thorough, but what they didn't cover was why the live product was hard to use, and that is what I diagnosed before designing more than 10 detailed flows.

Every structural decision came back to the same question. Can a user tell where they are, how they got there, and how to get back, without leaving the page to find out?

I arrived to a live product and a lot of documents. There was a six-page design brief, a statement of requirements for each new feature, sitemaps, and user flows for things not yet built. All of it described what the product should do. None of it described how a user would move through it.

Before any design began, I audited the already live product. It worked from a functional point of view, but it was easy to get lost. In one area you had a left sidebar and top navigation, in the next only the top nav with a completely different set of links. Elsewhere in-page content replaced the sidebar entirely, with no way to bring it back without leaving the page. Creating a project dropped both, swapping the top bar for a step progress bar, so mid-flow you had no global navigation at all.

Nobody asked me to look at navigational issues. The brief listed eighteen existing screens to redesign and treated them as eighteen separate jobs, which is how they had been built in the first place.

The brief did point me at one thing to study. JCT on Demand is the construction industry's established tool for document creation, and C-Link had named it as the reference for how their own document creator should work. I pulled it apart and marked each part of it keep or leave.

The part C-Link wanted fixed turned out to be the part JCT handled worst. Its progress percentage counts every question in the document while the finalise button only counts the mandatory ones, so a user can sit at 88% and still find the button greyed out. The step navigation has the same trouble. Grey segments can't be clicked, grey is most of the bar early on, and reaching one means going back a group and pressing Next. What I did take was the machinery underneath. Answers land in the document as they are typed and stay in view, questions branch on the answer above, and a finish menu lists every group with each unanswered one a link straight to the gap.

Each area shipped as its own feature with the navigation that made sense inside it, but nobody owned how they all fit together. The result was a product that behaved like four separate products sharing a login. A quantity surveyor is mid-task and working to a deadline, and every screen that rearranges itself makes them stop and work out where they are again before they can carry on.

I set two rules for the redesign. Every screen would carry the same navigation shell and a breadcrumb system that would run through the deep procurement flows. So a user three levels into a tender could always step back without losing their place.

A breadcrumb that only travels upward makes you climb to the top and back down again to reach a sibling screen, so the last crumb doubles as a switcher and you move sideways from where you already are. Pinned projects sit below the main nav and travel with it, because a quantity surveyor runs two or three jobs at once and needs each one a click away from anywhere in the product.

There was no design team on the client side and no design process to inherit, just a marketing director who owned the requirements and an engineering team waiting to build. My job over six to nine months was to turn that into finished screens, in an order that kept everybody moving.

I sequenced the flows by dependency rather than by priority. The navigation shell and the breadcrumb rules went first, because every later flow inherited them. Then the data-dense dashboards, because they exposed the component patterns everything else would reuse. The new features came last, when there was a system to build them out of.

The documentation was thorough. One tender-reminder flow branched across seven, three and one day deadlines, email toggles, status changes and calendar updates, all of it fanning out to both sides of the marketplace. I started wireframes in some areas and stopped. The requirements were that detailed, the low-fidelity pass was slowing the work down. The retainer was better spent working the structure out directly in high-fidelity UI.

During the process I mentored a junior designer who worked on other areas of the product alongside me. Any decision I made had to survive being applied by someone who wasn't originally there when the pattern was created. Most of that came down to making rules explicit enough that she could apply them without me, so the product read as one thing regardless of who designed which screen. It ran the other way too. She was applying the component library to screens I hadn't designed and kept hitting cases the components weren't built for, so a good part of our conversations were about which ones needed expanding, and how far that could go before the pattern needed changing.

We met with the client every two weeks to walk through what we'd designed and why. He'd push back with what a quantity surveyor would actually do, and where something was uncertain he'd take it to the engineering team to check it was buildable. I brought the junior designer into those sessions too so she could hear the reasoning first-hand, and she got the practice of explaining her own work.

The "creating a project" flow was the worst case the audit turned up, and it was the clearest test of whether the two rules held. The old flow took the sidebar and the top nav away and gave you a step progress bar in their place. The rebuilt one carries the shell and the breadcrumb trail the whole way through, so the steps sit inside the page instead of standing in for it.

The same shell carries the screens where a quantity surveyor actually spends the day, across the procurement schedule, quotes and tender analysis, the project dashboard, supply chain and file manager. Underneath them sits the component library the rest of the product was built from.

Ahead of the build I also designed the four new features the requirements were written around. Response tracking, notifications and reminders, the query channel, and the tender addendum.

All of it was handed over as high-fidelity, build-ready UI for C-Link's in-house team to build from.

Of every screen I reworked, the tender document creator was the most challenging, and it was the one problem C-Link had already diagnosed themselves. Their brief said users couldn't see progress as they filled a document out, and that yellow-highlighted fields left them unsure what was done and what wasn't. The brief named the answer too. JCT on Demand builds the document as you fill it in, and C-Link wanted the same.

So the pattern wasn't mine to find, though which parts of it to keep was. What hadn't been decided was whether it was worth what it cost. Building a live document alongside a form is a substantially more expensive build than fixing the highlighting, and it is the less original of the two answers. I backed it because the highlighting was never the real problem. The form and the document it produced were two separate things, and you had to hold the join between them in your head while you worked. Better highlighting doesn't touch that.

The creator ended up as two panes, the form on the right and the live tender letter on the left. Every answer drops into its place as it's typed, and the tokens still to fill stay clearly marked. The two panes are linked both ways. Click a highlighted token in the document and it scrolls you to its field, and selecting a field scrolls the document to the first token on that page, so the tie between a question and where its answer lands is never in doubt. Progress is the page count, the same way the paper version it replaces reports it, and no percentage claims a completeness the Send button won't agree with.

Everything I designed was checked against one person, C-Link's marketing director, and his knowledge of how procurement actually runs was deep. No quantity surveyor outside the business ever saw the work.

The questions I'd want answered are the ones only a real user can settle: whether the breadcrumb system holds up for someone three levels into a tender and up against a deadline. Whether the two-pane document reads as reassuring or as busy on a first encounter. And whether response tracking changes what a buyer does or just gives them something else to check.

Given the chance I'd have put the tender document creator in front of five quantity surveyors with a real tender to send, and watched where they hesitated.