Author: Michael Andrews

Categories
Content Engineering

Lumping and Splitting in Taxonomy

Creating a taxonomy — noting which distinctions matter — often seems more art than science.  I’ve been interested in how to think about taxonomy more globally, instead of looking at it as a case-by-case judgment call.  Part of my interest here is a spin off from my interest of birding.  I’m no ornithologist, but I try to learn what I can about the nature of birds.  And species of birds, of course, are classified according to a taxonomy.  

The taxonomy for birds is among the most rigorous out there.  It is debated and litigated, sometimes over decades.  The process involves a progression of “lumps” and “splits” that recalibrate which distinctions are considered significant.  Recently the taxonomy underwent a major revision that reordered the kingdom of birds. 

In the mid-2010s, scientists changed the classification of birds to consider not only anatomical features, but DNA.  In the new ordering, eagles and falcons are not as closely related as was previously assumed. Eagles are closer to vultures, while falcons are closer to parrots.  And pigeons and flamingos are more closely related than thought previously.  Appearance alone is not enough on which to base similarity.

More closely related than you might think (Both produce milk to feed their young)

Taxonomy and Information Technology

Taxonomy doesn’t receive the attention it deserves in the IT world.  It seems subjective: vague, hard to predict, potentially the source of arguments.  Taxonomy resembles content: it may be necessary, but it is something to work around — “place taxonomy here when ready.”

But taxonomy can’t be avoided. Even though semantic technologies are becoming richer in describing the characteristics of entities, the properties of entities alone may not be enough to distinguish between types of entities.  Many entities share common properties, and even common values, so it becomes important to be able to indicate what type of entity something is.  We can describe something in terms of its physical properties such as weight, height, color and so on, and still have no idea what it is we are describing.  It can resemble the parlor game of twenty questions: a prolonged discourse that’s prone to howlers.

Classification is the bedrock of algorithms: they drive automated decisions.  Yet taxonomies are human designed.  Taxonomies lack the superficial impartiality of machine-oriented linked data or machine learning classification.  But taxonomies are useful because of their perceived limitations. They require human attention and human judgment.  That helps make data more explainable.  

Humans decide taxonomies — even when machines provide assistance finding patterns of similarity. Users of taxonomies need to understand the basis of similarity.  No matter how experienced the taxonomist or sophisticated the text analysis, the basis of a taxonomy should be explainable and repeatable ideally.  Machine-driven clustering approaches lack these qualities.  

To be durable, a taxonomy needs a reasoned basis and justification.  Business taxonomies can borrow ideas from scientific taxonomies.   

Four approaches can us help decide how to classify categories:

  1. Homology
  2. Analogy
  3. Differentia
  4. Interoperability

Homology and analogy deal with “lumping” — finding commonality among different items.  Differentia and interoperability help define “splitting” — where to break out similar things.

Homology: Discovering shared origins

Homology is a phrase taxonomists use to describe when features, while appearing different, have a common origin and original intent.  For example, mammals have limbs, but the limb could be manifested as an arm or as a flipper.  

Homology refers to cases where things start the same but go in different directions.  It can get at the core essence of a feature: what it enables, without worrying so much how it appears or precisely what it does.  Homology is helpful to find larger categories that link together different things.

There are two ways we can use homology when creating a taxonomy. 

First, we can look at the components or features of items.  We look for what they share in common that might suggest a broader capability to pay attention to.  Lots of devices have embedded microprocessors, even though these devices play different roles in our lives.  Microprocessors provide a common set of capabilities of that even allow different kinds of items to interact with one another, such as in the case of the Internet of Things (IoT).  Homology is not limited to physical items.  Many business models get copied and modified by different industries, but they share common origins and drivers. We can speak of a class of businesses using an online subscription model, for example.

