User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I'm not a fan with long labels for buttons. Despite knowing the need to be explicit, I feel that this sometimes actually causes more confusion for the users.
Would love to know the UX benefits/drawbacks of having buttons with long text labels or multiple verbs (like Save and Close, Save and Exit, etc.).
Even better if there is any research material about the subject matter?
There is a factor that affects the choice of button's label - application's posture. According to A. Cooper "About Face 3. The Essentials of Interaction Design":
... applications fit into four categories of posture: sovereign, transient, and daemonic...Programs that monopolize users’ attention for long periods of time are sovereign posture applications.
He cited as examples of sovereign applications word processors, spreadsheets, and e-mail applications.
A product with a transient posture comes and goes, presenting a single function with a constrained set of accompanying controls.The application is invoked when needed, appears, performs its job, and then quickly leaves, letting the user continue her normal activity, usually with a sovereign application.
And now regarding button's labels:
Transient applications should have instructions built into their surface. The user may only see the application once a month and will likely forget the meanings and implications of the choices presented. Instead of a button captioned Setup, it’s better to make the button large enough to caption it “Set up user preferences.” The verb/object construction results in a more easily comprehensible interface, and the results of clicking the button are more predictable.
So, as you see, sometimes it's better to label a button with more clear and precise text but of course within a reasonable length. Using verb/object construction is enough. Don't put words that don't add any extra clarity.
Of course, there is an obvious principle - the button's label has to clearly explain what the button does. And the shortest way to label a button is to use the verb representing the action that performs after the button is pressed regardless of the application's posture. So, in common case, if the button performs two actions it must be labelled with two respective verbs. But I would say that there is an exception. If the second action is "exit" or "close" (like in your examples) there is a case when you don't need to say about it in the label. And this case is dialog box. Most of them have buttons like "save", "cancel", "OK", but not "save and close", "cancel and close", "OK and close". And we are all familiar with their behaviour and expect that most of the "main" buttons in a dialog box make respective action and close the dialog. I said "most of the main buttons" because here there is an exception too. I mean specific buttons like "apply" in Window's File Explorer Options dialog. But again, in common case, if it's a dialog's button you can use just "save", but if it's a button on main window use "save and close" or "save and exit" or else a user will be surprised and frustrated by the unexpected result.
Succinct and a focus on the action being taken, I see nothing wrong in the examples you have given, the one change we made from a usability point of view is to call out the primary action and make the secondary action have slightly less focus, this may not work in your scenario, but it's worth a look:
download bmml source – Wireframes created with Balsamiq Mockups
the button label examples you have mentioned here seem absolutely fine. As long as the label reads what clicking or tapping on a button is going to result in, there should not be any harm. Regarding the number of words, as a rule of thumb, I would keep it up to three and not more than that. The downside I see for longer labels is more time needed by the user to scan and comprehend. Also, sometimes visual design could be a challenge using buttons with long labels.
I would use a "close" button before showing a "do you want to save changes before closing?" modal, when the user has unsaved changes when closing. This way I would get rid of a big close button, which would steal the eyes of the user from what should be emphasized on the page, because the close button should be searched when the user needs it, not attract the user at first look, of course in my opinion. I'm not an UX professional, I'm just a regular user who also designs user interfaces.
