Training Users vs. Regulating Users
When developing software solutions or custom integrations for our clients, we start by taking a step back and asking ourselves “Does this feature provide value? Is this the best way to accomplish the goal?” Not every problem needs to be solved by a software feature. In this article, we discuss how to decide if it is more efficient to train the user how to correctly use the software, versus adding what we refer to as ‘regulating’ features.
Regulating features are generally added to software to control the user’s actions or keep the user from doing something they shouldn’t be doing. Some regulating functions are extremely important to a project, like managing access to sensitive information through user permissions. Others, like the choice between a Save button or an Autosave feature, aren’t so critical.
In most cases, there is always some training that takes place to acclimate a user to new software. Providing training in a mindful way can help eliminate the need for some regulating features which can save you money and your users some frustration.
Evaluating the Need for Regulating Features
When deciding whether or not to add certain regulating features to your software, we recommend evaluating in four general areas; Complexity, cost, flexibility, and user aptitude.
- Complexity – How will one regulating feature interact with other features? If there are many layers of regulating features which may affect each other, things can get complicated fast. Thought must be put into which features take priority, how they interact with each other and what happens if there is a conflict. If one feature requires an update in the future, how many other features may be affected? The benefit of the regulating feature should be measured against the amount of complexity being built in now and for the future.
- Cost – Naturally, adding regulating features costs development time and money. The complexity and interaction of multiple regulating features can drive that number up. Many times, placing an automated restriction on the user for one scenario opens up other scenarios which now must also be considered (We’ll look at this in an example later). This also spills over into testing the interactions with other features, and not just in the initial creation and testing of the regulating feature itself. The cost can quickly start to outweigh the benefit so this should be considered carefully.
- Flexibility – Any time you take the decision-making process out of the hands of the user, you remove some amount of flexibility from the system. This makes it less adaptable to new situations or needs that were not present when the system was initially designed. A good way to approach flexibility is to ask “How often will this problem actually occur, and what’s the worst thing that will happen if it does?” Weighing these answers against the typical user’s aptitude goes a long way to ensure you’re not spending money trying to solve problems you may not frequently have, while reducing the software’s flexibility.
- User Aptitude – Considering the typical user’s ability to make the appropriate decisions is also of paramount importance when considering regulating features. Are your users beginners with very little computer background, or are they incredibly tech savvy? Will you have control over training on how to use the software, or are the users on their own to figure things out? This can be a pretty varied and in-depth conversation, so we help our clients walk through these questions to determine what the typical user level is and make recommendations accordingly.
An Example
A good example of this process is a simple phone number input field. The simplest way is to provide a text input field with no restrictions for the user to enter a phone number. It’s not complex, has low cost, high flexibility to accept multiple formats, but relies on a certain level of user aptitude to understand the preferred ways to enter a phone number.
But what if we just want the system to prevent someone from mistakenly entering too many digits? You can restrict the number of characters, but what do you restrict it to? A typical phone number in the United States is ten digits long. But if you restrict it to ten digits, the user must only enter numbers. If you want your data to appear in a specific format like 555-555-1234, now you are restricting it to 12 characters. But you also now need to restrict to the format xxx-xxx-xxxx, or else someone could just enter 12 number digits. What do you do if the user tries to enter more than 12 digits? Stop accepting more characters? Provide an error message when they leave the field or submit the data? What if you need to accommodate international numbers with even more characters?
As you can see, one regulating feature spirals out pretty quickly into multiple layers of controls and restrictions – and this was just entering a phone number. It may be simpler and more effective to train the users on how the phone number should be entered and provide an example rather than build a number of functions to strictly control the input.
Our Guidance
Taking a step back and looking at the big picture is a best practice we strongly believe in and encourage our clients to do with us throughout the project. We use our experience to provide alternatives and recommendations with the goal of always providing the most value for the cost and effort, no matter the topic. Evaluating and saving the regulating features for where they are most important will help you get the most out of your project budget, and set your project up for success.
For more information on getting the most out of your project, be sure to check out our blog on The Importance of a Plan – Don’t Build Without a Concept Blueprint. Be sure to keep checking back for more tips, truths, and insights in the future!
