I find people’s quirks interesting.
When I meet someone new with a story to tell, I will devour it. I will ask them questions. I will ask why they did that thing… when they did that thing, how they felt about it… How did other people feel about them doing that thing…
Maybe this is why I gravitated towards studying users and the quirkiness that comes along with user experience and interactions. What I find most endearing about our beloved users (whom we’ve interviewed, surveyed and studied to death) are the times when they begin using the application not as it was intended.
Since people can at times be unconventional – so can business processes.
I noticed this usually happens when a platform is implemented with a large offering of different functionalities – all of which weren’t necessary as part of the build but were shared anyway; or a feature that offers a configuration with a wide variety of options. It usually goes something like this:
- A business process or piece of information is needed sooner rather than later
- A user that feels fairly comfortable in the system gets creative and tries to solve the problem using the system in an unconventional way (thus creating a new use case)
- Nothing immediately appears to be broken so user continues to use the new process
Everything is fine until an account manager checks and realizes what is going on and their internal melt down occurs.
So what do we do as product managers and user analysts? Scold them? Coach them? Ignore it and hope it doesn’t cause any problems?
A consultant-minded individual would advise you to coach them.
Administrative users may not be privy to the who’s, whys and hows of a system like a marketing director or eCommerce director would. They can become siloed in producing reports and managing data. At times these hacks can have adverse effects on a system – some not apparent until much later. In these situations, educating administrative users would give them background into why what they do is important and how it affects the bigger picture.
Here is where you can, very politely, explain why this new process may be a bad idea and reasons it should be avoided.
A curious individual would advise you to learn about them.
How lucky you are to have this new use case fall into your lap! You should be jumping for joy to talk to this individual and understand why they felt compelled to do this. Obviously someone who would creatively misuse the system to successfully accomplish something has imagination in their bones. Learn from them! A common pitfall when designing user interfaces is getting stuck in how things “should be done”. It’s hard to step out of the box sometimes with prior system and industry knowledge.
Some Would Say Build Off Of It.
Hell yeah… just go with it! See where it takes you! Here is where A/B testing may come in handy. Releasing a new beta version for a few select users that incorporates this change may be a great success. Offer it up to those who have the time to experiment. HOWEVER avoid any users who love standardized processes and whose job it is to get as much done as possible. These people can wait until this feature has been fully vetted for a full release.
Others Say Just Ignore It.
Sometimes it’s ok to turn a blind eye. If it doesn’t hurt anyone and is a positive to their workflow – why not? Just make sure you do your due diligence prior to letting it go.
Oh and document the sh*t out of it so it doesn’t cause any problems with new builds in the future.