Process Usability

In my previous post about code usability, I mentioned that usability applied to anything that can be used and doesn’t need to be something that can be seen. So today, I'll talk about that second part: making intangible things more usable. I'm talking about process usability.

What kinds of processes?

We all follow processes at work. Sometimes it's official, sometimes you don't even know you're following a process. Every time you follow steps to do something, it's a process. More specifically, I'll talk about software development processes, but process usability applies for processes in any business.

In the development community, there are processes for developing new features, for fixing bugs, for releasing the latest version, for time tracking, for testing, even for usability testing. What you need to ask yourself now is: how easy is it to follow these processes and can it be made easier?

What do the developers have to do beside implementing the feature? Do they have to produce some kind of paperwork? How difficult is it to release a new version? Is it a headache every time? What about time tracking? Do people have an easy way to track their time or does it piss them off to do it? (As a side note, every time something pisses off someone, it needs to be improved). I could go on, but I think you get the point.

Common areas of improvement

Here are a few processes that are commonly difficult to use throughout the industry:

  • Revision control process (branching, merging, maintenance of old versions, ...)
  • Time tracking
  • Releasing

How do I improve these processes?

Evaluating the need for improvement

Improving a process is not an easy thing to do, if it was, all processes would have already been improved. There's a trade-off that needs to be evaluated. Either you take a big hit initially by improving the process after which the process is easier to use and takes less time, either you don't improve it and people stick with the old less-usable process. You have to evaluate if the big initial hit is worth it: to do it there are 3 things to consider:

  • How often is the process used?
  • How difficult is it to use it?
  • How big will the initial hit be?

Once you answer these 3 questions, you'll have a better idea of whether you should work on making the process more usable or not.

What to improve

There are two dimensions that are most important while making something more usable: lowering the mental overhead needed to do something and lowering the time taken to do it. Once those two dimensions are at their minimum, a process (or something tangible) is as usable as it could be. Your goal is get as near to the minimum as possible.

Lower the number of clicks needed to do something (time tracking for example), the amount of paperwork required. Reduce the amount of mental processing needed to accomplish a task (if branching and merging was easy, people would do it). Reduce the risks by creating a checklist of things to do when releasing so that people don't forget something. Reduce the amount of information people have to keep in their head, make it easy for them to write things down in a website/wiki/...


You may have noticed that I talked a lot about lowering or reducing things. That's what usability is all about, removing the complexity from the use of objects and processes.

Where can I find more information about process usability

37signals created a few neat applications that can help you reduce the amount of information you need to keep in your head by putting them up in one of their tools.

Joel Spolsky understands the importance of process usability (even though I don't remember him ever mentioning the term) and he tries to make the development processes at his company as simple as possible. Just take a look at step 2 of The Joel Test and you'll understand:

2. Can you make a build in one step?

That's it?

I didn't go into too much detail because I just wanted you to know that process usability exists and that processes can be improved. I will go into more details about specific processes in future posts, but let me know what you want me to talk about or which process interests you the most, just mention it in the comment and I'll do my best to help.

Michel Billard's profile picture

A web developer's musings on software, product management, and other vaguely related topics.