Second, we can consider whole items and how they are used.  Homology can be useful when a distinct thing has more than one use, especially when it doesn’t have a single primary purpose.  Baking soda is advertised as having many purposes and some consumers like products that contain baking soda.  Here we have a category of baking soda-derived products.  In the kitchen, there are many small appliances that have a rotator on which one can attach implements.  They may be called a food processor, a blender, a mixer, or some trademarked proprietary name.  What can they do?  Many tasks: chopping vegetables, making dough, making soups, smoothies, spreads…the list is endless.  But the most seem to be about pulverizing and mixing ingredients.  It’s a broad class of gadgets that share many capabilities, though they scatter in what they offer as they seek to differentiate themselves.

But there’s another approach to lumping things: analogy.    

Analogy: Discovering shared functions

We use analogies all the time in our daily conversation.  Taxonomists focus on what analogies reveal.  

Analogy helps identify things that are functionally similar, and might share a category as a result.

Analogy is the opposite of homology. With analogy, two things start from a different place, but produce a similar result.  For example, the wings of bees and wings of birds are analogous.  They are similar in their function, but different in their origin and details.  Analogies capture common affordances: where different things can be used in similar ways

Analogies are most useful when defining mental categories, such as devices to watch video, or places to go on a first date.  It’s the most subjective kind of taxonomy: different people need to hold similar views in order for these categories to be credible.

Contrasting homology and analogy, we can see two concepts, which represent notions of convergence (from differences to similarity) and divergence (from similarity to differences).

The other end of taxonomy is not about lumping things into broader categories, but splitting them into smaller ones.

Differentia: Defining Segments

Taxonomists talk about differentia (Latin for difference), which is broadly similar to what marketers refer to as segmentation.

Aristotle defined humans as animals capable of articulated speech. His formulation provided a structural pattern still used in taxonomy today:

  • A species equals a genus plus differentia

That is, the differences within a genus define individual species.  

To put it in more general terms: 

  • A segment is a group plus its distinguishing characteristics (its epithet)

A group gets divided into segments based on distinguishing characteristics.  The differentia separates members from other members.  

One of the most popular marketing segmentations relates to generational differences. In the United States, people born after the Second World War are segmented into 4 groups by age.  Other countries use similar segments, but it is not a universal segmentation so I will focus specifically on US nationals.  A common segmentation (with the exact years sometimes varying slightly) is:

  • Generation W (aka “Boomers”): American nationals born between 1946 and 1964
  • Generation X: American nationals born between 1965 and 1980
  • Generation Y (aka “Millennials”): American nationals born between 1981 and 1996
  • Generation Z: American nationals born since 1997

Such segmentation has the virtue of creating category segments that are comprehensive (no item is without a category) and mutually exclusive (no item belongs to more than one category).  It’s clean, though it is not necessarily correct — in the sense that the categories identify what most matters.  

Segments won’t be valuable if the distinctions on which they are based aren’t that important.  A segment could comprise things with a common characteristic that are otherwise quite diverse.  It’s possible for segment to be designed around an incidental characteristic that makes different things seem similar.

The point of differentia is to represent a defining characteristic. Differentia is valuable when it helps us think through which distinctions matter and are valid.  For example, we might segment people by eye color.  But that hardly seems an important way to segment people. Such segmentation encourages us to refine the group we are segmenting.  Eye color is of interest to makers of tinted contact lenses.  But even then, eye color is not a defining characteristic of a potential contact lens customer, even if were a relevant one.

While differentia can be hard to define durably, it can play a useful role in taxonomies.  It seems reasonable to segment aircraft according to the number of passengers they carry, for example.  It can capture one key aspect that represents many important issues.

Interoperability: Distinctions within commonality

A related issue is deciding when things are similar enough to say they are the same, and when we can say they are related but different.

Our final perspective comes from nature. The similarity of species is partly defined by their ability to mate.  Some closely related species of birds, for example, will cross breed.  Other pairs of less similar species lack that ability.  

