“If ease of use were the only requirement, we would all be riding tricycles” — Douglas Engelbart
Have you noticed that many web-based services advertise themselves with the premise of “less,” or being “simple?” They say their programs reduce the time and energy that your team exerts using unecessary and distracting features, functions and options, letting them focus instead on just doing their work.
Many people appreciate the loose structure of these tools. We use terms like “agile” and “flexible,” and for a lot of use cases this sort of framework can indeed be very appealing.
For example, let’s look at the typical web-based project management tools. Most are essentially designed to be warehouses for all data pertaining to a project. They integrate basic to-do lists, messaging and milestones and provide a framework to hang our project upon and to make sure nothing gets lost. Their open nature and lack of structure make them capable of accommodating a wide array of projects, and you can essentially make them work for just about anything or anyone.
Conversely though, and what concerns me, is that often the lack of features and perceived overhead can actually introduce more real overhead to your process. At what point does their simple nature become a hindrance to the work that actually needs to be done?
Yes, incorporating something like dependent task assignment adds complexity. Yes, introducing advanced message routing can require some thought and set up time. But these features provide value and are worth it in some instances, because working around the lack of some useful functionality causes users additional real — and ongoing — overhead.
The concept of overhead in this context was introduced to me in a recent chat I had with Hamid Shojaee of Axosoft, developers of bug tracking/project management tool OnTime, which I’ll be reviewing in the next day or so. His comments really got me thinking about the way that web applications are developed and marketed.
I certainly recognize and accept that some products and services naturally offer too much or too little functionality and that a single application won’t work for everyone. Needs, goals and requirements vary across the board and I’m glad that there are the multitude of options available to us. Being mindful of our decisions when choosing these applications and accepting the trade-off that “simple” may bring with it other consequences down the road when your needs change.
I always say the best thing about doing what I do is having the chance to interact with smart people, and talking with Hamid and others is always a fascinating and enlightening process. It is my pleasure to also have occasional chats with self-proclaimed “interface radical” Amy Hoy, designer for the Freckle time tracking service. We rant about the state of user interface and interaction design, and I always appreciate her candid comments.
In our most recent chat we talked about the concept of “simplicity,” and how as a mantra it provides a nice warm fuzzy feeling and a compelling argument for use, but is “less” or “simple” really the issue? She says an application can be complex, or introduce complexity and still be powerful, enjoyable and surprising. “Way too much of the usability talk on the web focuses on first run experience, says everything should be obvious, but that’s oversimplifying the issue.”
So what concerns me is if this quest for creating simple software is hurting us. Are we creating a culture of users that require a dumbed down experience, at the expense of the increased efficiencies and productivity gains we can realize with more complex tools? Are we also stifling the creativity of the designers and developers who are afraid to provide useful features because of the fear that they may be complex or not immediately obvious?
Hoy says, “A tool you use a lot should offer opportunities to grow and learn,” and I love this concept. We as business owners, entrepreneurs, web workers and freelancers are smart, naturally inquisative, resourceful and creative. We are capable of using software that challenges us; in fact, I believe we could benefit from it.
Are you afraid of your software doing less?