by Derek Du

Flexibility has a real cost

It is common for people to ask UI designers to design a system as flexible as possible. People believe that it is always better for something to be flexible. They think the more flexible the system is, the better the overall experience of the system. However, this is not always true. When we say this design is more flexible than the other one, we are saying that this design can handle more use cases, conditions, or scenarios. In other words, it performs more functions than a less flexible system. But, because it can do more, it often is more complex, which in turn decreases the usability of the system.

A great example from Universal Principles of Design about this tradeoff between flexibility and usability is the comparison between a Swiss Army Knife and corresponding individual tools. A Swiss Army Knife has many attached tools that increase its flexibility, but to put all those tools in one tool, it sacrifices usability – users spend more time looking for the needed tool and then carefully digging out the tool. The complexity also has impacts on the Swiss Army Knife’s size and shape, which results in a less comfortable handle than corresponding individual tools. 

This diagram shows that the more flexible a UI is, the more it costs.

Why flexible?

Knowing this relationship, it seems that flexibility only decreases usability -- what benefit does it bring to the table? In my opinion, perhaps it is only beneficial to build a system flexible when you can’t anticipate future uses of the system. The flexibility helps accommodate any unexpected future uses, so the system does not need to be modified as much as an inflexible system. On the other hand, if you clearly anticipate the need, you don’t need flexibility. Why would you add features you know you will not need? There is a cost for keeping unneeded things, i.e. higher maintenance, more complex structure that makes changes difficult, etc. You aren’t gonna need it (YAGNI) principle also presents several reasons for not adding features until deemed necessary.

·         The time spent is taken from adding, testing, or improving the necessary functionality

·         The new features must be debugged, documented, and supported

·         Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future

About building a flexible system vs. a specialized system, a great example from Universal Principles of Design is a comparison between a personal computer and a video game console. We use computer to do all sort of things and can’t anticipate the future uses of the computer, thus the flexibility of it. Game consoles are built only for playing games. It is a specialized system that does not need the same level of flexibility as a PC because we can fully anticipate the uses of it.   

How flexible?

Knowing these key factors, when approaching the problem of how flexible a system should be, we can tackle the problem via the following practices:

1) Clearly define the uses of the system

Only when we clearly define the uses, can we know whether flexibility is needed. Requirement analysis itself is a topic that will require a whole series of posts, but knowing that this has to be done is critical.

2) Compare levels of flexibility with the cost in mind

As mentioned previously, increased flexibility has a cost for usability and development effort. So we have to look at all factors together. What I often do is put design candidates with different levels of flexibility side by side. I play with the different user interfaces just as if I am a user so I actually feel the pros and cons of each design.

An example involves setup screen for sending system notification emails, such as error reports. Should I provide the flexibility to allow the From Address and Sender Name to be edited?

Things like From Address and Sender Name, once are set up, may never change. Allowing these to be changed like in the first design below introduces more user errors and longer setup time, thus reduces usability. The second design does not allow these to be changed, but could cause some confusions - why are these read-only? Do I need a higher permission level to edit them? The third design allows these to be editable but also provides default/suggested values, which increases the flexibility without reducing much of the usability. By comparing the three designs, a decision can be made quickly.

Aside from usability cost, we also have to deal with the cost of time and money. Consider the same email notification designs. If the first design cost $1, the second $100, and the third $1,000, the first design is mostly going to be favored. Development cost like this can have a great impact on the decision. What I often do is presenting all the cost factors to the stakeholders and work out a decision together.

3) Stop when you have to

During the system design, we will apply the first two steps and create designs with high flexibility and low cost. When design phase is over, we hand it over to development team. Whatever level of flexibility we have in design at that point is the level the system will have. Every project has a time constraint. Even if you don’t want, it is going to decide the level of flexibility for you.

I covered a basic introduction to flexibility and a few practices we apply to our projects. There have been numerous discussions on software flexibility out there. Many of them are around flexibility on software architecture, but the basis is still the same - flexibility has a cost and it is beneficial when we can’t anticipate future uses. I hope that knowing about these basics is helpful!