In the standard software development lifecycle, one of the first things discussed are the requirements. How does it work? What is its purpose? What functions does the program need to provide? The casual conversation eventually leads to a more formal set of business requirements, or business rules, that the developers need to follow to ensure their program “performs as designed”.
This process works great, right? Well, not exactly.
In my experience, many times the program that the developers code does “function as designed” ““ except the design is incomplete. The form or screen “works” but the experience of using that screen, well, it sucks. This is not to say that developers do not have a sense of design style, or even common sense ““ far from it. It’s just that there are additional constraints and rules that they are not given, and many are “binary thinkers” – if it ain’t documented, they ain’t coding it.
This is where user experience designers come in. We provide that extra guidance, based on user research and testing”¦ We can provide the missing context and rules. These aren’t necessarily wireframes or specifications; sometimes, a high-level statement is needed. I call these “experience rules.”
So, what is a good example of experience rules? I’ll use a personal anecdote to provide an example. I filled out a fairly lengthy form the other day to access an account online. Well, I didn’t follow the “business rule” as to the formatting of my username and so the form CLEARED ALL THE DATA I had entered when I submitted the form and was presented the error message.
Now, was this form developed properly, according to the business rules that the requirements team defined? I’m sure it was. Was it a really frustrating experience? You bet.
So, what “experience rule” would I have defined for this form? Something along the lines of “Never clear data that the user has entered when presenting a validation message on submit ““ if the user has entered sensitive information like account numbers, hide that input”
Now, that looks an awful lot like a business rule, but it’s not, really ““ it’s a rule that is driven by user experience needs and best practices. You can “store” this rule in the business rules repository, WHERE you put it doesn’t matter: the point that the rule needs to be defined by SOMEONE (preferably a UX professional) is the important thing.
In closing, if you are a UX designer or a business analyst, start thinking about these “experience rules.” When you think about, and define, such rules in one of your projects, your customers will thank you for it.