19 November 2010

The Problem with Applications

Recovering the filesystemsphoto © 2005 Jared Klett | more info(via: Wylio)
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?"


  1. Hi!

    I totally agree with your post. I work for an IT company (Doolphy) and we are developing a project management software. In Doolphy, we have both marketing and technical staff and it's very important for us to combine the latest technology with the best usability, as we are always thinking about what is best for Doolphy users. We believe we have to create something that we would use ourselves and, therefore, we also use Doolphy daily.


  2. Great post!! Thanks for sharing such an wonderful information.

  3. Nice post!, so interesting...Thank you for sharing it.

  4. Rosa... eating your own dogfood, love it! everyone who develops apps should be required to use it at least for some amount of time before users everywhere see it. i'm glad to see you guys do this internally because a lot of development shops don't.