6 ms·

Minimizing Complexity In User Interfaces

67 points by nreece 17y ago

10ren 17y ago
80% of users use only 20% of software features - but they don't all use the same 20% (according to Linus, anyway).
- sachinag 17y ago
  And Microsoft, Oracle, Adobe, and pretty much any maker of any complex app. Hell, I bet that's even true for Basecamp.
- snprbob86 17y ago
  As you state, there is a lot of evidence that everybody uses a different 20% of the features. However, I think that primary applies to horizontal apps such as operating systems and core office productivity suites. I recall reading on Jensen Harris' Office 2007 new UI blog that they tried their damnedest to remove features, but no one could come up with any reasonable way to pick any features to cut other than a select few which were practically unused by anyone. They had extensive usage data to work with. Meanwhile, the feature-poor Windows Live Writer has taken off like a rocket for bloggers. That may be true for something like Excel, Word, Linux, etc, but I think that wouldn't be as true for vertical applications. Sometimes, I wonder if would be better off turning the core word processing components into a library and releasing verticals for different types of writers. Professional writers, for instance, probably don't need any formatting tools other than headings. Blog writers should only use things that can be represented well by typical HTML blog engines. Etc. I think this is a case where the advice that is right for startups (typically verticals) is not right for the big guys. As a little guy, I'm betting on nailing 20% of the features and scoring 18% of what people want :-)
  - 10ren 17y ago
    Your library point is technically appealing, but economically it costs Microsoft nothing to include everything (since the code's already written), and adds some value for some people, helping to support a higher price. In fact, Microsoft tries to go even further the opposite way, by grouping Word with other software in Office. Instead of separating an application into libraries, they combine applications. But you can simulate the absence of features by hiding them. In terms of usability, Word defaults to hiding menu items, to remove the clutter of rarely used items. Many people don't like it, and turn it on, just in case they need something, but the fact that MS has chosen to make it the default maybe indicates that it's been favourable in their user trials (though they also choose clippy). The same thing could be done for vertical specialization. Finally, I agree with you about startup strategy. My reasoning is that you have limited time and resources for implementing and polishing features, so you'd better focus on what's really important. There's that marketing concept that if you really nail it for some specific niche, you'll be successful with them ("a small number of users really love you"). That's much better than making it almost acceptable for a huge number of people. I think that if you can later add other features that also have some value, you should. 37signals disagrees, saying you should keep the feature set tiny and unbloated (though they have added whole other separate products instead), But maybe there can be a natural life-cycle for vertical applications that grow and generalize into a horizontal application, as capabilities are (sensibly) added, as in "Text editors evolve until they can read mail. Those that can't will be replaced by those that can"
grinich 17y ago
The lack of a button is a feature.
mmphosis 17y ago
I thought that I was a GUI whiz, until an old mainframe programmer told me that the best user interface is no user interface at all.
- mahmud 17y ago
  Cobol programmers are a goldmine of wisdom and knowledge. You will learn more about business software from an old, unsung bloke like Tony Marston than anybody celebrated methodology or blogsphere celebrity. http://www.tonymarston.net/ http://www.tonymarston.net/ Having said that. I really wish more people would ignore them, for my own competitive benefit.
mrshoe 17y ago
This is a great article and it covers almost all the bases. The only thing I'd add is a discussion of UI refactoring. Over time, creeping featurism tends to take over. Your users will request every possible feature and your marketing department will want to add more check marks to your product's column in the feature matrix. As this article points out, you have to be the bad guy and Just Say No most of the time. However, when a large subset of your users request a certain feature, the best response is often to refactor your design. Don't just add the feature. Figure out why they're requesting it. In other words, figure out why the current design is lacking. At that point you can come up with a new design which lets your users accomplish what they're trying to do. User interfaces age like code bases in this way. If you keep adding to them, they get really ugly really quickly. If you instead take the time to refactor them, they can remain beautiful while becoming more capable.
- gnoupi 17y ago
  Fully true, but how many times you will be able to justify that refactoring to the ones who asked ? Most of times, all they want in a "fast, small new important feature to put in a new menu item". It's hard to make them realize that because you add new features, most of times the dynamic of the UI has to be rethought. And it ends usually in an application with countless menus and modes even for these menus. So redesign is important, but how do you justify to your marketing (or head programmer) that they have to "pay" for a redesign of what they "paid" already months ago, just for one feature ?
  - megaduck 17y ago
    Refactoring doesn't have to be massive. Perhaps you can get by with a subtle tweak, so long as it's well thought out. Alternatively, if adding a feature demands a massive refactor, then it might be a warning signal that you've got some fundamental issues with your UI. In that case, it might be worth it to spend the time re-examining the core design of your app. You also might refuse to support that feature. Being able to say "no" is an important skill, both as a designer and a developer. Leaving stuff out is often as important as putting it in.
alabut 17y ago
The article has a lot of references to 37signals and is in the same spirit of advocating simplicity. The one link that got overlooked is the one that offers the most concrete advice on how to make a simpler interface - design from the inside out, what they call Epicenter Design: http://gettingreal.37signals.com/ch09_Epicenter_Design.php http://gettingreal.37signals.com/ch09_Epicenter_Design.php I found myself often doing the opposite before reading that - I'd noodle on logo designs, navigation, and general information architecture tasks, even at early prototyping stages. It must be human nature.
rooshdi 17y ago
“Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity." - Charles Mingus Couldn't have said it better myself. The UI is the work of art and the core features are the gems which capture the user's eye and imagination.
chrischen 17y ago
The intuition of the non-designer seems to always to be complexity. They are bothered by white-space and try to fill it. It's as if they are afraid to seem like their work took no effort if the end result looks simple, when it's actually the simplest solution which takes the most effort.
fauigerzigerk 17y ago
The best way to get a lean streamlined application is by eliminating features. Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't all be just variants that could be educated away. They are real needs. So, not having these features means not to satisfy some user requirements. Sometimes I get the feeling that we kid ourselves into believing that if we create a super clean, consistent UI that doesn't inundate users with features they don't use, we have somehow succeeded. Most of the time we have not, because for each individual user the application most probably lacks very important functionality. A user who repeats the same laborious steps day in day out in order to achieve something with my software will gladly accept any number of useless features in his face just to get that one feature that makes his/her work 10 times more productive. I'm afraid UI/feature minimalists will never understand why on earth so many people will pay $650 (or whatever) for MS Office, the mother of all feature monsters.
- TomOfTTB 17y ago
  Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't all be just variants that could be educated away. They are real needs. So, not having these features means not to satisfy some user requirements. Not necessarily. Interaction Design has always focused on profiling users and then using those profiles to expose the functionality that user needs while obscuring the functions they don't. So "eliminating" a feature can just mean having the user set up what features they will use before hand and then using that info the streamline your UI (clearly you'd want some way to change those preferences but that's another discussion) I think a lot of UI design has gone backwards by ignoring this insight. To give one example, Toolbars have gotten a bad name because developers used them badly in the past. But they had a good purpose which was to allow users to un-clutter their interface by hiding functions they don't use. Now we have Microsoft pushing the unwieldy, homogeneous Ribbon which throws all those confusing features at the user. But the bottom line is I don't think you need to go as far as taking out a feature just to eliminate it from the sight of a user who won't use it
  - 17y ago
imajes 17y ago
Wow. I didn't bother reading this post as the author's site is entirely cluttered with crap. Much better to read Ryan Tomyako's post on this: http://tomayko.com/writings/administrative-debris http://tomayko.com/writings/administrative-debris
RyanMcGreal 17y ago
> Studies have found that 80% of users use only 20% of software features. The problem is that it's not the same 20%.
thunk 17y ago
Yeah, emacs and vim would never have gotten where they are if it weren't for their simple, intuitive interfaces. The Simple UI camp is wrong: It's not complexity you want to minimize in a UI -- muscle memory will take care of that -- it's time and exertion. Reminds me of: http://www.theonion.com/content/video/apple_introduces_revolutionary http://www.theonion.com/content/video/apple_introduces_revol...
- cschneid 17y ago
  I disagree in a large part due to different use cases. Developers often "live" in their editor, using it all day. Because of that, a non-obvious interface is ok, if the benefit is faster processing. The same reasoning applies to the old school text interfaces for insurance agents. They can fly through it and get you a quote very quickly. But, I know that I don't use my time tracker application often enough to allow it to become super cluttered and non-obvious. Same with my bank's website. Different use models require different approaches to usability.
fnid 17y ago
The illusion here is that simple/less complex apps are better. But the reality is that more simple apps with fewer features means the end user needs more apps to manage their business or their lives. Your invoicing app may be simple and let you send an invoice, but does it integrate with your time entry system? Wouldn't a time entry system that does invoicing or an invoicing system that also does time entry be better than two disparate apps that do one or the other? Who wants to waste time entering the same information twice? Making data entry mistakes? Flipping between different apps, usernames, passwords... The problem with the simple is better line of thinking is that it actually complicates the business life. Multiple accounts at multiple sites. Multiple payments to multiple vendors. Different user interfaces to learn at each site. Different ways of doing things. Maybe the enter key over there submits the form, but it goes to another field somewhere else. All these separate systems are really just features of a business management suite and I'd rather keep all my stuff in one place than have 15 accounts at different locations to do one thing. If I can pay $50 a month for a system I can customize to do what all these 15 sites do for $10-99/mo I'd be a much happier customer.

67 points by nreece 17y ago

10ren 17y ago

80% of users use only 20% of software features - but they don't all use the same 20% (according to Linus, anyway).

sachinag 17y ago
And Microsoft, Oracle, Adobe, and pretty much any maker of any complex app. Hell, I bet that's even true for Basecamp.
snprbob86 17y ago
As you state, there is a lot of evidence that everybody uses a different 20% of the features. However, I think that primary applies to horizontal apps such as operating systems and core office productivity suites. I recall reading on Jensen Harris' Office 2007 new UI blog that they tried their damnedest to remove features, but no one could come up with any reasonable way to pick any features to cut other than a select few which were practically unused by anyone. They had extensive usage data to work with. Meanwhile, the feature-poor Windows Live Writer has taken off like a rocket for bloggers. That may be true for something like Excel, Word, Linux, etc, but I think that wouldn't be as true for vertical applications. Sometimes, I wonder if would be better off turning the core word processing components into a library and releasing verticals for different types of writers. Professional writers, for instance, probably don't need any formatting tools other than headings. Blog writers should only use things that can be represented well by typical HTML blog engines. Etc. I think this is a case where the advice that is right for startups (typically verticals) is not right for the big guys. As a little guy, I'm betting on nailing 20% of the features and scoring 18% of what people want :-)
- 10ren 17y ago
  Your library point is technically appealing, but economically it costs Microsoft nothing to include everything (since the code's already written), and adds some value for some people, helping to support a higher price. In fact, Microsoft tries to go even further the opposite way, by grouping Word with other software in Office. Instead of separating an application into libraries, they combine applications. But you can simulate the absence of features by hiding them. In terms of usability, Word defaults to hiding menu items, to remove the clutter of rarely used items. Many people don't like it, and turn it on, just in case they need something, but the fact that MS has chosen to make it the default maybe indicates that it's been favourable in their user trials (though they also choose clippy). The same thing could be done for vertical specialization. Finally, I agree with you about startup strategy. My reasoning is that you have limited time and resources for implementing and polishing features, so you'd better focus on what's really important. There's that marketing concept that if you really nail it for some specific niche, you'll be successful with them ("a small number of users really love you"). That's much better than making it almost acceptable for a huge number of people. I think that if you can later add other features that also have some value, you should. 37signals disagrees, saying you should keep the feature set tiny and unbloated (though they have added whole other separate products instead), But maybe there can be a natural life-cycle for vertical applications that grow and generalize into a horizontal application, as capabilities are (sensibly) added, as in "Text editors evolve until they can read mail. Those that can't will be replaced by those that can"

grinich 17y ago

The lack of a button is a feature.

mmphosis 17y ago

I thought that I was a GUI whiz, until an old mainframe programmer told me that the best user interface is no user interface at all.

mahmud 17y ago
Cobol programmers are a goldmine of wisdom and knowledge. You will learn more about business software from an old, unsung bloke like Tony Marston than anybody celebrated methodology or blogsphere celebrity. http://www.tonymarston.net/ http://www.tonymarston.net/ Having said that. I really wish more people would ignore them, for my own competitive benefit.

mrshoe 17y ago

This is a great article and it covers almost all the bases. The only thing I'd add is a discussion of UI refactoring. Over time, creeping featurism tends to take over. Your users will request every possible feature and your marketing department will want to add more check marks to your product's column in the feature matrix. As this article points out, you have to be the bad guy and Just Say No most of the time. However, when a large subset of your users request a certain feature, the best response is often to refactor your design. Don't just add the feature. Figure out why they're requesting it. In other words, figure out why the current design is lacking. At that point you can come up with a new design which lets your users accomplish what they're trying to do. User interfaces age like code bases in this way. If you keep adding to them, they get really ugly really quickly. If you instead take the time to refactor them, they can remain beautiful while becoming more capable.

gnoupi 17y ago
Fully true, but how many times you will be able to justify that refactoring to the ones who asked ? Most of times, all they want in a "fast, small new important feature to put in a new menu item". It's hard to make them realize that because you add new features, most of times the dynamic of the UI has to be rethought. And it ends usually in an application with countless menus and modes even for these menus. So redesign is important, but how do you justify to your marketing (or head programmer) that they have to "pay" for a redesign of what they "paid" already months ago, just for one feature ?
- megaduck 17y ago
  Refactoring doesn't have to be massive. Perhaps you can get by with a subtle tweak, so long as it's well thought out. Alternatively, if adding a feature demands a massive refactor, then it might be a warning signal that you've got some fundamental issues with your UI. In that case, it might be worth it to spend the time re-examining the core design of your app. You also might refuse to support that feature. Being able to say "no" is an important skill, both as a designer and a developer. Leaving stuff out is often as important as putting it in.

alabut 17y ago

The article has a lot of references to 37signals and is in the same spirit of advocating simplicity. The one link that got overlooked is the one that offers the most concrete advice on how to make a simpler interface - design from the inside out, what they call Epicenter Design: http://gettingreal.37signals.com/ch09_Epicenter_Design.php http://gettingreal.37signals.com/ch09_Epicenter_Design.php I found myself often doing the opposite before reading that - I'd noodle on logo designs, navigation, and general information architecture tasks, even at early prototyping stages. It must be human nature.

rooshdi 17y ago

“Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity." - Charles Mingus Couldn't have said it better myself. The UI is the work of art and the core features are the gems which capture the user's eye and imagination.

chrischen 17y ago

The intuition of the non-designer seems to always to be complexity. They are bothered by white-space and try to fill it. It's as if they are afraid to seem like their work took no effort if the end result looks simple, when it's actually the simplest solution which takes the most effort.

fauigerzigerk 17y ago

The best way to get a lean streamlined application is by eliminating features. Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't all be just variants that could be educated away. They are real needs. So, not having these features means not to satisfy some user requirements. Sometimes I get the feeling that we kid ourselves into believing that if we create a super clean, consistent UI that doesn't inundate users with features they don't use, we have somehow succeeded. Most of the time we have not, because for each individual user the application most probably lacks very important functionality. A user who repeats the same laborious steps day in day out in order to achieve something with my software will gladly accept any number of useless features in his face just to get that one feature that makes his/her work 10 times more productive. I'm afraid UI/feature minimalists will never understand why on earth so many people will pay $650 (or whatever) for MS Office, the mother of all feature monsters.

TomOfTTB 17y ago
Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't all be just variants that could be educated away. They are real needs. So, not having these features means not to satisfy some user requirements. Not necessarily. Interaction Design has always focused on profiling users and then using those profiles to expose the functionality that user needs while obscuring the functions they don't. So "eliminating" a feature can just mean having the user set up what features they will use before hand and then using that info the streamline your UI (clearly you'd want some way to change those preferences but that's another discussion) I think a lot of UI design has gone backwards by ignoring this insight. To give one example, Toolbars have gotten a bad name because developers used them badly in the past. But they had a good purpose which was to allow users to un-clutter their interface by hiding functions they don't use. Now we have Microsoft pushing the unwieldy, homogeneous Ribbon which throws all those confusing features at the user. But the bottom line is I don't think you need to go as far as taking out a feature just to eliminate it from the sight of a user who won't use it
- 17y ago

imajes 17y ago

Wow. I didn't bother reading this post as the author's site is entirely cluttered with crap. Much better to read Ryan Tomyako's post on this: http://tomayko.com/writings/administrative-debris http://tomayko.com/writings/administrative-debris

RyanMcGreal 17y ago

> Studies have found that 80% of users use only 20% of software features. The problem is that it's not the same 20%.

thunk 17y ago

Yeah, emacs and vim would never have gotten where they are if it weren't for their simple, intuitive interfaces. The Simple UI camp is wrong: It's not complexity you want to minimize in a UI -- muscle memory will take care of that -- it's time and exertion. Reminds me of: http://www.theonion.com/content/video/apple_introduces_revolutionary http://www.theonion.com/content/video/apple_introduces_revol...

cschneid 17y ago
I disagree in a large part due to different use cases. Developers often "live" in their editor, using it all day. Because of that, a non-obvious interface is ok, if the benefit is faster processing. The same reasoning applies to the old school text interfaces for insurance agents. They can fly through it and get you a quote very quickly. But, I know that I don't use my time tracker application often enough to allow it to become super cluttered and non-obvious. Same with my bank's website. Different use models require different approaches to usability.

fnid 17y ago

The illusion here is that simple/less complex apps are better. But the reality is that more simple apps with fewer features means the end user needs more apps to manage their business or their lives. Your invoicing app may be simple and let you send an invoice, but does it integrate with your time entry system? Wouldn't a time entry system that does invoicing or an invoicing system that also does time entry be better than two disparate apps that do one or the other? Who wants to waste time entering the same information twice? Making data entry mistakes? Flipping between different apps, usernames, passwords... The problem with the simple is better line of thinking is that it actually complicates the business life. Multiple accounts at multiple sites. Multiple payments to multiple vendors. Different user interfaces to learn at each site. Different ways of doing things. Maybe the enter key over there submits the form, but it goes to another field somewhere else. All these separate systems are really just features of a business management suite and I'd rather keep all my stuff in one place than have 15 accounts at different locations to do one thing. If I can pay $50 a month for a system I can customize to do what all these 15 sites do for $10-99/mo I'd be a much happier customer.