I’m doing you a favor today. I’ve written about this subject before, but I’m going to spare you the trouble of searching my blog and I’m going to spare you the accidental navigation (if you’re reading this on a mobile device and trying to scroll) caused by me inserting a bunch of links to previous posts. I’m looking back over my 35-plus years doing systems development and I’m going to summarize the whole thing for you:
The people who use the systems you build deserve the best experience you can give them.
There. That’s it. That’s really all you have to read. If you are wondering how I came to that conclusion or why I’m bringing it up, feel free to continue reading but if you’re content to nod your head and even grudgingly agree with me, well then, off you go.
OK, you stuck around. You know what that means. You’re going to have to read a story.
In 1988, I was in a meeting with my boss, a representative of our underwriting department and one of my better programmers. We were discussing a feature the underwriters wanted in the system we were developing for them. First, a little background (hey, you had your chance to leave):
Nuclear reactors get shut down for stuff like refueling and when they are shut down we charge them less for insurance. The way we do this is by dividing the year into a series of consecutive time intervals, each with its own set of state variables and its own pro-rata premium. Creating a new time interval was a big deal and a difficult process prior to the system we were writing. The designer wanted to make it easy. He wanted the system to show a list of time intervals and let the user highlight one and press the “+” key to insert a new time interval after the highlighted one.
This seemed like a simple request and I agreed to it. The designer wanted more. Since we had never had such an interactive feature in a screen before (this was running under DOS), he wanted us to build a prototype. I told him that wasn’t necessary. I told him that he could see the working element as soon as it was done. He argued that a prototype was necessary because this was a “radical departure from any previous approach.” He also added that he wasn’t sure we could make this. I slammed my hand on the table and said:
“If the feature you want can be programmed on a DOS PC, she can build it. We don’t have to prove that to you up front, just let her do her (expletive) job!”
After the meeting, the woman came into my office and said:
“I appreciate your confidence in me and I like the way you stood up for me, but I don’t actually know how to do that.”
I knew that, but as far as I was concerned, that fact was irrelevant. She could learn. The feature was going to make someone’s job easier and that was worth learning how to do.
Today, as we are in the early days of a new wave of development, I am more convinced than ever that the effort required to build a better user experience is a price worth paying. The math is simple. You build a system once every three to five to seven years but people use that system every single day. Where do you want them to register on the UI-O-Meter?
As an added benefit for those of you who stuck around, I am giving you the answers to a few common problems. Note: I have tested all of these:
“We don’t have time to do this” – Give them a choice of waiting a little longer or accepting a second phase to the project.
“We can’t do that in SharePoint” – Buy an add-on feature or hire one of those SharePoint whiz-kid consultants who can.
“This can’t be done in SharePoint” – Move the process to a different platform.
“This would take too many development hours” – Do the math. Development hours vs. hours spent using a crappy system.
If all of those fail, slap your hand on the table and sprinkle in a few bad words.
If you have your own favorite excuse and an alternate way of looking at it, please add your thoughts to the comments.