A similar situation exists with languages.  Where are the distinctions and boundaries between similar languages? And when are differences just dialects and not actually different languages?  In language, mutual-intelligibility plays a role.  (Language also involves convergence and divergence — but we’ll consider their interoperability here).

The presence or absence of connection between distinct things is associated with two overlapping but distinct concepts: 

  1. Interoperability 
  2. Substitution

Both these concepts address ways in which distinct things might be consider the “same.”

Interoperability is most often associated with technology, though it can be applied to other areas, for example, cultural norms such as religions as well.  The presence of interoperability — the ability of distinct things to connect together easily because they follow a common standard or code of operation — is an indication of their similarity.  If things interoperate — they require no change in set up to work together — then they belong to the same “family,” even if the things come from different sources. The absence of interoperability is a sign that these things may not belong together and need to be split.   

Being part of the same family does not imply they are the same.   Any distinctions would relate to the role of each thing in the family (same family, different roles).   Things that follow the same standard may be similar (same role), or they may be complements (different roles).  

If things can be substituted — they are interchangeable but require a different set up to use — they may belong to the same category, but that category may need to be broken down further.  Windows, Linux and MacOS computers can be substituted with one another  — they serve the same role — so they belong to the broader personal computer category (same role, different families).  But they are separate categories because they don’t interoperate.

The value of taxonomies

Defining taxonomies is not easy.  Interpretation is needed to spot the differences that make a difference. We can improve the discovery process by using heuristic perspectives for lumping and splitting. 

Taxonomy is valuable because it can provide a succinct way to express the significance of an entity in relation to another entities.  Sometimes we need a quick summary to boil down the essence of a thing: what’s distinctive about it, so we can see how it relates to a given situation.  Taxonomies help us overcome the fragmentation of information.  

— Michael Andrews

Categories
Content Experience

3 Tools to Set Tangible Goals for Content

How can writers know when content is good enough to satisfy users?  Content quality should not be the subjective judgment of an individual writer, whose opinion may differ from other writers. Content teams should be able to articulate what the content needs to say to satisfy user expectations. I want to explore three tools that content designers and writers can use help them determine how well their content will meet user needs.  Unlike the straight usability testing of content, these tools provide guidance before content is created and diagnostic evaluation after the content has been made.

Good quality content helps people accomplish their tasks and realize their larger goals. To create high quality content, writers need to understand 

  1. The tasks and goals of people
  2. What knowledge and information people need to use the content
  3. Any issues that could arise that hinder people having a satisfactory outcome

Writers can understand what content needs to address by using tools that focus on the user tasks.  Three useful tools are:

  1. Users stories and Jobs-to-be-Done
  2. Behavior driven design
  3. Task analysis 

Each tool offers specific benefits.

Defining goals: User Stories and Jobs-to-be-Done

User stories and Jobs-to-be-Done (JTBD) are two common approaches to planning customer experiences.  User stories are the default way to plan agile IT.  JTBD has gained a big following in the corporate world, especially among product managers.  Content professionals may participate in projects that use these tools.

I’m not going to recap the extensive literature on user stories and JTBD, much of which isn’t focused specifically on content.  Fortunately, Sarah Richards has explored both these approaches in her book Content Design, and she’s done a great job of showing the relevance of each to the work of content professionals.  For my part I want to explore the uses and limitations of user stories and JTBD as it relates to understanding content quality.

Sarah Richards notes: “a user story is a way of pinning down what the team needs to do without telling them how to do it.”

The basic pattern of a user story is: 

  • As a X [kind of person or role], I want to Y [task] so that I can Z [activity or end goal]

The “so that” clause is both the test of success and the motivation for activity.  User stories separate intermediate goals (Y) from end goals (Z).  If the user is able to get to their next step, the goal beyond the immediate one, we assume that the content is successful.   Richards suggests breaking out the “I want to” into separate discrete tasks if the person has several things they want to do in support of a larger goal.  So, if the user wants to do two things, they should be broken into two separate stories.

