I am trying to determine how to name buttons in a global element document:

  • There are two types of scenarios where buttons are used: (1) User submits a request and (2) Approver approves or rejects the request.

  • The nature of the request changes. Sometimes, it is to create a new entity in the system. Sometimes it is to ask for an association between the user profile and an existing entity (ex. a region). Sometimes it is to register for a program. Etc. But fundamentally, the requests are always to "activate" an association (to a program, to a region, etc.) or to "cancel" (de-activate) the association between the user profile and the other entity (program, region, etc.)

  • The nature of approvals is always the same: accept, or reject the request. This causes no issue for the buttons: we keep accept and reject as buttons.

For the request buttons, can we keep "activate" and "cancel" as generic names throughout the site to accommodate all the scenarios and uses? Is it better to customize them according to the scenario? I am trying to understand what the best practice may be for standardizing buttons having the same behavior but potentially a different label.

  • 4
    Cancel seems like an all-round poor choice. To me, cancel implies that I'm cancelling a process that I'm in the middle of (eg. cancelling a program that is currently being installed). Activate/Deactivate, Approve/Reject, Yes/No have an innate association that would help users discern exactly what you're asking for.
    – cimmanon
    Oct 4, 2013 at 20:06
  • Thank you very much Cimmanon! We indeed decided to be specific depending on the entity because each had its special terminology :)
    – user36060
    Oct 7, 2013 at 19:47

2 Answers 2


I would say, if you can code it in and it doesn't make button too wide, to be more specific in button wording. This way, I haven't seen your layout so I'm making an educated guess, the user isn't confused as to what entity the button is for.

Activate Region or Activate Program.

Approve Request or Deny Request.


In my experience, excessive abstraction causes more problems than it solves.

I would give it a name ("Big Important Button") and then describe what it is, when it should be used, when it shouldn't be used and then provide some examples on usage.

Big Important Button is used for important actions. Important actions are creating, saving and deleting items. For actions that only change elements of an object, use the Less Important Button. For examples of how the Big Important Button is used, see the Create New User form, the Delete Widget confirmation page and the Save Item form.

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.