User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My organization is implementing a tagging system to assign meta-data to incoming emails.

The goal is to extract a more diverse range of information which in turn allows us to analyze trends & issues. I'm having problems putting together a vocabulary that is both broad enough to cover each possible scenario and that the user knows when it should be used.

Does anybody have any tips or suggestions?

share|improve this question
How did this project go? Sounds super interesting! – Oliver Jan 1 '13 at 19:48

If you are putting together a tagbase yourself you run the risk of infecting the content with your own personal perspective of what should and should not be tagged, whereas the intention of tags is for them to act as the users' own interpretation of what is meaningful to them.

Depending on the role of a person within the company, different people will be interested in different sets of tags - whether for marketing, technical, hr, sales, management, etc. My bet is that if you asked people to assign tags to the same bulk of prior mail you will get different sets of tags from each role, let alone the differential between the actual incoming mail that is assigned to each person.

I think it will be very hard to correctly initialize a valid static tagbase, without allowing it to evolve naturally. You might want want to consider a data-collection phase whereby for some period of time, people at the company each determine the tags that they would use on their incoming mail and then feed this back into your process, thus getting real users input on real data to instantiate the tagbase for the implementation phase. You might learn something interesting in the process too about what users actually understand about tags and how they use (or expect to use) them.

share|improve this answer
In fact, you might say that the point of a tag-based folksonomy is to allow everyone to represent data in their own way, and let the most common representations bubble to the top just because they're used more often. If you only allow a predefined set of labels, perhaps what you're looking for is "categories", not tags. – Rahul Jun 20 '11 at 21:15

Keeping a tag set consistent over time is difficult for one tagger (e.g. blogs) and even more difficult for groups of people. (Look at any SE site, for instance.) So whatever your initial tag set, you should plan for tags to be refactored, renamed, and removed as the group reaches consensus or needs change.

If you plan for retagging from the start, then you can begin with coarse tags and refine over time. Do you (and your taggers) understand what the major "buckets" are? If you all independently tag an existing corpus of email, do you mostly agree on the answers? If you have consensus on initial coarse tags, I recommend starting with just that and allowing your taggers to nominate additional, finer tags during the tagging process. Eventually you will reach equilibrium, but I don't think you can go straight to that state.

Edited to add: if your users currently sort their email into folders, you might learn something by examining those structures.

share|improve this answer

Tags introduce a layer of abstraction that is nice and clean but introduces two places where you can skew data:

  1. Bias in tag selection
  2. Bias in user application of the tags to the messages

Based on your desire to analyze trends & issues, ie perform statistical analysis, you might get better results by directly analyzing the text of the messages.

This probably-out-of-date SO answer discusses algorithmically pulling tags out of text sources.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.