JTBD or job stories are similar to user stories, except they focus on the job rather than the user.  Richards states: “Job stories are a better choice if you have only one audience to deal with.”   That’s a good point.  And sometimes everyone has the same needs.  People may belong to different segments, but everyone faces a common situation and needs a common resolution.   Everyone on a cancelled flight wants to get booked on another flight that leaves soon, whether or not they are business class or “basic economy” passengers.  

In summary, the difference between user story and job story is the introductory clause:

  • User story: As a X [persona or audience segment]
  • Job story When [a situation]

What this introductory clause tries to do is introduce some context: what people know, what issue they face, or how they are likely to think about an issue.  But the introductory clause is not precise enough to give us much detail about the context.

User and job stories are a helpful way to break down different tasks and goals that needs to bed addressed.  But it is easy to see how these frameworks are so broad that they might fail to provide specific guidance.  For example, a job story could be:

  • “When the power goes off, I want to know who to contact so that I know when the power will be back on.”  

There are several leaps that occur in this story.  We don’t know if the power outage is isolated to the customer or is widespread.  We assume that having a point of contact is what customers need, and that POC will tell the user when the power will be back on.  Even if that job is how a customer expressed their story, it doesn’t mean the building content around the story will provide the customer with a satisfactory outcome.  

User stories and JTBD are loose, even squishy.  Their vagueness provides latitude on how to address a need, but it can also introduce a degree of ambiguity in what needs to happen.  

User and job stories often include “acceptance criteria” so that teams know when they are done.  In the words of Sarah Richards: “Meeting acceptance criteria gives your team a chance to tick things off the to-do list.”  Richards warns against the dangers of acceptance criteria “that puts the solution up front.”  In other words, the acceptance criteria should avoid getting into details of how something is done, though it should indicate exactly what the user is expecting to be able to do.  

As far as I can tell, no universal format exists for writing acceptance criteria.  They may be a list of questions that the story’s writer considers important.  

But even well-written acceptance criteria will tend to be functional, rather than qualitative.  Acceptance criteria are more about whether something is done than whether it is done well.  We don’t know if it was difficult or easy for the customer to do, or whether it took a lot of time or not.  And we never know for sure if satisfying what the customer wants will enable them to do what they ultimately are looking to accomplish.   

User stories and job stories provide a starting point for thinking about content details, but by themselves these approaches don’t reveal everything a writer will want to know to help the user realize their goals.

Specifying Context: Behavior Driven Design

Behavior driven design (BDD) is used in situations where content shapes how people complete a task.  BDD provides functional specifications that indicates a concrete scenario of the before and after state.  This approach can be helpful to someone working as a product content strategist or UX writer who needs to design flows and write content supporting customer transactions.  

The New York Times is one organization that uses BBD.  Let’s look at this example they’ve published to see how it works.  It is written in the Gherkin language, a computer programming language that is easy for non programmers to read.

Description: As a customer care advocate, I want to update a customer’s credit card on file, so that the customer’s new credit card will be charged during the next billing cycle.

 Scenario:     Change credit card with a valid credit card
     Given:     I have a customer with an existing credit card.
      When:     I enter a new valid credit card number.
      Then:     The service request is processed successfully.
       And:     I can see that the customer’s new card is on file.

 Scenario:     Change credit card with an invalid credit card number
      Given:    I have a customer with an existing credit card.
      When:     I enter a new credit card number that is not valid.
      Then:     An error shows that the credit card number is not valid

As the example shows, multiple scenarios may be associated with a larger situation.  The example presents a primary user (the customer care advocate) who is interacting with another party, a customer.  This level of contingent interaction can flush out many situations that could be missed.   Publishers should never assume that all the information that customers need is readily available, or that customers will necessarily be viewing information that is relevant to their specific situation.  Publishers benefit by listing different scenarios so they understand information requirements in terms of completeness, channel or device availability, and contextual variability.  So much content now depends on where you live, who you are, your transition history, customer status, etc.  BBD can help to structure the content that needs to be presented.

