UI = The Killer Feature

on Dec 4, 2007

iPhone UI

Many new electronics products and software have a bucket-load of new features. They try to incite you to make the purchase by flooding you with their extensive functionality and a million of things they can do. In the end however, the list of the functions would be capped, in some cases cut at a surprisingly low number — for example, if a product has 100 fancy features, they may actually be capped at 30. “Capped?!” you ask? If a product has 100 features, how can you possibly cap them? Let me tell you how…

This capping is done by the user interface (UI). The UI is the bridge between the heart and soul of the device and the user — if the bridge is not well made, you may not ever reach your destination. If a product has 100 features, but the user can only figure out how to use 30 of them, then they will only use 30 of them. There is no way that person can use the other 70 because they simply don’t know how to use them! A long list of bullet points on the product package does not actually mean that this product will give you access to these features — terrible UI design and thick manuals will mean that many people will never see half of those things.

The wrong way to design products is to first discover a new technology, then to slap a UI on top of that which makes use of this new technology and finally sell the idea to the market.

The right way to design a product is to identify users’ needs irrespective of technology and UI. What do people really want to do? Do they just want to share photos? Do they just want to buy and listen to music? What are the main few things people want to do? Don’t bring in technology or UI at this stage, because those things are irrelevant to what a person wants to do.

The second thing to do is to identify which technology can do the things that people want to do. Here you can revise your application “features”, though the list of features should never be extensive — you’re not trying to make a Swiss army knife here, you’re making an elegant solution to a problem. Once the technology is identified, don’t proceed to code anything, but start working on the UI.

Start with the UI — the layout of buttons, the typography of the text, the actual messages and labels that appear on the buttons and controls — what is the program or device going to look like? At this point, you must be able to solve the users’ problem in the easiest way possible. If someone picks up the device, they should be able to just use it straight away. The less thinking the better.

Once the core UI is in place, start producing the back-end. This way you are providing a solution to a problem, you’re not providing access to a technology through a clunky UI. One product that illustrates this beautifully is the iPhone from Apple. Many people point out the the iPhone is inferior to many other offerings from Apple’s competition. It doesn’t have this or that feature, it has less of this and that. Sure… you are absolutely right! The iPhone has less features! But look, I can actually USE all of them. Indeed, I don’t even care what the features are — the devices solves three problems for me: phone, mobile music and mobile internet access. The UI is so fluid, I can do everything I need quickly without messing about with clunky and complicated controls.

If you want the Swiss army knife, fine… that’s up to you, but some people just want a simple device that they can actually use. The UI in that case is the main feature, much more important than anything else on that bullet point list of things it can do. Not many companies have grasped onto this concept yet, which is a real shame. Companies like Apple understand this — they understand that the key to making a good product is by improving the bridge between the user and the device — that bridge is the UI. Use good UI to your advantage, and please, don’t ignore it.


  1. Comment by Alexis — Dec 4, 2007 @ 7:39 pm

    Hell yea! I’ll take UI over feature list any day. That is, providing it does what I want it to do :)

  2. Comment by Dmitry Fadeev — Dec 5, 2007 @ 11:45 am

    Thanks Alexis. This is true — you must also be careful not to go to the other side of the fence, creating beautiful applications with fluid, simple and pleasant user interface that just don’t do very much at all. The “delicious” generation of applications for the Mac have been under attack from this argument — applications like “Disco” look great and are easy to use — they just don’t do very much :)

    This is why I mentioned above that you should think about people’s needs irrespective of technology and the UI. These things come into play later. You’re ultimately trying to solve a problem, not to create something beautiful that’s of no use. But at the same time, be careful not to create something really useful that nobody can actually use!

  3. Comment by ee — Feb 28, 2008 @ 12:22 am


  4. Comment by spimb — Mar 19, 2012 @ 4:54 am


RSS feed for comments on this post. TrackBack URL

Leave a comment

Contact Information

If you would like a quote or a project proposal, just click here to fill in our short client web form and we'll get right back to you.

Direct Contact Details

Email Email: info@pixelshell.com Skype Tel: +44 (0)20 8816 8876