Why aren’t Apple’s error messages written by marketers?
This morning as I was updating my iPhone, I received the following error message in iTunes:
User Interface design, like website optimization, is all about removing friction for your end users, and I was offended by a number of Apple’s choices on this screen:
- An “unknown error”? That’s like a doctor telling you that you’re the FIRST person they’ve ever seen with a certain symptom.
- I was trying to upgrade, not “restore” my iPhone. I realize this is part of the process but this is confusing to end users.
- The error box offers no resolution path. This is a lost opportunity, with no guidance despite “Unknown Error 1604” being a well known, resolvable issue.
From a user-interface perspective, this process could be greatly improved with something like the following:
With this new, friendly error box we’ve:
- Calmly announced that a small issue, with a known resolution occurred.
- Eliminated specific error language that may confuse users.
- Created direct, next-step actions for users to resolve their problem.
These simple changes provide users with positive reinforcement, clarity, and a call to action that’s sure to lead to a higher resolution rate.
Why aren’t software error messages written from a user-interface perspective?
What am I missing?
PS – If you too have had trouble with Error 1604 you can find the link to the fix on this page http://support.apple.com/kb/ts1275
12 Responses to Why aren’t Apple’s error messages written by marketers?
Leave a Reply
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
Hadn’t seen that before, good one.
because writing good error text for possibly multiple localizations costs money?
The answer is pretty obvious, if you think about it. It takes one line of code to implement the dialog box you saw (if result != success errormsg “The iphone $name could not be restored. $errorstring ($errno)”). This isn’t the case of just taking some lines of text and giving them to some marketing dude. The developer has to think about each possible error which might be returned, figure out why this error might be returned, find a link to a page on how to deal with the error (which probably involves *creating* such a page), and then have a massive function to determine which of these hand-crafted error messages to return. Heaven help you if the same error code could be caused by more than one root problem.
Software development takes a lot of time, and optimizing for the error case isn’t always the best way to spend this time. Maybe the developer who would have written the function to display the box you wanted is instead working on a fix so that in the next version you don’t encounter this error at all.
No, the error dialog should show the root cause of the error and how to resolve it, not a link to a website and an “OK” button.
To a user with no interest in spending time poking around a website to resolve his or her issue, both of these dialogs are equally terrible.
Error: AppHole doesn’t care about your problems!
Haha, good one!
Whoops! I’m a patronizing dialog box! You may remember me as clippy from Word 97! Let’s all sing kum-bay-yah while all your data gets deleted!
I agree that the “unknown error 1604″ is too hostile, but there’s no need to assume your users are 7 years old.
Furthermore, the replacement is arguably worse because you’re throwing away potentially useful information. At least the original dialog told you that it was doing something with your iphone. The proposed replacement references some mysterious “update”. What update?
How about this:
A problem occurred applying the update for “iPhone”. [Help is available here](link to help), or you can [contact technical support](link to contact page) – please provide the error code “1604″ to our technical support staff.
I like your suggestion! But I’d caution you that most users, in fact, are WORSE off than your typical 7 year old growing up in the digital age
.
What you’re missing is that when that error message was written, there *was* no known solution, because it wasn’t a known problem yet. If the person who’d been writing that error-handling path had known about the solution, they almost certainly would have been able to avoid the error entirely.
Of course, in this always-online world, there’s no reason why the software couldn’t be written to submit the error information to the Apple servers and relay back any helpful response to the user. Unless the error has something to do with the network connection itself, natch.
@caf:
Considering that the error has an actual number assigned and a definite solution, then it was a known possible issue ahead of time.
@zack: Instead of a link to a website, the error box should go ahead and download the relevant information from the site to show. In this case, the box should go to apple servers, look up error 1604, and display that text to you. If the error is unknown, then they can say “contact support, we haven’t seen this one before!”
In the event the error is with network connectivity, well, it should be obvious what to tell the user.
Agree that the original isn’t helpful.
But making me read more isn’t the answer, either.