Never Overestimate The Customer

Developers, myself included, have a frequent problem with blaming the customer when we get a bad review or bad feedback about a product.  I don’t mean always, but it’s quite often – the user reports something is wrong, but in reality the user didn’t use the app properly.  Take this gem for instance, which just appeared in the AppStore in reference to Fruit of the Spirit:

I like it it I wouldn’t have bought it but it’s hard to rate each fruit. It doesn’t seem to top out like 1-10 with 10 being a perfect day in kindness or self control etc… and one being a bad day.
It just keeps going.
Do you just assign yourself one point each time you show kindness, etc… That would drag me back to the app many times a day and I’m not apt to do that. I’m more of a “judge your day at the end of the night laying in bed with your iPhone” kinda gal.
And if you play around like I did there’s no way to undo it. I have 24 patience points for yesterday and I wasn’t t that patient. Lol
There are no instructions.
And I didn’t see graphs or charts. I thought it was going to weigh each day against all the days so we can see patterns…..

This person is SO wrong.  ‘There are no instructions’, for instance – that would be under the help button at the bottom of the screen on every page.  ‘I don’t see graphs or charts’ – I wonder what that ‘graphs’ button on the bottom of the screen is?  *SIGH*  (I will, however, give the user two points on this one – I like the idea of using it as a 1-10 scale, and I’m adding that in the next revision.  Plus, sometimes touching a deed seems to be ‘laggy’ – next version improves upon that considerably with a bunch of optimization.)

Another complaint I fielded recently about another app (The Aston West Collection) was the user couldn’t figure out how to read the articles – and finally reported in the feedback that they figured out you had to click the title of the article.  Not very intuitive, they thought.  Except… clicking on the article thumbnail or the title brings up the article.  Heck, clicking anywhere near the article thumbnail brings up the article.  You know… kinda like every RSS feed reader or other article reading app out there.  *SIGH*

And one person couldn’t figure out in The Story of Gamer Zone (even though it’s in the app’s description) that swiping left flipped pages one way, swiping right flipped them back. *SIGH*

Oh, that *SIGH* isn’t because of the customer though.  That *SIGH* is because I didn’t do my job as an app developer.

See, we as developers have gotten pretty lazy about things quite often.  “The user can figure that out without any real directions” or “It’s intuitive enough I don’t need to provide instructions” is a bad way of thinking – WE, as the authors, understand how a system works just fine.  Potential customers may not.

It’s even worse with iPhone / iPad apps – I’m discovering that many folks with iPhones and iPads are really low end computer users (I’ve taught a seminar on iPhone / iPad usage at PixelTime – rather enlightening!).  As in, how to install an application on a Mac – this is pre-Mac App Store – is a daunting, mysterious process.  Even if all you have to do is pop open the .dmg file and drag the icon the the Applications directory.)

Plus, apps are a ‘get in, do something, get out’ sort of process.  Users expect it to ‘just work’, kind of like everything Apple does on their side of things.

Which brings me to the point – never overestimate the customer.  No, I’m not saying they are dumb – in fact, the folks who took the seminars I taught were successful, highly intelligent people… who knew absolutely nothing about their iPhone or iPad.  What might seem common sense to you and I may not to a customer.

For iDeeds I took a slightly different approach – when the app launches for the first time it brings the user to a help screen that they can return to later – and it tells them that in the first paragraph.  I made no assumptions on what the user did or didn’t know.  Buttons are clearly labeled (not that I had a problem with that before), and usage is clearly spelled out.  What does the app do, and what doesn’t the app do is all right there.  By the way, I did that before I had read the negative feedback on Fruit of the Spirit – I had a sudden revelation that people were going to be confused by the fact the app only gives you one deed a day, no matter how many times you launch the app.

