A person standing between appointments does not have the same attention available as someone sitting at a desk.
They may have one hand free, poor reception, a customer waiting and the next location already on their mind. If the software asks them to recreate the whole day in a long form, the record will be delayed, shortened or skipped.
That is often described as resistance to change. I think it is usually a design failure.
The moment is part of the requirement
A field workflow needs to be designed around where the action happens.
Can the person see the screen in daylight? Can they tap the control with gloves or a tired hand? What happens when reception disappears? Is the common action at the top, or buried under fields the office wanted “just in case”?
The physical and operational context is not a later usability detail. It changes the system.
Capture the smallest dependable record
The first action should collect what is needed to keep work moving.
A sales visit might need the customer, outcome, next action and follow-up date. A site record might need the job, activity, issue and photo. Extra detail can be added when it changes a decision—not because a database has an empty column.
Short does not mean careless. Validation, timestamps, ownership and a clear status can make a small record more dependable than a long free-text note.
Preserve context automatically
Good field software should remember what the person already knows.
If they opened the action from a job, the job should stay attached. If they are returning to a lead, the contact and previous note should already be visible. If the time and assigned person are known, do not ask for them again.
Every repeated field is an opportunity for delay or error.
Give the office a different view
Field and office users do not need the same screen.
The field team needs the next action, fast capture and useful context. The office may need queues, exceptions, totals and follow-up. A manager may need approvals and visibility across several people.
One data model can support several deliberately different views. Forcing everyone through the same dashboard usually makes each role work harder.
Design for interruption and recovery
The workday is not a clean demonstration.
A call arrives. The app closes. Reception drops. The person reaches the next job before finishing the note. Useful software saves progress where appropriate, makes incomplete records visible and lets the person return without starting again.
Offline behaviour should be decided explicitly. Some workflows can queue changes safely. Others should block a critical action until the system can confirm the latest state. The right choice depends on consequence, not fashion.
Adoption is something the system earns
Training helps, but a team will keep using software when it makes the useful action easier than the old workaround.
If sending a text is faster than opening the app, the text will win. If the system creates a follow-up, updates the office and keeps the customer context in one place with two taps, it has earned a place in the day.
Measure missing records, delayed entries and support questions after launch. They are signals about the design.
Start by watching the work
Do not begin a field system with a list of screens. Begin with one real day.
Where does information first appear? What does the person need at that moment? Which detail is forgotten by the time they reach the office? Who depends on the next handoff?
When those questions are clear, the interface becomes smaller and the result becomes more useful.
Field teams are not there to serve the software. The software is there to support the work.