Showing posts with label Taxonomy users. Show all posts
Showing posts with label Taxonomy users. Show all posts

Sunday, August 23, 2020

Taxonomy Terms for Different End-Users

The names of taxonomy terms need to be understood by the taxonomy’s users, and all users need to share the same understanding of what the term means. Typically, a taxonomy as two fundamental sets of users: those who tag content with the taxonomy terms and those who retrieve content with the taxonomy terms, the end-users. The taggers can usually be supported by definitions or scope notes for the terms. The end-users rarely have access to such explanatory notes for terms, and even if they did, it would be in some inconvenient collection of documentation that very few end-users would find and read. Therefore, the terms should represent concepts that should be obvious and intuitive the end-users and need no explanation. To this end, it is important to understand the users’ perspective and the terms that they would likely use to describe concepts. User research is thus an important part of taxonomy design.

Some taxonomies have two different end-users, and this is where it can get more complicated. Examples include health information whose end-users include both healthcare providers and patients or their family members; published educational content whose tagging producers are publishers, but the end-users include both students and instructors; marketplace websites who end-users include both sellers and buyers; and job search platforms whose end-users include both employers and job seekers. It is important in these cases that the different kinds of end-users have the same understanding of what a term means, but this sometimes not the case.

Example: The Problem with “Entry Level”


I recently noticed an example of a taxonomy term in the case of job search platforms (LinkedIn, Glassdoor, Indeed, etc.) that seemed to be understood differently by employers and job seekers. There are several controlled vocabularies that can be used in the “advanced” (or faceted) job search features. Job type (Full-time, Part-time, Contract, Temporary, etc.), Location, Company, Industry, and Experience Level. I took an interest in Experience Level (also called Seniority Level), because I wanted to help identify additional jobs for my daughter, who had just graduated from college. So, I selected the filter for "Entry level." The other options include Internship, Entry Level, Associate (in LinkedIn), Mid Senior Level, Director, and Executive.
Experience level options in Glassdoor, LinkedIn, and Indeed
I was dismayed to see so may jobs classified as “Entry level” requiring at least 2 years and sometimes as many as 5 years of experience. That is certainly not entry-level by the definition of a recent college graduate.

Then one day (after my daughter found a job) I noticed a job posting for a taxonomist that on LinkedIn was classified as Entry level. It required at least 2 years of experience designing and managing taxonomies. It was clearly not an entry level for fresh college graduate. This time, however, I was looking at the job differently. I was familiar with the employer, and it was clear that for the employer this was an entry-level professional position in their firm. Even though prior experience was expected, this was the most junior professional position available. So, apparently the human resources representative of the company considered it entry-level compared to other jobs they might hire for and classified it that way. It became obvious that employers and job-seekers do not use the same terms, such as “Entry level” to mean the same thing. 

How to make the term Entry level clear, short of creating a definition or scope not that the users/end-users will never read, might be to replace it with two other terms, one for Recent grad and one for Junior associate, but the exact wording may still have drawbacks and requires more research. Simplicity and elegance may have to be sacrificed for clarity. This is just one of the many trade-offs to deal with when creating taxonomies.

Thursday, October 31, 2019

Managing Tagging with a Taxonomy



A lot of work can be put into designing and creating a taxonomy, but if it’s not implemented or used properly for tagging or indexing, then that work can be wasted. As the volume of content has grown, many organizations have invested in auto-tagging/auto-categorization solutions utilizing text analytics technologies. However, there remain many situations where manual tagging is still more practical. So, support for correct and efficient manual tagging needs to be considered. This is the topic of my upcoming presentation at the Taxonomy Boot Camp conference, in Washington, DC, on November 4.



A taxonomy can be designed to support manual tagging by including alternative labels (synonyms), hierarchical and associative relationships between terms, and term notes, to guide those doing the tagging to the most appropriate terms, even if these taxonomy features are not fully available to end-users in their user interface. It may be easier to have these features available in a customized manual tagging/indexing tool than it is to make them available in the end-user application. A taxonomy has more than one set of users, and the tagging-users need the full benefits a taxonomy can offer.
It’s very important to develop a customized policy for tagging with a taxonomy, so that it is used correctly and consistently. Any policy for tagging or indexing should include both rules and recommended guidelines. Examples of policy topics include:

  • Criteria for determining topic or name relevancy for tagging
  • Depth and level of detail of tagging
  • Comprehensiveness of aspects (what, who, where, when, how, why, etc.)
  • Required term types/facets (and any dependencies)
  • Number of terms (of each type) to tag
  • Tagging of certain terms in combination (e.g.: a parent/broader term in addition to its narrower/child term)
  • Other types of metadata that must be entered

