The Airfleet Website Redesign Series

If you haven’t read the previous article, start with the Information Architecture Part 1.

Airfleet Website Redesign: Phase 2

In our prior article in this series, we covered what kind of research must be done in order to complete an information architecture project, how to create a page manifest, and how we thought through our information hierarchy.

This time, we’ll get into the really nerdy stuff 🤓

Of course we’ll go through our new navigational schema, taxonomy, and URL structure, but they aren’t the stars of the show.

Don’t get us wrong. These things are important. But it’s important to keep in mind that throughout these steps, we obsessed over the words we chose to represent various navigation elements, CTAs, and what we do as a company. 

We’ve seen the difference the right words can make in the data, so we really thought long and hard about what to call each part of our navigation, how to name what we offer, and how to talk about what we do. 

The data will be the judge of whether we’re on the right track or need to update things in the future, but for now, let’s talk through our process.

Building the Airfleet taxonomy

Now that we’ve created a page manifest, we can develop the levels of information we need and how that information should be grouped. 

Think of this like classifying organisms in science class. We want to group bears together, rabbits in a different group, and then bees in a different branch. If we put all those things in one bundle, it gets weird (and messy!) real fast. The page purposes we set in our manifest help a lot here – pages designed to convince users tend to be in clusters, while those that educate users tend to belong together. If we group the kinds of website content in the right bundles, it makes way more sense to our end users.  It also makes structuring our navigation (the next phase) a lot more sane and straightforward. 

What is website taxonomy?

A website taxonomy is how we classify different kinds of content using groups and levels. The intent of taxonomy is to help visitors quickly find the information they need.

A Level is hierarchical as well as recursive. Higher level groups contain related lower level groups. Higher level pages are, as a rule, both greater in importance and will be featured more prominently in navigation and signposting. 

Note: We aim to have four or fewer levels and try to keep things as simple as possible.

A Group is a collection of pages with a similar purpose and/or audience. The functional purpose of groups is to make user journeys as smooth as possible. 

Our goal with taxonomy is to make it obvious where someone “is” on our website and what to do next.

For Airfleet, we decided to tackle the project in two distinct phases, so we’re not listing the complete taxonomy here, but it’s a starting point.

For Phase 1, we mapped out the levels like this:

Level 1	Level 2	Level 3	Level 4
Home Page	Services Overview	Service Detail/Feature Set	Proof Points, Testimonials, Use Cases, Feature Specifics
	Partnerships & Technologies	Partner or Technology Showcase Page	Perhaps use cases/case studies?
	Resources	Blog Events Special resources Newsletter	Collection page: Blog Collection page: Event Collection page: Other Collection page: News
	About Us	Who we are Why work with us vs. someone else Vision & Mission Careers	Open positions FAQ Submit CV

In our sitemap, it looks like this (this is just a sample set because it gets really detailed really fast):

So if we were to look at this from the standpoint of a B2B marketer looking for a new website, we’d have different starting points in their journey that all lead to an outcome:

Creating Airfleet’s navigational schema

Now that we have our groups and their taxonomy, we can construct our navigation schema. This doesn’t concern design, functionality, or placement from a data storage standpoint (at least not anymore – these things used to matter more!). 

When building our navigational schema, we focused on four things:

1. What are our main navigation headings? These are the labels on our navigation bar.
2. What are our sub-headings? What shows up if we hover over a navigation bar item?
3. What CTAs do we need on every page?
4. What do our lobby pages contain? (A simple list of page types or specific pages.)

These are the rules we stand by when working with clients and for our own website:

1. Never mix groups – Pages from one part of the site do not belong with pages from another. If you have a strong desire to mix, it suggests your taxonomy is not correct or adequate.
2. Never repeat – No two navigational headings should ever lead to the same page. It is fundamentally confusing and feels like an error
3. Less is more – Shorter, simpler headings are always better. If you need more than three words in a heading, it’s time to stare at a thesaurus and find a better phrase or word.
4. Design with repeat visitors in mind – Many B2B sites convert a potential prospect to a lead after repeated site visits. You must design the navigation to keep finding a page someone has already seen in mind just as much as what the site is about for first time visitors. 

