How do you minimize destructive user workarounds? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

Summary

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)

---

Examples

• 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?

Solutions?

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.

Answer 1

First of all: if your software allows to mess things up, it is not the fault of the users!. The only effective way to prevent this is to fix the software, so it won't allow workarounds, or only with some pain. If that's not possible, find a way to mitigate the consequences of these software issues. Of course, some of the problems you mentioned are management problems, but some simple technical measures can help a lot.

For example:

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

I see three things going wrong here:

• your companies process of creating accounts for new employers is way too slow. People want to start working in time, but they can't. Start fixing that - when your company looses money because the users cannot work, you will surely get management backup for optimizing this process.

• Second, why is logging on to the system as another user even possible? Users should not have the possibility or need to log in with an account different from their network account, your software should provide an auto-logon feature. Multiple need for authentication does not increase security, it only gives you and the users a headache.

• Third, if the system allows to enter user specific information, why is it so hard to transfer it from one account to another? Either you should have administrative tools or scripts for doing this painlessly, or the software needs a feature to let the users do this by themselves.

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.

So what? Either these features cause problems so severe they are totally unusable (which means you don't need a permission to block them completely), or they are required for some use cases, even if they interfer with others. Make the application tell the user the consequences immediately in the moment they try to use them (like showing a warning "note, this field is currently not exported to our Foo process, use it at your own risk"). And make sure the use of such a feature, even if it currently does not integrate with other automatic processes, does not "create a mess" which needs to be cleaned up afterwards.

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.

If your application has a field tagged as "adress", which is not actually treated as an adress field by your application, but as an "additional information" field, don't blame the users for this. They learned how the field works and understand the adress tag just as a misnomer - and they are 100% right about this. Instead, be more careful when you change the application in a way where it starts using older, existing fields in new ways.

In such a case, there needs to be a thorough test and rollout process, to make sure these fields were not used the way you liked them to be used. That is why tests should always be done not only with some artifical data, but also with real production data. Moreover, the users need to be informed in detail about such a change, and they need to be informed where they should put the things like "comments on the customers" now, if the 3rd line of the address field (which for them clearly looked as pure comments field) now gets a different semantics.

Proper communication of new application features and tests are an IT responsibility, not a user's responsibility.

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)

Where exactly is the problem here? You have not enough resources to create reports for them quickly enough, so some power user who obviously knows SQL offers support. Sounds good at a first glance, that should take some burden from your shoulder - at least in theory. And if it works, it is probably ok. If this, however causes more trouble than it saves, you either need to train those power users better, or tell your superiors why you won't let every unskilled user access the database in an arbitrary manner. This works best if you have numbers at hand, like the number of working hours you needed to invest to fix a specific case.

So stop blaming the users or trying to control them, instead work on the things you can control and see what you can do on your side of the table to help your users to get their job done.

A final note about your your edit: "what does one do when you're not allowed to treat the disease but only the symptoms" - the one thing you can do is to create some tools - or workarounds - to handle these symptoms more smoothly (which can, to my experience, often be done with a fractional effort of creating a full-blown, perfect solution). For example, if there are "features from the external app that our app can't deal with", instead of investing one month of making your app dealing with all those features, invest one or two days to make the fact your app cannot deal with it more visible to the users, and make sure even when a user uses this "unsupported feature", nothing really bad will happen in your application.

Answer 2

You (perhaps your whole department) need to change your attitude towards users.

Your software is there to help the users to get the job done - not the other way around! If the users are not able to get the job done, or they have to jump through hoops to do it, then is a fault in the software, not a fault with the users.

When the user is using a workaround it is because they are trying to solve a problem which is not supported in a straightforward way by the system. Observe the workarounds used and consider this valuable information about missing features or bad/confusing user interface. Your proposed solutions seem more concerned about hindering the users in solving their problems, rather than helping them actually get their work done.

users won't/can't wait, they don't express their needs, they just come up with workarounds

Honestly, given the attitude expressed in your "solutions" ("punish" the user for trying to solve their immediate problems - seriously?), I can understand why the users try to solve problems on their own below the radar, rather than go to your department to express their needs. You need to rebuild trust with your users.

A first step might be to start regarding the users as customers rather than users. You could introduce the role of a product owner - a person which have the overall responsibility for deciding and prioritizing what goes into the product. In in-house development, the product owner would represent the interests of the people having the use the program. Obviously such a product owner would never prioritize punishing the users, but would have a genuine interest in enabling them to their job.

Answer 3

Sorry, why this question.

You know the problem, then what else you want. Stop user destructive workaround design your application that way that user is bound to use the procedure.

I understand the business point of both the sides, here you and the other user both are looking for the solution.

The only way to solve your problem is that you decide the procedure to solve the issues and share the plan with your user/company whoever the stakeholders are, and mutually agree on what you need to do.

Achieving something is not that easy but can be made easy with planning.