I’m currently reading Designing the Obvious, and I’ve also read Rework before that, along with a few other web design and usability books. This by no means makes me an expert on the subject, but even someone new to the field can discern some main trends just from reading these few books. Most books advocate keeping things simple, reducing features, and the “less is more” philosophy (or, as 37Signals would say, “less is less“).
I don’t have a problem with this in principle. I think it’s an admirable goal, and it certainly makes everybody’s life easier when an app is easy to use and straightforward.
But I also wonder if the proponents of this simplification dogma are not, well, over-simplifying the problem.
For example, one of the most common piece of advice is reducing the number of features, until you’re left with only the ones that are absolutely vital to the application or website. This way the app will be both faster to develop and easier to use, and you’ll be well on your way to holding $1,000 a seat workshops. Sounds good, but how does this hold up to reality?
Not very well, it turns out. Most clients don’t hire you to tell them to drop half of their app’s features. They’ve already spent thousands of dollars developing these features, or maybe a big clients of theirs has requested them. Or maybe, and this is the most common scenario, those features are actually vital to the app but you just don’t have the experience in that particular field to know that.
Yes, there’s a world besides project management software and sign-up forms. A big part of design happens behind closed doors, on intranets or highly specialized applications for fields like medicine or finance. How can you be sure which feature is core to the application and which isn’t really needed? Is the decision even yours to make?
The real challenge of design lies in taking an app full of confusing features —including a few that you might not even understand yourself— and still make it usable.
And don’t believe those who tell you that you shouldn’t compete on features. A product with two features will always lose to a similar product with three well-implemented features. People might want “simple”, but they don’t want “dumb”. And in a lot of case, they don’t even want simple at all.
The other issue with this line of thinking is that you might start to always try to “out-dumb” your users. You’ll to think up the dumbest thing someone could do with your app, and end up designing for the lowest common denominator. And this leads to the inhibition of creativity and risk-taking.
Once you’re designing for the least computer-savvy users possible (the ones who try to log in to Facebook on ReadWriteWeb) there’s no way you’ll ever try anything new.
Ironically, people tell you to stick to user interface conventions to avoid confusing users, but they forget that in order to create those conventions, someone, somewhere had to once try out something that worked better than what was there before.
Thankfully, not everyone is buying into this. A perfect example would be the new Twitter for iPad app. Are the sliding panels absolutely necessary? No, none of the other Twitter apps use them. Do they make you think? Yes, they take some time getting used to. Do they make the app more enjoyable to use than any of the other, “simpler” Twitter apps? Absolutely.
So in conclusion, I think we should all trust our clients and our users a little more. Sure, most people hate computers and can’t tell their browser from their operating system. But our goal shouldn’t be to cater to their ignorance. It should be to take them by the hand, and make it easy and painless for them to get better at the Internet.
Hi, I agree with you in some points you are making, but I think it highly depends on context in which you are designing the app. If you design your own application, keeping things simple will protect your sanity
You would go crazy to well implement all features in the first release.
On the other hand, if a client hire you to build complex app, you can’t tell him to reduce features unless they are not making any sense. The client should know, which features are vital and which are unnecessary.
@Icoach, I agree with you. But my problem is that a lot of usability resources simply don’t address the “complex app” situation. For example, they rarely touch on the subject of managing information density.
I don’t think 37signals would disagree with you about making products for other people, their recommendation is just that they don’t do it
If they did, they’ll absolutely have to find out what the requirements are and work to implement them through a usable interface.
The problem lies in knowing less than your client. 37signals don’t want to be in that position. If you are, then you absolutely have to communicate and discover exactly what it is your client needs. It’s going to be harder than making something for yourself, but it doesn’t contradict 37signals advice: their choice is simply strategical, they don’t design web apps that they themselves don’t need.
Also, feature selection is a key part of application design. Sure, the client may know exactly what they want, but they may not be necessarily the right people to translate those requirements into features–the designers are. The conversation shouldn’t just end at selecting the best interface for a given feature–it should inquire into whether that feature is needed at all. Maybe there’s a better way to give the user what they need? Maybe adding this doesn’t make any sense at all? The designer should be asking these things.
Of course the problem here is that you’re not the user of the application, so it’s much more difficult to make these calls. I agree with you that it’s not really about making something as simple as possible: it’s about translating requirements (however complex) into something that’s easy to use.
@Dmitry, thanks for your comment! I mostly agree with you. Obviously the 37Signals approach works for them, and can work in many cases. In fact I would probably use the same design philosophy for my own products.
I guess the problem is when this philosophy is used as a way to avoid dealing with hard problems like managing complexity. Usability should also be about making complex apps work, and not just simplifying them.
I only sort of agree with you. I think, as software developers, it is our job to work with the client to help them prioritize what are the base, most fundamental elements/features that need to be implemented. Once this skeleton system has been built and “played with”, then the client can prioritize the rest of the features. In my experience, if developers follow this method, only about 60% of the features will ever be implemented.
There are always things that are absolutely needed, things that should be built and a list of things that are simply “nice to haves”. By implementing the must haves and the should haves first, you are simplifying the system for you client and yourself. The nice to haves may never be implemented. But this all takes very careful client management in terms of expectations and prioritization.
As for the user interface, there are certain conventions out there that are followed, not necessarily because someone took a chance and found something that worked better, but because those things have been tested over the last several years and proven to work the best. This is not say that there are not areas for innovation, but do not confuse something that is new and novel with something that works.
However, as developers and UX people, it is our job to take what the client wants and give it back to them in a format that is usable for them. This means that you test your ideas with your users and have them tell you what the best implementation is.
In all, you are confusing software built for clients with software built for customers. For the later, the developers have the ability to innovate and try new things. However, the former requires a lot more discipline and, ultimately, needs to be created to meet the needs of the user. This means figuring out the conventions that work for the user involved (both computer related and otherwise).
Maybe being a freelance designer brings me a different perspective than working in a company. But I find that most of the time, I simply don’t have the authority or the knowledge to decide for sure which feature is vital and which is simply “nice to have”.
I can’t rewrite a company’s business plan for them, nor is it my role. The best I can do is make sure that the features that they do have are easy to use.
My criticism of usability advice is that it pretends that we’re all working at Apple or 37Signals.
The rest of the world, the companies who don’t — or can’t — adhere to “less is more” are the ones who need usability advice the most, but are often dismissed as dinosaurs from a bygone era who simply haven’t seen the light yet.
Pingback: Wochenend-Lektüre #4 – FRONTAND
Pingback: What I’ve Read: 10-09-05 to 10-09-19 | CSS Radar
Don Norman has another article, “Simplicity is not the goal,” that hits the nail on the head: http://j.mp/2iv0Dt.
He argues that ease of use and capability are the true goals, not to be confused with “simplicity” and “features.” It’s true that simplicity implies ease of use, but ease of use does not necessarily imply simplicity. (And similarly for features and capability.)
So simplicity and features are false idols, over-simplifications of deeper issues, like ease of use and capability. There is furthermore a tension between desirability (which is driven by features) and usability (which is threatened by feature creep). At purchase time users are motivated by desirability, whereas at the time of use they are motivated by usability.
So the designer’s job is to manage these tradeoffs and find balance points.
Correction: the article title is “Simplicity is not the answer.”
Thanks for the link! That’s basically the same point I was arguing, except he does it much better of course
Each time a designer says the words, “I think…” a user dies.
Question … what do you call it in mass production when you don’t (and can’t) design for the lowest common denominator?
For example, an auto maker can’t make cars for the entire population (ie. real short people, real tall people or real heavy people)
Airline seats, walkways, parking spots.
You build for the masses knowing some won’t benefit.
For example when building a website and not considering IE6.
That philosophy has a name, anyone know it?
Thx.
Webhead