A business process usually sounds tidy when it is described in a meeting.
A customer owes money. An employee records the payment. A receipt is issued. A manager checks the report.
The same process may look very different during a working day. There may be a promise made on WhatsApp, a note in a paper ledger, a partial cash payment, a colleague covering somebody else’s shift, and a manager who reconciles everything later from memory.
Neither description is completely false. But software built only for the tidy version will miss the work people actually do.
Watch the handoffs
Feature requests are useful, but they rarely reveal the whole system.
I want to know where information begins, who touches it, where money changes hands, and what evidence is left behind. I want to see what happens when the normal path breaks. Who notices the difference? Who is allowed to correct it? Which record does the manager trust at the end of the month?
The handoffs usually expose the real product problem.
People often describe the official process because it is easier to explain and sounds more professional. Observation brings out the parts held together by habit, personal trust, and experience.
Calling those parts “informal” can be misleading. A paper mark may have a precise meaning. A WhatsApp message may be the accepted approval. One employee may know which customer is allowed to pay late.
There is structure. It just has not been put into software yet.
Do not remove a working support too early
A new product often asks people to stop using the tools they already trust.
Sometimes that is the goal. But removing a notebook or spreadsheet before understanding its role can make the job harder. The parallel tool may carry a detail the new system missed, provide a backup during a bad connection, or give a manager a familiar way to check the numbers.
The safer approach is gradual. First understand why the old tool survives. Then make the new workflow reliable enough that people choose to leave the old one behind.
Digitisation is not the act of turning paper into screens. It should make the work easier to follow, correct, and hand over.
Trust belongs in the workflow
Trust is not only a marketing concern. It appears in small product decisions.
Can someone see why a balance changed? Does a correction keep the original history? Is it clear who recorded a payment? Can a report be shared with a person who does not use the app? If the connection fails, does the user know whether the action succeeded?
These questions matter more than a clever dashboard.
A business can tolerate a plain screen. It has much less patience for an unexplained number, a duplicate payment, or a record that disappears.
When an action involves money, the product should never ask the user to guess what happened.
A phone is not a small desktop
A person using a phone may be standing in front of a customer, moving between locations, or holding the device with one hand. They may switch between the product and WhatsApp. The connection may drop.
That changes the design.
The main action has to be obvious. Optional details should not block it. Important amounts and consequences should be visible before confirmation. If something fails, the user should know what was saved and what to do next.
Offline support is not automatically the answer. Full synchronisation can create a great deal of complexity. Sometimes the right first step is a narrow workflow that preserves the entry, shows the connection state clearly, and confirms the result without ambiguity.
Write in the language of the work
Translating an interface into French is not enough.
A technically correct term can still feel foreign if nobody uses it in the office. Financial and legal words can change between formal documents and everyday speech. Sometimes an example is clearer than a label.
Product language should be tested like any other part of the workflow. What does the team call an unpaid balance? How do they distinguish money due from money received? Does a reminder sound helpful or threatening?
Clear language reduces mistakes and support. It also shows respect for people who already understand their work and should not have to learn our internal vocabulary.
Build the record before the intelligence
AI can be useful here. It can clean imported spreadsheets, flag unusual entries, draft explanations, or help a user find information.
It still needs reliable records.
A polished assistant cannot explain a balance if the payment history is incomplete. Adding intelligence before the basic workflow is trustworthy only makes the uncertainty harder to see.
This is the standard I want to use for operational software: begin with the work as it exists, make important actions understandable, and introduce structure at a pace people can trust. The result may look less dramatic in a demo. It will be far more useful on a difficult working day.