Taxonomy is a fancy word. Perhaps you are more familiar with other terms like hashtags, categories, keywords, vocabularies or metadata. It’s more formally defined as a simple method of classification that provides structure, context and meaning to a thing.
How does that relate to web development?
Taxonomy interrelates with many aspects of web development starting from content management system selection, information architecture, search technologies, page engineering and finally web design.
Web developers regard it as essential information because it creates structure from unstructured content. When the basic principals of taxonomy are defined at the start, it enables developers to design logical, organized and efficient infrastructures.
One example of taxonomy we use everyday is site navigation. Navigation enables a user to get around the website by category and is often structured using parent/child relationships or in terms of broad to narrow.
But taxonomy is much more than just navigation. Rich taxonomy and interactions aid the user to engage content that is most interesting, and most relevant to them by directing them to related content, page archives and search pages. Instead of a parent / child relationship, the relationships between the various points of content are multi-faceted, multi-directional.
Web developers have to code the website so that these interactions can take place and is therefore more technically and functionally oriented while designers concern themselves with the aesthetics after the infrastructure is already well defined and in place.
Why not just build it?
Often inexperienced developers/designers or clients try to build sites without a clear understanding of how it should be structured. They just want something that is pretty and works. They have no idea what that means and what they want.
Imagine trying to build navigation without a clear understanding how many pages are going into it? How are you supposed to organize an abstract? This is why many navigational systems fail and end users leave in frustration. This is because rather than the content informing the design, the design informs the content. Imagine trying to design a page without knowing what elements are going to be presented on each page? How do you design typography if you aren’t sure what kind of content will display nor the the length of it? Do you think an article page design that works well for The Atlantic works equally well for CNN? The result of poor information architecture is a poor user experience, and difficulties when the site needs to grow.
A clear idea of information architecture at the outset will dictate the structure and aesthetics of the entire user interface of a website effecting every single element on the page. Web developers have to solve these and the following problems before they can begin coding and before a web designer can design the page.
- How are the pages organized on the website?
- How many different types of pages. Article, landing pages, archives, galleries?
- What information is presented each page type?
- How is information organized on the each different type of page?
- How are the pages discovered by the end user?
- How is the content on each page type updated? Will it be automated, manual or a combination of both? What will trigger automated content?
- Is content populated in multiple location?
- Are there dynamic pages, and dynamic content?
- How is older related content discovered?
- How easy / difficult is it to update the content from the content administrator point of view?
- What is the expected longevity of the proposed software infrustracture and how flexible is the product over time?
Only after those questions are answered can one begin to align with technical, functional, aesthetic and business requirements. That’s when coding and design begins.