Reflections: what three years on Aconex Field taught me about assumption vs. evidence

Situation

I worked on Aconex Field — the mobile and web product construction teams use for issues, inspections, and checklists — for close to three years, inspired by the "First 90 Days" framework to run a regular personal pulse-check on what I was learning and shipping. Over that time the product moved from small, easy-win fixes (pull-to-refresh behaviour, real estate battles on tiny mobile screens) toward genuinely complex, high-stakes features touching how head contractors and subcontractors collaborate.

Complication

The clearest example of where assumption and reality diverged was the first phase of a comments feature on Issues — something users had been asking for, for a long time, to give rationale for a dispute, provide a progress update, or explain what had happened to an issue.

In discovery, I assumed two things would matter to users: seeing the number of comments on an issue, and seeing the number of comments made by each organisation. The UI shipped with separate comment tabs per organisation, each showing a count — a design intended to give users a quick sense of activity.

Users didn't get it. Feedback came back that comments "weren't reflecting in the right order" — which, after digging in with actual screenshots from users, turned out to be a symptom of a deeper problem: the visibility rules around who can see which organisation's comments are core to how head contractors and subcontractors actually work, and in this context, more openness wasn't obviously better — it could genuinely hurt a subcontractor's position in a dispute. The tabbed, count-based UI added complexity without adding the clarity I'd assumed it would.

Question

How do you catch — and correct — a feature built on plausible-sounding assumptions before it does lasting damage to trust in a live, safety- and dispute-relevant workflow?

Answer

We looked at where the mobile version of the same feature was already working better, and the answer was almost entirely about information reduction, not addition. Mobile's limited screen real estate had forced a simpler pattern by necessity — showing only one organisation's conversation at a time — and that constraint turned out to be exactly what users needed on web too. This is a direct application of Hick's Law: the more options you give users, the longer they take to decide what to do with them.

On web, we:

• Removed the comment count entirely
• Added a "with [Organisation]" label to make it explicit what each tab represented, rather than relying on users to infer it from a raw count

This is a pattern that showed up repeatedly across the three years — the empty-state work on Issues and Checklists followed the same logic: rather than one generic empty state trying to cover every scenario (which itself violated Hick's Law by giving users too many possible actions to parse), we split it into two dedicated states — one encouraging a filter change when results existed but were filtered out, another encouraging item creation when there was genuinely nothing in the system yet.

Outcome

Beyond the shipped fixes, the lasting change was in how I approached new features afterward: treating an assumption about what users would value as a hypothesis to test, not a design decision to ship. The clearest articulation of that shift, from later reflections in the same period:

"Listen, read, talk to team members who worked on it before. Listen to users. Listen again. Stop. Think and digest all the knowledge. Ask why and help users understand the why. Lastly, use design artefacts as a conversation tool — the product is what matters, not the design artefacts."

That period also shaped a broader point of view on where the platform needed to go strategically — captured in later work on what I called "collaboration fabric" (an interwoven, omnipresent service enabling seamless cross-process collaboration for construction teams, starting at the individual user and rippling out to groups and organisations) and "modular data mobility" (recognising that user expectations around consuming data in small, mobile-friendly nuggets required a decoupled common data environment, not a monolithic one) — both of which fed directly into the design direction for Aconex's next generation of mobile products, including the pinning concept covered separately in this portfolio.