11 Rules of Awesome Software

Fashion Failure

Fashion Disaster

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupery
French writer (1900 – 1944)

In honor of 11/11/11, I’ve put together my 11 Rules for Awesome Software.  I’ve been using software my entire life, and I’ve been building software for most of it.  When I think about what makes the difference between software I love and software I hate, there are some common themes that come out. 
I’ve tried to give specific examples where possible, but many times I’m drawing on intenrally built line-of-business applications you’ve never heard of.  
Much like a “fashion disaster,” software that is cumbersome, painful, crashes frequently, or looks ugly should not be let out of your shop.  You wouldn’t be seen dead in it.

I would love to hear your thoughts!  What software do you love to use?  What makes the difference?  What rules or heuristics do you use to evaluate software?

1. Do as Little as Possible

Great software doesn’t need lots of bells and whistles tacked on to try to impress people.   Of course, you need to provide a certain level of value and actually solve a problem, but the trick is to really understand where that point is and stop there.

2. Users are Imperfect

Don’t expect your users to know what you were thinking when you built the software, or to behave the way you expect.  They might make a mistake or try to do something you didn’t anticipate.  Software that guides new users to do the right thing but allows more control to power users creates a sense of mastery and adaptation.  It makes the software way more fulfilling to use.

3. Keep it Accurate & Honest

Name things correctly, give people consistent cues & metaphors, and don’t forget to word your error messages for humans.  Stop your users from starting tasks they won’t be able to complete.  And please, if you have a freemium offering make sure the paid vs. free features are clearly marked.

4. Always Allow Recovery

Design your software for failure cases, and assume that your software or some other dependency will fail at just the wrong time.  Think about how you can optimize around what the user would expect and want.   “You forgot to hit save” is not a useful excuse, software is here to remind people to do things they forget and let them focus on creativity, critical thinking, and community with others.  Don’t leave a user hanging where they can’t stop and come back to it later.  

5. Familiar Is Good

Fancy new user experiences can be exciting and bring a “wow” factor, but if not done correctly can get in the way.  Striving for a modern user experience that is slightly pushing the boundaries of the current design conventions is a good place to be, but easier said than done.  Put things where people will expect them.  Use simple names for concepts and user interface elements.

6. Collaboration is Key

People usually need to do things with other people.  It’s part of how we have lived and worked for thousands of years.  If you haven’t thought of how people can use your software to collaborate, you haven’t thought hard enough.  I’m not saying everything needs crowd-sourcing or instant messaging or a Like button.   But consider enabling features to review, share, approve, delegate, oversee, upload, etc.  Let people work together.

7. Perception of Performance

It doesn’t matter how fast your algorithms are if your software feels slow. Slowness comes from a variety of problem areas – too many clicks to complete a task or action, not enough priority to user interface layer, bad user metaphors for showing progress, long timeouts for tasks involving an external system, and synchronous calls to name but a few. It’s very important to optimize and tune the internals of your system, but make sure you present an experience that feels fast.

8. Match the Mental Map

People learn things in different ways, and they construct a “mental map” in their heads for how they imagine your software works.  They may have a series of pictures or abstract concepts depending on how they imagine things.

The best software has a clear model for how it works and how its concepts link together and presents that to the user in a way that feels “intuitive.”  I believe that software feels more intuitive is related to how easy it is to build & maintain a map of that software in your head over time.

The Like button on Facebook is an interesting example of mental map weirdness.  When your friend says “My dog just died,” do you show support by “liking” it?

9. Personal Touch

If you can let users take control of how things look, the layout, color scheme, accessibility, etc. makes software more fun! More importantly you can help build an emotional connection to the software through a sense of ownership and control.   This won’t overcome other design problems, but if done correctly adds an extra oomph to your app.

Examples include WordPress, SharePoint, Gmail, and many others.

10. Solve a Problem

People don’t use software unless it actually makes their lives better and helps them through a problem.  That problem might be simply a boring meeting and they need to slingshot some birds or slice some fruit (as I love to do).  Or it could be a multi-billion dollar supply chain that needs to be managed and optimized.  In either case, the software needs to perfectly fit the situational needs of a customer, or it will cause frustration and be forgotten.

11. Unique & Fun

Awesome software has a sense of novelty, surprise, and is somewhat unconventional or irreverent.  One of my favorite examples is mint.com, which for me makes managing my finances actually enjoyable.  It treats me as a person first (vs. just an account from one bank) and tries to be useful in how it sells me things.

Conclusion

What separates terrible from awesome is not always straightforward and can be very subjective.  These are some of the ideas and rules that I use to make my software better, and how I evaluate the software that I choose to use or live without.

What rules do you use?

Advertisements

About Kit Merker

Product Manager @ Google - working on Kubernetes / Google Container Engine.
This entry was posted in Business Continuity, Disaster Recovery, Downtime, Technology, Uptime and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s