Appropriate Expertise

It’s long been a core belief of mine that it is vitally important to have appropriate expertise applied to each different facet of a software development project.

At it’s most fundamental level, this means that you don’t make guesses or presumptions about the way the business area operates - you ask your users for guidance, advice, and feedback on a regular basis. I expect that most experienced developers would agree with me.

There are a couple of common problems that are brought to light when you start to seriously consider this principle: User Bias and Misplaced Authority.

User Bias

Every user brings their own bias to the table when they start to describe the requirements and processes in their own business area. Essentially, users very seldom give a complete and reliable picture of their area - there are always distortions, omissions, and errors. It is important to remember that in most cases, with most users, this isn’t a deliberate act, but a simple consequence of users being human, and therefore fallible.

In many cases, users are (or can be made) aware of this bias and they will work effectively to overcome it themselves. In other cases, may be unwilling or unable to overcome bias through their own efforts. (A recent article on Hacknot.info calls this User Fraud.)

Always, however, is the need for the development team to be aware of the possibility of user bias and to work to reduce or eliminate its effects.

Often the most enterprise-wide tool in this regard is to interview many users for their opinions and then work towards a consensus with them all.

Misplaced Authority

There is a pervasive mantra within the software industry that The User is Always Right. Within certain limitations, this is correct.

When talking about the users business, where they are undoubtedly the Subject Matter Experts (SMEs), the collective voice of your user base is always right.

Problems occur, however, when you start to let users make decisions where they are not the subject matter experts.

Here are some real-world examples that I’ve seen where users have been given misplaced authority, with untoward consequences.

• In one case, the key colors used throughout the User Interface of an enterprise-wide system with hundreds of users were chosen by a user. How did he make his choice? He chose the colors of the shirt, tie, and trousers that he happened to wear that day.

• In another, the client’s insistence on a simplistic database structure crippled performance (requiring additional server hardware) and introduced a raft of consistency and update issues that required ongoing vendor support.

Note my key point here - in each case the users were not SMEs in the area of the decision being made.

In the first case, User Interface decisions should have been made by someone with skills as a User Interaction Designer. If no designer was available, using the default look and feel of the available widgets would have been a good play.

In the second case, a Database Administrator should have been consulted to ensure the design worked with sufficient performance. At the very least, consulting a developer with a basic understanding of data normalization would have prevented the data consistency issues.

Conclusions

It is vitally important to consult with users continually during a project, to ensure the system delivers real value.

It is just as important, however, to keep users well away from areas where they don’t have the expertise, lest their lack of knowledge cripples the system completely.