Our development/support team creates applications for company employees (invoicing, task management and the likes).
We have a recurring issue where users misuse the applications they're provided, using workarounds, stepping outside of business process boundaries, leaving data or automated processes in poor states, often hard to recover. It's quite obvious they compensate for features perceived as missing, or bad UX. Sometimes, though, they just make mistakes following procedures.
Business managers are aware of this and lament the fact, but nothing changes.
We are aware that our apps are not state-of-the-art. There are bugs and less-than-ideal UIs. Lack of resources also means it's not evolving rapidly.
The behavior is generating extra support load, making us less likely to deal with root issues. It also often generates requests for workaround features, rather than requests to fix the root issue.
What can be done, from the IT side, to prevent or minimize destructive user workarounds?
(I'm not sure much can be done at the developer level, so any management-level actions are welcome)
- Because the user account for a new hire was not created in time, the user logged information in another account "in the meantime". Now user wants IT to transfer said information to his proper account (a purely in-DB manual task)
- Enabled by: logging app allows any user to log information in any user's account (very low security). User account creation is late (reason unknown, done by another team)
- Users make use of features in one application that mess up our automated process because our app cannot deal with the extra or missing data, or simply never receives calls for the unimplemented features. Users have been told by management not to use these features. IT has been told not to bother blocking the extra features. Users still use the extra features. IT has to fix things manually all the time.
- Users misuse predefined fields because the field they need is missing (putting notes about a customer in its 3rd address line field for example). Users do not ask us to add the field. Management does not seem to prevent the behavior. IT gets in trouble when said notes suddenly appear on invoices because a new feature displays that 3rd address line, as expected.
- User does not want to wait for us to develop his reports, thus asks to access DB and makes his own solution. Has led to further demands about specific fields and tables (instead of expressing business needs) and to execute pre-made queries (with many mistakes and no explanation as to what it's meant to do business-wise)
All of these seem to follow the same template: users won't/can't wait, they don't express their needs, they just come up with workarounds. I understand the temptation, even the need, as a user myself. But it has consequences: bad data, gets in the way of strict DB constraints, and in nearly every case it adds manual-fixing work to the team.
What bothers me is that it feels like being punished for something you did not do. It's like they cross the river instead of walking around to the bridge, and then complain to us that they're all wet and cold and request that we setup a raft service in that spot. Then complain because a bump made them drop their bag, and ask us to dive to get it back.
Isn't caving in with every request enabling the behavior further?
While I've come up with ideas to avoid the behavior, or the consequences, I'm unsure which might be more efficient, and which might get us (IT) in trouble.
- Saying no to such requests. Users would have to formally request their initial requirement and wait for it to be ready. Workaround mess ups would be cleaned by users.
Anytime I suggest this, colleagues look at me with this look: "that would be awesome, in an ideal world, but..." It feels as if the business side has guns pointed at everyone's families. It's also not always possible to let users fix their messes. Lack of admin tools means we're often the only ones capable of cleaning the mess.
- Locking forbidden features incompatible with our workflows and inciting formal requests for any improvement deemed necessary.
This has been an issue so far because features are hard or impossible to lock, or that the people who could lock them are "busy" (other teams not affected by the falldown)
- Train the users (not controlled by IT)
Supposedly done multiple times, but has had NO effect whatsoever.
- Punish the users when they step out of established processes (not controlled by IT)
Many memos sent as a reminder. No change. No harsher punishment than reminders has been dealt out.
- Explain why it's bad, how much work it creates for IT
Repeated ad nauseum to business managers, who tried the two previous actions, to no avail. Not sure the actual users know the impact it has.
Bad developer, no cookie
In reply to many, and to hopefully save face a little: this question was both a sanity-check and a way to learn if anything can be done when the sensible thing (actually implementing the features users need) is removed from the table by management.
My team and I are working with legacy applications with less than ideal structures that makes it hard to fix and upgrade. New parts are thankfully done in a more sensible manner and rarely give us trouble, except when we're told to not focus on things like user experience or validating requirements.
We'd love to fix root issues, remove bugs, implement the rails and safeguards to guide users down the expected process paths, and so on... but there's never time for it because in spite of suggesting this many times, we're put on firefighting duty and creating new features or upgrading existing ones.
Some fixing happens when we edit existing code, but larger overhauls are needed to fix the bigger problems, and this requires time we're not given. It also often depends on application from other teams, and they're "busy" too.
I've recently given a reminder about the users using the extra features from the external app that our app can't deal with. Either we adapt our app, or the team in charge of the external app locks down the features. It's been acknowledged, as it often is... but now to see when/IF it ever gets a greenlight. In the meantime, we douse the fires.
This is the cradle in which the question was born: what does one do when you're not allowed to treat the disease but only the symptoms? I apologize that it was not clear but part of me wanted to see genuine reactions to the base problem, to reassure myself that I'm not the only one to think we're dealing with user needs very poorly.
I don't even condone most of the solutions put forth, I've just seen these applied so far and wondered if any really made sense. Clearly, no.