Level 6 · In practice

6.5Field feedback

Goal: recognise the frequent mistakes in the field and draw from them reflexes you can apply tomorrow.

Estimated time: 9 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

Listen: users often describe the symptom better than the developer guesses the cause.
Own it: an acknowledged and documented mistake becomes an improvement; a hidden mistake always comes back.
Pass it on: what is not written down disappears with the person who learned it.

Yacine's thread — what the field taught

Yacine learned the essentials of his trade in the field, not in manuals. A badly linked control that skewed stock, an update done without a backup on a busy evening, permissions that were too broad discovered too late: each incident left a concrete lesson. The feedback below is what comes back most often in SMEs.

A lesson kept is better than an incident forgotten: note down what the field teaches you.

The mistakes that cost dearly

The costliest incidents are not the most technical: they are the ones that touch the data (wrong stock, incorrect invoice) and the ones that happen at the worst moment (update in the middle of activity). Their common point: a shortcut taken earlier.

What users know

The user knows their trade better than the developer. They don't always say “the link is wrong”, but they know that “the displayed stock doesn't match the count”. Listening to the business symptom often leads faster to the technical cause.

Capitalising

Each resolved incident is an opportunity to update a checklist, a template or a procedure. What is not capitalised will be rediscovered — sometimes by someone else, at the worst moment.

✓ Do

Have a user review the analysis and the screens before coding.
Test a feature with real data, on a copy.
Announce updates and schedule them outside peak hours.
Document each important fix in the incident log.
Briefly train users after each major change.

✗ Avoid

Considering that a screen which opens is a screen that works.
Fixing in production under pressure, without a backup.
Assuming the user will always do the right thing at the right time.
Keeping knowledge in your head without ever writing it down.
Stacking changes without ever consolidating or testing the whole.

Common misinterpretation: “The field is about improvisation.” No. The field reveals precise causes, often the same ones. What changes from one project to another is not the nature of the mistakes, but the speed at which you recognise them.

Text version of the diagram (SEO / screen readers / translation): 1) Listen to the business symptom. 2) Reproduce on a copy with real data. 3) Fix the cause, not the symptom. 4) Document and update the checklist. 5) Announce and train after the change. Lesson: the field teaches fast, provided you note the lesson.

Ready-to-say script — gathering feedback (30 s)

“Tell me what you observe in your work, when it happens and with which data. I then reproduce it on a copy to find the cause without touching production.”

Keep this to turn a complaint into useful information.

Ready-to-say script — announcing an incident (30 s)

“I've identified the cause, I'm fixing it on a copy, I'm checking the full path and I'll schedule delivery outside peak hours, with a backup.”

Useful for reassuring without promising the impossible.

Copy-paste template — lessons learned

Situation: [what happened]
User observation: [business symptom]
Actual cause: [link / query / permission / dependency]
Cost: [time / data / customer]
Fix: [action]
Lesson: [reflex to add]
Updated in: [checklist / template / procedure]

Copy-paste template — intervention plan

1. Notify users (date + time)
2. Back up and check the restore
3. Test on a representative copy
4. Intervene outside peak hours
5. Test-run after the intervention
6. Train / inform users
7. Note the lesson in the log

Very small business / small budget

Focus on the incidents that touch data and updates: they are the ones that cost the most, even in a small organisation.

SME in Oran

Adapt to local constraints: power cuts, old hardware, lightly trained users and quick interventions between two customers.

Remote / multi-site

Gather feedback remotely with screenshots and precise descriptions, and document it for the whole team.

Cross-cultural

Reformulate feedback in a common language before capitalising on it, to avoid misunderstandings between trades.

48h challenge — apply it tomorrow

Take an incident you lived through, write its lessons learned and turn it into a concrete reflex added to your checklist or procedures.

Section exit checklist

I can listen to the business symptom and trace it back to the real cause.
I capitalise my incidents in a checklist or a procedure.
I have done the 48h challenge or scheduled its date.

Self-assessment 1-5: do I listen to the user before concluding?do I turn my incidents into procedures?

← Previous : Toolkit (V3)Next : Going further (V3) →

Check your understanding

A user reports a wrong stock figure. Which approach helps Yacine the most?

💡

A lesson kept is better than an incident forgotten: note down what the field teaches you.