Restructuring Morningstar’s B2B website
How I turned an organization that couldn’t agree on what it sold into a shared product taxonomy, content model, and scalable system of page types.
Role
Lead UX Designer
Project Type
In-House | Morningstar
Year
2023-2026
What products do we sell?
When I joined Morningstar in 2022 as the sole UX designer assigned to its B2B website redesign, I started with what I thought was a simple question:
What products do we sell?
I ask because in order to put the puzzle together, I need to gather all the pieces.
There wasn’t a simple answer.
Different business units acquired over time maintained their own product portfolios and described their offerings differently. What one team considered a “platform,” another might call a “product.” Another team’s flagship product wasn’t even purchasable.
And that inconsistency wasn't just an internal terminology problem—it was reflected on the website too.
My job became larger than designing wireframes. Before I could design an information architecture around Morningstar’s products, I needed to create a shared model of the business itself.
The source of truth that didn't exist
I began interviewing people across the business to understand what their teams sold.
I stored the answers in a centralized Airtable database containing Morningstar's B2B products. What began as a practical tool for my own UX work gradually exposed inconsistencies in how the organization categorized and described its offerings.
Over time, I expanded the database beyond products and began modeling the relationships among:
Offerings (or “Products’)
Add-ons
Business Units
Audiences
Geographies Sold
etc.
The database eventually became more than a UX artifact. I maintained it for several years before formally handing ownership to the Brand team in 2026, and it continues to serve as Morningstar's central reference for its B2B product portfolio.
Translating the experience into an architecture
Individual business units had historically been able to create pages according to their own marketing needs. As a result, similar offerings were represented differently, there was no backlinking strategy, and the user journey often led users in circular paths around the site.
Instead of solving those inconsistencies page by page, I wanted to create a finite set of structural patterns that could represent the entire ecosystem.
I introduced the concept of page types.
A standalone offering would use a Product page. An extension of a product would use an Add-on page. Audiences would use Segment pages. Other entities had their own defined structures: Family Brand, Insights Type Hub, Research Report, Blog Post, and so on.
By the end of 2025, an enormous, flat B2B website could be represented through 10 page types.
What’s the big deal?
This did two things at once:
For users, it created predictable patterns for understanding where they were and what information they could expect.
For internal teams, it created consistent content expectations and faster turnaround time. Instead of every new business request becoming a new kind of page, teams could ask: “What are the objectives of this request, and which existing pattern helps achieve it?”
Page Types x Sitemap
Turning the system into a tool (or skill)
Now, the benefits above might be obvious to you and me. But not everyone spends their days thinking about information architecture. As the website grew, I felt that manually reviewing each new page request felt unscalable.
So I turned the page type framework into a Claude Skill. I gave Claude the same definitions, decision criteria, and content expectations I used to classify pages myself.
In doing so, I realized the real value of this skill wasn’t one-off page requests—it was the impending sitewide migrations of Morningstar’s acquired businesses.
Can you imagine auditing thousands of pages of another B2B website to assess whether they fit in a page type? Now do that three more times.
Absolutely not.
In its POC stage, you could give Claude a URL and it will analyze the page's schema and content, recommend the appropriate page type, and explain its reasoning with a degree of confidence.
Now that the functionality and output is confirmed, it opens up a much bigger possibility: applying the skill to sitemap.xml files.
Rather than treating the page-type system as documentation people had to remember to consult, I was beginning to turn it into infrastructure the organization could actually use.
A mature system still needs to evolve
By 2026, our page-type system was mature. Most new content requests could be accommodated by one of the 10 existing page types in a matter of days, not weeks.
Then AI exposed a gap.
Search demand showed that people were looking for Morningstar's AI products and solutions. We initially responded by adding Artificial Intelligence as a filter on our All Products page, but that didn't give us the narrative, dedicated landing page we needed for search.
The obvious solution might have been a Capability page. But Morningstar’s leadership team had deliberately decided that AI wasn't a standalone capability—it was something woven throughout the business. Capabilities also had a required one to many relationship with products, so a product could only be associated with one Capability. This entity representing AI offerings needed to be more flexible.
None of our existing page types quite fit.
So I introduced a new one: Solution.
Product Page type
Designed to highlight a singular offering.
Designed to route users to individual product pages AND instances had to be sanctioned by Brand.
Capabilities Page Type
Solutions Page Type
Ahhhh just right.
A Solution without a solution
Unlike a Capability, a Solution page could bring together products from across the business around a shared customer need or theme. It was also an optional relationship, so products could appear on none or several Solution pages. It was flexible.
But it came at a price: we had to accept the trade-off of having two different yet very similar product category page types.
And that price came with taxes: leadership did not want Solutions to compete directly with Capabilities with its own label in the navigation.
So we nested AI Solutions under the “Products” branch of the website and navigation. You see, we hypothesized that our Solutions pages would gain so much SEO traffic for their flexible, user-centric terminology, that eventually leadership would have to reconcile the two similar page types.
Jury’s still out as of September 1, 2026.
Outcome
What started as my attempt to answer “What do we sell?” became infrastructure for how Morningstar understands and represents its B2B business.
The work produced:
A centralized B2B product source of truth
A B2B taxonomy connecting products to other meaningful business entities
A reusable system of 10 page types
A shared vocabulary across previously siloed teams
A structural foundation that could evolve as Morningstar's business strategy changes
A Claude skill that can classify page types by URL (and soon by sitemap)