Helping Users Switch Between Legacy and Current Docs

Overview

Users were struggling to tell whether they were reading documentation for the legacy or current version of the product, and there was no easy way to move between equivalent pages. The problem had surfaced repeatedly through customer feedback, internal users, and documentation backlog tickets. I led the project from research through design and handoff. I organized a heuristic evaluation with writers, consolidated the findings, created early design concepts, worked with UX Research and UX Design, and used an AI prototyping tool to turn the selected design into a working prototype before handing the final direction to Docs Tools for implementation. The shipped version switcher resolved about nine existing backlog tickets. No new tickets for the same issue have been raised since launch, and the feature received positive feedback at the customer conference.

My role

I owned the documentation side of the project from problem definition through implementation handoff.

• Planned. Defined the project scope, stakeholders, milestones, and handoff path.
• Researched. Led a heuristic evaluation with documentation team members and consolidated the findings into shared priorities.
• Designed. Created three low-fidelity concepts and worked with UX Research to evaluate the options.
• Prototyped. Used an AI prototyping tool to turn UX Design’s mockups into a working interactive prototype, giving stakeholders something they could test before development.
• Aligned. Coordinated across Documentation, UX Research, UX Design, and Docs Tools through the design and delivery process.

Worked with

• Documentation leadership. Supported the project and helped create space for the work.
• UX Research. Provided the evaluation framework, reviewed the user journey and wireframes, and helped assess the design options.
• UX Design. Created the high-fidelity design.
• Docs Tools. Implemented and shipped the feature.
• Technical writers. Participated in the heuristic evaluation and contributed domain knowledge about the documentation experience.

The challenge

The product existed in both legacy and current versions, each with its own documentation.

Readers could land on either documentation set without an obvious indication of which product version they were viewing. Moving from one version to the equivalent page in the other version was also difficult.

The result was predictable: users could follow instructions that did not apply to their version of the product.

The issue had already appeared in customer feedback, internal reports, and documentation backlog tickets.

The challenge was to turn that scattered feedback into a focused UX problem that could be researched, designed, and shipped.

Key decisions

1. Combine UX methodology with documentation domain knowledge. UX Research provided the evaluation framework, while writers brought detailed knowledge of the documentation site and common user journeys. Four writers evaluated the experience independently before comparing findings. Trade-off: The evaluation required time from several writers, but independent reviews helped separate recurring usability problems from individual opinion.
2. Keep the problem deliberately narrow. The project focused on version identification and switching. Related issues such as search, SEO, and table-of-contents improvements stayed outside the project. Trade-off: Other documentation UX problems remained unresolved, but the narrower scope made the project easier to move from research to delivery.
3. Explore multiple solutions before committing. I created three low-fidelity wireframes rather than starting with a single preferred solution. UX Research reviewed the alternatives and recommended the strongest direction. Trade-off: Exploring several options required more work up front, but reduced the risk of committing too early to one interaction pattern.
4. Use AI to prototype before development. Once UX Design produced the design direction, I used an AI prototyping tool to turn the mockups into a working interactive prototype. This let stakeholders experience the proposed interaction before Docs Tools invested engineering time in implementation. Trade-off: The prototype was not production code, but it made the design tangible earlier and improved the implementation handoff.
5. Ship a focused solution, then evaluate real use. Rather than waiting for every related documentation UX issue to be resolved, the team shipped the version switcher and planned to learn from actual use. Trade-off: Some questions remained for post-launch evaluation, but users received the core improvement sooner.

My approach

I treated the problem as a documentation product experience rather than a content issue.

1. Map. Chart the user journey across legacy and current documentation.
2. Evaluate. Review the experience independently with multiple reviewers.
3. Synthesize. Condense the findings into a small set of shared problems.
4. Design. Sketch several possible interaction patterns.
5. Validate. Test the options with UX Research.
6. Prototype with AI. Turn UX mockups into a working interaction.
7. Hand off. Pass the validated design to Docs Tools for implementation.

The solution

The final experience introduced a version switcher that lets readers move between the legacy and current versions of equivalent documentation pages.

When no equivalent page exists in the other documentation set, the interface explains that clearly instead of sending the reader somewhere unexpected.

This addressed both parts of the original problem: readers can identify which documentation version they are viewing, and readers can move between versions without manually searching for the equivalent page.

Tools: Figma · Lucidchart · AI prototyping

Impact

• Resolved existing demand: About nine backlog tickets related to version navigation and identification were closed after the feature shipped.
• Reduced recurring reports: No new backlog tickets for the same issue have been raised since launch.
• Improved user experience: Readers can now move directly between legacy and current versions and receive a clear message when no equivalent page exists.
• Validated a known pain point: All four evaluators independently identified issues that aligned with problems customers and internal users had already raised.
• Cross-functional delivery: The project moved from documentation research through UX validation, design, AI-assisted prototyping, and implementation across multiple teams.
• Customer response: The feature received positive feedback when demonstrated at the customer conference.

What I learned

Documentation UX benefits from combining disciplines. The strongest result came from combining different types of expertise. Writers understood the documentation structure and recurring user problems. UX Research brought a structured evaluation method. UX Design refined the interaction, and Docs Tools made it real. My role was to connect those disciplines around one clearly defined problem.

Narrow scope makes improvement easier to ship. The research surfaced more issues than the project could reasonably solve. Keeping the scope focused on version identification and switching gave the team a problem small enough to finish while still addressing a pain point users had repeatedly raised.

AI can shorten the distance between design and validation. Using an AI prototyping tool let me turn UX mockups into a working interaction without waiting for production development. That made the design easier to evaluate and gave stakeholders something concrete to react to before Docs Tools began implementation. The value of AI here was not replacing UX or engineering. It was reducing the time between a design decision and a testable prototype.