Thank you for your interest and continued support.
This is Takahashi from the Marketing Plan Research Laboratory.
To explain the systems we’ve developed,
we create screen captures and operation overview documents to present to our clients.
This is a mandatory task for each SE,
and we have incorporated it into our system development procedures.
(What we create is essentially a "manual-like" document
and are kept simple enough to avoid incurring additional costs,
but for the sake of convenience, we will refer to them as manuals in this article.)
Why do we create manuals?
In short, “because the process of creating the manual improves system quality.”
I will explain the details below.
When developing a system, many companies
commission software companies to create user manuals.
These are impressive documents,
resulting in impressive documents spanning dozens of pages.
After the system is implemented, just as many companies
forget about the existence of the manuals they ordered.
Once you get used to the operations, your body remembers them,
it’s quicker to ask someone if something is unclear,
and as operations become more established, the rules become more detailed and strict,
so manuals tend to be the least reliable resource when you’re in a bind.
That said, because they contain so much information, they’re hard to use for new employee training,
which is a classic scenario with manuals.
On the other hand, every time a small feature is added to the system or a screen is changed,
the manual must be updated as well.
This is because if they aren’t updated, the manual will no longer match the actual screen.
However, document management costs are not cheap,
and this becomes a budget line item that “nobody uses.”
So, would it be wiser not to create manuals in the first place?
In fact, many system companies say that “manuals offer poor cost-effectiveness.”
We are, of course, well aware of this.
Nevertheless, we continue to create manuals.
The reason is simple:
"Because creating a manual dramatically improves the quality of the system itself."
.
The process of taking screen captures and writing out step-by-step instructions
forces the SE to adopt a “user’s perspective.”
When they look at the screens they designed and try to write explanatory text,
they notice the awkward placement of features and confusing item names.
The moment a systems engineer feels, “This feature is hard to explain or difficult to understand,”
that is an opportunity for improvement.
If this happens before the manual is released, the cost of making corrections can still be kept low.
We believe the true value of a manual
not in “getting people to read it,” but in “the process of creating it.”
The very act of putting operations into words during the final stages of development
is the last line of defense for verifying the system’s usability at low cost.
Of course, the existence of a manual
.
However, that frequency is at most once a year.
If a function is used more than once a month or once every six months, users will naturally memorize it.
We do not treat manuals as “deliverables,”
but as a “quality inspection tool,” and we require every SE to create one.
For this reason, we do not
we do not charge our clients for documentation management fees.
Furthermore, rather than creating a lavish, comprehensive manual,
but rather a simplified version that includes screen captures and an overview of operations.
This allows us to keep costs down while achieving our primary goal of improving quality.
This approach is the practical wisdom that realistically supports system operations for small and medium-sized enterprises.
We hope the above serves as a useful reference
we hope the information above proves helpful.
That's all, Thank you for reading.
------------------------------
■ Previous / Next Column ■
>>> Previous Column Vol.168 - Operation manuals are money pits — all effort, no reward 2025.10.01
Sending your message. Please wait...