Forget Hashtags for a Moment: Most Sites Still Aren’t Taking Advantage of ANY Tag Functionality…

…and this is a huge missed opportunity in a world where we need help with overwhelming choice and information overload!


I believe tags are one of the best and most versatile ideas in helping software, humans, and information all get along nicely. We are all familiar with tags in lots of contexts, but it is staggering how underused the idea is by software and website designers.

Anything involving a lot of items, products, or choice can be improved a lot, from a human usability point of view, by smart implementation of tags. Music, book, and film discovery… hotel and holiday catalogues… fashion and online shops for every type of product… the places where implementing tag functionalities would improve our experience seem to be everywhere, yet good examples are few and far between.

In this article I hope to provide some theoretical food for thought for those who are not sure what the correct place of tags are in software, and use some examples to illustrate the good sense of using them.

Whatever your website or software, I think there is likely no good reason why you should not to be developing extensive tag functionality for your users.


Let’s begin with a back-to-basics explanation of where tags fit in to helping humans work with data.

When you wish to access, read, interpret, and work with sets of data, such as customer lists, products in an online shop, mp3s, books in a library catalogue, or flight options, you will approach this task with a combination of three methods: 1 — Browse; 2 — Search; and 3 — (what I call) Result Focusing.

Browse means you wade straight into information but are highly likely to make use of a step-by-step tree/branch approach, using taxonomy (usually the officially presented categories) to reduce the full list of data entries down to a narrow enough group that ought to match your interest. For example “shoe shop -> men’s -> formal wear” or “customer list -> Germany -> Berlin”. Despite the obvious inefficiency, this is still the way most people use ecommerce sites, possibly because the implementation of search is so often horrid.

Search means you try to go directly to your “narrow enough group” or even single item within one step, using a simple (or maybe more advanced) query. For example “show me matches for the query black oxfords” or “show me all customers where customer address city field equals Berlin”.

Browse and Search are fairly obvious and established, but we rarely stop with the results we attain using these initial tactics.

I have named the third term Result Focusing to encompass (from a human point of view) the various related work we do to improve the usefulness of what we initially got from browsing or searching. It is “result” because you have to start with something, and the metaphor “focusing” because you are trying to make something clear but it could be various focal lengths or depths of field within your result set, and it may involve a bit of back-and-forth until you see what you want (twisting the focus dial).

Result focusing could include: sorting; searching within results; adjusting parameters of the original search or browsing; adding up similar class parameters in an AND and OR logic; or adding parameters from new dimensions.

Examples of Result Focusing

Sorting: shoes — “black leather shoes, price lowest to highest” customers — “customers in Berlin most recently added first”

Searching within results: shoes — “black leather shoes Church’s” customers — “customers in Berlin called Smith”

Adjusting parameters: shoes — “ah, not just black oxfords but all black leather shoes” customers — “what about customers whose city field says Potsdam instead of Berlin”

Adding up similar class parameters: shoes — “black leather shoes in office OR formal categories” customers — “customers whose address contains Potsdam or Berlin”

Adding parameters from new dimensions: shoes — “black oxfords which are on sale” customers — “customers from Berlin who have logged in in the last 90 days”

Your site/software should provide good functionality for all of the above (and mixtures of them) before we even get on to tagging…

A Usability Universal

In normal user behaviour it is easier to begin with simple broad browsing or searching and then follow on with result focusing based on what they see in the intermediate results, than front-loading all of the query options and dimensions in the initial search or browse. Seeing the intermediate results is likely to help the user understand and guess how to employ the result focusing options. That is a universal usability principle to take note of.

Humans improvise and software should recognise and help that

What we can already see here is a wide range of possible “wetware algorithmic approaches” that humans will take towards working with data sets, and flexibly use them in sequences and combinations that they (on the fly) guess will get them usable information efficiently, even if actually their behaviour is often characterised by trial and error, overlooking better methods, or even irrational preference for particular tactics. The design and usability of the software will interact with the user’s skill level and current activity to complicate the picture further. Furthermore, one person’s concept of efficiency and usability in the software will be quite different to another person’s, particularly based on skill level. (Just ask a user of emacs or vi.)

It is in this context that we look at tags: a data structure hack with a layer of software usability, designed with an eye to target users’ likely behaviour and needs. An effective implementation of tags on the one hand adds a new option of access to data somewhere between Searching and Browsing, and on the other hand adds a powerful tool to the user’s Result Focusing activity.

The primary characteristic of tags is that they are used in a many-to-many approach. While one item can certainly be “in” more than one category, that tends not to be the our approach to categorization. On the other hand, tagging things encourages us to give all sorts of attributes to an item, choosing attributes which we assume will be shared by other items and thus help us relate them in many different combinations.

A second characteristic of tags is that they are part-way to being a restricted array of possible values. Any implementation of tags is about using a field which has a finite number of fixed values but where (a) the taxonomic meaning of the field may be very loose or deliberately multidimensional*, (b) the choice of fixed values may be added to over time, and (c) the allowable data for any value may still be restricted according to its utility in the expected usage.

