Simplifying the architecture of a complex product portfolio

COMPANY

Entrust

date

2019

ROLE

Principal UX Architect

EXPERTISE

Information Architecture

IMPACT

  • Created a structure and process to consistently represent our content

  • Cleaned up 80% of the problems in our content model and naming conventions

Digital Security IA
Digital Security IA
Digital Security IA

One of the 6 Information Architecture structures used in this project

Information Architecture: Resetting Our Bones

The company was undergoing a rebrand from Entrust Datacard to Entrust. At the same time we were integrating the content, products, and solutions from 4 acquisitions, to be closely followed by a fifth (also the largest). Our site would go from 2500 to 8000 pages. Our architecture was already suffering from poor definition, mixed naming conventions, varied site architecture schemas resulting in navigation challenges and poor SEO performance.

The foundational exercise to help set us on the right path for organizing everything was to correct how we organize and express ourselves in the service of our users. We needed to think through our information architecture. This would later inform our navigation, page templates, and landing pages.

Certificate solutions IA structure
Certificate solutions IA structure
Certificate solutions IA structure

An example of a confusing schema. 'Certificate Solutions' was a legacy meta-product category (even though it's got 'solutions' in the name). It had no common meaning in the marketplace or to our customers. This was also a cul-de-sac in the taxonomy as there were a dozen other products outside of this meta-category. There was no way to have a clear /products directory with this in the mix.

Process

I lead the collaborative effort between content owners, business stakeholders, incoming acquired companies, our SEO agency, our creative agency, and marketers. This required many collaborative sessions over several months. Much of IA work in my experience is really self-reflection and knowing who you are so that it can be expressed properly in the content model, taxonomy, and content itself.

We needed a map

Creating sitemaps for current states was the first step. The problem was we had no less than six sitemaps to consider. Entrust Datacard's current sitemap, plus all four of the incoming acquisitions. This is pretty easy to do with tools like Screaming Frog and others. I then used Whimsical to document the sitemaps in a way that allowed sharing and collaborative work sessions.

Define terms

We were all speaking english, but were very inconsistent in how we defined and used even simple terms like 'solution' and 'use case'. A big part of the exercise was to get us all on the same page as to what Entrust means by 'solution' vs 'product' for example. Muscle memory in language is a tough nut to crack. Marketers, stakeholders, executives, and sales people would use 'solution' to describe products. Seems harmless enough until you realize the impacts on information hierarchy and the contexts of our users.

In our world a 'product' is a standalone SKU. It has features, specifications, integrations, and can be bought directly and individually. A 'solution' is a group of products that together solve a use case. Usually requires a consultation to architect properly. This is one example among many.

Getting our internal definitions right sets us on a path to show up clearly for our customers and future customers.

Naming Conventions

What you call a product is important for user recollection and SEO. Our challenge was some products had semantic, plain names, like SSL Certificates. We also had products with creative, non-semantic names, Intellitrust™️, TrustedX™️, et al. Cute names, but no one would know what those products were just by the name. A serious weakness in a world of commoditized products driven by SEO and recognizability.

Much of this work was led by the Brand team along with agency partners. I participated by offering competitive research to support simple, semantic names. This was a parallel process that fed into our architecture to some degree. Also a big consideration as we integrated products of acquired companies.

Presentations

After several months of effort between all groups, I presented the content model to each of the stakeholder groups and our CMO for final sign off.

Solution

Once we clarified our terms, standardized naming conventions as much as possible, and got everything on a Whimsical board the IA structure and taxonomy pretty much assembled itself. 'Products' organized under a /products directory. 'Solutions' we're organized into 'Industry', 'Use Cases', and 'Compliance'. Those categories represent a very common framing for users to see their business challenges in our solutions. The rest of the content organized itself neatly into Partners, Resources, and Support related elements.

After pulling all of the 'solutions' content out of their previous locations into a /solutions tree, we realized we had A LOT of content that often overlapped and repeated. So the next layer of the onion was to edit those items down to a more useful representation of our solutions. One that more accurately expressed the promise of the broad portfolio we were building.

Results:

Mostly solved, but never 'done'

Overall we solved 80-90% of the problem and had a structure we could use for navigation, taxonomy, and was well-suited for any new content coming from acquisitions. Projects like this are never really "done" in an absolute sense. A few sticking points remained. It would take a little longer to change out some product names to semantic names, but the process had been started. There were still a few wrinkles in the directory, based on an earlier concept of 'Digital Security' vs 'Issuance Systems' that separated software and hardware products. As time went on the line blurred between those products and that dichotomy was scrapped to allow all products to mingle together under a single /products directory. This ultimately had nice SEO benefits as well as improved way finding and orientation for our users.

A wonderful side-effect of this project was the relationships that developed across the groups that participated via the work. This raised the understanding, trust and respect the organization had for experience design.