24 Comments

Summary:

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.

Less Than Sign

“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?

  1. Since I just wrote an ebook titled “A Simple Guide to SEO”, I’m not sure I’m the guy to ask about simple.

    I do love my Photoshop, which is one of the most complicated applications I know of, except maybe for Final Cut, which I’m able to use, but feel overwhelmed.

    I think “simple” is not the best goal and is hurting the value of “ease of use”. I don’t mind complexity if it’s easy to use. I don’t like “limited”.

    It’s a matter of definitions. If “simple” equals “limited”, then I hate it. If “simple” equals “easy to use”, then I like it.

    Share
    1. It does come back to the definition of simple. Ultimately though, my fear is that the goal of simple as easy forces us to accept simple as limited.

      Share
  2. Scott — Great post! Doug Engelbart and Alan Kay (of Xerox PARC, Dynabook, Smalltalk etc) had a really good conversation on this during a panel at the Oct 1995 MIT/Brown symposium on the 50th Anniversary of Vannevar Bush’s As We May Think. One great quote from Alan:

    “Alan Kay: Looking back I think that one of the paradoxes is that we made a complete mistake when we were doing the interface at PARC because we assumed that the kids would need an easy interface because we were going to try and teach them to program and stuff like that, but in fact they are the ones who are willing to put hours into getting really expert at things – shooting baskets, learning to hit baseballs, learning to ride bikes, and now on video games. I have a four-year old nephew who is really incredible and he could use NLS [Engelbart's 1968 hypertext system] fantastically if it were available He would be flying through that stuff because his whole thing is to become part of the system he’s interacting with and so if I had had that perspective I would have designed a completely different interface for the kids, one in which how you became expert was much more apparent than what I did. So I’m sorry for what I did.”

    My favorite quotes from the panel and more Engelbart links: http://traction.tractionsoftware.com/traction/permalink/Blog1246

    My two cents on Tricycles vs Training Wheels: http://traction.tractionsoftware.com/traction/permalink/Blog9

    Share
    1. Thanks for the links Gregg.

      Certainly it is important to define and acknowledge your audience and present accordingly, having it also discount the intuitiveness and tenacity of your users isn’t the right way to do it. I don’t envy those who have to find that balance.

      sb

      Share
  3. Simplicity even looks better in many cases. Photoshop has plenty of features&buttons, that’s why i wanted to learn GIMP when moved to open source.

    Share
    1. It’s been a few years since I’ve used it but I think GIMP is a great example – although I think it can ironically be used to present the argument either way. The GIMP interface is a bit radical at first glance and I find that it does initially turn a lot of people away. Most who do take the time to master it though will rave about the quality of the program.

      sb

      Share
  4. Good points. Balancing simplicity and robustness is always an issue when looking at new applications.

    Share
    1. Absolutely Bill. As a user / evaluator how do you insure that you are choosing not only an application that your people can use but one that also fills the needs of your business?

      thanks
      sb

      Share
  5. That’s exactly what I’ve been running into lately. I love the idea of simple, easy to use software. But that only works if it’s all you need. The overhead and cost savings are easily shot out the door when you factor in the need for a handful of other web apps to make up the lack of features of others. Now you have a bunch of “disconnected” systems, new costs for EACH app, bigger learning curve, multiple systems to log in to and overall lower productivity.

    http://thesmallbusinessweb.com is one of my favorite initiatives in this arena, but I wish the integration was better. Sure some of those apps can push data back and forth, but it’s nowhere near as smooth as having an all-in-app.

    Look at 37signal’s single sign on feature they released recently. Anyone who’s uses it will tell you that the increase in speed of moving through your apps is amazing. We need more of that going on in small business apps.

    Share
    1. Jason,

      Exactly – the integrations are critical. I’m amazed at some of the horribly complex Rube Goldberg inspired processes people use to get data from one place to the other.

      I’m also big fan of The Small Business Web and what they are working towards. I hope that they continue to build upon the integrations that they have put in place – it’s a great first step but there is still a ways to go.

      thanks
      sb

      Share
  6. [...] the rest here: Less is Less Share and [...]

    Share
  7. Interesting thoughts. I think there needs to be a mix. Growing into a program is ideal. But if there is not a layer of simplicity to start off with then there is a barrier to people using it. A great example of this working is Gmail. Anyone can use Gmail from day one. At the same time, there are enough added features ( complexity) to satisy power users.

    I think we like “less” because of simplicity and ease of use. To a basic core of simplicity, add features. If they are layered in progressively, you can maintain the feeling of less but still offer more.

    Share
    1. Gmail is a great example. The interface is complex, but not overwhelmingly so.

      With that said though, I have worked with a number of people that have trouble with the threaded conversation view and are generally confused by the presentation. Which email am I responding to? If I reply to this can they see the whole thread?

      The feeling of less but offering more. I really like the sound of that.

      sb

      Share
  8. I think a corollary to this problem is that flexibility and simplicity are considered the same thing. My best example of this is not web software, but Mac task-management apps.

    Omnifocus has been deemed the “complicated” of the programs, compared to Things, The Hit List, and Taskpaper. But unlike all of those programs, it has no open-ended tagging system. It has no Areas of Responsibility like Things. It has no smart folders like The Hit List. And you can’t spread tasks over multiple documents like Taskpaper.

    That’s not to say that Omnifocus doesn’t have confusing yet powerful features, like perspectives and the Projects vs. Context modes.

    But if you’re going to follow GTD fairly strictly, Omnifocus is the best option because it’s the simplest to use, because the structure is already there. You have projects and contexts, not lists and tags that you have to remember are projects and contexts.

    If you’re not into strict GTD, Omnifocus will seem very complicated because it’s trying to pigeonhole you where you don’t want to go.

    So there’s no such thing as an app that’s simpler than another. Just an app that simpler for a certain task(s) or certain user(s).

    Share
    1. Yes, excellent point. In this context, the same things seen as the complexities of OmniFocus are actually making it easier to use for some folks. That really does speak for the concept of creating an application for a specific audience.

      thanks for the comment,
      sb

      Share
  9. User adoption – in my experience – falls dramatically the more feature rich the tool is. I have seen this happen time and time again. Interface – is also a huge part of the tools chance of success. If the interface takes into account workflow and present user with the correct feaures at the correct time then you have a winner.

    I have gone through Salesforce, Batchbook, Basecamp, Huddle, JIRA, TRacs, etc, etc, And most recently Attask. It almost always comes down to – can an average business user do the basics quickly. If not – they loose interest and will most certainly never find use for the more complex features.

    Share
    1. David,

      That’s the rub then isn’t it. Not overwhelming folks upon first visit but providing them what they need contextually.

      There is the danger of hiding the more advanced features as well. I routinely look at new apps and can easily dismiss something if it doesn’t appear to be customizable enough to handle a more complex workflow.

      thanks,
      sb

      Share
  10. [...] Less is Less by Scott Blitstein on WebWorkerDaily [...]

    Share

Comments have been disabled for this post