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.
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.
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:
Add a new entity related to patient's medical situation with create, display, change and hide
Link a medical entity with a journal entry
Display a historical view filtered by various criteria
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 …
The process we used for making our design more usable was quite simple:
measure how long it takes to implement each feature
discuss the outliers in the retrospective
identify the root cause in the design that prevents us from going faster
define & implement the changes
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:
Quantitative: start measuring the actual time spent by user story
This is the basic method to obtain more usable software design. The advanced method is taken from usability practice…
Usability tests can be ran in multiple ways. There's one format I found most fit for software design:
Write down a list of tasks the user has to perform
Bring in a room users that have never seen the product (or the part of the product you want to test)
Ask them to perform those tasks
Measure the time it takes them to do it. Write down where they get stuck.
Use the feedback to improve the product.
Here are some examples of common tasks for a web application:
add a new form with one text field and a save button
add more validations to a field
change the text on a label (for one language or all supported languages)
add a new business rule
display a list of entities in a page
Here are a few important things to know about usability tests:
Make sure to tell the participants that if they don't know how to do something, it's the design's fault and not theirs. Encourage them to ask questions when they get stuck.
A complete test with one person shouldn't take longer than 1 hr.
Start with the most typical tasks first, and with as little information as possible. Only offer information when the person gets stuck or asks for help.
Prepare about 10 tasks, but be prepared for partial results.
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:
Clarity
Consistency
Here are some direct applications:
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:
Each of them contains three things:a request class
a controller 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.
by Diana Muntea