Content must support customer decision making. BDD provides a framework for thinking about what information customers have and lack relating to a decision.  Let’s consider how BDD could help us think about content relating to a  a hotel room.

ScenarioSome determinable user situation
Given some precondition (user knows where they want to holiday)
And some other precondition (user knows their budget)
When some action by the user(user visits travel options page)
And some other action (user compares hotel prices)
Then some testable outcome is achieved (user compares hotel prices)
And outcome we can check happens too(user books hotel)

This format allows the writer to think about variables addressed by content (decisions associated with hotel prices) and not be overwhelmed by larger or adjacent issues.  It can help the writer focus on potential hesitation by users when comparing and evaluating hotel prices.  If many users don’t compare the prices, something is obviously wrong. If many don’t book a hotel after checking prices, that also suggests issues.  BDD is designed to be testable.  But we don’t have deploy the design to test it.  Some basic guerrilla usability could flag issues with the content design.  These issues might be too much information (scary), missing information (also scary), or information revealed at the wrong moment (which can feel sneaky.)

I believe that BDD is better than JTBD when specifying the user’s situation and how that influences what they need to know.  We can use BDD to indicate: 

  • What knowledge the user knows already,
  • What decisions the user has already made

We can also indicate that more than one action could be necessary for the user to take.  And there may be more than one outcome.

The power of BDD is that it can help writers pin down more specific aspects of the design.

BDD obviously includes some assumptions about what the user will want to do and even how they will do it.  It may not be the approach to start with if you are designing a novel application or addressing a non-routine scenario.  But in situations were common behaviors and conventions are well known and understood, BDD can help plan content and diagnose that it is performing satisfactorily.

Specifying Performance Standards: Task analysis

Task analysis has been around longer than computers.  When I studied human computer interaction nearly two decades ago, I had to learn about task analysis.  Because it isn’t specific to computers, it can help us think how people use any kind of content.

A basic task analysis pattern would be:

  • Activity Verb
  • Performance standards (quantity/quality)
  • Mode

Here’s an example of a task from a review of task analysis.  The writer would need to add content to explain how to perform the task:

 To instruct the reader on how:

  • To make the nail flush …without damaging the surface of a piece of wood……using a hammer.

Design thinking purists might object that this example presupposes the use of a hammer to pound a nail.  Why not consider a shoe instead?  But the task assumes that certain tools will be used.  That’s a reasonable assumption in many scenarios.  If you are writing instructions on how to assemble a table or mend a shirt, you will assume the reader will need access to certain tools to perform the task.

Yet it is possible to change the mode.  There’s more than one way to wash windows without leaving a streak.  A person could use vinegar and a rag, or use an old newspaper.  If both methods were equally effective, the writer could compare how clearly and succinctly the instructions for each could be.  Remember: consuming the content is part of total work involved with completing a task.

What’s nice about the nail example is that it includes problems that the user might not be thinking about.  The user may just want to make the nail flush.  They may not be focused on how they might fail.  Content supporting the task can be tested with real people to determine if they misuse the tool — getting some unintended consequence.  In our complex world, there is plenty of scope for that to happen.  

Checking Quality

Writers are concerned that customers are successful.  There are many reasons why customers may not be.  Content needs to address a range of situations, and at the same time not be too burdensome to read, view or listen to.  Consuming content is part of the work associated with many tasks.  Content needs to facilitate completion of the task, and not detract from it.  

Much of the poor quality in design ultimately stems from bad assumptions.  Designs reflect bad assumptions about user goals, their knowledge, the information they have available, the decision they are prepared to make, and so on.  The three tools covered in this post can help writers to understand these issues more clearly, so that content created is better quality.

— Michael Andrews