The inherent complexity of present-day smartphones risks all kinds of bad outcomes:
- Smartphone device creation projects may become time-consuming and delay-prone, and the smartphones themselves may compromise on quality in order to try to hit a fast-receding market window;
- Smartphone application development may become difficult, as developers need to juggle different programming interfaces and optimisation methods;
- Smartphone users may fail to find the functionality they believe is contained (somewhere!) within their handset, and having found that functionality, they may struggle to learn how to use it.
In short, smartphone system complexity risks impacting manufacturability, developability, and usability. The number one issue for the mobile industry, arguably, is to constantly find better ways to tame this complexity. Hence the title of this post: simplicity, simplicity, simplicity.
But I’m not calling for the rich functionality of modern handsets to be eliminated. Instead, I’m calling for improved packaging and selection of that rich functionality. The concept of “simplicity” itself turns out to be far from simple.
For example, let’s again consider Raku-Raku phones (which I mentioned in my previous post, The Next Big Thing?). These handsets are designed to give users a simple experience when using the handset. But the handsets retain powerful functionality:
- Digital TV reception
- GPS navigation
- the ability to use the camera as a magnifying glass – handy when reading newspapers with small print
- the ability to slow down incoming speech – handy when feeling flustered.
The point isn’t that the handsets become inherently simple, but that they become simple to use. Instead of users feeling overwhelmed by the functionality, they find the functionality to be accessible and straightforward. The user interface avoids bad surprises, puzzling inconsistencies, and oppressive clutter.
After all, just because someone has passed the age of (say) 60, it doesn’t mean they have lost interest in advanced functionality such as viewing mobile pictures and videos (for example, videos of grandchildren), mobile maps, or social networking. However, this market segment has a stronger requirement for the simplicity of use of this advanced functionality.
But, let’s face it, it’s hard to make things easy. As stated in Meyer’s Law,
It’s a simple task to make things complex, but a complex task to make things simple
It’s similar to the comment made by Blaise Pascal: “I have made this letter longer than usual because I lack the time to make it shorter.”
To my mind, there are three basic keys to engineering a great user experience:
- Make sure your team includes people with real passion and skills in user experience – and make sure these people have authority in your team. Note that user experience is a deep discipline in its own right;
- Allow sufficient time, in your project plans, for iteration and experimentation of the user interface elements;
- Ensure that your underlying software supports rapid iteration and experimentation of new user interface ideas.
The third of these keys is something you need to get from the software platform. The software platform needs to make it easy to obtain the effects in graphics, timing, layout, visual feedback, and so on, that the UI designers have in mind. If the UI designers propose changes in how an application works (or how applications fit together), it needs to be a swift task to implement these changes – otherwise the project manager may veto them. The situation to avoid is when UI designers come up with good ideas that, however, the underlying software system cannot implement.
That’s why a sophisticated, flexible software platform – such as the Symbian platform – is a core requisite in enabling the creation and evolution of devices which users will perceive as being “simple to use” (even though these devices pack powerful functionality).
Footnote: any reader of this blog who is interested in attending the conference “Mobile phones for the senior market” (where some of the conversation is likely to build on the points I’ve made above) can get a 10% discount as follows:
- Go to the conference registration page
- Click on “Enter Discount Code” and enter “symbian” (without the quotes).
As I mentioned before, this conference is on the day before SEE09.
I think the design platform needs to support rapid iteration and experimentation of new user interface ideas; it need not be in the development software itself. Sticking with the existing platform in the design phase ensures that your designs are easy to implement but not necessarily as easy to use as necessary.
In other words, throwing out all preconceptions while designing can lead to discontinuous innovation.
Sticking with an existing platform can relegate designers to fixing problems with the platform (if platform/device designers) or focusing solely in their apps little silo (if app designers). The result: I can’t make a phone call on my E71 because some background Java application is asking if I want to access the network – the same network I always say yes for all applications dozens of times a day – and I have to babysit the one rather than do my primary task.
Yes, this is difficult. But the whole system has to be re-thought occasionally: have the requirements outgrown the platform? My prototypical example of this is the late-model Motorola StarTACs which had a browser wedged into the calculator user interface. It was just broken.
Once the new design concept is developed, then the leadership needs to help design, marketing, and engineering work out how to move from where the current platform is to where the new platform is.
One of the basic curx is that we are designing the UI which is not inline with our brains are accustomed to think , why do we have to click icons to do some thing , why doesn’t Ui offer us all information in the real time story board approach?
Nokia used to have a model where the user interface was different for their consumer segments.
Feature creep has led to S40 becoming all things to all men and it is no longer easy to use.
There is plenty of scope for a UI which is consumer segmented. What will surprise people is just how big that segment is.
I do wish Symbain Foundation the best, but the Elephant In The Room here is the iPhone, which already *is* a smartphone that normal people find easy to use (so an endless stream of ‘normal’ users tell me), and which already *does* provide wide functionality to a huge range of customers, ie without needing consumer segmentation.
Apple got there because their process is to let the designers design something good (with lots of user testing) and then have the techies basically report into that. And this process only exists because their CEO is design-savvy and wants this to happen, and all the endless techies and endless suits who jockey for position in every large organisation understand that, in Apple, that’s the bottom line, that’s what success is.
And which key bit of the iPhone UI can you not do in Symbian, Qt etc? It’s really not about how incredibly flexible your platform is, it’s about having huge organisations (and you need to be huge to launch and succeed with a phone) *who are truly design-savvy* (ie “design for normal, non-techie people”) making phone apps/UIs based on that platform. And huge organisations almost never end up that way.
There are various ways I can think of that Symbian Foundation can nudge its licensees into becoming that way. I leave it as an exercise to the reader…
Well you could also write a post for us Nick – please get i touch.
I don’t think there is an elephant in the room. There’s hardly a day goes by when the iPhone isn’t mentioned somewhere – it’s a great design and Jonathan Ives is a brilliant designer.
Haydn,
I guess my comment above will have to be my “post”.
And I’m sure you Symbian folk know Symbian and Nokia and other licensees much better than I do. You can think up ways to make them “driven by user-friendliness from the very top” better than I can.
When I called the iPhone the “Elephant in the Room” I meant “this room”, as it were – David (who I respect enormously) wrote 650 words on taming the complexity of smartphones – and a couple of comments were posted too – and the word “iPhone” didn’t appear.
Well, overwhelmingly ordinary iPhone users will tell you that “smartphone complexity has largely been solved”.
best, Nick
Nick is, of course, right that any full analysis of smartphones and complexity ought to talk about the iPhone. The iPhone has succeeded, for a great many users, in providing an easy interface to lots of complex functionality.
On the other hand, the iPhone is far from being the last word in usability. Even though many people have a great fondness for it, there are others who feel uncomfortable with one or more aspect – eg its physical dimensions, lack of a real keyboard, high cost, etc. And there are people who are initially enthusiastic about the iPhone UI who, over time, find it loses its golden shine.
(I’m half-tempted to call, as a witness, none other than Dan Brown. One of the minor subplots in “The lost symbol” concerns a smart, middle-aged person who nevertheless struggles with the UI of the iPhone. But I accept that much of what Dan Brown writes is fiction…)
I agree that the UI successes of the iPhone arise, in large part, from a company culture at Apple in which user experience is paramount. That’s why I gave the advice,
Apple are an example of a company that vividly follows this advice. They’re not the first such company, and they’re not the last.
The key thing here is “authority”. It’s upsetting to see that virtually all of the positive attributes of the iPhone are little more than the implementation of usability rules that have been known as good practice for a long time.
Holding the whole thing together has to be vision and the will to act. Too often the people who hold the real authority think of each device as being a box filled with features, (usually building on a previous model) rather than a conceptual whole.
The partitioning of a system into discrete applications doesn’t help much either – it blocks the thinking surrounding cross-application use cases.
For example, the other day someone sent me a text with an address written in it. It struck me as absurd that I couldn’t merely tap on it and see it on a map. Instead I had to highlight and cut-and-paste, switching between apps etc. etc. Most people wouldn’t bother and would write it down on paper and retype it in whatever “maps” application they use.
If you’re walking down the street, the lack of consideration for this one, very common use case is infuriating – but there are dozens of other use cases that are overlooked – simply because applications don’t care about what lies beyond their boundaries.
Maybe there should be a Wiki somewhere of cross-application use cases that people could add to. I think both me and NickH (& BillB) have written many conceptual documents and Lotus Notes postings about this over the years.
Another option is to post ideas like this on ideas.symbian.org, where they can benefit from community discussion and improvement