Restricting user freedom of customisation

Question

The context:

Currently working on the redesign of an employee attendance app that's used by various companies. At the moment the companies that use the app can set their own attendance statuses to fit their needs.

For example Company X created and use the attendance statuses: Present, Late, Absent. Whilst Company Y uses: Present, Absent, Absent without notice.

We give the client companies full control over how many and what options of attendance they want to use so it differs from company to company.

Now this is all fine and dandy until you look at the user interface (I'm not obliged to show you and it doesn't hold relevance anyway since the redesign is well underway) which is a complete mess as you have to cater for so many possible options and it slows the whole work flow down unnecessarily.

Edit due to comment further explaining the pain point: It becomes a complete mess because all the clients really need, fundamentally, is to see whether they were present, absent (with notice), absent without notice, or late. Some clients have 13 different statuses for what seems like just for the sake of it because they can and the end users who mark it end up being terribly confused as to which status to check because they end up being rather similar. It also clutters the UI unnecessarily with all these options.

As such, what we want to do is...

... standardise the attendance options for all client companies as to avoid the current situation of catering for possibly hundreds of different variations of statuses that are essentially the same in meaning. We plan to set a small yet sufficient number of available statuses and remove any option for clients to create their own statuses.

Our concern is...

... that we would face an outcry from existing customers about limiting and cutting back on the current level of customisation and control that they have over the system and that they would simply stop using the system even if they would be able to complete their work flow much easier and faster without missing anything critical.

The question at hand:

Is limiting the users ability for customisation and forcing them into standardised practices a dangerous path to take and why?

And to a further extent, how could users be persuaded to accept giving up the freedom of customisation?

Answer 1

I'm dealing with this at the moment on quite a large scale (large areas of an older complex system being evaluated and updated). Relevantly, I also recently attended an Atlassian Design Talk/Panel where they said (paraphrased)...

"Think very carefully about each feature you put into your applications, because once they go in, they are very difficult to get out".

---

Reduction in feature set

You say that the UI at the moment is a "complete mess", which is subjective - but what isn't subjective is:

• Every additional feature in an application requires work to be built/updated, and a maintenance effort by your team or others.
• Every bit of non-essential information detracts from the essential.
• Providing an abundance of choice increases the cognitive load of a user

My view is, if you have the opportunity to remove content/features from your application that are not providing value, then the removal of them can be itself valuable.

... [our concern is] they would simply stop using the system even if they would be able to complete their work flow much easier and faster without missing anything critical.

I think here you have partially answered your own question, nice!

The solution is two parts:

1. Conducting research to confirm your hypothesis that the planned consolidation of options will be of overall benefit to users. Personally, I prefer to re-frame this and ask 'What do users actually need / what are their end goals?'.

2. Communicating the changes and making sure the update is adopted as smoothly as possible.

---

Research - Are the features providing value?

Ideally, the first step is researching how users are currently using the application, and how they are utilising the options available.

