Buttons

Buttons are crucial when it comes to copy for two reasons. First, they are one of the main ways in which users interact with the product. Whenever a button is pressed, something will happen. Second, buttons are among the most space-limited elements in the UI, which means that button copy needs to be extremely sharp. With this in mind, buttons on Tradeshift need to have two specific qualities: they need to be collectively consistent, and individually descriptive. What does this mean?

Collectively consistent

It is essential that the user can recognize buttons as such. This is in large part made true through visual design – there’s a very limited and well defined set of possibilities for how buttons should look. However, this can also be strengthened by button copy being consistent in terms of how it relates to its context. We achieve this through the following rules:

1. The button that begins the flow must work together with the one that ends it to make the flow a self-contained unit. All actions on Tradeshift that result in flows that require more than one step have two buttons that act as "gates" – one to initialize the flow, and one to finalize it. The copy on these two buttons should be written with this in mind. As a general rule, if the opening button contains an action ‘Reject document’, then the same verb should be present in the finalizing button. On the other hand, buttons that do not include an action (for example, "Settings"), can have a more generic finalizer, such as "Done".
2. If a button results in the opening of a new page, or a picker, the title of said page or picker must be consistent with the name of the button. So a button that reads “Reject connection request” should not lead to a picker that reads “select value”. In very specific cases the title of the destination can read differently from the button, but in 99.9% of cases, they should read exactly the same.

Individually descriptive

Whilst we want buttons to be consistent in how they relate to their context, we also want them to be tailored to this context. This means that as a general rule, we do not want generic, nondescript buttons that read ‘proceed’, ‘continue’, ‘done’, or ‘back’. Rather, the copy on a button should be as descriptive as possible in terms of what the button will achieve (of course, within the length restraints implied). Following the rule of thumb from the principle above, if the button is related to an action, then always use the verb in the button. Furthermore, if the verb is an action that can have multiple logical objects, then include the object as well (for example, ‘Reject’ can refer to documents, connections, and potentially more, so describe what is being rejected).