Redux: Rules From a User to Software Developers

More than a year ago I posted a list of 13 rules that software developers should follow — all from my perspective as a user.

Since it’s been more than a year I thought it would be worth a look back to see where we are today — have things gotten better. So excuse me for gratuitously quoting myself.

Blue makes for a great icon color and everyone else uses it — be the exception, not the rule.

Since I wrote the original post I have noticed a sharp decline in blue app icons (Apple is the exception). I still don’t like it when there’s a new app with a blue icon, but even more annoying is the new trend of low-contrast silver/gray looking icons. Writer, Instapaper, Drafts, Launch Center Pro, Notesy, all these apps (if put next to each other) present the same problems as too many blue apps presented.

My best suggestion to an app developer: look at what people are putting on their home screen and determine how your app icon can complement “normal” home screen app icons. (Hint: that doesn’t mean making your icon red, so think more like the original Gowalla icon.)

Make the name of your app/service something that a normal person can pronounce, on first try, without help.


Spell the name like a normal person. Twitter works because it makes logical sense, spelled as it sounds. Tumblr is hard to explain to a non-tech user — tell your Mom to go to and see what she types in. I don’t want to remember which consonant you doubled or which vowel you dropped. Things like Digg work because you can tell people: “it has a double g” — stray from the basics too far and your service/app will confuse people.

This too seems to be getting better. So I would then amend this to ask that we stop with the insta-xxx names. It worked for Instagram and Instapaper — let’s let that be it. I would also amend this to say that we need to stop with the annoying, confusing, and generally bullshit names that append lite and pro to them. The truly good apps don’t have lite or pro versions — they just have one app, one name. (e.g. Agenda, Dark Sky, Instapaper [there used to be a free version], OmniFocus.)

Ditto for your URL. 37signals couldn’t get, so they chose — I can remember that and so can most people, more importantly I can say that: basecamp “H-Q” dot com. Don’t make it hard on the user.

Funny enough, they now have that URL. I still stand by what I say here, but let’s append some additional rules to this. Mainly: make your app URL easy to remember/find. Most users don’t need this, but as a writer it is a pain in the ass to find most app websites to link to.

If you are going to change a standard UI behavior, you better have good reason for it — looking cool doesn’t count.

Re-read that.

People look for save buttons, if you don’t need your users to worry about saving — tell them that.

I think I was misleading by saying “tell them that” — what I really meant was: make it obvious to the user that they need not worry about hitting a save button. Lion does too subtle a job with this in my opinion.

In fact if you change anything that a user would normally press button to do, best to tell the users that you don’t have the button and why.

Again, “tell” was a poor word choice. I also don’t think you need an explanation if the change was done well and logically. I would revise this statement to say: If you deviate from the norm in any way (on that specific platform) then you need to have hints for the user. I can’t tell you how many apps I have tried and stopped using because I thought the app couldn’t do something I wanted it to do — only to find out you can via a hidden gesture.

If I am putting data into your app/service I damned well better be able to get it back out with a click — in some sort of useable format.

Yes, a thousand times yes.

If you can’t come up with an innovative user interface — stick with generally accepted standards. ‘Unique’ is never a good word when a person is referring to your UI.

An innovative user interface is Clear, and ‘Unique’ user interface is Apple’s Podcast app.

Beta testing is free, users understand this — but please charge for your product once you launch, that is, unless you have another reliable income stream setup already (e.g. a trust fund).

I am happy to say that more and more apps are charging now — so let me append this to say: charge for updates (find a way) and charge more. The last thing anyone (but cheap asses) want is a race to the bottom which leads to crappy me-too apps.

No one has a perfect version 1.0 product, just make it stable.

There’s always going to be a million things you want to add to your 1.0 app, but I will tell you right now that I won’t bother using your app if it is not stable. I will wait for features, I will not wait for a stable app.

Look at what other apps do wrong, more than you look at what they do right — fill the voids, don’t clutter the market.

I think everyone glossed over this one, because the clutter is worse than ever before.

If you are replicating a stand alone product (e.g. Calculators) try to think about how it is best implemented on the particular interface you are building for — don’t focus on directly copying the device. (e.g. Soulver’s reinvention of the calculator UI)

I have been seeing more and more really neat apps come out, but nothing that I would say is redefining a category of apps. This bums me out.

Overall I have seen progress over the last year. Progress towards a better crop of apps.

For my 2012 list let me add two things:

  1. If your app has a nag dialog for ratings, remove it and apologize to the users of your app. Not only is it whiny, but it actually gets in the way of using your app — thus detracting from the functionality of your app.
  2. New rule: You are only allowed to have ads in your app if it needs a million plus users in order to be useful to one individual user.

Become a Member

This site is 100% member supported and free of advertising. Members receive access to exclusive weekly content: iPad Productivity Report, videos, and the best products listing.

Join Now

Already a member? Please sign in.

Article Details

6 minutes to read.


More than a year ago I posted a list of 13 rules that software developers should follow — all from my perspective as a user. Since it’s been more than a year I thought it would be worth a look back to see where we are today — have things gotten better. So excuse me […]