Enthusiasm on day one is not adoption
Four salespeople were immediately enthusiastic about our site survey app. The weeks that followed taught us more than that first reaction did.
We built an app that lets four salespeople document a job site on location. Photos, measurements, notes, and a site survey sheet comes out of it.
The first reaction was enthusiastic. All four of them.
That is pleasant and it says almost nothing. New things are fun. The question is what happens in week three, once it has become ordinary work.
Where it started to chafe
At the mandatory fields.
We had made a number of fields mandatory, for good reason: without that information a site survey sheet is not finished and somebody has to call afterwards to ask what exactly was meant.
Except that asks for discipline at a moment when nobody feels like discipline. You are standing on a job site, it is cold, you have three minutes, and the app will not let you continue until you have filled in a field that may not even be known at that point.
That is the tension every app for the shop floor runs into. Require nothing and you get incomplete data. Require too much and you get no data, because people drop out or type something in just to move on. The latter is the worse of the two: then you have a full field with nonsense in it and everybody assumes it is right.
What we changed
Usability, and mostly in the places where it hurt.
The lesson I take from it is not that mandatory fields are wrong. It is that you only know which fields really need to be mandatory after a few weeks. You cannot decide that at a desk, because you do not know which information is genuinely available on location at the moment of filling in.
Our approach since then: start with less mandatory than you want. After two weeks, look at which fields systematically stay empty. Then talk to the people using it about why. Sometimes the answer is that it is not known at that moment, and then that field should not be mandatory but filled in later. Sometimes it is just a badly placed button.
You discover that difference by asking, not by looking at the numbers.
The moment it tipped
For the owner there was one thing that decided it, and it was not the app itself.
It was that the quote from their existing system could be linked to the site survey sheet. Suddenly the survey on the job site was attached to the commercial file. What had been seen on location sat next to what had been offered.
That is the pattern I see again in every project of this kind. Users are won over by whatever makes their own work lighter. The owner is won over the moment two things that existed separately hang together.
You need both. If only the owner is enthusiastic, it does not get used. If only the users are enthusiastic, nobody invests in it.
What I watch for next time
Three things, out of this experience.
Schedule a revision round from the start, two to three weeks after go live. Not as a guarantee of mistakes, but because only then do you know what you have built.
Do not ask whether they like it. Ask what annoys them. The first question gets you politeness, the second gets you information.
And make sure there is one visible link to something that already existed. That is what turns a loose tool into part of a system, and it is usually the smallest technical change in the whole project.
The claim
The first reaction to a new app measures curiosity, not usefulness. The real verdict lands in week three, which is also when you should be scheduling your second round of development work.