I've read a couple similar questions and answers but haven't been able to piece together a good answer on my issue. I have a form where based on the input given in the form, back-end decision modeling will only allow for one of three different cal-to-action options "Submit", "End Task", or "Next". I am trying to figure out the best way represent this.

Option One

Depending on form input have the call-to-action button label dynamically change. This would keep just one main button in the bottom right of the form. The button would change to either say "Submit", "End Task", or "Next". enter image description here

Option Two

Don't change the call-to-action button dynamically but have all three buttons shown with one active and the other two would be disabled. Due to the decision modeling only one button would ever be active. enter image description here

  • 1
    Why do either? What problem are you trying to solve by changing the button at all? Commented Sep 16, 2016 at 19:13
  • I probably shouldn't have used such a simplified form in my example. Sorry about that.So based on the data input into the form tool a user would have 3 options, Submit the form (everything submitted was correct), End the Form Task (something input into the form would not allow the form to continue), or Next (the tool may need more information before allowing the user to submit). So all the options aren't necessarily a submit. Users would only get one of these 3 outcomes. So would I change the one button label or have all 3 outcomes displayed but gray out the two that aren't available?
    – dmasini
    Commented Sep 16, 2016 at 19:51
  • Are the selections for Element Two dependent on the selection(s) of Element One? Is the user always only picking between Element One and Element Two? Commented Sep 18, 2016 at 0:46

4 Answers 4


It looks like you are doubling the amount of decision trees in this thought flow, creating unnecessary redundancies.

Is there a way you could instead make the form dynamically update based on what they are selecting above? Rather than change the button at the bottom, focus on the inputs you are gathering along the way.

For example, if the user selects Element One: Checkbox One, it could limit the amount of options in Element Two: Dropdown. If the user selects Element One: Checkbox Two, the user then has a different set of options for Element Two: Dropdown.

The point is that the form process should be a funnel, eliminating options along the way, until the final option is Submit. Generating additional options at the bottom will create a lot of usability issues: Why are they asking me what to submit? What is the correct submit button? Did I do something wrong? Try to eliminate the guesswork at the end so they simply have to just "Submit". Too much guesswork at the end may result in false leads, and abandoned forms.


It makes more sense to change the button on a go rather than create additional buttons. In regards of UX, why would you even do that? Just "submit" works for the last (at least) 15 years.


Ok, so I'm literally at a bar writing on a receipt, so excuse the poor drawing.

The boxes are buttons. My thinking is that is is a candidate for question piping. Use buttons to advance the user instead of Submit buttons.

Think about mobile - drop down menus are so yesterday.

enter image description here

  • So we will have a back-end decision management tool where based on the options chosen in the form will decide what final action is available to the user. The tool will give the user one of three options, "Submit", "End Task", or "Next" (to add supporting information). The user won't have the ability to decide which to choose because the decision modeling will do that for them. I am trying to figure out from the front end if I should only show the one option that is available or to show all three with two disabled.
    – dmasini
    Commented Sep 19, 2016 at 13:43
  • I think I have answered my own question though. If decision is only going to allow for one option; "Submit", "End Task", or "Next" then I should probably only show the one one active option. Showing all three where only one option would ever be active sounds like it'd be confusing to the the user of the tool.
    – dmasini
    Commented Sep 19, 2016 at 13:47
  • Yes. If there is a way for them to supply inputs to have the back-end tool re-evaluate, then presenting that option might make sense. Otherwise if you need to describe the other two options not presented, a tooltip or text description makes more sense. Commented Sep 19, 2016 at 15:13
  • And if your user testing shows that you should present the buttons disabled for clarity, a tooltip would still be helpful : ux.stackexchange.com/questions/72777/…. But based on my experience in web development, less is generally more. Commented Sep 19, 2016 at 15:17

One of the thorniest problems for a user is having a button with a label that doesn't seem to have an obvious referent. In your example, I don't see anything --except the button-- labeled "option one". So what would I be submitting?

  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. Commented Sep 19, 2016 at 4:01
  • It seems to be conventional--many do it without being criticised--to use answer space to make a comment when one cannot yet make a comment in comment space.
    – MMacD
    Commented Sep 19, 2016 at 12:44
  • Not really. As soon as we (mods) see it, or through flags get notified for it - we post a comment, or convert to comment or delete. In the StackExchange network there are questions and there are answers. Comments have a special field to clarify questions or answers. Nothing else. Commented Sep 19, 2016 at 16:15

Your Answer

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

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