Trusting software

Where’s the Save button? Scrolling up and down the settings page, finding none. The trend is nowadays to just skip those and save all changes automatically. Just like we don’t need the Stop button ever since the iPod came out. We just need Pause.

The trouble with this approach is trust. Most users do, and always will, approach any computer system with a slight discomfort. On the surface, there’s this colorful array of boxes and buttons, maybe with a few cute icons. But underneath, there’s this made-in-hell machinery, that operates on the verge of magic. Nobody knows how it works “under the hood”, besides the creators maybe. Least the users.

When I modify settings and click an explicit Save button, I assume my changes were saved. But what if there is no such button? And no message that says anything about saving? I feel this inner discomfort knowing that perhaps something just malfunctioned, the app probably saved my changes, but maybe it didn’t.

Think of software design as a conversation. One where the parties cannot see each other – like with walkie-talkies. The receiving party responds with a confirmation – “roger”, “over”, “settings saved”, “account created”.

The more operations your app performs automatically for the user, the more important it is to confirm outcomes, both correct and erroneous. This is how you build trust.

Software installations for Noobs and Freaks

“Copying Windows files”, “Getting files ready for installation”, “Installing features” … and so on. Installing Windows 8 is an experience pretty much the same as it’s ever been, where too much information is presented to those who don’t care, and not nearly enough to those who do. On top of that I’m informed that “my computer will restart several times.” Lovely.

Computers used to be the domain of hackers – people, who wanted to push the limits of what’s possible and know all about the machines they were using. Then the PC came along (or the Mac, if you’re that kind of fan) and all sorts of people strolled into the computer world, not always willingly. Most software changed along the way, but the installation processes were mostly left out of the changes.

Every piece of software – as big as an operating system or as small as an instant messenger – should have two modes of installation:

  1. I’m a Noob – I just want the software up and running, as soon as possible. Assume all the defaults, get on with the installation, tell me when it’ll be over (I really don’t care what you’ll do on the way) and show me the workspace immediately afterwards. And yes – this mode should also be the default.
  2. I’m a Freak – I want you to tweak the software precisely to my needs. Show me all the knobs and handles, let me decide what goes where, then show me exactly what the installer’s doing every single step of the way. If I don’t like something, let me reconfigure the process. When done, show me a configuration dialog so I can fine tune the final details.

What we’re getting instead is usually a mix of both. Noobs find the installation process too daunting, to the point where they’re just confused and keep clicking “Next”. Freaks find it mostly unsatisfying, distrustful about the installer doing something they would probably not approve of. Nobody’s happy.

Think of installing software as the “unpacking experience”, like Steve Jobs always emphasized it, and Apple continues to do. It’s the first experience a user may have with your application and you want it to be as comfortable and pleasant as possible. Do your users a favor and design your installation process, just like you design your application.

“Beta” is here to stay

Every web application is in “beta” these days. It’s these pesky developers excusing buggy software by saying “we’re working on it, so expect a few quirks”. Can’t they deliver quality? Not really, folks, sorry. Business is too quick nowadays.

The appeal of web applications is their ease of maintenance. No need to install or upgrade locally. Launch your web browser, type in the web address and you’re already using the newest version. For business units this means they can keep rolling out tweaks and new features daily. Obviously they shouldn’t because things take time to develop and test properly. But if they’re not quick enough, competition will be, will outrun them and put them out of business.

So we, the IT people, are at war now with Business. We demand time to ensure quality, they demand speedy development and deployment. And since business pays, they win, we submit and can only beg customers for forgiveness by calling our software “beta”.