‘We’ve seen some user testing that has shown users asking for more complexity to help enable their decision making.’

I’d approach that kind of user comment with extreme caution.

I often see users asking for more information to help make a decision. But that doesn’t mean they need more information. It just means they’re not comfortable and that they *assume* that more information will solve their problem.

We’ve recently been looking at designs that provide less information, but present it in a more compelling way. Users were happier to make decisions and happier with the outcome.

Equally, we frequently see users succumb to information paralysis. They get so obsessed with research that they become unable to make a decision.

So my experience is that, often, less really is better.

At 37signals we build software for people who are looking for simple tools that execute on the basics beautifully. That means our products aren’t for everyone. And that’s ok. Besides food, water, and shelter, nothing is for everyone.

Just as Microsoft Project isn’t for us, Basecamp may not be for you. Just as Outlook isn’t for us, Backpack may not be for you. And that’s fine. There are plenty of people out there on both sides to make both sides equally good and successful.

As it’s been echoed many times the answer is “it depends.” We’re just trying to provide an alternative so there’s something else to depend on when it depends.

Bottom line: Use what works best for you. It may be our products, someone else’s product, your own custom product. Heck, paper and pencil still works great! I use it that combo all the time myself. And sometimes I use a pen instead, and other times I use a post-it note, and other times I use lined paper, and other times I use unlined. You should use the right tool for the job. It’s up to you what the right tool is for the particular situation you’re in.

Anyway, thanks again for everyone’s civil and interesting comments here!

Right now we have ditched MS Project and waterfall for all our large projects. We have had vastly better results running agile processes, especially now we’ve found good ways to make the process user-centric, including rapid prototyping and multiple rounds of user testing. Above a certain level of scale, waterfall just breaks down. The last $1millon+ project we ran waterfall was a couple of years ago and was probably the toughest project I’ve ever worked on in terms of meeting deliverable and deadlines. And it almost killed the people working on the project. Never again!

For small projcts we still run waterfall, so MS Project is somewhat useful. However the threshold for going agile is getting lower and lower for us, our aim is to eventually be able to run every project this way, at any scale.

As for less is more, this TED lecture is the most compelling argument for it I’ve seen for a long time:

http://www.ted.com/tedtalks/tedtalksplayer.cfm?key=b_schwartz

I love this idea in theory, but I’m yet to see it in practice. The “Advanced” button that Zane mentions is one way, but it doesn’t offer the fine grained “unfolding” that I think is necessary. To my mind, with this approach you either have simple/uncluttered or complex/cluttered.

My thinking is that an “unfolding” UI would gradually release the complexity to the adventurous in the context of their workflow. But that’s easier said than done.

Does that even make sense? If it does, if anyone has any suggestions as to applications/sites that “unfold” or “onion skin” I’d love to hear about them…

I may be an expert on an application, but as a developer, I most often want to get my next bug, not get reports on bug trending. But, maybe I develop and manage a project, so I want to flip between roles quickly. Even if I’m a power user and know everything, I don’t necessarily *want* to be presented with all options. It makes navigation/use difficult, even if comprehension is not a problem.

I believe, therefore, that experties and role (perhaps related to the idea of intent?) represent two different dimensions that must be dealt with as such and cannot be meaningfully collapsed.

But as, the highly talented project manager, Lisa says, it should be more about learning the application, rather than the level you (the user) THINK you are at (we are all worse than we perceive, or is it better, I forget).

So, chuck that into the mix and you get an interface that, somehow, uses HOW you use the UI (decisions you make, and why you make them) coupled with the amount of time you’ve used the application for (allowing for differing rates of comprehension) and it must never ever hide things away without letting the user know about them.

Crack that and become a millionaire!

I’ve been quite interested in this concept that Interaction Designers have been talking about lately, that they call ‘Onion Skinning’, which doesn’t really make that much sense as a metaphor, but the ideas is that there are layers of complexity available, and you only show the bare minimum to start off with, and then users can make their interface more and more complex as they require/desire.

I think it’s entirely true that there’s not one rule as to how simple or complex an interface should be. Instead, as designers/information architects and the like are forever saying ‘it depends’.

I reckon that there are probably some rules/guidelines that can be made around when and how complexity is required (and similarly for simplicity). One day when I have some spare time on my hands, I might have a bash at working out what those are.

At a starting point, it’s got something to do with novice/expert, but I think it also has something to do with decision making processes and intent.

What do you think?

We see this all the time in configuration menues where the common stuff is on the first page, but we can click “advanced” to get a handle on the fine details. Perhaps we need the same thing in UIs. Common stuff up front, uncluttered, and easy to use. Power features, however, are still available by clicking a button that would bring up more features, or maybe even dynamically change the UI itself. Indeed, one could even envision a fully mature approach moving the user through many different UI experiences that, in the case of project management, expose power functions for executives, QA, project managers, etc.

But what if that project manager and the processes she follows are overblown and antiquated? Is that when “less is more” comes into play?

Like most things, I think the less is more approach is useful for certain things. If you have a business manager demanding breakdowns of work, and whatnot, then you can either try and educate that having someone spend a day producing a spreadsheet on costs isn’t really cost effective in itself… or just give him the figures he wants.

To me, the one issue with the 37signals stuff is that it is “just less”. There is no more, no learning curve beyond a certain point. Want more project management features? Use something else? Now that’s advantageous to the 37signals guys but leaves the user high and dry, and having to learn multiple products. A product that hides the ‘more’ until it’s needed is the true holder of “less is more”.

I hope that makes some sort of sense. Hell I know what *I* mean!

I agree with Zane - it totally depends on context and who the audience is. An accounting product by necessity has to do a lot more than, say, a BlinkSale.

But at the same time, BlinkSale probably has more customers because of its simplicity and targeted approach than my friend’s business. So for a reasonable part of the market those added features just aren’t warranted.

I don’t use tools like Basecamp because I need much more nuanced control of defect tracking for a larger scale project. But I can think of many projects I’ve done where Basecamp is perfect. So in one case Basecamp’s “less is better” approach is a benefit, in another it’s a drawback. Each tool for it’s job.

The trick is working out the right balance and making sure that whatever you build it’s as usable as it can be. And sometimes usable != simple.