We know both from our own experiences and articles about UI and UX that consistency within and across our applications can provide great value for the user; that which is familiar becomes easy.
We also know from the Agile Manifesto that we value responding to change over following a plan.
Are we at odds with ourselves? Can we both embrace change with an open mind while also valuing the benefits of consistency?
Yes. With intention.
Valuing Intentional Consistency
Consistency within and across software applications can provide for a positive user experience once a user has become familiar with the conventions that are used. Consistency can exist in multiple levels.
From specific to broad, we can look at consistency on several layers:
- Within a single application, we expect consistency for similar functions.
- Within an organization and line of business, consistency could be expected across applications used by the same user groups.
- Within an organization as a whole, consistency could be expected across applications built by or for that organization.
- Finally, we value consistency with other similar applications in the industry. If your text-editing program offers a toolbar button to make text bold, it probably should be a big bold letter B on the button (assuming you’re in the English language).
Conscious choices to be consistent can help users become comfortable faster as they use your program for the first time, or as they gain proficiency and can apply previously-learned skills and behaviors from other areas of their work.
That said… if we always do things the same way we’ve always done them, we’ll never change, right?
Embracing Intentional Change
We want positive change. If we never changed as software development teams, we’d all be writing COBOL software to build command line applications, right? Any new interface or functional paradigm is going to be inconsistent with the existing pattern simply by virtue of being new.
Much like we embrace intentional consistency, we can embrace intentional change. It’s okay to use a new design paradigm if the benefits of the new design provide a lot of value.
Change… with a purpose… is good.
Do Not Confuse Sloppiness for Change
Where we get in trouble, and create poor user experiences, is when the development team gets sloppy and we introduce change without a purpose.
Perhaps a developer is new to an application that has handled validation errors by lighting the field up in red and displaying an error summary at the bottom the page, but he instead makes field labels bold and introduces an error toast in the upper right.
If a designer is used to dates in MM/DD/YYYY format, she might not know that for this line of business, dates are always displayed as YYYY-MM-DD, and would create misleading design comps.
These are usually innocent mistakes, not done with malice but without the knowledge of existing consistency patterns, or by not asking questions before diving into a bad pattern.
Build software with intention, and your change vs. consistency issues should work out well.