It’s a User Interface, not a Feature Interface

Posted in Front-End, Thoughts

Designed by engineers.

It invokes visions of legacy Windows programs, burdened by buttons and menus and dropdowns consisting of all its features and devoid of aesthetic pretense. It is undeniably and unabashedly functional, yet is barely understandable and nigh unusable save for a handful of memorized workflows. I think most software engineers can relate[1].

In 2012, the community is blessed with better design resources and more examples to study from; from iOS core animations to Twitter bootstrap, designers have provided a nice set of building blocks to get apps off the ground. These tools allow engineers who care more about the backend to focus on coding features instead of wrangling with the UI.

Then again, there is no cure for people who think they can write a better interface, try, and horribly fail.

But now that we have a reasonable baseline for software aesthetics, the underlying issue is laid bare: a lot of the software written today is driven by features, and subsequently wrapped in feature interfaces. Somewhere along the way, we left the user behind and let the almighty feature drive the experience.

Take Facebook. Over the years, it has become the landing spot for features spread across disparate products, so the interface has been overloaded to allow for everything a Facebook user may want to do, plus all the things that Facebook wants to promote:

  • The logo, friend requests, messages, and notifications;
  • Search;
  • Profile, friend finder, account settings;
  • Events, apps, groups, pages;
  • Facebook chat;
  • Status update, photo/video post, Facebook questions;
  • The news feed (embedded with comments, likes, photo albums, apps, videos);
  • Real-time ticker;
  • App requests;
  • Facebook ads;
  • Footer with privacy policies, TOS, developers, help.

And this is just on the main page of Facebook, recorded at a glance, without going into the inner workings of each feature. With a few clicks, many of these features open up to reveal more widgets and controls and dialogs, with mysterious options and if we’re lucky, blocks of explanatory text. Instead of what users want to do, Facebook’s UI is a culmination of what users can do; their task is to figure out when and where to click and type.

Contrast that with the redesigned Twitter interface. There was plenty of hate for the new Twitter at launch, but it took a giant step forward by redefining itself into three categories: Home, Connect, Discover. Each section is near-identical – with tweets on one side and follower suggestions and trends on the other. The most complex interface is the embedded actions within each tweet box.

Of course, there is a cost to reconfiguring an interface for the user. Twitter chose to align its interface with its new and casual user base, and in doing so gave up a number of power user features (which originated much of that hate). It illustrates one of the difficulties with simplicity: to remove features is to make tough decisions, and to get stripped-down controls to behave as the user expects requires much more thought[2]. While most of us adhere to the KISS principle for coding, we don’t quite do the same for the interface.

All this is just a roundabout way of saying that everything begins with thinking about how the user would solve the problem with the product. Everything built is to support the user in their quest to find this solution.

In fact, to plagarize from myself:

Let the backend inform, as opposed to dictate, the design.

Footnotes    (↑ returns to text)

  1. That above screenshot is of Chronos, an app I wrote in Delphi to rename files sequentially. It was my first side project from my first job out of school.
  2. And realistically, a boatload of engineering work.