Turn a business process into a simple tool
A useful tool does not begin with a list of screens. It begins with real work, its steps, its exceptions, and the person who must make a decision without searching in five places.
06 chapters
Observe one complete task before drawing a solution
Choose work that starts and ends: receive a request, prepare a quote, open a file, schedule an intervention, check a document, or follow up with a client. Watch how it is done today, including calls, post-it notes, and copy-paste. Those details are not secondary: they reveal what the tool really needs to carry.
The goal is not to judge the team’s habits. Workarounds often exist because they allowed work to be delivered despite an incomplete tool. Understand what they protect before removing them. A person keeping a private list may, for example, be compensating for the lack of an alert, status, or clear responsibility.
- Define the trigger and expected result.
- Observe one simple case and one unusual case.
- Record the tools, documents, and people involved.
- Identify the moment when a decision must be made.
Describe the journey in everyday words: who does what, when, and why
A process can first fit on one page. At each stage, write the person involved, the information they receive, the action they take, and what allows the next stage to begin. Verbs are more useful than screen names: receive, check, complete, approve, assign, send, close.
Exceptions deserve the same attention as the main path. What happens if a document is missing, a client does not answer, data is inconsistent, or a person is away? A reliable tool does not pretend these situations do not exist; it makes them visible and lets them be handled without leaving the journey.
Make data, statuses, roles, and rules visible
An app becomes useful when it avoids asking for the same information again and shows the real state of the work. Identify core data, possible statuses, people who may change them, and rules preventing an action too early. That structure matters more than colours or labels.
Do not try to model everything. Keep data that serves a decision or an action. A field nobody reads, a stage that changes nothing, or a status that nobody can explain are signs of unnecessary complexity. The CRM, ERP, Notion, or custom guide helps decide whether those rules belong in an existing tool or a new app.
- Information required at each stage.
- Statuses that genuinely change what may be done.
- Roles that may read, edit, approve, or administer.
- Actions that need history and actions that may be undone.
Choose a first version that solves one entire problem
A first version is not an incomplete mockup of all future software. It must make it possible to go from start to finish on an important case. If the goal is tracking a request, someone must be able to receive it, see its status, fill what is missing, know who acts next, and find its history.
That limit protects both the team and the budget. It lets words, rules, and access needs be tested on real files. Adding a stage, role, or connection then becomes an informed decision instead of a promise made before the first journey works.
Connect existing tools only where they truly remove duplicate entry
New software does not need to own every piece of data. It can receive a contact from the CRM, send an invoice to accounting, or read availability from a calendar. Every connection needs a concrete reason: remove duplicate entry, avoid a status mismatch, or make a decision faster.
Before connecting two tools, define which data is authoritative, when it moves, and how an error is reported. A well-scoped web application can become the right passage between existing services without trying to replace them all.
Put the tool into service, listen to use, and measure the result
Launch is not the last step. Support the people using the journey, observe real cases, and record what remains outside the tool. The most useful feedback is not “it would be nice to have everything” but “here, I do not know what happens next” or “I still need to call to verify this information”.
Measure one simple change: processing time, incomplete files, response delay, number of reminders, or correction volume. These points make it possible to decide the next step calmly. They are also a healthy base for later automation or AI: a system can only improve sustainably what is already visible.
- Plan a trial period with real files.
- Give one person responsibility for collecting feedback.
- Keep a way to return to manual work if a problem occurs.
- Choose changes from observed use, not ideas alone.
The remaining decisions
Must every screen be designed before development?
No. The journey, data, and decisions need to be understood first. Screens become more accurate when they rest on these elements. A first version can focus on one complete journey.
How long does it take to scope a process?
It depends on its complexity, but the first level can start with a few observations and a workshop with the people involved. Time spent understanding exceptions mainly avoids discovering them after development.
Can AI be added to the tool later?
Yes. It is usually better to make the process, data, and approvals clear first. AI can then prepare, classify, or suggest inside a framework that is already understandable and measurable.
Put the guide against a real project.
A few lines are enough: context, the main constraint, and the expected result.