In this sense we could say that any data field which is intended to be used for search or interrelation of items is a “tag” if (i) the users can add “possible values” to it, and (ii) there are no rules about which item must have what combination (if any) of values, but (iii)the range of values and the usage of the field tends to standardise the values used.

*Deliberately multidimensional means that a tag can be different conceptual things, without straining the user to work through lists of choices (or guess search variables) under a logical conceptual framework.

So a product description writer can tag the shoes “office” “black” “black leather” “leather” “mens” “formal” “oxfords” and so on. Then the user taking a tag-based approach could ask for “office + black leather + mens” without having to work through categories “mens -> office” in any order, and (compared to searching) being able to match products which are in the material black leather and in the category of office wear, without the exact words “black leather” or “office” necessarily appearing in any of the product’s own description data fields.

It also obviously means you can dynamically offer pseudo category pages of “office shoes” or “formal black leather shoes”… or rather you are allowing your users the beginning of the ability to create personalized ways to sift through your listings. This applies to any data set, not just ecommerce. Why try to predict all of the possible logical and programmatic ways of listing out the data when you can let your users contribute to human ways as they go along.

A tag may have a deliberately different meaning than the literal expectations of a field-specific query. For example for our customer query we might search or filter with the tag “Berlin” to mean customers who are within the sales region of Berlin, not necessarily actually having that city in their address. Or we could construct deliberate meanings informally within “deliberately multidimensional” tags without having to create formal data fields, e.g. on the fly we could start using the tag “Trade Fair” to mean customers whose original contact was at any trade fair, without at all being obliged to apply that tag or any other “where did the contact come from” data to any other entries. Then we could combine those informally created fields to query “Trade Fair” + “Berlin” to access a list of customer in the Berlin sales region whose original contact was at the trade fair… something that would be hard to replicate in normal searching and browsing, and something which would require serious study and database/software modification to implement formally, let alone to match the requirements of adding new possibilities e.g. “Trade Fair 2014" (the practical meaning of which could be decided by the user without any reference to any technicians or any other data).

The main point of hashtags is to aid discovery by avoiding the situation of having variations of natural words for one entity create many different (and messy) search results for that entity. The addition of the hash # deliberately creates a unique non-dictionary term to which the users collectively assign a clearer scope of meaning, because only the items they deliberately hashtag will be included in the search results for that unique term. It is a kind of bookmarking system that is flexible across different software because it requires no new functionality, just normal behaviour of search engines. Read more from me about hashtags here.

Tag Implementation Examples on the Web

Let’s look at some examples of ways tags are used in real situations and then at the end come back to a discussion of what makes a good and bad implementation.

The “labels” for conversations in Gmail are simply tags but masquerade as categories because of label links appearing as if they are directories/folders in the left sidebar navigation.

The price comparison site Nextag has product-category-dependent attributes that are clearly created in the back end as a tag system using loose conceptual groups.

The Prepper Journal (a blog) doesn’t really have good categories but this is not much of a problem when the content is (a) all roughly on one theme, (b) not usually time-related (evergreen), and (c) readers are likely to dive into specialisms instead of broader themes. So extensive tagging solves this nicely.

The tag pseudo-category page for Prepper Journal also shows us a good us of tags to interrelate multi-part blog posts (pt4… pt5)

The now-apparently-maligned frequency-size-weighted “tag cloud” offers tags as a usable alternative to category navivation. This example from the support section of

Blog posts can employ tags as a way of helping connect related articles as “further reading”. This example is from and is a good example of “non scarcity thinking” about tags — more is better!

This example from Longreads nicely illustrates the flexibility of offering links to other posts by the same author, in a very broad category “travel”, or theme similarities like “friendship”, as well as tagging it “exclusive”. It is a good illustration too of the way that tags can reasonably overlap with normal navigation functions (as there is of course also a formal “travel” category and a formal author link). In the case of Longreads, as the name suggests it is a very long page and so the tags are somewhat wasted only being at the footer of a post instead of at the top or in a sidebar.

Of course tagging for discovery in both directions (item<->list) commonly uses the hashtag as a way to encourage and focus tagging. The Google+ implementation is straightforward and helpful…

… with a good twist of showing related tags on the tag browse page.

Instagram tagging provides excellent examples of crowd-sourced interrelation leading to great discovery value.

At Naked Wines the products are tagged using standard but quite loose type descriptors — “Merlot” and “Rich and Smooth”. In my view they should go further than the limited implementation, given all the abstract ways people describe and compare wines, and their approach seems a little dubious in the sense of linking to a search-within-description results page instead of a clean tag metaphor. But points for daring.

The fashion site Lookbook does a good job of relating looks together with wonderfully vague and conceptually heterogenous tags. However, this navigation is in a very demoted place on the page and so the usefulness is not obviously that believed-in! Clothes ecommerce sites are mad not to be tagging with vague/subjective style words like this.