It’s often not enough to just provide people with a policy document. Some degree of training on proper tagging can be very beneficial. In a current SharePoint taxonomy project, one of the users who tags uploaded documents said to me, “The problem is that we have not been trained. We are guessing.” Policy and guidelines should initially be delivered as a presentation (live or web meeting) to allow for questions and answers.

With large volume tagging, the initial tagging should be reviewed and feedback should be provided. This is the case for both new and experienced indexers. Even experienced indexers need to become familiar with the content and learn the policies and guidelines that are particular to the organization and project. In a recent taxonomy project that involved indexing hundreds of articles by a professional indexer, even the professional indexer’s initial indexing was reviewed to make sure it was as thorough and accurate as required.

Finally, there needs to me a method of communication and feedback between those doing the tagging and the person (taxonomist) who is managing the taxonomy, which is a controlled vocabulary, after all. The taxonomist should inform those tagging of new terms and changed terms, especially if they are high-profile terms, and may also provide tips for tagging new and trending topics. Meanwhile those doing tagging need a method to contact the taxonomist to request clarifications or the addition of new terms. This could be by email, but collaboration workspaces may also work well.  While I, as a consultant, do not stay on as tagging continues, I like to be available at the start of tagging with a new taxonomy, to answer indexing questions, something I did just this past month on my most recent consulting project.



Sunday, December 11, 2016

Use Cases for Taxonomy Development

Developing use cases in the initial design of a taxonomy is something I did not learn about until I went into consulting, but it is a useful approach to taxonomy and metadata design in any circumstance, regardless of the involvement of an external taxonomy consultant.
The use case technique comes from the field of systems analysis, and especially software and systems engineering, but use cases are increasingly applied in the development of systems and structures for knowledge management, content management, information management, etc. Typically use cases for a taxonomy are not limited to the taxonomy alone but are for the design of all metadata and the broader information or knowledge management system. “System” means the combination of software, content, metadata/taxonomies, and users.


What is a use case?


A use case describes a scenario of how a user uses a system to accomplish a particular goal. A use case should not be confused with a case study. It need not be long and detailed, although they may vary in their descriptive length. All use cases include:
  1. A designated user type and role (sometimes called “actor”), which could be as simple as an internal organization job title. Examples of external users could be designated as: undergraduate college student, paralegal, pharmaceutical corporate librarian, experienced online shopper, etc.
  2. A task that the user is engaged in which uses the system. This will likely be described in more detail than the description of the user. Taxonomy use cases would typically involve a specific aspect of one of the following tasks: indexing/tagging, using search to find information, using browse to find information, discovering/exploring for related information and finding/retrieving certain content items
  3. A goal and perhaps ultimate purpose of the user’s task.
I had participated in a consulting project once whereby the stakeholders were advised to create use cases that went so far as identifying fictitious personas, a practice that is often done in marketing planning. I don’t think it’s necessary to go that far in taxonomy use case development, although it might be useful if there are users of the taxonomy who are external customers/clients.


Why create use cases for taxonomies and other metadata?


The task of developing taxonomies and other metadata can benefit from use cases in particular ways:
  • It grounds the taxonomy in reality, ensuring that it is designed to be usable, rather than being an academic taxonomy on a subject domain.
  • It engages the users and other stakeholders in the taxonomy development process, who then become more interested in supporting/promoting or using the taxonomy, especially when the taxonomy serves their user needs and solves their problems.
  • It provides sample situations which can then be utilized for testing the draft taxonomy before the taxonomy and content are fully implemented in the system. As a taxonomist who has led taxonomy testing activities among sample users, I have personally found used cases to be valuable for this purpose. 


What are examples of use cases for taxonomies and other metadata?


The following brief fictitious use case examples are of the kind that could be used for taxonomy development.


Internal organization use cases:

  • A subject-matter-expert author who is required to tag authored documents with subject categories so that users can find documents by subject.
  • A digital asset manager in an advertising agency, who needs to ensure that image files are assigned the proper copyright information.
  • A content manager at a publishing company who, as a major responsibility, needs to assign full metadata to XML file content for various downstream purposes to assembly digital content products.
  • A marketing copywriter seeking an expert on a specific subject among a company’s employees to give feedback on the accuracy of a blog post the copywriter is writing and who is inclined to browse subjects if available. 
  • A manager who wants to find historical information on product offered in order to prepare a presentation about the product.
  • A digital marketer who needs to update the public website with seasonal images that were not used last year (but two years ago is OK).
