“Consistency” Does Not Mean “Uniformity”

In a user interface, similar things should look the same. But different things should look different.

Why do over 75% of Facebook’s users think that the new Facebook UI is bad? Because it makes different things look similar to each other. Nobody can tell if they’re updating their status or writing on somebody else’s wall, because even though the text is slightly different in the box depending on what you’re doing, the box itself looks the same. The new Chat UI (introduced a few days ago) makes idle users look basically identical to active users, except for a tiny icon difference. (It’s also important that different things are different enough, not just a little different, because people often won’t notice little differences.)

This is an easy pitfall for developers to fall into because developers love consistency. Everything should be based on a single framework, in the backend of an application. But that doesn’t mean that everything has to be displayed the same in the UI.

This fact–that different things should look different–is actually true with code, too, but people rarely think about it, because developers are actually pretty good about it. For example, accessing a value of an object should look different than calling a method on it, and in most programs, it does. For example, in Bugzilla’s code, accessing a value on an object looks like $object->value whereas calling a method on the object looks like $object->method(). It’s not all that different, but the () at the end is enough difference for the average programmer to notice “Oh, that’s a method call that does something–it’s not just accessing a value in the object.”

All in all, consistency is really important in both the backend and the frontend of an application. But that doesn’t mean that every single thing should look exactly the same–if we took that to extremes, we’d just have a solid white page, and that doesn’t seem all that usable (frontend) or readable (backend), does it?


  1. Heh, is that a stab at getter-setter-style properties? Function calls that look like value accesses?

    • You know, actually it wasn’t intended to be, originally, but thinking about it some, those types of properties actually really can be confusing. How can I tell the difference between a property that takes an argument to return something slightly different, and setting the value of a property? This isn’t an issue in smaller apps, because you don’t have properties that take arguments to return something different. But in, say, Bugzilla, we definitely have or want those, so I wouldn’t want all of those to look the same and be really confusing to casual code readers.


  2. Even the nature does not follow the rule of consistency and uniformity, then why should we follow it ! Nature has given us all chances to be creative by exploring diverse patterns in environment, but – we never follow it. Specially the inception of Technology has put the world to an uniformal and monotonus stance. So becoming a part of novel approach towards old version is something about keeping the ‘consistanccy’ yet not following ‘uniformity’.

    • Ahh, it took me a second to see what you were saying, but yes, I fully agree with that last bit. 🙂 Keep the consistency, but that doesn’t mean you have to be totally uniform with what came before. 🙂


  3. good article…. but is dat practicle enough to lose uniformity while being consistent??? as people dnt accept change easily….

    • Hey, it’s true that people don’t accept change easily. Maybe the best solution is to design a user interface that’s consistent but not uniform, in the first place, so then you don’t have to change it! 🙂


  4. I love how in Scala, the () is optional because in the end everything just computes down to a value anyway.

    functional programming is fun!

Leave a Reply