---
title: "Build the tracking plan that survives your next redesign"
canonical_url: https://ampl.webclat.com/use-cases/tracking-plan-that-survives-your-next-redesign
description: "Most tracking plans break the moment the UI changes. Separate what you're measuring from how the screen looks, and a redesign stops being a data-loss event."
source: Webclat | Amplitude Solutions (official Amplitude partner, independent consultancy)
---

# Build the tracking plan that survives your next redesign

**In short:** We name events after the user's intent, not the button or screen that triggered them, so a redesign changes the UI without breaking the historical data. A tracking plan built around 'what happened' instead of 'what it looked like' survives every reskin that follows it.

## The situation

Every time the design team ships a redesign, half your Amplitude charts go flat or start counting something slightly different.

## The pain

Analytics becomes something everyone quietly distrusts around a redesign, and the team either freezes the UI to protect the data or breaks the data to ship the UI - neither of which should be the choice.

## What we implement

We name and structure events around user intent rather than interface elements - never 'Blue Button Clicked,' always 'Report Exported' - what's called UI-decoupled event taxonomy, so a redesign changes pixels without changing what's being measured.

## What you get

- Historical charts that stay comparable across a redesign instead of resetting to zero
- A design team free to ship UI changes without a data-loss conversation first
- One less reason a redesign project runs over schedule

## Illustrative

A team whose events were named after UI elements might find that a routine navigation redesign silently breaks a third of their dashboards - a cost that a UI-decoupled taxonomy, paid for once up front, would have avoided entirely. (Illustrative scenario - not a measured result.)

## FAQ

### Isn't naming events after UI elements just easier in the moment?

It's faster to write once, and then every redesign after that becomes a data-migration project - the taxonomy linter catches exactly this pattern (UI-coupled names) because it's the single most common way a tracking plan quietly rots.

### Can an existing UI-coupled taxonomy be fixed without losing history?

Yes, with a deprecation and migration map - old events get aliased or translated to the new intent-based names and archived rather than deleted, so history stays queryable under the new convention.

Related: [Free tracking plan template](https://ampl.webclat.com/resources/tracking-plan-template), [Event taxonomy starter](https://ampl.webclat.com/resources/amplitude-taxonomy-template), [Tracking plan, defined](https://ampl.webclat.com/glossary/tracking-plan), [Amplitude taxonomy linter](https://ampl.webclat.com/tools/amplitude-taxonomy-linter)