Benchmark Gensuite — Modernising a 75+ application enterprise suite

01 / THE DILEMMA

Two sets of customers, pulling in opposite directions

Existing customers valued familiarity. Prospective customers saw an ageing product.

Benchmark needed to improve the interface without disturbing workflows people already knew. The request was measured: move the front end towards a newer framework and improve the look and feel, without turning it into a wholesale redesign.

Familiarity was not resistance to change. It was part of how customers got work done.

Users "may not like it, they may not think it's pretty, but if you move their T's, they get very upset".

BENCHMARK TECHNICAL LEADERSHIP

02 / THE CONSTRAINT

One product that could not stop while it changed

Benchmark could not pause a shared enterprise platform for a screen-by-screen redesign. Improving isolated pages would create cleaner fragments, not a more coherent product.

The work therefore began at the shared layer and moved into one real feature.

• Stabilise — resolve reusable components and their states.
• Apply — assemble those foundations inside a real feature.
• Diagnose — separate visual friction from structural confusion.
• Rebuild — change only the layer the evidence says is broken.

PRODUCT PRINCIPLE: Restyling a product is not modernising it.

03 / THE DIAGNOSIS

The interface misrepresented itself

The first pass modernised the components and preserved the existing model. The remaining problem became clearer.

Search looked global but covered a narrower set. Two archive controls changed different results. Nearby sites sat inside a hierarchy built for browsing the organisation. The interface worked, but it did not explain the boundaries between those jobs.

04 / THE DECISION

Three jobs deserved three honest views

The selector had been asked to do three jobs. Separating them was the decision that mattered:

• Browse the organisation — move through the hierarchy and choose the scope of work.
• Return to recents and favourites — re-enter the parts of the organisation used most often.
• Find sites nearby — use location rather than hierarchy to identify the relevant site.
• Each view could now be honest about what its search covered. The nearby view needed no search bar because the map was the search.

05 / DESIGN ENGINEERING

Reviewing behaviour, not pictures

Benchmark needed working HTML, CSS and JavaScript, so stakeholders could review behaviour rather than pictures. Tcules used code to preserve the interaction decisions, not to replace Benchmark's development team.

The attachments prototype tested reordering, folders and system states while those choices were still cheap to revise.

I was curious if you use an external library for the drag and drop because Bootstrap 5 doesn't natively support drag and drop.

BENCHMARK ENGINEERING STAKEHOLDER

06 / WHERE IT STANDS

Design proof, before product proof

The work established a component direction for the Bootstrap 5.3 migration target and a selected three-view direction for the scope selector.

The modules had not reached customers when documented. This is design proof and feasibility review, not production impact.

WHAT THIS PROVES

The hardest part of modernising a mature platform is deciding which layer of the product is actually broken.

A framework upgrade, a visual refresh, a structural repair and a design-system programme are different investments. The expensive mistake is committing to the wrong one.