In the content curation tool Swayy you choose which topics to subscribe to: obviously there are thousands of possible (fixed) topics so you cannot select from a list: enter the tag!

As expected, the use of the tag approach means that you can select “categories” by tying and getting suggestions, as well as suggesting new topics (halfway to the full tagging approach of letting the user create tags freely).

The Asos “Buy the look” popup, offering a whole outfit to match one clothing item, surely in the back end works on a tagging system.

Kershaw knives has a very strong relevance in their “related products” leading one to imagine a manual tagging job in the back end of the product descriptions.

At Slashdot, the “category” of posts is always a parody of a category, making a humorous comment on the article itself. This means that the interrelation of “you may also like to read” suggested posts can’t be from a category and is likely from some hidden tagging.

The way that software makes use of tags easy and usable is important: here in the Wordpress post editor, beginning to type a tag immediately starts offering suggestions based on existing tags. Good tag implementations reinforce the use of tags.

The same Wordpress editor also has an entire menu to choose from. It’s not clear how useful this will be with a lot of tags, though.

An annoyance of the Wordpress tag system is that it apparently cares about CaSe and therefore you can have duplicate tags just because of different capitalization. This, in my view, works against one of the key principles of tags, which is to assist the user to standardize.

The “Don’ts” of tag implementations

The above Wordpress example leads me to show some bad examples, which also help us to consider the correct ways to employ tag functionality.

Here is another example from the excellent Kershaw ecommerce site. The design is cool and usability OK, but considering the staggering array of attributes which the user can use to filter down a custom browse list of knives… surely a free-typing tag approach would be a good alternative to offer customers? Their search does not “interpret” tag-like words such as “large” or “black” so there is a usability weakness here considering the huge list of very similar products for users to look through.

This is one of my personal bugbears. When you post a job on Odesk you tag it according to the skills you require from the freelancer, which in turn helps freelancers Result Focus when searching for gigs. Unfortunately, for some reason known only to an obstinate programmer, the tags are so ultra standardized they do not allow any spaces or any natural language variations. Stupid x2.

This current “functionality” of Pinterest is so horrible that I can only call their designers idiots. When you submit a multi-word search, those individual words get visually clumped in a style which imitates tags. They are aiming, I guess, for some sort of AI that recognises phrases and entities, but it does not work properly. The result is one enormous troll against usability.

This example, somewhat surprisingly from Google’s guru Avinash Kaushik, shows a mess of placing a blog post into multiple categories, and then tagging it with several pretty category-like tags. It’s muddled and not useful for the user, and the formatting and layout don’t help either.

At Fontsquirrel the categories are presented in exactly the same way as tags, and apparently the taxonomic approach to creating categories isn’t much different to tags. The result is that neither are useful for users.

Newegg product descriptions are already notoriously lazy, but here you have a big missed chance to help connect related products together: the simplified description lists attributes but these are not linked to anything: if they just used tags instead it would at least help people hop between similar products, unlike their difficult to use categories. Tell me how else I am supposed to browse more Casual Bulova watches?

A similar example of a missed opportunity at wine seller Laithwaite’s: they have a table-styled list of standard attributes but these don’t link anywhere: as above, please tell me how then I am supposed to look through other “White Blend” wines?

It is not really that clear how Youtube uses those tags that you put in when uploading a video. Certainly not in any nice front-end way to let users hop from video to video: they only want to use their AI for the recommendation engine (which as Google folk would assume, knows better than humans). But apparently we are helping this algorithm by contributing freebase-style entities into their tags instead of just normal language tags. This is frustrating for the user and overall unclear what the point of bothering with it is.

Facebook encourages us to “tag” a photo… oh, except they don’t actually mean tag, they mean identify people in the photo, as a way to create annoying notifications “George tagged you in a photo!” etc. This is not tagging and it sucks that Facebook, which can pretty much make up the rules of the internet for a lot of people, abuses the term in this way. (Btw uploading crowd photos is a good way to troll Facebook’s algorithms…)


Let’s try to keep this simple. We can say the following about good tagging implementations:

  1. The implementation helps the users deal with information, often opening up completely new and much better ways to navigate and consume;
  2. The common concepts of tagging are respected — see above notes about many-to-many, restricted array, user-defined, and deliberately multidimensional;
  3. The details of the functionality and usability in practice support the intended use case for tags;
  4. The intended use of the tags is equivalent between the taggers and the users, if in fact they are not the same user, and mutually agreed, even if only implicitly;
  5. Since the implementation of tagging is useful, well-understood, and relates to shared needs of the users, the presentation of the tagging functions is prominent and shares similar levels of priority with other browse, search, and result focusing functions.

To end, I iterate the question for your own sites and software: are there really any reasons for you not to be implementing tagging processes and functionality as a major part of helping your users do what they want to do?

Thank you for reading a Digital Marketing theory article by George Baily

Disseminating GeorgeThought™, Enlightening The Vast Hordes Of The Benighted

Disseminating GeorgeThought™, Enlightening The Vast Hordes Of The Benighted