I'm redesigning a product for iPad and Windows, and currently looking at the way buttons are placed in the application.

Base screen

Here is what a generic "base screen" looks like. Nothing special, just a navigation with some actions aligned to the right, with the content appearing underneath. The content is editable, so when you make a change to it, you must save it by clicking the save button. Auto-save beyond the scope of this.



When clicking on one of the links in the navigation, a small modal will appear, which contains a form for editing.

Current design

Currently, you fill out a form or edit it, then you either accept or cancel your changes by tapping on two icons in the top-right of the modal. This has a number of immediately obvious limitations:

  1. Icons are ambigious and should be accompanied by labels to clarify meaning
  2. A destructive action (cancel) and constructive action (complete) are styled too similar (given the same level of prominence) and placed too close together
  3. Actions appear after the form, so the user fills out the form from the top to the bottom, only to return to the top to action it.

current modal

Proposed design

disputed modal proposal

  1. Icons are replaced with buttons that clearly specify what each action does with a label.
  2. Cancel and complete buttons are separated and now styled differently, most importantly: the destructive action "cancel" is styled only as a link as opposed to "complete" which is now a button. This will hopefully encourage form completion as opposed to cancellation.
  3. Actions are now at the bottom of the form.

The problem

It has been pointed out that it seems strange that for the base screens we have our actions before the form (the save button which saves the content below it) while on my proposed design for the modals, they're at the bottom.

I see his point although the reason for this is simply to conserve space. What these wireframes don't reflect is the amount of content we're having to fill into such a small place, so aligning the save button to the main navigation makes sense. If we didn't do this, we'd have to sacrifice our content area instead by including a new row to accommodate a save button and maybe one or two more buttons in the future. Hardly seems worth it.

My question is this: has anyone else encountered this problem and what did you do about it? Is my proposal OK considering this inconsistency between the button placement on the base screen and modals, or does it really need to be fixed?


  • User testing right now is unfortunately beyond scope.
  • Has to work for touch as well as mouse.
  • Screen height is a issue that you might have to deal with if you choose to put your action buttons at the bottom. They might not be in the viewport, or the user might not be able to scroll down for whatever reason.
    – Adnan Khan
    Jan 28, 2017 at 22:21
  • The design change for the modal is good. What I worry about more is the semantics of "complete": Completing something on a modal does not save immediately? Only the Save button does? How is the unsaved change done on a modal represented on the main screen? Mar 30, 2017 at 6:06

2 Answers 2


All of your points regarding the current design are absolutely correct, and I would highly suggest moving away from it.

Having buttons on the bottom of a modal is common practice so your users are likely to be very familiar with this pattern regardless of the consistency with your base screen. If the users aren't very tech savy, it's still a very natural pattern to have the action follow after the content.

If you're really concerned about screen real estate, I would consider a "focused task" approach, as demonstrated by Atlassian: https://www.atlassian.design/server/patterns/focused-tasks/


If your top row above the content has the purpose of a toolbar, I would move the "Save"-button to the left. This way you are consistent with most other applications. It is common that the importance of the toolbar buttons decreases from left to right (importance: for example with regard to the frequency of use). A typical example are office applications such as Microsoft Office.

Furthermore, you will notice that many applications (e.g. Office) simultaneously use toolbars in the way I described above and modal dialogs like in your proposed design. This is a typical design and many users are familiar with it. In my opinion it is not necesseary to enforce consistency here.

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.