To be completely honest, the navigational schema exercises led to the most debate on our team. Particularly around headings. That’s why it’s going to be important for us to collect feedback and monitor how people are navigating through the site using path analytics. For now, at least, this is where we landed with the main navigation:

Main Header	Sub-Header	Menu CTAs
Create	Visual Identity Information Architecture Website Design Development Content Migration	Explore the process
Optimize	Technical Perfection Website Enhancement Conversion Rate Optimization Search Engine Optimization	Optimize overview
Platform	Features CMS Integrations Optimization Add-Ons	N/A (TBD)
Learn	Blog Events	Featured Posts
Careers*

Now it’s time to decide on our CTAs based on what we want the visitor to do next. There will be CTAs throughout the website, so let’s just focus on the home page.

Global CTAs like the call to action in the navigation bar have to be clear and concise. “Contact Us” is embraced by much of B2B, but that’s a bit pedestrian for our tastes. We deliver a professional experience, but you’re going to get our opinion. We’ve been building websites long enough to have plenty! That’s why we went with “Let’s talk.” We want our first interaction to be a conversation. We’re happy to talk about best practices if you’d like – but we really want to understand if we’re both a fit for one another.

Other CTAs are structured by the journey the visitor is taking and where they are in the journey. For example, if they want to learn best practices, we hand-pick some of our favorite articles and give them the option to “See all resources.” 

For our key solutions, we have different offers and CTAs that correspond with them. 

For our Create (new website) solution, we offer a 90-day go-live timeline for new website customers*. *We’d be insane if we didn’t put some parameters around that offer. If you’ve been in business for 20 years and have thousands of pages of content or twenty business units, 90 days is not going to be enough. That’s why we say “See if you qualify.”

For our Optimize solution, it made the most sense to offer “Get an audit” as the next step. You need a solid evaluation of what’s good and what’s not. We need an opportunity to understand the scope of work we’re committing to.

Platform is our website platform for DIY marketers, and we know these digital experts will need to research every feature before they can commit to major change. That’s why we kept it simple with “Learn more about our Platform.”

Finally, we need to round out the page with a CTA that is for buyers but not so narrow that we’ll exclude people who have a specific solution in mind. “Book a meeting” is a classic because it’s fantastic. You know exactly what you’re committing to and what you get.

The logic behind URL structure

There are several parts to a URL string. We already had a domain we use since this is a redesign, but we did need to put some thought into the path. Here’s a very simplified illustration of the anatomy of a URL:

In addition to the above, you may see a port after the top-level domain, a fragment after the path (to indicate a special portion of content or a page), a query string, and, of course, the beloved UTM parameters for tracking purposes.

For us, our main URL string is the protocol (“https://”), the subdomain is blank for our main website, the main domain (“airfleet”), and the top level domain (“.co”).

In the past, the path was driven by the folder structure or directory of storage buckets for a website. There was a purpose and physical component mapped to each branch. These days the path is more of a navigational construct (although with some platforms, you’re stuck with the CMS label for a collection of pages).

Because we have much more flexibility in how we can label pages, we tie them to the navigational schema. That way, people understand where they are on the website at all times. Here’s a good example of a few clicks into our navigation from our new website:

Between our Part 1 article and the steps outlined in this piece, you have a complete picture of what all goes into a typical information architecture phase. It’s a lot of work! But if done correctly, you’ll have a more streamlined buyer experience that helps visitors understand 1) what you do, 2) how it solves their problem, and 3) exactly where to go to get the information that’s appropriate for their stage in the buyer journey.

We hope you enjoy this look behind the scenes and welcome any feedback!