Recently I’ve started being far more up-front with colleagues about progress on tasks. It’s not that I ever set out to communicate badly, or – gasp! – let tasks slip by, it just happens sometimes. New tasks and conversations come into my head and some of the older ones fall out of mind.

So what’s changed?

At my company we use an internal web-based Collaborative Platform to manage our day-to-day consulting business. One of the features is “meetings and actions”. All internal meetings have action lists which are captured on the platform alongside owners, due dates and escalation routes. It’s not ground breaking, there are many such standalone online web services but the integration with the rest of our platform means it links into people, projects, etc. very easily.

We recently rolled out a new iteration with an enterprise social layer and a vastly improved UI. The design intention was to grease the wheels of collaboration across the organisation. This meant it was natural to place rich user profiles, networks, discussion threads and groups prominently on the landing page. It doesn’t leave much room for anything else.

How should the screen real estate be used?

Deciding what to build on prime real estate is an age old problem. It’s no different for a system designer sitting in front of the blank sketch pad on day one of the project. In every design, there are a number of competing priorities but the decision making process can be framed with two considerations in mind:

  • What features are the users telling us they access most regularly?
  • What features do the system owners want users to access most regularly?

Ideally, there is direct overlap between the two but that is not always the case. Amazon wants us to buy, buy, buy whereas we might just want to use the site for “search inside this book”. There’s no doubt that Amazon believes the feature will sell more books but there’s nothing stopping us from using the feature to read a few pages and move on elsewhere.

Getting to the heart of the matter

Bearing in mind the considerations noted, the design team did a round of transactional analysis to determine what functions users are most likely to require ready access to. They polled users, looked at transaction logs and observed people using the then current design. They blended this analysis with the design intentions of the overall system (“better working together”).

Informed by this insight, user journeys were revisited and to-do lists have moved from being a poorly sized pane on a crowded landing page to being a third of the landing page, prominently in front of users every time they open the platform.

I now see my tasks every time I look at the platform. And because it is our centralised management platform for lots of things, I look at it a lot. Dozens of times every day. So I am subconsciously reminded of open tasks dozens of times every day. I am more likely to click into the tasks and make quick updates as I progress work on them. This means my colleagues are better informed as things progress, are more likely to be able to align their work to my work and collectively we are in a position to get more done in less time. That’s got to be good.

I was reflecting on this

I am a regular user of lots of web services as well as the platform itself. There can be no claim it was unfamiliarity with the features that meant I wasn’t keeping tasks up-to-date. I work as hard as I used to, so it’s unlikely to be laziness. I am a vocal advocate of using collaboration tools, so it’s unlikely to be attitudinal.

The more I thought about it, the more I realised I was thinking too much about it. There’s no deep and dark secret which required uncovering – I was just being blind to basic human nature: the easier designers make something, the more likely it is to be used.

If there are transactions that are important to day-to-day business, or to drive engagement in the enterprise social context, they should be moved above the fold on page number 1.

Amazon’s one-click ordering. Facebook, Twitter & Yammer‘s “share box” at the top of the page. It’s all the same principle. These are sophisticated web services where designers have identified the single-most important transaction and made that transaction the one most likely to be regularly accessed by users.

I’d like to believe that I knew this but I fear I had boxed the knowledge in the category of “consumer software”. I had never applied it to enterprise software. Going forward I think I’ll give more consideration to the “raison d’etre transaction” of any system and ensuring that access to the transaction is central to the usability of the system.