2

So I have a configuration menu with many different menu options. Currently, I feel that the flow is very annoying for users to make changes to as it requires the following steps:

  1. Make change
  2. Hit apply
  3. Hit submit change
  4. View pop up with preview of changes, and hit OK

I have been told the apply button is necessary, but I feel that it is creating an extra step in the process. The user needs to hit apply for each page, i.e. the user picks menu1, makes changes, hits apply, then moves to menu2, makes changes, hits apply... hit submit changes and then submit again.

If the changes get "applied" as the user is making the change, I feel we can eliminate step 2 and make the UX much simpler for the user. What are the benefits to having the "apply" button be present? Currently, if we make a change and switch menus without hitting "apply", none of the changes save which I think causes more issues than benefits.

Improve this question
4
  • Where did those ideas come from? Why might they over-ride simple logic? Who doubts that much of the problem is having 'a configuration menu with many different menu options…'? If it requires all those steps, why would the flow not be annoying for Users? Make change Hit apply Hit submit change View pop up with preview of changes, and hit OK If that description was clear - which it certainly is not - still you would be forcing your poor Users to make at least one unnecessary choice. More follows…
    – Robbie Goodwin
    Apr 12 at 23:09
  • Further… if that description was clear - which it certainly is not - still you would be forcing your poor Users to make at very best one unnecessary choice. How can you explain any difference between 'Make change…' and 'Hit apply…' Exactly how are they not the same? In the same way, how can you explain any difference between 'Hit apply…' and 'Hit submit change…' How are they not the same?
    – Robbie Goodwin
    Apr 12 at 23:16
  • Just wondering whether the actual changes to the values are made in step 2, 3 or 4. It seems like you only need to save the changes at one of the steps, and that the other steps are opportunities to undo or make further changes before the user exits the configuration menu.
    – Michael Lai ♦
    Apr 13 at 1:54
  • 1
    @MichaelLai so as far as the front-end programming goes, step 2 saves the change locally (does not make a call to the server), step 3 provides a pop-up window with a list of all the changes you made and step 4 actually pushes all the local changes made in step 2 to the server.
    – Gene Lee
    Apr 13 at 16:24

3 Answers 3

Reset to default
2
+50

I have been told the apply button is necessary

It sounds like your limiting criterion is technical in nature. If this limitation is based on how the backend technically works, then from a purely pragmatic perspective you may need to work within those limitations. If indeed this is the case, then your question should be more geared towards how you can make the process of Edit > Apply > Submit visually clearer to your customers. I won't go into a lot of detail on that now, as it really should be another question - and would be a good type of question for this site.

If however, that is not a technical limitation, then I would agree with you that it seems to be an unnecessary complication. Most people are used to Edit > Save as their paradigm, and functionally from the human perspective there aren't any good reasons that I can think of to split the "save" process into "apply" and "submit". There are situations where this makes sense, such as using git repositories, but then that's typically because several changes will be staged ("apply") together before being committed ("submit"). It's not a normal paradigm to use for making smaller changes at a time that people outside of the programming world would be familiar with.

It would help a lot if you would go into more detail in your question as to who your target customers are and how big the relative changes are, as well as why this structure is "necessary".

Improve this answer
6
  • 1
    Yup, the second I read "...being told...", I knew a developer was behind this. Even just thinking about the solution, I can see why a dev might want to put the onus on the user to keep track of changes. Though the OP has a point, this is going to be frustrating for the users.
    – Kitanga Nday
    Apr 12 at 22:25
  • 1
    @KitangaNday I absolutely agree that this is likely frustrating to users, but what can be done UX wise isn't done in isolation of everything else. If it's a technical limitation within that organisation, a UX designer has to do the best job they can within the constraints that they have. We can't just have an ideal solution that can't or won't be implemented, as the end result will be no improvement.
    – JohnGB ♦
    Apr 12 at 22:58
  • 1
    I would say it is originally a technical limitation, however I am a UX engineer and can rewrite the code to fit the UX I want. I think the initial idea was to limit calls to the server, but because the current "apply" only saves changes locally and the "submit changes" makes one call to the server for the entire list of changes, I can remove the apply button and have the changes save locally automatically. I mainly wanted to know if there were any benefits worth discussing as far as keeping the "apply" button
    – Gene Lee
    Apr 13 at 17:16
  • @JohnGB I see what you mean and I agree. Unfortunately, I agree more with my mentor when he told me that technology shouldn't limit design. My opinion is that it can, this situation being a good example, especially with the popularity of agile. But still, I feel that the Devs should at least give a shot. "Please don't stop trying" - apparently a Japanese proverb
    – Kitanga Nday
    Apr 13 at 17:53
  • 1
    @KitangaNday that's a hard one because I kind of stumbled upon it. I started as a ux designer and as we outsourced our developers, the front-end design was never up to par with my wireframes/prototypes I provided. I asked if I could do my own coding so I wouldn't bother the developers with my small changes. I started by taking the code they wrote and rewriting the front-end so that it was more UX friendly. The more I comfortable I got, the more they had me coding. Eventually I pushed to change my title from UX designer to UX engineer.
    – Gene Lee
    Apr 13 at 18:18
1

The "apply" button may have some benefits, but it's essential to weigh them against the potential drawbacks in terms of user experience. Here are some possible reasons for having an "apply" button in a configuration menu:

  • Immediate feedback: The apply button allows users to see the effects of their changes without committing to them. This can be helpful when users are unsure about the impact of their modifications and want to test different options before finalizing their choices.

  • Error prevention: Users can sometimes make unintended changes, and the apply button provides an opportunity for them to review and correct their actions before they become permanent. This can minimize the chances of incorrect configurations.

  • Separation of concerns: The apply button separates the process of making changes from the process of saving those changes. This can be useful in some situations where users may want to experiment with different options without actually committing to them.

  • System performance: Depending on the complexity of the menu options and the system that the menu is part of, the apply button can help manage the performance by avoiding unnecessary updates. If applicable, it can also reduce the number of server requests by batching changes together.

That said, if these benefits do not outweigh the inconvenience caused to users by having to go through an extra step, you can consider alternatives to streamline the process:

  • Auto-save: As you mentioned, you could have the changes "applied" as the user is making them, effectively eliminating the need for the apply button. This can simplify the user experience but may require more robust error handling and undo/redo functionality.

Ultimately, the best approach depends on your application's specific context and your users' needs. Testing different designs with real users is essential to determine the most efficient and user-friendly solution.

Improve this answer
0

"Apply" button is just a short cut for the sequence "Submit and close" + "Edit". "Apply" button should submit all changes. If submitting requires validation or preview of changes, this will make the process too complex, because user will have to keep in mind if after preview and submitting the edit mode will be exited (if "Submit" was pressed) or if the application will remain in the edit mode (if "Apply" was pressed). That's I'd suggest to remove "Apply" button.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.