Learning Conversations

There was a time, not too long ago, when the only exposure normal people had to Information Technology was at work.

We didn't have the internet or email in our homes, but we may have had it at work.

Everything was tightly controlled - to conserve valuable bandwidth and resources (both digital and human).

At that point, we had nothing to compare against. If we were given a green DOS screen to carry out our work that was fine. We might have thought some of the commands were a bit hard to remember but nothing that couldn't be fixed by a cheat sheet.

Now, however, we are often carrying around in our pockets IT systems that are more powerful and more connected than those provided by our employers. With them we can immediately look up information, ask questions of our peers around the world, share ideas through video, collaborate on documents, carry out complex operations on our bank accounts, and even remotely control equipment in our homes.

All these applications have one thing in common: If they are to take off they need to have as few barriers to usage as possible.

Aral Balkan has written extensively on user interface design. I've copied his key points below, but look up the source article if you want the detail.

1. The Client Is Not The User
2. Don't Give The Client What She Thinks The User Wants
3. You Do Not Know What Your User Wants
4. Only Users Know What Users Want
5. Test Early, Test Often, Then Test Again
6. Talk One Language
7. Respect User Effort
8. Make Difficult Decisions
9. Let The User Work
10. Prevent, Don't Scold
11. Give Sufficient Feedback
12. Show, Don't Tell
13. Don't Lose The User
14. Don't Sell What You Can't Deliver
15. Don't Keep Them Waiting
16. Innocent Until Proven Guilty
17. Usability Approach to Accessibility

For some more ideas, see Jakob Nielsen's post on design mistakes.

Applications that rely on users to keep using them follow these principles closely. These include the consumer applications we have on our personal computers, phones and tablets (whether browser-based or not).

But it also includes the new breed of corporate "Cloud"-based Software-As-A-Service applications, such as Kashflow, Salesforce, Cornerstone etc. If people don't use them the client will think long and hard about renewing their license each year.

Those applications that sit inside our corporate firewalls seem to be excluded from these design principles. They might be fit for purpose, but often they don't encourage use.

A couple of examples that I've come across in my travels:

1. A Learning Management System that doesn't allow people to link directly to a particular course. This means that, to market courses (whether virally or otherwise), all you can do is give people the link to the corporate self-service portal, and then provide instructions on where to go next. At least six clicks (in various esoteric parts of the screen) and two popup windows later, you might get to where you want to go.
2. An internal document library that was so hard to use that employees would use Google to find out information about the organisation rather than trawl through the official internal documents.

It goes back to Aral's first five points. IT depts need to get closer to us, their users. It's not that we can go elsewhere at the moment, to be honest. But it's about inspiring confidence to ask them for future developments, and about getting most value from what we already have.

If that doesn't happen, there are plenty of providers of consumer-grade systems out in the cloud who can do what corporate IT offer. And then it's just a matter of deciding whether you risk your data there... (but that's for another day!)