Issue 33

Usable Software Design

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works


In a previous Article for Today Software Magazine - 4 Ideas To Apply For Better Software Design, I wrote about the fact that we tend to perceive software design as userless.

Whenever we talk about design in other domains than software, we discuss it from a user-centric point of view. Apple's products are renowned because they focus on the experience of a user with their device: how it feels, how it looks, how fast it responds, the sounds it makes etc.

Software design is the only type of design that seems to be userless. After all, the end-user has no idea how the software works and doesn't care. All they do care about is to work fine.

Software design is not userless. The user is the developer that will have to change the code after you do. If you have collective code ownership (like most Scrum teams these days), you'd better consider user-centric software design.

Ideas such as "Clean Code" touch this idea. But I'd like to explore this topic in detail.

1. New Developers Working On Usable Software Design Will Get Productive Faster

Why is usability of web applications such an important topic today? I would argue that it brings a competitive advantage because users find it easier to start and use an application that's built with the user in mind. No user has time to spend days learning a new product; we want to start using it immediately and get instant benefits.

The new users of software design are the new developers joining your team. We will assume they know the programming language, the main framework used and have worked in the business domain before. How long does it take for them to become productive in your environment? The time spent familiarizing with the design of the application and with how things are done mostly translates to expenses. In the economy of the product, that's waste.

2. Most Common Tasks Get Done Faster With Usable Software Design

Think about the type of work you did on your current product. Chances are some of them are repeated patterns.

In the eHealth application we're developing, the first few features took a while to get done (NB: we were also learning a new technology at the same time). By carefully looking at what slowed us down and adjusting the design, we optimized the development and got to the point where about 60% of the work is the UI/UX design. The development was no longer the bottleneck. We then looked at optimizing the UI/UX design, but that's another story.

The key to this improvement was that, looking back, we realized that the features we develop fall into several types of work:

Since we know from that roadmap that more work like that will come, we started optimizing for these types of work.

Occasionally, we have to do a new type of work that takes longer. One example was a drug search service that is fast, scalable and easy to update to the latest version of an official drug database. We had to learn and use vertx and mongodb to do it, and it took about 3-5 times as much as the usual tasks. Since that is a local situation that is unlikely to repeat, we did nothing to optimize for it.

The point is this: like an application that's easy to use for most common tasks, usable software design allows fast implementation of most common types of features.

These are the main benefits I see for usable design. But how to achieve it? The first thing is …

<img src=

3. Measure and Improve

The process we used for making our design more usable was quite simple:

We're using a Kanban / XP process, so we used the cycle time distribution diagram to identify the outliers. We have a recurrent retrospective every two weeks where we discuss the impediments and identify potential solutions. The implementation was made in the next two weeks, and we kept an eye to the cycle time distribution in the next months. It was easy to see the improvement since most items moved to the left.

In a Scrum context, teams don't measure cycle time, only velocity. The trouble is that the velocity is an aggregated indicator for all features implemented during the sprint. Therefore, Scrum teams have two options for getting to more usable software design:

This is the basic method to obtain more usable software design. The advanced method is taken from usability practice…

4. Run Usability Tests On Your Software Design

Usability tests can be ran in multiple ways. There's one format I found most fit for software design:

Here are a few important things to know about usability tests:

5. How Does Usable Software Design Look Like?

Let me start by saying that the idea of focusing on developers as users of software design is very new. I have seen work around this topic, and I've done some myself; past literature on design has touched this topic without making it explicit.

There is however a lot of literature on usability. I will only state three basic principles of usability that apply to software design:

Here are some direct applications: <img src=

Clarity: Name Namespaces Based On Feature

Here's a screenshot from an application I'm developing. Can you tell what it does based solely on the namespaces?

I first heard Sandro Mancuso talking about this idea at I TAKE Unconference 2014, and I was very interested to give it a try. I see it as a very good start for usable software design.


Consistency: Have a Consistent Structure For Each Feature Namespace

Here's how the namespaces look when expanded:

<img src=

Each of them contains three things:a request class

I still have to figure out a better place for the InvoiceFileNameGenerator, as you can clearly see. This is a violation of the third principle, minimizing the unexpected.

Consistency: Each Type of Class Should Have a Consistent Interface

We've seen above that a feature namespace consists of three types of classes: a request class, a controller class and a view class. There's an additional level of consistency that you can reach, specifically the interface of each of these types of classes.

In this example, all the Request classes above have one method: response(). All controllers have one method: render(). Each controller uses a view to render the information. This is consistent across feature namespaces.

Final Thoughts

Usable software design will bring two main economical benefits:

faster implementation time for most common tasks

and easier integration of new people in the project. To obtain usable software design, we need to get feedback from its users, namely the developers. There are two ways of doing it: through retrospectives and by running usability tests.

This idea is not entirely new. Principles such as clarity and consistency have been used for many years to obtain better design. The idea of usable software design is however a change in perspective; thinking of the developer as the user of the software design and actively trying to get feedback from them will bring forward changes in the way we're organizing our code.


I have been inspired in writing this post by many conversations with: Sandro Mancuso, Samir Talwar, the attendees at SoCraTes UK, Rebecca Wirfs-Brock, Adi Bolboaca, Claudia Rosu and many others.

For more in-depth approach of Usable Software Design, I kindly recommend you the Usable Software Design Workshop \@ I T.A.K.E. Unconference 2015 http://2015.itakeunconf.com/sessions/alex-bolboaca-usable-software-design.




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects