Is a sedan less than an 18 wheeler? Certainly in terms of cargo capacity, but it is more in terms of MPG. So, is less always more? Is more always more? Depends.

Less can be thought of as a feature in-and-of-itself. It has pros and cons. If you need more, less is bad. If you don’t, less is good. And in doing this analysis, one has to define the problem precisely. More of what? To much of what?

In my view, these aren’t questions that one can meaningfully ask ‘in general’ outside marketing brochures (or dogmatic methodology books).

To that point, I think the ‘cult of less’ is the perfect name. What 37 Signals pushes is (at least judging from their blog) more dogmatic than thoughtful. Much of what they say is right for themselves and their target audience, but they seem to not realize that there are other factors at play in the larger market and I’ve seen many a time when they react quite strongly to comments that point out that their points and methods are often put in terms far to general for their actual application.

In light of Ian Crawfords (from 37 Signals) comment that ‘Less is less. Less is just right. Less is better.’, I should have said is ‘is less better?’ rather than the pithy ‘is less more?’.

The point is the same though. Is ‘less’ better when you need an 18 wheeler? No. It’s a ludicrous assertion. You’d spend an order of magnitude more time and money transporting cargo in a fleet of sedans rather than a single 18 wheeler.

And yes, the same is true for software. Many people have been seduced by the ‘cult of more’, but that does not validate the cult of less. Most of the time a simple text editor is all I need, but sometimes there is clear benefit from using Open Office.

Sorry for the serial posts… it’s like a schizaphrinic conversation.

‘Less is more’/'less is better’ is a reaction to the ‘more is better’ philosophy that I think is actually better answered by the Agile crowd. Agile (which has it’s problems as well mind you) is focused on trimming the unecessary, rather that preaching the idea of less as an absolute good.

The goal of Agile is to maximize the utility of the customer, and if we want something as an absolute, this works better IMO than a philosophy of ‘more’ or ‘less’. It is then the art of the developer to determine whether the customer needs more or less to be ‘happier’.

If we wanted to put a pithy name for it (am I coining this for software?), we could call is ‘least is more’.

I had this conversation with a friend of mine that’s developing an online accounting product. He consistently gets requests from customers who need functionality in order to run their business. To these customers, the “less is better” approach doesn’t serve their needs.

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.

So, MS Project helped you become the project manager you are/were today.

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!

To both Grant and Gordon’s point, it reminds me of an excellent design trick that we’re all familliar with: the “advanced” button. The best discussion I ever saw of this idea was in terms of the Java SWING API (which is very complex) by (I believe) one of the creators of JNDI. He was arguing that the base API should be very simple, allowing developers to do common things, like create a dialog box, with a single command (SWING as it stands would take dozens). For those users that need it, you’d call “getAdvancedApi” or whatever and get a handle on the full blow API.

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.

hey guys, thanks for your comments so far! I’m agreeing with pretty much all of it (except that I think Gordon was suggesting that I must be a bad project manager because I got my initial skills from Microsoft!!)

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?

Zane - some applications already offer that ‘view’ of functionality. I’ve used a few that, as part of the installation, ask what type of user you think you are and then limit the interface based on that.

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 don’t think it’s so much about level or expertise as role. I’ve not seen an application that does that yet, but I’d think the better solution is to do this dynamically rather than during installation as the interface should be dynamic on role (I’m assuming a bit here).

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.

The idea of “onion skinning” is something that intrigues me. Returning to that online accounting application - one of the things I discussed with my friend is that the interface should “unfold”. The simplest usable UI by default, then the UI provides hints to more advanced features that are then accessible.

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…

MS Project is a perfectly ok tool. The problem is that it is built around the waterfall project management approach: gantt charts, dependencies, milestones etc. Agile design / development doesn’t work that way or need this. Planning an agile project with MS Project is a pointless exercise: you could use the same gantt chart for all agile projects, just change the dates.

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

Great discussion. Thanks for getting it started.

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!