Case Studies Revamp

Problem

Company projects were spread across the website in a messy way, making them challenging to find. Once someone found a project, the information often looked different from one project to the next, and it was often incomplete.

‘I grasp Hitachi Energy’s long history, but it is difficult to find projects similar to mine which they have worked on in the past or are currently working on’

Client

Needs to actively search for projects across product pages, news, and reports

‘It is hard to display our experience and know-how if we rely on constantly updating internal slides and regularly asking Business Units about information on their latest projects’

SALES MANAGER

Repeatedly requests updated project information when presenting to prospects

Proposal & Process

The proposal was to standardize projects by structuring them as Case Studies and cataloging them through a centralized tool. That tool would let users sort and filter by predefined categories with less effort.

Research activities stayed internal and practical:

• User interviews with colleagues (sales, marketing, and other intranet users) about how they looked for project stories before opening tickets or asking around, what they searched for, and what they grepped for when something was missing.
• Surveys and questionnaires on the intranet and website, especially intranet questions on whether search was useful and whether people found what they needed in specific document areas.
• High-level usability testing of the selector and template by showing designs and walking through the signs of the experience.
• Google Analytics and Crazy Egg heatmaps after release to see whether people could actually find and use Case Studies, plus A/B testing of selector placement where it mattered.

It was necessary to go through the following steps:

1. Collect throughout the website all existing pages that meet the Case Study criteria
2. Clean up and sort through the collection
3. Brainstorm, define, and agree on a tagging and categories system that would work across all Business Units
4. Tag each Case Study individually to match that tagging system
5. Analyze existing Case Studies to find patterns in the information that should be displayed
6. Go through the template creation process with stakeholders
7. Migrate existing pages into Case Studies
8. Design, develop, and test the filter and sorting component
9. Release the new component and include it on multiple product pages

Steps 3, 4, 5, and 6 were connected, so we had to re-run them across several iterations.

Result

The initiative delivered 4 things:

The most impactful was the Case Study Selector, a component that shows descriptions and links to all Case Studies. Users can filter across 7 possible categories. In the backend, the component can be set up so each page shows the most relevant filters. A second iteration also let us showcase a limited set of Case Studies based on criteria set in the backend.

A new Case Study Template, plus writing guidelines for using it. Existing project references had to be rewritten to fit the Case Study Template. Editors followed Case Study guidelines that explained each section, showed example text, and shared best practices.

A centralized backend system. All Case Studies now live in a simpler folder structure in the Content Management System. That makes updates easier, because editors can filter and browse all Case Study pages in the backend without walking through the full website folder tree.

A tagging system. A uniform set of 120+ tags from 5 categories (Offering, Markets, Country, Specific Products, Voltage) that works across the complex products and services of all Business Units.

Impact

The new Case Study Selector made it clearer how important it was to show the company's projects to customers. That helped start a culture shift inside product marketing teams, so that new Case Studies are published every week and older Case Studies got better content quality.

Monthly visits to Case Study pages, compared with their original pages, doubled or tripled. Traffic moved from a low average of about 400 monthly views up to 1,500, and in many cases grew from 0 to 1,000 monthly visits.

The Sales team benefited from getting updated information about the company's projects using the website as an initial source of truth. Sharing with customers also became more transparent, because most of that information is now public.

Products, News, and Events pages can now connect easily to related Case Studies by placing a Case Study Selector limited to that page's topic in one section. That supports better storytelling and adds useful context to the page content.

Challenges

This initiative faced many difficulties, among them:

• Aligning Case Study tags into a system that worked across Business Units and would stay useful for at least a couple of years took 60% of the project's timeline. Leading many workshops with 30+ stakeholders, dozens of cleanup sessions, and endless emails was hard and often frustrating. Through mediation and by helping Business Units collaborate, we reached a stable set of tags.
• Categories with number values could not use fixed predefined tags. Those numbers could range from 0.005 to 125,000,000 in the matching energy-related units, because products and services in a project could sit at any stage of the energy grid. We had to design a one-of-a-kind slider filter that grouped those values in a logical way.
• Finding content that could later become Case Studies was hard, because this was a new writing structure that marketing teams had not defined yet. The source material came from news, events, references, and parts of product pages. Rewriting that material to fit the new structure sometimes needed extra research to fill in missing information.

Role

This initiative required me to wear two hats:

Project Manager

• Coordinated creation of the tagging system (easier said than done; see Challenges)
• Managed release communications to editors and content owners
• Released the new component and included it on multiple product pages

User Experience Consultant

• Ran internal user interviews about how people looked for project stories before opening tickets or asking around, what they searched for, and what they grepped for when something was missing
• Used intranet and website surveys and questionnaires to check search usefulness and document-area findability, and to pressure-test tags and filters
• Analyzed content in existing Case Study pages and checked for redundancy and relevance
• Established requirements for the Case Study template and writing guidelines
• Went through the template creation process with stakeholders
• Collaborated on the design, development, and high-level usability testing of the filter and sorting components (showing designs); used Google Analytics and Crazy Egg heatmaps after release, including A/B testing of selector placement
• Checked accessibility of the Case Study Selector: keyboard reach for filters and sorting, focus order, and labels so the catalog stayed usable beyond mouse-only browsing
• Released the new component and included it on multiple product pages

Learnings

From this project I got three main takeaways:

1. A great product is the one that can start a culture adjustment in an organization. Before the Case Study Selector, content about existing projects sat on the sidelines and was overshadowed by new products and services. After Case Studies became easier to understand, find, and update, they gained real meaning.
2. Working across siloed departments can become endless if you do not watch the clock. It is important to set expectations and deadlines to avoid the project from extending itself.