
Minimizing Complexity In User Interfaces - nreece
http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in-user-interfaces/
======
fauigerzigerk
_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.

~~~
ahoyhere
The thing that people get wrong about the idea of "less is more" is that they
choose the wrong features to eliminate. They don't have a strategy, except
that they will do and be less. (And it's often the HARD things to design and
build that they leave out.)

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.

~~~
fauigerzigerk
I'm sure you're doing something right. If you have users you're definately
doing something right.

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.

~~~
ahoyhere
It's not about excluding features to make people happy, it's about designing
something right from the ground up.

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.

~~~
berntb
Let me limit this to web applications.

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?

~~~
ahoyhere
There are a few problems with this.

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.

~~~
berntb
You and 'toadpipe' are probably correct. I'll argue the point anyway, to see
if it could be made to work:

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!)

~~~
ahoyhere
Then the question should be:

Why?

~~~
berntb
I thought that was obvious from the starting point. Lacking features is a
problem for large subsets of users.

This would be a way to add functionality (and possibly to integrate with other
services, so you e.g. could do "legal" XSS.)

------
chrischen
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.

------
10ren
_80% of users use only 20% of software features_ \- but they don't all use the
_same_ 20% (according to Linus, anyway).

~~~
snprbob86
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
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"_

------
mrshoe
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
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
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.

------
imajes
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>

------
fnid
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.

------
mmphosis
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
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/>

Having said that. I really wish more people would ignore them, for my own
competitive benefit.

------
rooshdi
“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.

------
alabut
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>

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.

------
thunk
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_revol...](http://www.theonion.com/content/video/apple_introduces_revolutionary)

~~~
cschneid
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.

------
grinich
The lack of a button is a feature.

------
RyanMcGreal
> Studies have found that 80% of users use only 20% of software features.

The problem is that it's not the same 20%.

