Consistency vs. Simplicity
(flickr tags: consistency, simplicity)
One problem that I always seem to run into when creating a user interface is the conflict between consistency and simplicity. Clearly they are both valuable, but what do you do when you cannot have both?
To give a little background, I work on a workbench application that provides a graphical interface to core text analytics technology provided by my company. Our customers have a choice to use the core technology directly through an API or to use the workbench application. The assumption is that more advanced users will choose the API, while less experienced users will choose the workbench. We also have several other GUI products built on top of the core technology that provide various types of text analytics functionality.
The problem we often run into is terminology. The API has its own set of terms for all the features and options it provides. While those may work for experienced developers, they are often too obscure for the less experienced users of our GUI products. Each time a core feature is exposed in our UIs, we have to make a decision whether to use the obscure technical term or to come up with one that is easier to understand. We want beginners to understand what we’re talking about, but we also want it to be easy to transition to an expert level without having to re-learn all the necessary vocabulary. This is the main dilemma. Should we err on the side of simplicity, assuming that expert users will simply understand the terminology differences? Or should we err on the side of consistency and deal with a steeper initial learning curve?
Both of these options have their own set of problems. If we err on the side of simplicity, there is a good chance that our users will not be motivated to move beyond beginner level to take advantage of everything our core technology has to offer. In addition, without proper communication between development teams, we can end up with several different terms for the same concept. This makes it difficult for users to switch between our complementary applications because each time they need to make the mental connection that Term A in one application means the same thing as Term B in another. While there is a seemingly easy solution to this problem (namely, establish good communication channels between teams), it is something that has already happened, so changing to a more consistent set of terms means significant changes for current users of our applications. It seems like in this case, simplicity actually breeds inconsistency.
On the other hand, if we err on the side of consistency, there is a good chance that beginner users will be unmotivated to use our GUI applications because of all the difficult terms. This is a big problem because we have the GUI applications specifically so beginners can use our core technology. We can offer documentation and training, but this is a significant time investment for the users. In addition, there is a good chance they won’t remember everything they’re taught, so we’ll essentially be forcing them to use our applications with a manual constantly in hand. That is hardly the way to create a good user experience.
One of the things that would solve the problem in our case is to make API terms more user-friendly and then use them consistently in all our GUI products. However, this is not an option because the API has existed longer and has wider distribution, meaning that more people would be affected than if we just simplify the terms in our UIs. In addition, changing the terms in the UI involves modifying a few labels and updating documentation. Changing the terms in the API involves significant work for its users because they would need to go in and refactor all their code. Work for us vs. work for them? Obviously we choose work for us because that keeps our users happy.
So here we stand — consistency or simplicity? We can’t have both.
Right now, I choose simplicity. We could have the most powerful technology in the world, but if it’s not accessible to inexperienced users, it’s practically useless. People may not understand exactly how our software works and everything they can do with it, but if it offers them something they couldn’t do before and makes it easy to do, then we’ve at least made a difference. True, making users remember terminology differences between applications is a big problem, but that is something we can resolve over time. For now, it’s better to be inconsistent but usable rather than consistent and impossible.
Consistency is certainly something to strive for, but in the short term, simplicity should be given higher priority. Learning three things that are easy to understand is easier than learning one thing that is difficult. It’s like learning that red, yellow, and blue are primary colors versus learning about the physiological responses of the human eye to color so you can then infer which colors are primary. Knowing the physiology would certainly help you work with all colors, no matter where you encounter them (consistency), but if you use primary colors most of the time, all you need to know is red, yellow, blue (simplicity).
Consistency vs. simplicity is a difficult choice and it’s much better to not have to choose at all. In an ideal world, standardizing terms from the start is the best option. In the real world, standardization can take a back seat… for now.
