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

Aconex · Senior Product Designer

TL;DR

  • What changed: I stopped treating my assumptions about what users value as design decisions, and started treating them as hypotheses to test.
  • What we did: We cut the comments UI back to one organisation's conversation at a time, removed the counts, and labelled each tab "With [Organisation]".
  • What we had to figure out: How to catch and fix a feature built on assumptions before it damaged trust in a workflow people use to settle disputes.
  • What went wrong: I shipped comment tabs with counts per organisation, and users couldn't tell who had said what to whom.
  • Where it happened: Three years on Aconex Field, the mobile and web app construction teams use for issues, inspections and checklists.

Three years on Aconex Field

I worked on Aconex Field, the mobile and web product construction teams use for issues, inspections and checklists, for close to three years. Aconex's mobile platform is used by more than 70,000 organisations around the world.

Inspired by the "First 90 Days" framework, I ran a regular personal pulse-check on what I was learning and shipping.

Over that time the work moved from small, easy wins like pull-to-refresh behaviour and real estate battles on tiny mobile screens, to complex, high-stakes features that shaped how head contractors and subcontractors work together.

Before and after of the Aconex Field checklists screen on iPhone, from a crowded toolbar with a refresh button to a simpler layout Apple Human Interface Guidelines entry for the Refresh icon, advising that apps should refresh content automatically whenever possible Map of the roles in a construction project, the issue workflow between them, and the content rights and organisation visibility each group has

When my assumptions met real users

The clearest example was the first phase of a comments feature on Issues. Users had been asking for it for a long time, so they could explain a dispute, give a progress update, or say what had happened to an issue.

In discovery, I assumed two things would matter: seeing the number of comments on an issue, and the number of comments made by each organisation. So the UI shipped with a comment tab per organisation, each with a count, to give a quick sense of activity.

Users didn't get it. The feedback was that comments "weren't reflecting in the right order". When I dug into the screenshots users sent us, it turned out to be a symptom of something deeper.

User-annotated screenshot asking why a comment sent from one organisation appears listed under the other organisation's tab The same issue seen by the other organisation, annotated to ask why comments from both sides are listed under a single organisation

Who can see which organisation's comments is core to how head contractors and subcontractors work. Here, more openness wasn't obviously better. It could hurt a subcontractor's position in a dispute. The tabs and counts added complexity without the clarity I'd expected.

What I had to figure out

How do you catch and correct a feature built on plausible assumptions, before it does lasting damage to trust in a workflow people rely on for safety and disputes?

Less, not more

We looked at the mobile version of the same feature, which was already working better. Mobile's small screen had forced a simpler pattern: one organisation's conversation at a time. That constraint turned out to be exactly what users needed on web too.

It's Hick's Law in action. The more options you give people, the longer they take to decide what to do.

Hand-drawn chart of Hick's Law, showing reaction time rising as the number of options increases

On web, we:

  • Removed the comment count entirely
  • Added a "With [Organisation]" label so each tab said who the conversation was with, instead of leaving users to work it out from a number
Redesigned Aconex Field web issue view with the comments section showing one organisation's conversation at a time Close-up of the redesigned comments tabs, labelled 'With' followed by each organisation's name and no comment counts

I saw the same pattern again and again over those three years. The empty states on Issues and Checklists are a good example. One generic empty state tried to cover every scenario, and gave users too many possible actions to parse. We split it into two:

  • One nudging a filter change, when results existed but were filtered out
  • One nudging users to create an item, when there was genuinely nothing there yet

What stuck with me

Beyond the fixes we shipped, the lasting change was how I approached new features. An assumption about what users value became a hypothesis to test, not a decision to ship. I wrote this down in my reflections from around that time:

"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."

Where it pointed next

That period also shaped my view of where the platform needed to go.

Collaboration fabric: a service woven through every process, so construction teams can collaborate seamlessly. It starts with the individual and ripples out to groups and organisations.

Illustration of conversations woven between people across phones and browser windows Concept comment card with a richer profile and identity, #links to Aconex objects, @mentions of team members and an extendable action bar

Modular data mobility: people increasingly expected to consume data in small, mobile-friendly nuggets. That needs a decoupled common data environment, not a monolithic one.

Illustration of modular data cards flowing between a browser, phone, smartwatch, smart glasses and a building model

Both fed directly into the design direction for Aconex's next generation of mobile products, including Pin the plan.