Agile Consistency Without Reams of Specs

My first actual article on this site was explaining my take on three tiers of consistency within software and assuring that a software program provides an experience where a user can expect things to be consistently intuitive and behave based on the user’s expectations.

Consistency in the Waterfall

Putting on the old man costume, one might muse a bit about the good old days of waterfall software development when everything worked out perfectly because we had reams of specifications for each project. The specifications must be right because they had sign-off by someone important and we had a big stack of change control paperwork for each modification!

Stepping off the sarcastic soapbox for a moment, I will note that implementing consistent behavior wasn’t likely easier in the waterfall days, but it was probably less ambiguous. One could always look up requirement where it specified how something should work and compare the software to the letter of the requirement.

The Agile Consistency Dilemma

When we transition to a more agile way of building software, where we value

Working software over comprehensive documentation

how do we ensure consistency in the absence of pile of specifications?

Consistency by Communication and Familiarization

Looking at the three aspects of consistency I wrote about previously, we have:

  • Consistency within a given application
  • Consistency across applications within the line of business
  • Consistency with industry norms and trends

Within an application or across a line of business, we can help facilitate consistency by enabling and facilitating communication within the development team. Developers that chat and communicate about how they’re solving problems are likely to solve those problems in similar fashion.

Familiarization with products can help prevent reinvention of the wheel. If your company has six products, a developer ought to have end-user knowledge of all six such that when implementing a new feature they would know how that feature, interface, or workflow might already be in place in a different program. This seems like it would be obvious, but I can recall several cases where I’ve raised an issue of inconsistency across products (by the same organization) and the developer indicated that he or she had never seen that other product.

Consistency failures are often failures of innocent ignorance… the developers aren’t being inconsistent with intent. They’re being inconsistent because they aren’t aware. Increasing awareness increases the consistency.

Take that day or two that you might have spent reviewing specifications and go work with the software.

As an added bonus, that time spent communicating about consistency? Your developers will also communicate about other things and build a more cohesive team.


Ingredients of a Helpful Error Message

As they say, shit happens.

Even in software.

And when things go haywire, we want to communicate with the users in a helpful manner. Ideally, an error message:

  • Informs the user a bit about what went wrong (if known)
  • Instructs the user how he might fix the problem on his own (if possible)
  • Suggests what the user should do if further assistance is required


A Threesome of Consistency

As we build software in a business environment (and in any environment), it’s desirable for software to be discoverable, allowing users to easily use the system without extensive documentation or training. Software that “just works” the way a user expects will result in a pleasant user experience.

Consistency in the software helps facilitate this experience.

As I test software, and keep user experience consistency in mind, I find three guiding areas for which I seek consistency.

The Consistency Threesome

  • Consistency Within the Application – Within a given application, similar behaviors should act similarly. If your dialog boxes usually have OK and Cancel buttons, they ought to be displayed in the same order in each place. Error messages should be displayed in the same manner everywhere. If your date standard is MM/DD/YYYY, every date should be shown in that format.
  • Consistency Across Line of Business Applications – In a business environment, the same group of end users often works with several applications to perform their job duties. A product manufacturing company might have applications for materials ordering and inventory management. Law enforcement organizations likely have multiple computer systems that store information about common entities such as an offender. A car dealership could be working with auto sales, financing, and service-related systems. As new software is introduced or changes are made to existing systems, ensuring that similar functions work in similar ways across applications can help enable the user to have a comfortable experience.
  • Consistency with Industry Conventions – Beyond applications used by a particular individual, we ought to look at industry trends and conventions. If widely used applications or websites have begun using a convention to do something, it probably makes sense to use that same convention. Folks are used to separating email addresses with commas… if your program allows a user to type a list of email addresses, let them delimit with commas. We often use the color red as one of the ways to denote an error… using green would be disingenuous. Go with the flow.

…and the Exception to Every Rule

There can be exceptions to every rule. You might have a really good reason to buck convention and make something inconsistent. But if you can’t identify that good reason, or the answer from the developer is “I just felt like doing it this way,” it’s probably not a good reason.

Even the Big Boys are Consistently Inconsistent

I present to you, the current Updates screens for the iPhone and iPad. Let’s play “Find the Update All button.” Hint: it’s not in the same place. More than once my hand has reached to the wrong side of the screen.

iPhone Update Screen showing 'Update All' in the Upper Right

iPad Update Screen showing 'Update All' in the Upper Left

And I know what you’re thinking… you’re thinking that I’m comparing the portrait-oriented iPhone to the landscape-oriented iPad. So here’s the portrait version of the iPad.

iPad Updates - Portrait Version

Coming in the future: Consistency in the Absence of Specs