An application your teams will actually use

"My teams will never use it": it is the first objection from an owner who has already seen software bought, presented in a meeting, then dropped after three weeks. The short answer fits in one sentence: an application gets adopted when it saves time from day one, not when it has the best demo.

Why off-the-shelf software fails on site#

An installer on a job site has one hand on a tool, the other on a phone, and dust on the screen. A driver steps out of a truck with a paper slip in hand. A team lead answers five people at once.

Software built for a desk asks for a login, a menu, several screens before reaching the useful action. On site, every extra screen is a reason to go back to paper or a voice message. This is not about age or resistance to change: it is a gesture that has to fit in a few seconds, standing up, outdoors.

What we watch before building a screen#

Before the first line is written, we look at how information actually moves today, not how it should move. The audit takes one to two days and answers one question: what does this person really do, in what order, with which tools.

For hours worked, for instance, we check whether they arrive by voice message, on paper, or from memory on a Friday evening. The screen we build next follows that same gesture: it does not ask the person to learn a new way of working, it keeps theirs and removes the retyping.

Building with the people who will use it, not with head office alone#

A specification written at head office describes an ideal process. A team lead or a site manager describes what they actually do, shortcuts included. The two versions rarely match, and it is the second one that matters.

The first version of a screen is tested by someone from the field, not by the owner who commissioned the application. If that person hesitates, hunts for a button, or goes back to paper to check, the screen changes before anyone else sees it.

A gesture, not a form#

A hypothesis, to show the principle: on an end-of-day screen for a site crew, the number of fields asked can drop from twelve to three without losing anything useful.

The two weeks after going live#

Adoption is not decided on launch day, it is decided in the two weeks that follow. We keep a fallback (paper, a message) during this period, without treating it as a failure: it is the time it takes for everyone to open the screen several times in real situations, not only in a demo.

Every piece of feedback from this period matters more than anything said at the initial presentation. A button in the wrong place, an unnecessary step, a word that is not the one the trade actually uses: these are a few hours of fixes, not a new project.

What not to expect#

A well-built application does not convince everyone on day one. Someone who has worked a certain way for twenty years takes longer than someone else, and that is not a failure of the method. Naming one person in each team who tested the screen before the others, and can answer a question on the spot, does more than any user manual.

What changes with an application built for the company#

Everyone opens their phone and sees what concerns them, nothing else: the team lead sees the day's schedule and their crew, the site manager sees their current sites, the owner sees what is moving and what is stuck. No one navigates a menu built for someone else's job.

The screen used most often is the one that asks for the fewest gestures: open, confirm, move on. What used to be a form filled in at the end of the day becomes a box ticked during the day, at the moment the information is already in the person's head.

Application adoption: the key takeaways#

An application gets adopted when it follows a gesture people already make, not when it imposes a new one. It is built by watching the field, tested by the first people concerned, and adjusted in the two weeks after it goes live, not before.

The sign that does not lie is not satisfaction at the launch meeting: it is that nobody needed to go back to paper in the third week.