A taxonomy is a way to group things together, and it is one of the most important things I do in the realm of user experience. The reason why is that it affects so much…

  • Salespeople speak about features and functions when selling
  • The website and marketing collateral communicate about the product in terms of tasks, features and functions
  • Analysts and product reviewers describe the product and you want them using your terms and definitions, which will only happen if you are consistent
  • Customer service has to communicate with users about terms and troubleshoot problems
  • C-level executives and board members are not necessarily technical and need easy-to-grasp concepts, just like your end users do
  • Documentation writers will not necessarily push for easier-to-comprehend terms as they are pretty technically adept sometimes… they can get tunnel vision like developers and just write about what they see on the screen

Developers, in my vast experience working with them, do not necessarily label things in a way that the end user would think of them. I consider this a uxp function and am usually a driver of creating a taxonomy for a product, product suite, or company-wide and then educating all the parties about how to use and understand it.

When it comes to taxonomy and information architecture, the larger the volume of data, or feature sets, the better a user experience practitioner needs to understand how to approach taxonomy in different levels and structures based on the learner (or the user role, in software terms). In the teaching world, there is a fun example using Hans Solo (a play on the acronym for Solo Taxonomy) that depicts these levels in terms just about anyone can understand.

Hans Solo TaxonomyInfographic by @MrsWellsNZ

Below is an example of terms for one of the PentasSafe product suites and how to refer to them when writing or speaking, plus the products that contain references.

Note: it is up to UXP professionals to catch taxonomy discrepancies which is why UE Design Reviews are critical! Don’t rely on the Quality Assurance (QA) to do this for you.

Do train your doc writers to catch issues and alert you and the product team to make screen corrections and then correct the documentation when the change has been made inside the product.

 More Fresh Practices