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.