

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

I'm reading The Grammar of Interactivity on UXBooth and finds it quite interesting. However, the article quotes David Hamill who said (or wrote):

Buttons are for actions, like “Get a quote,” “Download,” “Open an account,” “Go to checkout.” The text on the button should begin with a verb. Otherwise it’s not a call-to-action, just a button with some text on it. “More information” for example, is not a call-to-action.

But that would mean that the adjective "OK" as button text is wrong. If it's wrong - what should we use instead of OK? I'm confused, so that's why I'm asking "Should all button text start with a verb?"

share|improve this question
I read that the other day - very interesting. Worth noting that OK/okay can be used as a verb to approve, authorise or give assent, so the "OK" action in dialogs would follow the pattern. – Matt Obee Feb 21 '13 at 15:35
See this very related question, especially the top answer… – JonW Feb 21 '13 at 16:05
@JonW It is indeed a very useful answer. – Benny Skogberg Feb 21 '13 at 16:50
I would say OK on a button is acting as an interjection, not an adjective. – AakashM Feb 27 '13 at 10:16
up vote 8 down vote accepted

The "OK" text of a button normally refers to an action mentioned above in the form, that will usually be a dialog.
For example a "Delete this thing" dialog's "OK" button means delete it, a verb.
Actually, I prefer when the verb is in the button, no matter if it's repeated, because a fast user can check the action to take without needing to read the dialog content.
In the example above the title would be "Delete this thing?" and the buttons "delete it" and "keep it".

So yes, buttons should be or refer to verbs.
There might be exceptions, hence should instead of must.

share|improve this answer
+1 I like the distinction of Delete It or Keep It. There are numerous of times where you read a long text and still arn't sure if you are goint to click Yes or No. One could say that there will be less cognitive load using verbs rather than yes/no. – Benny Skogberg Feb 22 '13 at 9:52
Yes Benny, I was exactly thinking about that cases! I saved a screenshot of Windows7 copy file dialog as an example of the case when one needs only one bit of information but it's hidden into a big set of irrelevant data. – Juan Lanus Feb 22 '13 at 21:26

Prompts or dialogues where 'Ok' is an option are basically asking for the user's acknowledgement that they have received and understood the action they just made or the message in the prompt/dialogue.

You could say by clicking the 'Ok', the user is 'Okaying' (hypothetical verb) when they click Ok. Or every 'Ok' could be changed to 'Acknowledge', though I can't see that happened for a number of reasons I won't get into here.

Also consider that prompts could be asking whether it is 'Ok' for the user to let something happen. In those instances, the button text should read as the action of the action they're permitting. E.g.

Would you like to search for this file?

Ok | Cancel

Should be

Would you like to search for this file?

Search | Cancel

share|improve this answer
+1 I like the distinction of Search/Cancel vs. OK/Cancel. – Benny Skogberg Feb 22 '13 at 9:53