External/customer use cases:
  • An undergraduate student who uses the default search to look for information on the events leading up to the fall of the Berlin Wall for a history class paper.
  • An experienced online shopper who is searching to purchase carry-on luggage and wants to filter results by price, color, and positive reviews.
  • A corporate librarian conducting competitive intelligence research on market strategies of leading competitor companies in the same industry and who would like to use advance and/or Boolean searching, if possible.
  • A lawyer specialized in commercial law who need to find out where and how to file a financing statement in the proper jurisdiction for a client of his who to secure a loan, but lacks experience in legal research.
  • A cancer patient searching for an oncologist with a certain type of cancer specialty, acceptance of certain insurance, within a certain geographic region, and with a number of good patient reviews.
  • A compliance officer who needs to find regulations and associated policies and procedures that pertain to various departments and products lines of his employer, who knows the names of statutes but not the titles of associated regulations.

How are taxonomy use cases utilized?


In addition to serving the purposes of engaging stakeholders and ensuring the taxonomy is content- and user-focused, use cases can have additional specific applications, such as:

  • Identifying or validating who all the different types of users are, so that their issues and feedback can be taken into consideration in the future.
  • Suggesting improvements in the user interface design.
  • Developing walk-through scenarios, with specific search criteria or topics of browsing spelled out, for offline testing of the taxonomy usability (including adequate depth and breadth) for both indexing/tagging and retrieval. (Read more at the post "Testing Taxonomies.")
  • Providing scenarios that can be used in other taxonomy/knowledge management project research, such as ROI (return on investment) research.

Friday, October 19, 2012

Taxonomies for Multiple Kinds of Users



This week, I again attended the annual Taxonomy Boot Camp conference held in Washington, DC, the only conference dedicated to taxonomies. The main theme I came away with this year is that taxonomies serve diverse audiences and users.

The theme of different users was best exemplified in a session dedicate to comparing taxonomies for internal and external use. Representatives from Johnson Space Center (JSC), Astra-Zeneca, the Associated Press (AP), and Sears gave examples in panel “Representing Internal and External Taxonomy Requirements in a Taxonomy Model,” moderated by Gary Carlson. While still remaining connected, internal and external taxonomies not only have different terms for the same concept but they may also have different structure. According to Joel Summerlin of AP, internal taxonomies can be more specialized and complex than external taxonomies, and internal taxonomies need to support greater precision in retrieval results, whereas external taxonomies need to support greater recall.

Even within either the internal or external users of a taxonomy, there is great variety. But unlike the situation of internal and external taxonomies, where you can have different taxonomies linked together, you will have a single taxonomy serving a diverse audience. The use of taxonomy features of polyhierarchy and nonpreferred (aka synonym) terms can help diverse users with different vocabularies, perspectives, and approaches find their way to the desired content.

In the session on internal and external taxonomies, the diversity of internal users was mentioned by Sarah Berndt as a characteristic of JSC. In another session, Helen Clegg described the process of building an enterprise taxonomy at the consulting firm AT Kearney, which has employees in different countries and in different industry specialties. As for external users, Jenny Benevento of Sears described how the customers of its retail website range widely, from repeat shoppers of clothing to those making one-time purchases of engagement rings to those buying large appliances. From the audience, Paula McCoy of ProQuest commented on the importance of knowing, before planning the indexing, who the users are of its different database products.

Other sessions, such as “Taxonomy & Information Architecture,” also addressed the multiple uses and users of taxonomies. Panelist Gary Carlson explained how different personas are used in designing websites, and that the kinds of things that the user-persona seeks or needs can then become taxonomies or facets.
Overall in various sessions of the conference there was a great diversity of taxonomy types, and thus taxonomy users, described. These included:
  • Enterprise taxonomies for internal users, with a set of three presentations under the title of “Enterprise Taxonomies in Action”
  • Public web site taxonomies, as in the case study example of the Consumer Products Safety Commission and additional examples from in the keynote.
  • Retail ecommerce taxonomies, as in the example of Sears and additional mentions of Target and REI in other presentations.
  • Taxonomies used in for article indexing and then retrieval by library patrons of periodical/reference databases, as described in a presentation about Proquest.

Not only may the same taxonomy be targeted at different users at once, but also different users over time. In the closing keynote, Patrick Lamb observed that taxonomies can further add value when we make them available for re-use.

Finally, the conference itself attracted a diverse audience: taxonomists, information architects, data warehouse managers, search specialists, knowledge managers, and others; those from corporations in all industries, government, and nonprofits; and those both new to and experienced with taxonomies. In fact, it’s rare that you would find such a diverse audience at a professional conference. They are united in their need to make information findable, and they understand the value of taxonomies to make that happen.