<aside> 💡

This is v1. I understand this isn’t the most comprehensive process, but I also acknowledge that we are too early and small to use too complicated process.

</aside>

Process

1. Define goals and metrics

Based on the goal of the initiative or the problems that we’re trying to fix by redesign, define the goal of the design and any trackable metrics to be measured. Define metrics to measure both short-term user behaviors (e.g., feature adoption rates), and long-term outcomes (e.g., customer retention or satisfaction). This ensures we track progress holistically.

It could include:

1. Any success metrics that can measure the impact of design (both qualitative and quantitative)
2. Any metrics that help collect evidence and help us understand customers better.
3. Any business metrics that it could contribute to

<aside> 💡

For quantitative metrics, share with PM and Eng team to check if they are technically trackable.

</aside>

When defining the metrics, think about:

1. What problems are you trying to solve? What’s the goal of this initiative?
2. What change did I make in design? What result do I expect these change make?

Sometimes, features are too small to do throughout user research, we make changes based on our analysis and hypothesis in order to move fast, then think about:

1. What underlying problems do I think are? How can I validate my assumption?
2. What are you not sure about when you are designing? What data can you collect to help you get more insights?

2. Obtain baseline data

Around 2 weeks prior to release, obtain baseline data of the metrics you want to track. When getting the data, make sure you record the date.

3. Submit new tracking events requests before release (optional)

Make sure new events are documented in design brief doc.

When testing the feature before release, make sure to confirm all events are tracking accurately.