When “Easy to Use” Is the Wrong Goal

I’m Aki Matsumura from the operational efficiency project team. Our company is in the early stages of planning a new internal system, and the process has already surfaced a gap in my own thinking — one worth sharing.

A Question I Misread

During a conversation with our CEO about the project, he offered a piece of advice: make sure to coordinate closely with each department about what they actually want to achieve through the system.

My response was something like: “I’d like to shadow each department’s actual work so I can design something that fits how they operate.” A reasonable answer, I thought. But the CEO gently pushed back: “No, that’s not quite what I mean.”

I had interpreted the question as being about usability — designing a system that’s intuitive and friction-free for each team. But that wasn’t the point. The deeper question was: does each department understand what the system is ultimately trying to accomplish? And does our project team understand their answer?

The Real Pitfall: Optimizing the Parts, Breaking the Whole

That exchange made me reflect on the real priorities. Here’s how I’ve distilled it:

• The primary goal of a system isn’t to solve each department’s individual problems — it’s to improve the flow of work across the entire company.
• That sometimes means individual teams take on more work than before — for example, capturing data they never tracked. That extra burden exists for a reason: it serves the whole.
• The system is a means to improve the company’s overall performance. Think of it as improving the “circulation” of the organization. Usability matters, but only in service of that larger goal.

Written out like this, it sounds obvious. But these things are easy to lose sight of when you’re in the weeds of requirements gathering and interface design. I suspect the CEO has seen DX projects go sideways before — optimizing for individual convenience while the bigger picture drifts.

The Company as a Living Organism

The real purpose of system development isn’t to fix individual department pain points. At a higher level, it’s to optimize the company’s entire operational flow — to increase the organization’s overall value.

A department might prefer to keep doing things the way they always have. But if the whole company benefits from a new process, that department may need to adapt — even if it’s harder for them in the short term. That friction is not a failure of the system. It’s a necessary cost of improving the whole.

I think of the system as the bloodstream of the company. Good circulation means every organ — every department — gets what it needs and functions well. When blood flow is blocked or sluggish, the whole organism suffers, even if individual parts feel fine. Building that circulation requires understanding the whole body, not just the part in front of you.

That requires more than a developer’s perspective. It requires something closer to a management perspective — understanding the company’s strategy, its constraints, and where value actually gets created.

Frontline Experience Still Matters

None of this means usability doesn’t matter. A system no one uses is a system that doesn’t work, no matter how well it serves the company’s strategic goals in theory.

In manufacturing especially, the people keeping operations running are often the busiest people in the building. Even a small friction point in a data entry screen is a real obstacle. So yes — intuitive UI, mobile-friendly input, smooth workflows: all of these matter.

And there’s room to go further: image recognition to auto-read gauge values, AI-assisted data entry, automated capture of data that currently requires manual effort. The ideal is a system where people spend their time on decisions and judgment — not on feeding information into a machine.

Holding Both Goals at Once

The challenge is holding both things at once: the strategic goal of whole-company optimization, and the practical need for a system that real people will actually use. Neither can be sacrificed for the other.

That balance — and the discipline to keep returning to first principles when the design pressure mounts — is what I think DX actually demands. There’s still a lot for me to learn. But this conversation with our CEO made one thing clear: the question to keep asking isn’t “Is this easy to use?” It’s “What are we actually trying to accomplish?”