When I started in UI/UX design, it was all about the design itself: how it made users feel, the screens, the steps to complete an action, and testing with users. I worked in agile teams, getting user stories and acceptance criteria from product managers. Then I would sit down and design screens, flows, and interactions. Sometimes I stayed up all night just to make the flow clean enough for sprint planning the next day. The work was focused on usability: did users understand the screen? Were there too many steps? Could friction be reduced? Most feedback from engineers and product people was either practical, “Can this actually be built?” or focused on usability refinements.
Back then, success in UX was measured mostly by qualitative signals: usability test feedback, smoother flows, fewer steps, and an overall better experience for users. That was my day-to-day focus.
Then everything changed. Suddenly, the question wasn’t just “Does this feel good and usable?” but “How is this contributing to the business?” Leadership started asking for numbers: dashboards, funnels, conversion rates, and product analytics. UX work alone didn’t feel enough anymore.
I remember one project vividly. I had designed a stock trading experience flow. Usability tests went well; users navigated the flow easily. But in the monthly review meeting, the focus had completely shifted. It wasn’t “Can users use our application?” anymore. It was “What are our revenue this month versus last month?”
When the data team answered, there was a sharp drop in the metrics compared to the previous month. The question became: what changed? Was this a UX issue? Were users confused in the live environment? Or was it a technical issue? Even though usability testing had gone well, the live metrics told a different story, and we needed both perspectives to understand what was really happening.
That moment hit me: designers need to understand the story behind the numbers. My role shifted from just producing screens to interpreting impact, connecting qualitative insights to quantitative signals, and asking the right questions when the data doesn’t tell the full story.
Designers today are expected to connect their work to metrics. It’s no longer enough for a flow to “feel” intuitive; leadership wants numbers to show impact.
For us, this means reading dashboards and collaborating with data and engineering teams to create dashboards that reflect real user behavior. I had to understand event tracking, set up funnels, and monitor metrics like conversion rates or drop-offs.
Part of my work involves creating an event tracking dictionary. An event tracking dictionary is essentially a reference document used in product design, analytics, and UX research to standardize how user actions (events) are tracked in an app or website. It helps teams capture meaningful, consistent data about user behavior so that analytics are reliable and interpretable across the organization.
Purpose:
Here’s a simple guide:
Interpreting the numbers became part of my weekly routine. A drop-off isn’t just a red flag; it’s a question: is this a UX issue, confusion, or a technical glitch? Each metric needed context, and that’s where designers step in.
In my team, this changed how I approached design. Every sprint, every adjustment, wasn’t just based on instinct. If data suggested friction in a flow, I ran the investigation, talked to users, reviewed session replays, and adjusted the design. The goal was to tie decisions to evidence, not opinion.
The new expectation is clear: designers aren’t asked to become data scientists. We interpret data, ask the right questions, and use it to make better designs. The skill lies in bridging numbers and human behavior, figuring out what a metric really says, and deciding what design action to take in response.
This project made the gap between metrics and human behavior impossible to ignore.
A stock trading application I worked on. The flow was simple: users entered the stock trading section, saw a list of available stocks, selected one, and landed on a buy page. From there, they could proceed to purchase. Once the design was completed and tested, the feature went live.
After launch, we began monitoring performance through our dashboards. The data immediately flagged a problem: many users were dropping off at the buy page. A display issue on iOS devices hid the buy button, so the initial conclusion in a review meeting was that the UX was bad.
From a purely metric-driven perspective, this looked reasonable. But it didn’t feel right.
Stock trading is high-risk. Users don’t always buy immediately; hesitation is natural. So I went deeper. I reviewed session replays and watched user behavior. Users weren’t stuck; they were exploring, reading, and then navigating back to the stock information page.
To validate this, we reached out to users who had dropped off. Most said:
The data was correct, but the interpretation was wrong. The drop-off wasn’t a UX failure; it was a decision-making moment. Users needed reassurance, context, and time. The insight reshaped how the team approached engagement: marketing created follow-up emails and push notifications, rather than trying to “force” users to buy immediately.
This reinforced a critical lesson: designers don’t add value by producing data or blindly following it. We add value by challenging what the data appears to say and reintroducing human behavior into the conversation.
None of this undermines the importance of data scientists. Product teams need them, they bring rigor, structure, and statistical depth. They build models, optimize metrics, and identify patterns across large datasets.
Designers, however, are trained for something different. We focus on understanding human behavior, interpreting context, and identifying unintended consequences. We notice when something technically works but still feels confusing, frustrating, or emotionally draining.
Trying to fully become a data scientist comes with risks:
The real value emerges when each role stays grounded in its strength. Designers don’t need to optimize algorithms; we need to understand what metrics mean in human terms and when they need to be questioned.
Metrics are signals; they tell us what happened, not why. Designers step in to explain the meaning behind those numbers.
A drop-off might mean confusion, or it could mean hesitation, comparison, or deliberate choice. High engagement might signal value or frustration. Designers ask whether metrics reflect real value, short-term optimization, or something more problematic.
When designers work with data, we act as bridges, connecting quantitative signals to qualitative insight, intent, and long-term impact. We help teams understand not just what changed, but what it means for users.
When designers don’t challenge metrics, problems accumulate quietly.
Pushing back doesn’t reject data; it ensures metrics are interpreted, understood, and used responsibly.
The real gap in modern UX teams is not a lack of tools or technical literacy:
Most designers today can read dashboards, understand funnels, and collaborate with analytics teams. Tool access is no longer the bottleneck. The deeper gap is what happens after the data appears.
The gap is interpretation, judgment, and ethics.
Data can show what happened, but it cannot explain intent, hesitation, fear, or trust. It cannot tell you whether a user clicked because they felt confident or because they felt cornered. That distinction requires human judgment, contextual awareness, and an understanding of behavior beyond numbers.
Designers who can bridge data and human context bring something rare to product teams. They do not compete with data scientists. They translate insights into meaning. They ask whether outcomes align with user intent, business values, and long-term impact.
This is why designers with this skill set become trusted partners, not just executors. They are invited earlier into conversations, relied on during ambiguity, and listened to when metrics feel contradictory. In AI-augmented teams, especially where systems generate insights faster than ever, the ability to question, interpret, and contextualize becomes even more valuable.
The future does not belong to designers who collect more data. It belongs to designers who can decide what the data should and should not be used to justify.
Designers are no longer just interface makers; they are interpreters between systems and humans.
As products grow more complex and data becomes more persuasive, our responsibility expands. We don’t just design or accept the data from the dashboard; we challenge assumptions. We don’t reject metrics; we ensure they don’t replace understanding.
Data needs challengers, not just producers.
And that is where UX designers still matter most.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Linear-style UIs look simple, but the theming system has to do real work. Here’s how to meet WCAG 2.2 contrast requirements across light, dark, and high-contrast modes — whether you’re using a UI library or rolling your own tokens.
Linear design is a minimalist SaaS aesthetic inspired by Linear. Here’s what to use to recreate it — from Radix UI + shadcn/ui ecosystems to Linear-style Figma kits — plus how to structure pages using modular components and an 8px spacing scale.
Teams often use “customer” and “user” interchangeably — until it breaks alignment. Here’s how separating the two clarifies research, prioritization, and messaging across B2C, B2B, and B2B2C products.
AI is great at producing copy fast. UX writing isn’t about speed. It’s about meeting users where they are. Here’s how to use AI to support your UX writing workflow and where human judgment remains non-negotiable.
Learn more →
