Software is built to solve specific business challenges. These challenges are defined by the software vendor. Sometimes the challenges are defined with a lot of input from the customers who are actually experiencing the business challenge. Other times the software vendor assumes they understand the challenges and builds features in isolation. No matter how the features are defined, you can never predict how the actual users of the software will choose to engage with it. It never ceases to amaze me how we can be so confident in our approach to software and then watch first time users to our dismay—they engage with it in ways we never considered.

I purposefully focus on the definition of the business challenge because typically there are a lot of different ways to solve the same business challenges. One of the concerning things I find over and over in the implementation of print software is users trying to use a feature that was built to solve one challenge to solve a totally different challenge. Some would call this innovation or creative thinking; which in some cases it surely is, but in other cases it is a shortcut that can cause some real issues downstream.

For example, let's say you need to sell things in “packs” on your web-to-print system. The web-to-print admin doesn’t see any obvious place to tell the user how many items are included in the pack so you simply add that information to the product name field. This sounds like innovative thinking, getting things done, moving things along. The issue is that the field “product name” wasn’t really intended to describe pack quantity. It was intended to be easily searched, indexed, optimized for SEO, and sorted on—all of which could be disrupted by adding pack quantity to the end of it. What happens when the customer decides that some products can be sold in several different size packs (i.e., 25, 50, or 100)? Now you have a different challenge.