• Direct observation would be difficult given people are changing statuses over a large span of time (e.g. over the course of a day), but you may have access to some sort of analytics data or data from your database (people's current statuses). Determine which are used frequently and infrequently.
• Warren had a good suggestion of conducting a card sort. Elaborating on how this could be done...
  • You would take all the currently available options and write them down on individual cards.
  • Get real users, in individual sessions, to categorise cards into logically similar groups.
  • Get them to name the new groups that they made.
  • There are two benefits to this - the end result (the new smaller subset of options based upon your analysis of how users grouped the cards), and the conversation you can have with users as they perform the task (remember to ask them what they are thinking if they hesitate, and after chat to them about how they use the app currently and drill down into what they are ultimately trying to achieve when they change their status).

---

Communication - Changes are coming

If you have confirmed that users don't get value from the other options, then you just need to communicate the changes to them.

• Send communications ahead of time stating that "Updates are coming..." detailing the changes, so it won't be a shock when the UI changes for them one day.
• Since it is a positive change, spin it like one e.g. "We are simplifying the way you... This should make it easier to..."
• If the UI of the feature changes quite a bit, consider adding some simple onboarding explaining the change and the new way it works. This only needs to be seen by users who existed prior to the change, not brand new users.

You say that this is also part of a larger update, and so with that should come user benefits in other areas, likely overshadowing any one single change since it was an informed change based on the output of user research.

Answer 2

My thinking is: if you restrict it, you will face the outcry from existing customers. Let's remember that they created these statuses to make them fit their needs. Besides, there is some data from the past they would need to keep a at least comparable with the future data. And finally, people got used to using them after all.

On the other side, giving people too much freedom to customise data may indeed lead to mess in some cases especially as it is prone to users misconceptions about how to organise the information they enter.

Having this in mind, I would search a solution in shifting the current statuses to some lower level, making them further, more detailed information about the new statuses that you create. While it's still an idea and needs to be put against the real data that is there (namely: the statuses particular clients of yours have created), this could be:

New, standardised status 1

• sub-status 1.1. (an existing status that meets status 1 criteria = further explanation)
• sub-status 1.2

Etc.

At the same time, I would allow users to only select the top level statuses, without a need to choose the lower ones.

In your case the top level statuses would be probably: presences, absences with a notice, absences without a notice, being late. Then, for example, if a company e.g. allows working from the office or remotely or people can be on a business trip (but still at work) these could be the further breakdown of the "Present" top status – and it gives some room for nicely representing it on a graph using various shades of green for example.

But I would start from deeply analysing how your users customise the statuses and asking them why, then testing any concept you come up with with them.

Answer 3

I think your first focus needs to be on limiting the options shown in the UI, not those available in the settings. If you show every attendance status from every customer's customization, no wonder things became a mess. In this case, the customizability isn't the primary cause of the mess, other factors are. Now, if one customer decides that they want 30 different attendance options with similar names to all show on the screen, then they need a separate conversation.

If for some other, unmentioned reason, you must limit the choices, you could gather a council of clients (can be a carefully-chosen subset if you have too many clients), explain to them the problem, and ask what options would be acceptable (picking most common custom options and limiting to those, only allowing one custom status per organization, etc.).

Answer 4

It's a fundamental question and it touches every aspect of design: flexibility vs. rigidity, freedom vs. order. As designers we want to please the users and give them the tools they need and want. However, being too liberal and compromising can result in "committee design", which in turn results in a very mediocre product in the end.

Users come in different sizes and shapes: some of them use mainly the keyboard and some do it all with the mouse, But in the end, they all have better things to do than adding useless options to choose from.

In your case I'd give the best practice options for attendance that you've come up with (3-5 options), and hide the "add status" functionality somewhere in the general settings, making it harder for users to reach it and thus discouraging them from adding an unnecessary status. Your existing clients won't hate the change, while new users will probably never reach that dreadful functionality and stick with the defaults, and we all know how much users tend to change defaults :P

Answer 5

I assume you've done the necessary taxonomy research with users/customers (via card sorts etc) to identify the most common attendance status values. Including users in this process, and/or communicating why you are making the change in advance, would be key to keeping users on board with it.

This actually sounds more like a business/product direction question, than a strictly UX one. There are inherent "dangers" in any change within a product, especially when it comes to user choice. The question is whether your organisation is willing to accept the risk of disgruntled (and potentially departing) users vs retaining control over the product vision.

If the product is regarded as valuable by the users, the "cost" to them of any change would likely be outweighed by the overall value of the product.

Answer 6

Regardless of this specific case that you mentioned, It is a common and in my belief very important question in world of software and product development: Where is the true threshold point to stop blindly applying user requests and start to build what you think is true and better than users want?. I was dealing with this issue for several years and i share my opinion and conclusion: There are commonly three group of peoples with three different mindset:

1. Peoples who think user is god, And user is the indicator of our works, our vision and only the user knows what he want. Immediate user's satisfying is more important than any other aspects of the job. This mindset is near to businessman's mindset. Peoples whom focus on today and don't think about building tomorrows.
2. Peoples who don't care about users opinion and try to solve problems through philosophical consideration of the problem and try to dictate and publish their thoughts as god roles. This mindset is near to theoreticians and my be fine artiest.
3. Beside these two groups, there is another group of people who believes, Users don't know what exactly they want. Users act based on their previous experiences and rarely can think about what could be in future. This mindset say You should consider the issue philosophically and consider users needs and users wants and finally offer a philosophically true and yet acceptable solution for users. This mindset belong's to designers.

You should act like a designer. In opposite to specialist like developers, designers don't focus on one aspect but saw many aspects of a problem and combine them to build best possible result.

In case of your problem, If you try to satisfy all users, for sure you encounter other problems and finally end-up with unsatisfied users. you should consider the employee attendance issue philosophically and try to group all possible kind of cases then consider your users company's culture and extract critical cases. Now based on the acquired information you should decide to choose the policy and user freedom threshold. it's an interactive and time-wasting process. but it cost.