Hey y’all, figured I’d drop a little bit of a thought exercise.
Shooting for outcomes was the one thing that I’ve always found to be tricky to understand, but as time went on, it became the source of truth that I try to follow on a day-to-day basis.
One funny way that I’ve found to correlate this to a real-world scenario (and why it can be so tricky) is this:
Wireframes are an output to the outcome of a design. Designs are the output to the outcome of code. Code is the output to the outcome of a product. A product is the output to the outcome of a solution. A solution is the output to the outcome of a problem.
How would you tie UX Metrics into this chain? Or would you change this chain entirely?
I likeeeee this. From an ops angle, I think of UX metrics as the checkpoints and feedback loops that keep this chain honest. Otherwise, wireframes, designs, or even shipped code can turn into deliverables for their own sake.
There’s a need to understand, across each stage of development, which metrics need to be gathered and how. Is this behavioral tracking or self reported? Etc…
Is this a helpful view? How would you recontextualize this?
Conversion is a metric we can consistently track across each of these steps, through user testing, beta testing, and Google analytic events.
Sentiment and Comprehension drop off into an inaccessible place (red) once things move to code. These are user self-reports, and the majority of companies will not introduce surveys for user feedback.
Ah, that makes more sense! It felt weird to have Sentiment and Comprehension next to conversion for some reason.
Unsure if that’s from bias on my end.
Also, why is satisfaction towards the bottom under conversion rather than being above with sentiment and comprehension? The chart is starting to piece together much better in my mind but there are still some gaps creating some confusion for me
