Why 'Correct Specifications' Make Work Inconvenient: The Quiet Clash Between Global Standards and Local Operations
When using CAD, you sometimes encounter specifications where you don't understand why they are the way they are.
These are not bugs, but rather the result of being 'correctly designed'.
Some time ago, when I was using Autodesk Inventor, I contacted support about the flag direction for welding symbols.
In Japanese workplaces, it is common practice for the flag to be fixed to the right, regardless of the symbol's orientation.
However, the software's specifications were different.
It was designed so that the flag's orientation would change depending on its placement.
This was not a unique Japanese custom, but a behavior based on international standards.
The support response was simple.
'Please explode the symbol to handle it according to your needs.'
What I felt at the time was not coldness, but a 'difference in premises'.
The common sense of the workplace and the design philosophy of the software did not align.
—
■ Standard specifications are 'governance rules,' not 'correctness'
In global CAD software, specifications are designed to prioritize overall consistency rather than individual optimization.
If you change certain behaviors to match Japanese customs, the consistency with other countries breaks, affecting training, data, and integration.
What is being protected here is not 'ease of use,' but 'globally shared logic'.
* Global standard: Logical consistency
* Local operation: Custom and efficiency
Both are correct, but making them compatible is difficult.
—
■ What happens when you incorporate customer feedback exactly as it is
I have seen a similar structure at a CAD vendor I was involved with in the past.
As a result of carefully collecting customer requests, the product gradually became an 'all-in-one' solution.
Consequently, the specifications became complex, and the overall design philosophy became difficult to see.
Being close to the customer is a strength.
However, closeness without a filter is dangerous.
* Turning requests directly into specifications
* Accumulating exception handling
* Loss of consistency
This is also a form of design collapse that proceeds quietly.
—
■ The same structure exists in public spaces
The same structure is not limited to CAD.
For example, in the management of public spaces, there are cases where the strong opinions of a minority are excessively reflected.
Ideally, there should be a balance with overall usage and design policies, but this is a situation where the 'loudness of the voice' overrides decision-making.
What is important is that what is happening in all these areas is not a 'problem of correctness,' but a question of whether there is a 'design for translating decision-making'.
—
■ Postscript: Specifications are not fixed, they change
Incidentally, when I contacted support about the flag direction of the welding symbol at that time, the answer was to 'explode it to handle it according to the specifications'.
Since then, the product has added a 'fixed to the right' option for JIS standards and behavior selection based on standards, strengthening support for local operations.
In other words, this problem is not being fixed as a 'clash of correctness,' but is evolving in a direction where it is absorbed into the design.
—
■ Not about correctness, but about which layer to protect
Ultimately, there is no simple right answer to this problem.
* If you cater to the workplace, it falls apart.
* If you cater to the standard, the workplace becomes inconvenient.
What is important is not 'which is correct,' but the design judgment of 'which layer to fix and where to allow flexibility'.
CAD, government, and business systems cannot escape this structure.
—
■ Afterword
Specifications are not a collection of correctness.
They are a decision-making process about which of multiple 'correct' options to fix.
Listening to the voices of the workplace is important.
However, how you translate that and incorporate it into the system is the essence of design.
That is why a 'correct specification' is not necessarily an 'easy-to-use specification'.
