Measuring success
Beyond shipped
How I agree on success with product and engineering before design starts.
Topic
Measuring success
Reading time
3 minutes
Covers
Outcomes, behavior, quality
Visuals
Original illustrations
Three layers of success
Sample measures
Outcomes
Did it get easier?
Task completion time
Error rate
Behavior
Are people coming back?
Adoption over time
Repeat use
Quality
Does it hold up?
Consistency across screens
Accessibility checks passed
Before design: agree on measures
After launch: review and learn
Three layers: did it get easier, are people coming back, does it hold up.
Shipping is not the finish line
A release tells you that something went out the door. It does not tell you whether the work helped anyone. I define success before design starts, with product and engineering, so we are not deciding afterward which numbers to celebrate. We agree on what should get easier, who should notice, and how we will know.
Connect the goal to the signals
I like to draw the chain from the goal to the measures that move it. A top-level outcome breaks into a few behaviors, and each behavior has signals we can actually observe. The tree keeps the team honest: if a feature does not connect to a signal, we ask why we are building it.
Outcome, behaviors, signals
Driver tree
Outcome
Team leads start the day informed
Target: no missed items on Monday mornings.
→
Behavior
Open the summary daily
→
Signals
Daily active users
Time to open
Behavior
Act on flagged items
→
Signals
Actions per session
Time to first action
Behavior
Return within a week
→
Signals
7-day return rate
Repeat use per week
Every signal traces back to the outcome it serves.
Watch behavior, not just clicks
Adoption and repeat use say more than raw traffic. I look at where people start, where they stall, and whether they come back, and I compare the numbers with what we expected when we planned the work. The gap between the two is where the next design question lives.
Funnel and adoption
Sample data
From open to return
Opened the summary
100%
Viewed a flagged item
72%
Took an action
54%
Returned within 7 days
41%
Adoption over 8 weeks
W1
W2
W3
W4
W5
W6
W7
W8
Dark bars met the adoption target.
Sample data: a funnel from first open to repeat use, and adoption by week.
Quality is a measure too
A product can hit its numbers and still feel rough. I treat consistency, accessibility, and maintainability as first-class measures: contrast and keyboard checks, reuse of shared components, and the number of one-off exceptions. These signals keep a product healthy as it grows.
Quality audit
Sample audit
Checks passed
46 of 52
Healthy
Contrast to review
3
Review
Keyboard issues
2
Review
Contrast checks
Element
Ratio
Result
Body text on surface
12.4:1
Pass
Links on surface
5.6:1
Pass
Button label on action
6.1:1
Pass
Placeholder text
3.9:1
Review
Disabled button label
2.8:1
Exempt
Sample audit: contrast checks and the issues worth reviewing.
Numbers say what. People say why.
Dashboards tell me what is happening. Conversations with users and teammates tell me why. I use both, and I share what I learn in plain language so the next decision starts from evidence instead of opinion.
Success is something you agree on, then check
Next article
Raising the bar, together →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
Measuring success
Beyond shipped
How I agree on success with product and engineering before design starts.
Topic
Measuring success
Reading time
3 minutes
Covers
Outcomes, behavior, quality
Visuals
Original illustrations
Three layers of success
Sample measures
Outcomes
Did it get easier?
Task completion time
Error rate
Behavior
Are people coming back?
Adoption over time
Repeat use
Quality
Does it hold up?
Consistency across screens
Accessibility checks passed
Before design: agree on measures
After launch: review and learn
Three layers: did it get easier, are people coming back, does it hold up.
Shipping is not the finish line
A release tells you that something went out the door. It does not tell you whether the work helped anyone. I define success before design starts, with product and engineering, so we are not deciding afterward which numbers to celebrate. We agree on what should get easier, who should notice, and how we will know.
Connect the goal to the signals
I like to draw the chain from the goal to the measures that move it. A top-level outcome breaks into a few behaviors, and each behavior has signals we can actually observe. The tree keeps the team honest: if a feature does not connect to a signal, we ask why we are building it.
Outcome, behaviors, signals
Driver tree
Outcome
Team leads start the day informed
Target: no missed items on Monday mornings.
→
Behavior
Open the summary daily
→
Signals
Daily active users
Time to open
Behavior
Act on flagged items
→
Signals
Actions per session
Time to first action
Behavior
Return within a week
→
Signals
7-day return rate
Repeat use per week
Every signal traces back to the outcome it serves.
Watch behavior, not just clicks
Adoption and repeat use say more than raw traffic. I look at where people start, where they stall, and whether they come back, and I compare the numbers with what we expected when we planned the work. The gap between the two is where the next design question lives.
Funnel and adoption
Sample data
From open to return
Opened the summary
100%
Viewed a flagged item
72%
Took an action
54%
Returned within 7 days
41%
Adoption over 8 weeks
W1
W2
W3
W4
W5
W6
W7
W8
Dark bars met the adoption target.
Sample data: a funnel from first open to repeat use, and adoption by week.
Quality is a measure too
A product can hit its numbers and still feel rough. I treat consistency, accessibility, and maintainability as first-class measures: contrast and keyboard checks, reuse of shared components, and the number of one-off exceptions. These signals keep a product healthy as it grows.
Quality audit
Sample audit
Checks passed
46 of 52
Healthy
Contrast to review
3
Review
Keyboard issues
2
Review
Contrast checks
Element
Ratio
Result
Body text on surface
12.4:1
Pass
Links on surface
5.6:1
Pass
Button label on action
6.1:1
Pass
Placeholder text
3.9:1
Review
Disabled button label
2.8:1
Exempt
Sample audit: contrast checks and the issues worth reviewing.
Numbers say what. People say why.
Dashboards tell me what is happening. Conversations with users and teammates tell me why. I use both, and I share what I learn in plain language so the next decision starts from evidence instead of opinion.
Success is something you agree on, then check
Next article
Raising the bar, together →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
Measuring success
Beyond shipped
How I agree on success with product and engineering before design starts.
Topic
Measuring success
Reading time
3 minutes
Covers
Outcomes, behavior, quality
Visuals
Original illustrations
Three layers of success
Sample measures
Outcomes
Did it get easier?
Task completion time
Error rate
Behavior
Are people coming back?
Adoption over time
Repeat use
Quality
Does it hold up?
Consistency across screens
Accessibility checks passed
Before design: agree on measures
After launch: review and learn
Three layers: did it get easier, are people coming back, does it hold up.
Shipping is not the finish line
A release tells you that something went out the door. It does not tell you whether the work helped anyone. I define success before design starts, with product and engineering, so we are not deciding afterward which numbers to celebrate. We agree on what should get easier, who should notice, and how we will know.
Connect the goal to the signals
I like to draw the chain from the goal to the measures that move it. A top-level outcome breaks into a few behaviors, and each behavior has signals we can actually observe. The tree keeps the team honest: if a feature does not connect to a signal, we ask why we are building it.
Outcome, behaviors, signals
Driver tree
Outcome
Team leads start the day informed
Target: no missed items on Monday mornings.
→
Behavior
Open the summary daily
→
Signals
Daily active users
Time to open
Behavior
Act on flagged items
→
Signals
Actions per session
Time to first action
Behavior
Return within a week
→
Signals
7-day return rate
Repeat use per week
Every signal traces back to the outcome it serves.
Watch behavior, not just clicks
Adoption and repeat use say more than raw traffic. I look at where people start, where they stall, and whether they come back, and I compare the numbers with what we expected when we planned the work. The gap between the two is where the next design question lives.
Funnel and adoption
Sample data
From open to return
Opened the summary
100%
Viewed a flagged item
72%
Took an action
54%
Returned within 7 days
41%
Adoption over 8 weeks
W1
W2
W3
W4
W5
W6
W7
W8
Dark bars met the adoption target.
Sample data: a funnel from first open to repeat use, and adoption by week.
Quality is a measure too
A product can hit its numbers and still feel rough. I treat consistency, accessibility, and maintainability as first-class measures: contrast and keyboard checks, reuse of shared components, and the number of one-off exceptions. These signals keep a product healthy as it grows.
Quality audit
Sample audit
Checks passed
46 of 52
Healthy
Contrast to review
3
Review
Keyboard issues
2
Review
Contrast checks
Element
Ratio
Result
Body text on surface
12.4:1
Pass
Links on surface
5.6:1
Pass
Button label on action
6.1:1
Pass
Placeholder text
3.9:1
Review
Disabled button label
2.8:1
Exempt
Sample audit: contrast checks and the issues worth reviewing.
Numbers say what. People say why.
Dashboards tell me what is happening. Conversations with users and teammates tell me why. I use both, and I share what I learn in plain language so the next decision starts from evidence instead of opinion.
Success is something you agree on, then check
Next article
Raising the bar, together →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.