The Fruit of the Spirit user mentioned there were no instructions – even though there was a help button.  I can quickly dismiss that person as a moron, right?  Wrong.  The person may not have clearly defined what they felt there were no instructions for.  Was it that there were no instructions  for the app, or was it that the user couldn’t find proper instructions for the usage of a particular feature of the app?  I’m betting on the latter, and for 1.1 I’ll change how I lay out the help (and, even though users are already using it, when they update they’ll end up with the same first time user help screen that someone who just downloaded it will.  Assume nothing.

For Jill Dearman’s Bang The Keys I released the app, and then on a whim, handed it to my girlfriend.  She played with it for a little bit, and pointed out three UI deficiencies she had in under five minutes.  It’s so easy for us developers to assume that people will use our apps the way we programmed them we rarely stop and think outside of our pre-defined usage box we create for ourselves.

Oddly enough, I should already know better.  A lot of my background is in interfaces for Industrial Automation – programmable logic controllers (PLCs) and man-machine interface packages (MMI) that work in conjunction to make things like food production plants run largely automated.  And yes, some of those people actually are morons – just a few, not all.  They are just above minimum wage workers without skills sets necessary to do other, more technical jobs.  So I learned to not assume the user was going to know what I was intending with the interface – I made the interface as downright intuitive as possible, and then spelled it out, and then provided instructions for those who couldn’t get it even when it was spelled out directly on the interface.

Make the same assumptions for iOS apps / Android apps – pretend your customer is a moron.  I don’t mean ‘not technologically literate’ like your grandmother.  I mean, flat out, only got two teeth in their head, already won an honorable mention in the Darwin Awards sort of dumb.  That’s your worst possible customers – now then, try and explain it to your worst possible customer in such a way that A) they understand it, and B) they give you a five star rating.

Users of our products aren’t dumb most of the time.  They are just in a hurry or aren’t particularly savvy with the iDevice in their hands yet.  We want to sell lots of apps – good reviews help us sell apps.  So first time used help screens, walk throughs, and detailed help sections are about to become standard on all of our products.

This should actually be the standard for ALL iOS apps – along with getting negative feedback on my apps, I’ve been surprised how many first time iPad users (who make a lot more money than me because of their smarts) stumble over what I consider to be a easy, intuitive interface.  Those 1 and 2 star ratings use developers get in the App Store and curse about ‘brain dead users’ are our fault, not the users.  It’s our job to tell them everything they need to know to use our wonderful, highly intuitive product. 😉

So how do we implement help without being annoying?  That’s a hard balancing act.  Take Flipboard for instance – it gets the balance just about right.  When you start it, there’s an arrow in the corner that says “< FLIP”.  If the user moves their finger a little bit on the button, the page starts to flip, indicating they’re headed the right direction.  So it starts out great.  However, after that it sort of falls down on the job – you’re presented with a selection of feeds, but with no instructions.  It sort of falls down at that point, unfortunately.  But that first button does set the tone – at that point the user is now trained that any page they see can be flipped the same way, including the main menu.  The rest of it falls to user experimentation at that point (which is not good.)

iDeeds brings up a big block of explanation text.  Even though I wrote it and released it, I can already say it’s the wrong approach, and I released it knowing that.  What it should have been is a short walk through – “When you touch this button, it brings up the deed of the day.  Go ahead, touch it!” would have been a better approach.  Hand holding isn’t wrong – but be sure to offer users a way to opt-out of the hand holding.  Also, first feature use context is great – iDeeds is small, so it doesn’t have much need of it.  But when a user is presented with a new UI concept, or a new feature of the app, start a short walk through for that one feature.  You only have to train them once, really – if they have to use the functionality to proceed to the next part of the app, you’ve trained them. (But, just in case, make sure textual help exists for features too.)  It’s sort of like teaching a child how to blow a bubble – you could write them a diagram, or a long text file on the subject, or you could show them how it works, and help them do it once.  After they’ve done it the first time they’re good to go for life.

And yeah, I know – for large apps, this becomes a pain.  But which would you rather have – good reviews, or bad reviews in the AppStore?  Even if it’s a pain you’ve got to be the one to train your user how to use your app 🙂