I would say it depends on the action of the button. When you are dealing with Calls to Action (CTA's) your primary emphasis is on communicating an action to an user as highlighted by this article about writing effective CTA's which has this to say :


By not including a verb in the CTA copy, you aren't prompting readers to take action, which can hurt the click-through rate of your call-to-action and negatively impact conversions.

enter image description here


I also recommend looking at this article for additional inputs on why CTA's should be direct and should start with a verb

Be Direct: Your website is not the place to beat around the bush. It is imperative that you let your visitors know exactly what you do and exactly what you would like them to do. Visitors shouldn’t have to think about what to do next; be clear with your directives: “sign up,” “download,” “submit,” “get started.”

Be Demanding: Your CTA should always have an action (duh). But make sure your action is short, simple and strong, to the point of being demanding. Say exactly what you want the potential customer to do: “download,” “watch,” “buy.” Avoid weak words that every other website out there is using, such as “click,” “get,” “see” or “try.”

However if you are dealing with buttons which are just affirmative in nature, then this is what microsoft has to say :


Exception: The following standard labels are acceptable without verbs: Advanced, Back, Details, Forward, Less, More, New, Next, No, OK, Options, Previous, Properties, Settings, and Yes.

share|improve this answer

I can think of various classes of buttons:

  • Action buttons: Tell the system to perform a function. These should generally start with a verb (Search, build, etc)
  • Communication buttons: Communicate something to the system, usually based on a question to the user. These take the form of an dialogue style answer or statement (OK, Yes, No, I agree, I don't understand)
  • Navigation buttons: Don't tell the system to do anything, but navigate through a workflow, information system, etc. These don't have labels that have a distinct syntactic class. (Next, Previous, Back)

I'm sure this isn't comprehensive, and I'm sure there are buttons that fall between categories. Rules like these are pointless if you follow them thoughtlessly, and they really shouldn't be communicated as rules. I would frame it as a good practice:

"When designing a button, consider using a verb at the start of the label. Often, this is the best option. Do this everywhere and your buttons will communicate their effect clearly and be brief, consistent and emphatic."

share|improve this answer
I would probably disagree with your 3rd bullet point. Navigation should be done with links, not buttons. If you're navigating using buttons then something is probably amiss. Progressing to the next step in a set process is OK as a button because you're submitting the first step to the process, but not just straight navigation though. – JonW Feb 21 '13 at 16:08
I would agree in many cases and contexts. On the web a link is almost always the way to go for straight navigation, but even there, you may legitimately prefer a button. One example is a website that has one to three primary use cases that they want to give almost all attention on the home page (download, contact, tell me more). Links are small, difficult to click and have a limit to the amount of attention they can grab. Buttons have a nice metaphor, good affordance, and can be made both big and pretty. – Peter Feb 21 '13 at 16:15
I think there's a gradient between things that have to be a button and things that have to be a link. A wizard is still performing actions in a way, but a troubleshooter is navigating. At the end of the day, these are just ad hoc standards, with rule-of-thumb best practices. There will always be exceptions. – Peter Feb 21 '13 at 16:19

While labeling buttons (and hyperlinks), we should be mindful of the fact that first word of the label is our starting point. This initial word should be good enough to give you "some" understanding.

Look at this aspect. Press Ctrl + Alt + Delete (on windows 7) and look at the list of options.

  • Lock this computer
  • Switch User
  • Log off
  • Change a password
  • Start Task Manager

Coming towards the last option "Start Task Manager", You are supposed to "read" whole "Start Task Manager" to know this was about Task Manager but for all other option, you merely look at the first word and that is enough to convey the meanings. (Although "Change a Password" is yet another option which requires more reading but it should have been "Change Password" instead of "Change a password".)

What if we had to introduce few more Actions and if we follow ACTIONS ALWAYS approach then see how those would look like.

  • Launch Control Panel
  • View Fonts Folder
  • Start a Private Browsing session
  • Set Folder options

This is laborious to look at and you have to read whole darn line get the concept. Even though use of "actions" before a command makes the understanding better, this is at the cost of visual scanning.

Use of Actions also kill the idea of other possible actions which a user could perform. For example when I say "Set folder options" then does that mean I would have to modify or specify and I cannot just "view" or "see"? If an action as simple as clicking of a link requires implicit "ACTION" explanation then action may itself lead to new controversies and series of thoughts.


  • not to make it a rule that action must appear before every link. Use them for features which are less common and perform something important.

  • We read left-to-right and the first words are always more important than what follows them. Use first words wisely.

  • Links which are commonly used are well-understood and "Launching Control panel" may easily be replaced with "Control Panel".

  • Twitter sells actions more doesn't mean I need actions on my Honda Accord! Whenever looking at content, never overlook its context.

share|improve this answer

While the primary call-to-action button should be a verb, there are other situations where instead of a verb, you catch the user's feelings. Consider these buttons:

enter image description here

This would work well in situations where the intended audience might not be using email on a daily basis. So a blanket ban on non-verb button titles won't work in every situation.

share|improve this answer

It's not an unreasonable guideline, but not universally true that you need to explicitly state the action as a verb. At times, the verb describing the action is implicit but understandable what action is intended because of the context. For example, if navigating, the button labels could be Previous or Next (users know the buttons mean "Go To Previous" etc.) if searching, buttons could be labeled Basic or Advanced. Depends on context. Dismiss or confirm actions such as OK or Done would be other exceptions.

A general guideline is here:

share|improve this answer

Your Answer


