03 August 2010 by Steven Hoober
All mobile phones are still too engineered. By which I mean, they are too engineering-focused. Engineering is a good thing to most tech companies, because they are founded by hardware or software engineers, who like making products for themselves and their friends.
When there’s a failure (say, the antenna on a popular phone doesn’t work) more often than not it can be ascribed to a technical failure, and just gives ammunition for the technical and implementation teams to get even more power over the process.
But in a world where technical products are so pervasive that a billion people have mobiles who have never seen terrestrial TV and have no power to their house, I have to believe that engineering-driven product development design processes cannot last forever; the world will demand products designed for farmers and housewives and truck drivers as well.
We’ve all used devices which were filled with all the features and technical specifications we wanted, and yet were unusable. Annoying, difficult, buggy. Each of these are problems that usability, user experience and interaction designers can help solve.
But instead of rambling on generally, let’s take one specific item on all our portable devices and look at how that fails us: the battery indicator. It is almost always complex and difficult to decipher, and can even be downright misleading.
Now, there are scads of battery indicators, and for every method of implementing one, there are a dozen ways to make it annoying. So instead of picking on one device, or even a set of them, I’ve categorized them a little bit into the most common cases.
The indecipherable indicator
This is the “PC Load Letter? What the !@#$ does that mean?” of the mobile world (link NSWF, language). If your battery indicator is primarily or only lights, color changes of on-screen icons, cryptic descriptions or symbols with no clear meaning, you are falling into this trap.
Solving this:
Use clear signalling. If you need color, or only have an LED, use simple changes that are already well-understood, like red = bad. Make sure display elements tell you what any blinking lights mean. If you can control hardware, sometimes you can do neater things; I have seen printers that had a red light for errors. But instead of a simple square LED lens, it shines through to an exclamation in a triangle. Without a legend, everyone knows what that means.
Be sure any descriptions or labels – whether on screen, printed on the device or in the manual – are as clear as they can be. This is the second line of information, and it’ll be the rare user (with some cultural variance) who will need to keep seeking answers.
What is it doing?
More and more – due especially to the use of USB from computers – it is not entirely clear if you are charging or not. The indicator might do something like change colors from green to blue, but no one notices the original color so the difference isn’t seen either.
Solving this:
Remember how mobile works; it’s only got the user’s attention for a few moments, so they will not notice changes. Animated “filling the battery” displays will mislead users into thinking it’s whatever level it’s at the moment they look at it. Clear symbols solve this easily. Lightning bolts aren’t bad, power plugs are better, but any almost icon indicating a clear state change is better than something not-very-important like blank battery.
Ideally, monitor the power level during the charge cycle and display this as well, so users don’t wonder how much more till it’s done. If possible, tell them how much time is left to full charge, though I have only seen this in computers so far.
Is that a lot?
A lot of the information I am given on battery meters is functionally useless to me. Like “10% battery remaining” which leads me to ask “is that a lot?” Also, how important is it really? I have a phone that gives me a large modal warning when it’s an hour from shutting down, which means I ignore it, often for so long that it just dies on me and I end up with a dead phone anyway. And think about context: it hardly ever feels helpful for a modal box to pop up and tell me about battery level when I am typing or talking.
Solving this:
People don’t work in percentages, and especially not percentages of something they can’t see or feel. They do care about tasks and time, so communicate with that instead. How much more helpful is “your phone has about 20 minutes of battery remaining”? And don’t annoy the user more than is needed. Sure, make the phone blink to get their attention, make the battery meter bright red, but getting in the way of their work is always bad. I’d also love to see user-set battery-remaining warning times, like the screen backlight timers.
Even better, work the way mobile does and let the user tell the handset what they want to do with the time. What if you cannot get to a charger, like when I was recently driving for hours and hours using navigation services, and the phone doesn’t have enough battery? Powering off is not that helpful as it takes so long to start a smartphone. What if at lower power levels the phone offered to sleep itself to preserve battery. Or, only use some features, so it could work longer. Let them be task-based, so if you only need to talk via SMS, pick that from a menu and the handset turns off all but the SMS app, and switches on the radio only to send, and only every few minutes to receive.
Fear, Uncertainty and Doubt:
Alison is on her second Casio GzOne ruggedized phone, and they still come with special warnings not to over charge them. In the manual, and when introduced to the phone in the store, you have to listen for the distinctive beep when it’s done charging and take it off as soon as it makes the beep. Or… something. It’ll blow up, or damage the battery or something.
Solving this:
This is just dumb. As far as I can tell, the Casio and their batteries are no worse than any other phone, and these guys have just gotten an extra bit of battery FUD into the documentation. But let’s say it’s true. Then, my answer is: stop doing that. If the phone can beep, it should be not a lot harder to have it stop charging. Or, use a battery that doesn’t have this issue.
This one reminds me of the vampire draw green fears. Sure, power adapters (for example) draw power when off, but I am not sure why. Even talked to a few EEs and a robotics programmer friend who works in a factory, and it should be trivial to simply put sensors that cut off the power entirely.
I have at least one AA battery charger where inserting batteries pushes a switch and turns on the charger. Pull them out, and a hard switch cuts it off from the supply, entirely.
While I’ve used a somewhat detailed design examimation of battery meters, this is just an example. Almost anything can suffer the same poor experience from too much engineering, and not enough human-centered design.
I am sure there are other aspects of business and politics that result in an excess focus on engineering, but a key one I get still – even when hired to improve a product – is the worry that UI design will add a step to the process, and add layers of complexity.
And looking at some of my solutions above, you’d think so. I want, for example, to add software that calculates time remaining. That’s indeed extra work. But I’m also going to eliminate pretty much every error pop up. I might get rid of several display states, significantly reducing the complexity of some lookup tables or other calculations. Personally, I probably would remove animations, keeping the system as a whole running faster.
Any interaction or interface designer that knows the difference between the two knows technology (and, like I know mobile, knows the specific technology they were hired on) in the same way they know their users. In each case, enough to make the best experience all around, for the business, the best use of technology, solving user needs.
C. Enrique Ortiz on 09 August 2010 – 8:43a.m.
Hey Steven… Good writeup. A couple of comments…
The difficulty with “20 minutes of battery remaining” is that it is hard to predict. I can calculate “20 mins left”, but then if the user makes the screen brighter and starts the facebook app, then the 20 mins doesn’t mean anything and trying to predict how the app or future apps uses the resources is very hard and will be inaccurate. (don’t you hate it when downloading and the system says “3 minutes left to go” except it really takes 10 to download?) The next best thing is to show how much power is left in the battery (% or simple image or simple green/yellow/red, again based on capacity vs. used/remaining).
On tech vs. design and using the Antennagate issue as as example, I read rumors that technical issues were found and raised early on. If those rumors are correct, it would be an example of (industrial) design taking priority over tech/engineering, and failing.
ceo
Steven Hoober on 09 August 2010 – 9:05a.m.
Time remaining works pretty well when I see it (albeit on computers mostly). Especially if constantly calculating (and it varies periodically), it’s probably more useful than suddenly warning that you have 10 minutes left… oh, sorry, now three!
I just raised the issue and brought up the simplest solutions for each facet. Really, this is a design issue that needs to be addressed as a whole. Mode shifting, or even asking the user what mode they want, seems a good way around it also, to make it clear how much time is (probably) left for a particular set of behaviors. Make it more difficult to change screen brightness, for example, in those last few minutes of battery life.
On to — as all blogs must — Apple. Presuming some things (as you said, rumor) I am not at all sure the antenna issue had to come up as a result of engineering vs. pretty-design. Instead, it seems to me it’s very much the point of my post, and they need to work together more. I’ve had engineers come back to me plenty of times saying something can’t be done, and instead of just saying “do it anyway” (even if I have that power) I try to find out /why/ they can’t do it. Often, it’s just a mismatch in communications. Very, very often, the end solution is better than either of us came up with on our own.
Communicating better between design and engineering always works best.
C. Enrique Ortiz on 11 August 2010 – 7:26p.m.
Agreed!