When I graduated from college and became a C programmer for NCR Corporation, IT developers were isolated from our systems’ end users by several layers of company teams.
There were the technical writers, who wrote and edited functional specifications. Systems analysts spoke directly with customers about their needs and helped frame functional specifications with the technical writers. And then there was the industry architect. Industry architects were the royal family of customer interaction. They spent time onsite, in meetings and with boards of directors. Industry architects had everything to do with customers—and our customers’ customers, the end users.
With such a long distance between IT developers and end users, you can imagine my surprise when I visited a customer site for the first time.
IT Developers Go Onsite: A Pivotal Experience
Our team of C programmers went onsite to a bank in New Hampshire to do performance testing of the module’s second release. This visit came long after the code was written, the module was tested, software was quality approved, training was developed, and the application was distributed and sold. The new release was finally out in the wild at banks across the country.
We literally shut down the back office of the bank, reinstalled their NCR tower (Unix platform) with release 2 of all the applications, brought the system back up, and tested interfaces with all the peripheral equipment. It was great! So I thought.
Within 30 minutes, the manager of the account processing team asked me to his office. I went in, all smiles, ready to talk about how much faster the new code was. He said three words:
“Put it back.”
That meant, remove the new release and put the old one back on.
“Why?” I asked.
“It’s not the same.”
And truthfully, it was not.
Keyboard shortcuts had been changed. Menus were different. Features behaved in new and mysterious ways. In short, the bank’s highly trained staff did not know how to get their work done with the new release. We put the old one back on and our team of IT developers returned to Atlanta.
Function Trumps Bling: Keep the System Working
That night, at a scary biker bar-slash-Chinese restaurant that was the only place in town we could get a much-needed drink, I went over the implications and asked the team what we had learned.
The main lesson, and one that sticks in my head to this day, is that function trumps bling.
IT developers have thousands of opportunities to bring new shiny objects into the hardware and software space. Some are valuable. But the main focus must always be to keep the system working, and working in a predictable way. End users will overlook product features and even limitations if they are comfortable with the functionality.
Closing the Gap
IT is responsible to keep the drives humming. IT developers have the responsibility, along with IT, to not make massive changes to a look-and-feel of applications. Developers must stay tuned in to what the customer needs and wants, not try to find some excuse to use the latest user interface tricks.
To close the gap between IT developers and end users, I advise my team, and would encourage other programmers to:
- Start with the end-user experience and their satisfaction in mind.
- Sit with users to see how they work with current software in their day-to-day jobs.
- Shorten the chain of command between IT developers and end users.
- Find specific pain points in the user experience, and make them better.
- If it’s not broken, then don’t try to fix it.
The healthcare IT industry needs rigor—strong change management and process documentation. However, getting hands-on input and feedback from end users bridges the growing divide that technology can create in any healthcare organization.
This article was originally published on LinkedIn and is published here with permission.