In our daily lives we are affected by the wording and labels we are exposed to. Just have a Google for labeling mistakes and the number of stories returned is quite frightening. These can range from simply not presenting key information but can go so far as creating an almost global frame of mind that dictates future actions or perceptions about an entire topic such as war.

Likewise, interface design is hugely affected by the labels we give to elements of the UI or the documentation we provide. We have technical authors at Red Gate who review our designs and every string in the interface is carefully selected and reviewed before a release. When it comes to websites the same rule applies but how carefully do we really review or test the wording we use on web pages? Some labels are standardized across the web and and in almost all cases shouldn’t be deviated from.

Recently an A/B test was run on the wording of the download button on the Firefox website. This simple example demonstrated an effect which we have seen before where a button performing the exact same action (linking to a particular section of the website), had its wording changed to a stronger call of action which appeared to change the mindset of the user and led to higher conversions with exactly the same conditions.

How carefully do we really think about each label on a webpage given what a large effect it can have? When a user lands on a product page they often want to be immediately pointed in a particular direction. Not only the design of the site comes into play here but the clear wording and signals we use. How strong are your calls to action and how many visitors are you losing as a result of your choice of labels? If you aren’t sure then it’s time to review your calls to action and test alternatives to find out. You may be surprised… or even shocked.


  • Admin

    A great example of how strong calls to action can affect click or response rates:

  • Brian

    Excellent blog post. It’s long overdue that the same attention is given to choosing the words we use on our web pages as is paid to the text in our application interfaces. Even though the objectives may be slightly different (in our programs, we’re aiming for clarity and simplicity, whereas on our web pages we want to entice, pique interest and encourage further browsing or downloads) the requirement for attention to detail on every single word is the same. It’s often the simplest, most innocuous looking text that has been given the most time and care.

Related posts

Customer-Specific Database Deployments


A question that we often get asked is how to deploy specific variations of a database to different customers. Or how to deploy different static configuration data to each customer, and how to version control, test and deploy this per customer in an automated way.

In the post below I’m going to run through an example scenario on how to to achieve customer-specific database deployments using SQL Source Control, SQL CI and the Red Gate Team City Plugin and Octopus Deploy with Redgate SQL Release.

Release Wednesdays: Deliberate, Frequent Releases


The team I work with release every Wednesday.

Why? Well, we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. We’ve believe in keeping the delta between releases small and the risk associated with an individual release low. We think practice makes perfect and that the more often you release the less frightening it is to do so.

Moreover, we want to be deliberate about releasing frequently, rather than opportunist. An opportunist frequent release process is one where you are able to deploy a given code change reliably and with little overhead, but that you choose to do this when the opportunity arises. That could be when you’ve just fixed a bug, when a feature has been completed or perhaps when ‘all the planets align’ and all your automated tests have finally passed.