We shared one of my posts on design metric trees, which shows metrics in a tree format. Inside that idea is the role of concepts, which sit inside an initiative.
We’re leaning more into the Focus part of Glare, and that starts with initiatives. An initiative is made up of many concepts, which come from the Measure step.
My question is this: in design, most people think in terms of projects. That works fine, and it’s how most agency work happens. But in an ops mindset, people often see ongoing work as initiatives instead of projects.
Part of our goal is to reframe these ideas from a business perspective.
OOOoOoO love this @Bryan - In my opinion ops tries to emphasize “what’s the ongoing value here?” Projects are easy to start and easy to forget and initiatives force teams to connect outcomes into a bigger arc. It’s a small language shift, but it changes the cadence of how people start thinking about impact, not just delivery.
I think this is the million dollar question, though. ““How do we keep teams accountable for long-term outcomes when the work is structured as short-term projects?”
We use a similar concept called KPI/metric tree with each layer having drivers. These drivers will have their own KPIs and drivers. It maps to north star of the organization and helps priorities which areas of the company to target for ai driven change.
Initiatives is a good model too for designers/PMs. It is a good parallel to drivers and gives room for actions which have outcomes beyond quantitative kpis. For instance CX, premium look and feel, non anxious check out process etc are really good qualitative drivers and building them will.become the initiative.
I wonder how one would use that for brown field projects vs green field.
First off, that’s the first time I’ve heard brown field project… needed to look it up!
So, in using this for AI-driven change, do the initiatives vary much from a KPI perspective? Is this mainly about efficiency, or something else @ nikhil_mahen?
We consider 4-5 major types of KPIs- growth, efficiency, risk, experience. In some cases data clarity also becomes part of it but that’s rarer now.
For e.g. for a customer service inbound bot we are building for a real estate company - the KPI is leads converted to on-site visit of qualified candidates. As we have known percentages of conversion from on-site visit to seriousness to buy to becoming a customer - we can extrapolate the ROI.
An example of customer experience can be new ways of information discovery. For instance Sara AI in Saudi is a good example of a knowledge retrieval agent combined with a CDP (and some fancy AR tricks) for customer delight. The KPI can be a CSat score or % increase in spend etc.
Goal: convert qualified inquiries into on-site visits, then revenue
User Needs
What users are trying to do when they engage the bot
Understand if the company can help them
Get answers quickly without friction
Feel confident before committing to a visit
Avoid wasting time if they are not a fit
This is the anchor. Everything else maps forward from here.
User Outcomes (Design KPIs)
This is where UX metrics live
Mapped directly from your attitudinal and behavioral categories:
Attitudinal metrics
Trust: Do users feel comfortable sharing details?
Confidence / Sentiment: Do they feel reassured about next steps?
Helpfulness: Did the bot feel useful, not scripted?
Expectation: Did the interaction match what they thought would happen?
Behavioral metrics
Comprehension: Do users understand what the bot is doing and why?
Effort: How hard does qualification and booking feel?
Completion: Do users finish the flow?
Intent: Are users indicating real interest, not just curiosity?
These metrics explain whether the experience worked from the user’s perspective.
Product Outcomes (Product KPIs)
What the system successfully enables
Completed qualification flows
Visits successfully booked
Drop-off points in the conversation
Ratio of qualified vs unqualified bookings
Time to complete booking
This layer translates UX metrics into product behavior the team can act on.
Business Outcomes (Business KPIs)
What leadership already measures
Leads converted to on-site visits
Conversion from visit to buyer
Cost per qualified lead
Revenue attributed to bot-driven visits
Reduction in wasted sales effort
At this point, ROI extrapolation becomes credible because the chain is visible. The UX metrics contribute to design signals that can used as leverage to shift conversations and decisions.
I’d love to use this a reference material in the documentation @nikhil_mahen!
I find that there are big problems with most of what’s online. One reason it’s so difficult to find concrete examples online is that most design data can’t be cleanly packaged for sharing…so concrete examples are helpful (it’s also why we are sharing the concept tests).
Here’s what we have to overcome with Glare:
Design impact often shows up as fuzzy design signals (like trust, understanding, or reduced friction). Those are meaningful, but they don’t translate into tidy charts you can screenshot and post. So people end up talking about data in the abstract instead of showing it.
There’s also no shared playbook. Teams define metrics differently, collect them at different moments, and tie them to different goals. Even when someone shares a “case study,” it usually won’t map to another company’s reality without a lot of context that rarely makes it into a post.
The data itself is usually fragmented. Research lives in one place, analytics in another, revenue somewhere else. Pulling that together into a clear before-and-after story takes time, access, and internal trust. Most teams can’t do that publicly, even if they’ve done the work internally.
On top of that, causality is hard to prove and risky to claim for some people. Saying “this design change led to X outcome” invites scrutiny most teams aren’t ready for, especially when so many variables are in play. This needs to change in 2026!
And when teams do have strong examples, they’re often kept private. Real metrics, methods, and formulas are treated as competitive advantage, so what gets shared publicly is usually high-level or sanitized.
That’s why so much of the conversation stays abstract. There are helpful examples, but they’re hard to extract, generalize, and share safely.
