This post originally appeared November 19, 2010 on BetterProjects.net
About 10 years ago, I was one of the new hire trainers in my technical support department. It wasn’t a full time job, I still spent most of my time answering the phone, but I was incredibly grateful for those 2-3 days each month I didn’t have to wear a headset. The two years I spent training new hires saw our department go through an interesting transition regarding the skillset that incoming technicians possessed. During the first year, most of the new hires had a good understanding of how to use the command line in an operating system, while those who were hired in the second year had mostly never seen anything but a graphical user interface.
This was the late 90’s and early 00’s, so graphical user interfaces had been the norm for some time. I had started using a PC when DOS was used more than Windows but even before that, I had used an Apple IIe which was almost completely text based (except for a few games). I knew how to use a command line, yet suddenly my trainees did not. A significant portion of our troubleshooting tools required knowledge of DOS and command line tools, so I was tasked with making sure the new hires had this knowledge by the time they left my course.
The problem though is that more and more computer users do not have the underlying knowledge that most programs and operating systems assume them to have. This leads to an innumerable amount of problems for those of us that seek to, or are begrudgingly drug, into supporting these users.
I used to love mucking around in the command line or hacking my computer’s registry, but as I’ve spent more and more years on projects developing software, I have come to realize that most users should never need to do either of those things. If applications are designed and developed correctly, user configuration should be near zero. Its this conclusion that makes articles such as this one at The Brooks Review hit so close to home for me:
The article continues by saying that by simplifying the applications we build, we also require less of their time to educate themselves about how the application works. Yes, a program like Adobe Photoshop will always be complex, but if Adobe spent time to make it less difficult to use instead of just adding more functionality with each release, they could improve their user’s productivity.
This is a lesson that all of us who work on projects with a software development aspect need to understand. Corporate applications seem to be, at least from what I have seen, significantly more difficult to use than most consumer applications. The next time you use your company’s expense reporting application, hold up your iPhone next to it and consider if filing an expense report is more difficult than it should be. Now hold that iPhone up next to the last application you helped gather requirements for, created a project plan for or developed code for and ask yourself, “What would I do differently to simplify this for my users?”