Minimizing Complexity In User Interfaces
smashingmagazine.com
smashingmagazine.com
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.
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
Sure, but to do that the feature must exist in the first place. The author of the original article makes a distinction between eliminating a feature and hiding it. What you suggest is a clever way of hiding a feature.
I'm ambivalent about the idea of hiding a feature based on usage. Microsoft had that idea of hiding menu items that were not frequently used. I don't know anyone who liked that. I always disabled it because I didn't like my UI to change all the time. If I use a feature rarely, I still want it to be where it was last time, not move around until it's seven nested dialog boxes away.
Programs exist to solve user's problems, UI exists to make it easy for the user to discover how to use a program to solve their problem. So UI is supposed to serve the functionality not the other way around. Which is why I think making a program less capable of solving the user's problem based on UI consideration is backwards.
As far as the hiding, I'll agree the "menu hide" trick in office sucked but that's sort of my point. Microsoft did it badly so there's this assumption it can't be done. But figuring out how to do it is what UI design is all about. At least, that's my opinion.
Not necessarily. Some are needs, some just wants. Software should offer solution to user's problem, not features. Often features are wanted just because user has a particular vision of solving his problem which requires these features, but that does not mean that there is not more elegant way to solve the problem with less features.
> 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.
I am afraid many who paid for MS Office won't know themselves. And I bet many of those still use spaces instead of tabs in Word :(
They focus so hard on elimination, that they don't add back things that the other apps do not have.
AND they think that they will still have universal appeal. They don't consciously say "OK, we are going to remove these features, because we don't want to serve this type of customer... which will make us more appealing to another type of customer."
They just think that less === more, and that's it.
Just like any dogma, people cargo-cult it. They use it as a mantra without understanding why.
FWIW, my app was one of the ones featured -- Freckle Time Tracking (http://letsfreckle.com/). They wrote:
"Freckle just makes you want to keep track of your time. The conveniently condensed interface shines with energetic color, turning a routine task into something fun."
And that, in a nutshell, is much of what we tried to achieve with Freckle. Our key feature? Take away the pain. Take away the guilt. Make it effortless, and dare I say it, fun.
We don't have everything, by choice.
Do we have fewer features than Harvest? Damn straight.
We don't do time sheet approval. We don't do pre-approved tasks. We don't do any kind of extreme permissions control.. anyone in the account can create new projects, for example.
Our software is built for small teams with a flatish hierarchy, not for traditional iron-fist-control businesses.
That is LESS with a purpose.
For our customers, that's not a "lack of features" -- it's a downright BONUS. Because they have a small team, or are by themselves, and so having to set up tasks in advance (like in other software) actually reduces their ability to work effectively.
On top of all those removals, we've added back things that nobody else does. Time entry on every page. The Pulse, which helps you identify your work patterns. Saveable reports.
Even most of the people who cancel their accounts write us that they love the app and they're sorry they have to cancel.
So I certainly feel we're doing something right. We don't want to be Microsoft Word. Our goal isn't just to make gobs of money, or even dominate the niche. We want to build software that fits our philosophy and makes people happy.
We have a smaller audience, yes, but it's an audience who agrees with our principles.
But do you really think that the only way to make one group of users happy is to simply exclude functionality that would make another group of users happy? Is this an unsolvable problem in your opinion?
I tend to agree with TomOfTTB that it is a UI challenge that can be met.
I didn't take a mental image of a time tracking app and then remove stuff. I started from scratch.
Different groups of people have different use cases, and different needs. It's a fallacy to think you can design one thing for all people. It compromises your vision.
Make sense?
And yes, by the way, there are lots of things we are able to do with Freckle because we have decided paths that we do not want to tread. For example, project creation is always on-the-fly. It's so elegant I could cry.
But if we added permission restrictions, based on who could create projects, that would take away the elegance, and add confusion.
In the end, our approach -- which is awesome for our desired audience -- would be totally compromised by the additional error-checking and rigamarole if we were to add this as a feature.
Thus, we won't do it. There are plenty of people who don't need or want that, who are our potential audience. And people who do need it, won't like the other assumptions our app makes. They will be better served by more traditional products.
To my mind, this is win/win/win.
To me this discussion sounds like an argument for user controlled scripting languages in web applications.
This is needed since web applications which use lots of Javascript can't be automated by normal web scraping libraries with no Javascript/DOM emulators (they support cookies, etc so they can do sessions etc).
Something like the classic Applescript, for user control. (Or maybe the latest web frameworks already have that?)
Edit: Reformulated sentence for clarity.
Edit 2: I think the plugins for Firefox etc are too hard to write? Maybe you could add scripting languages to them?
1. No one will do it.
2. Even people who do know how to program have a special aversion to JavaScript, especially.
3. Almost no one is equipped (or willing to invest the time/effort) to analyze their work and come up with a process that is best for them.
A typical person is about as self-aware as a box of rocks. Even particularly smart, savvy, successful people. It takes a lot of work to get real insight out of them in terms of work processes. And impossible to get them to generate novel ideas for solving those problems.
More importantly, to design great software you have to understand not just business processes, but software itself, and the human animal (psychology, sociology).
That is an extraordinary amount of extra crap to expect somebody to do, when they just want to get their work done.
This is born out wherever you see "lay people" creating their own solutions. Ever worked in an organization that powers itself on Excel? It's not only not pretty in a technical sense, but they never, ever, ever do a good job, even within the constraints of what is possible with Excel. And they also never think to question if there could be a better way.
So, that's what people like me are FOR.
All this crap happens to be my passion.
Consider that the scripts would run on the web server. That means they would be published and used by other users... (After a bit of analysis, so they don't do anything destructive.)
And charge money from users that really want their scripts to be private.
Just make certain that there is a script language defined for the web app framework -- and an extensible object model for the local web site's data. (Again, Applescript. But not that syntax!)
Why?
This would be a way to add functionality (and possibly to integrate with other services, so you e.g. could do "legal" XSS.)
I think ahoyhere has alluded to the reason why the pile of features tends to win, and that is because it is better at leveraging the economies of scale in the shrinkwrap software business. It is so cheap to distribute software that you are much better off building for the mass audience. Now the hot thing is webapps which do not scale nearly as well (but avoid most of the junk that comes with shrinkwrap scaling, like having to deal with a strange machine and a crappy OS that deluges the end user in spyware, or pushing updates to users you don't know much about), so there is more incentive to meet the needs of a niche audience. And Apple is having some success sort of splitting the difference (vertical integration from the hardware up, and attempting to exert more discipline on developers to increase quality, all at the expense of distributing software to mass audiences). Microsoft, of course, is still in a pretty dominant position from exploiting this scaling to the max when IBM so graciously made the hardware into a commodity mass market item.
So far, the most successful web app (Google) is the one which has made web app discovery scale like nothing else (every page with useful content on it is a web app - code, data, it's all the same). The brilliance of Google is that it captured a mass end user market with a minimal user interface. They did it with math (maximal leverage of plain text queries plus the structure of the web, and similarly with ads which have simple interfaces at both ends and are backed with sophisticated algorithms), and scaling by imposing unusual amounts of internal discipline on the best developers they can get (and they can get pretty good ones). All this just to get to a position where they might be able to compete with Microsoft as a platform, and unseat the power of shrinkwrap scaling. I think the only way they can do it is by attracting a lot more developers than Microsoft, and the only way they can do that is by taking a lot of Microsoft's developers away. They might be able to do it, but there are all sorts of challenges. My guess is that what will happen is that they will draw a lot of developers away from Microsoft, and in the process they will lose a lot of their external cultural influence as far as being able to promote clean interfaces. Web apps will be even more dominated by the everything in one place aggregators (exemplified by Amazon and eBay) than they are now.
The problem with nice UIs is that there just aren't enough good developers to make it scale.
Don't worry, we're working on our invoicing attack plan. And marking reports as invoiced is step #1.
Our #1 feature request has been a timer, and we built one. (Have you tried it yet?)
#2 is invoicing. We're building that next :)
It's just a little bit slow because A) I am a perfectionist when it comes to defining the initial approach (and it serves me well), and B) we're doing the part-time 37signals thing.
But we will get there... soon, hopefully!
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 :-)
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"
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.
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 ?
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.
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.
Having said that. I really wish more people would ignore them, for my own competitive benefit.
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.
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.
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_revol...
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.
The problem is that it's not the same 20%.