You know, if I could answer that question, I could make a great deal of money.
Truly “making things simpler” can be exceedingly difficult, because it generally involves rethinking every assumption, or taking the whole paradigm out for a thorough flogging.
But an easier exercise for most of us is “making things less hard,” or looking for those steps in a process that we include even though they get in the way.The fundamental hurdle to “making things less hard” is recognizing the gap between those that design a system and those who use a system.
How many times have you fired up a piece of software, and found yourself looking for the way to do the simplest things? Just look at all of the buttons on Microsoft Word, for instance, and ask yourself how often you’ve actually used some of them. Ever? At all? Those features are there for a reason, but why do you have to look at all of them all the time? “Feature creep” is not the person who installed all of those bells and whistles, but instead the inevitable drift toward adding without subtracting.
I’m sure there are power users out there who have taken advantage of tab stops and style sheets, but most people are happy writing a simple letter with a little bold here, and a little italics there as warranted for emphasis. (Is it possible that the proliferation of blogging has less to do with “joining the conversation” and “being heard ’round the world” and more to do with a small, sleek interface with fewer than 15 button options?)
“Feature creep” is just one of the eventual bugaboos of a system that goes unexamined too long. The other one to watch out for is just who ends up owning the simplicity. I can create a very simple system for posting prayer requests on a church website. In fact, we can make it as simple as possible: send an e-mail to the church staff. Or place a phone call. Simple, simple technologies. But that requires human intervention on the back end to physically type up the information and prepare it for the web, and for the print newsletter.
In the above case, the simplicity for the end-user results in less simplicity for the staff. A truly functional system will try to automate as much as possible without placing more burden on one end than it already has.
I’ve been noodling around the back-end of my church’s current website, and it certainly is designed to be “simple.” You don’t need to know anything about ftp access or web technology at all. But looking at the interface and the way you have to go about placing the information, there is virtually no flexibility. The staff doesn’t like the interface at all, and there is a big reason for that: the system was designed to be simple for the webhost, and not the end user. Yes, one is able to run a website with just 15-percent of the knowledge required to do it from scratch. However, the site only gives you 2-percent of the functionality.
In making complex things more simple, you need to strike a balance. And if I had my fingers on that magic formula, you’d better believe I wouldn’t be sharing it for free. But I’m willing to bet it resides somewhere close to the reality that many inventions and innovations are created by the people who actually use an item or do a task. Shepherds didn’t need a design committee to generate the proper angle on a crooked stick. So, how many “barnacles” do you no longer need that have attached themselves to a process or system of yours?
[tags]Ike Pigott, Occam’s RazR, Simplicity, Microsoft, blogging[/tags]
