Research Patterns That Changed My Designs
The most valuable research finding is rarely a single comment.
Meaningful product decisions emerge when individual observations begin forming patterns across users, workflows, systems, and moments of friction.
These patterns have influenced how I organize information, prioritize actions, design operational workflows, and help users make decisions with greater confidence.
Research becomes more useful when separate observations begin telling the same story.
One comment may identify a problem. A repeated pattern helps explain how widespread it is, why it happens, and where the product needs to change.
During interviews, contextual inquiries, workflow reviews, and usability studies, I look beyond what users say they want. I study how they gather information, what they compare, where they hesitate, and which workarounds have become part of their routine.
The goal is not to turn every request into a feature. The goal is to understand the underlying behavior well enough to make a stronger product decision.
Six patterns that repeatedly changed the direction of my designs.
These patterns appeared across transportation platforms, enterprise systems, higher education websites, mobile applications, and decision-support products.
Users create workarounds when the product does not match the real workflow.
Spreadsheets, handwritten notes, bookmarked screens, and side conversations often reveal missing product support.
I map the workaround back to the underlying task and redesign the workflow around the information or action users are trying to preserve.
Users rarely make decisions from a single data point.
Operational decisions often require users to compare status, timing, history, exceptions, location, and supporting documents.
I group related signals around the decision instead of separating them according to database structure or internal ownership.
Repeated navigation often signals fragmented information architecture.
When users move back and forth between the same screens, they may be mentally assembling a view the product does not provide.
I reorganize the experience around the user’s question, bringing related context into one connected view.
Users need exceptions to stand out from normal activity.
Dense dashboards become difficult to scan when urgent issues, routine updates, and completed work receive equal visual weight.
I use hierarchy, status, alert behavior, and progressive disclosure to separate what requires attention from what is simply available.
Users interpret history differently when events lack context.
A list of updates may record what happened without explaining sequence, cause, ownership, or operational impact.
I introduce chronological timelines, event grouping, labels, and supporting details that help users understand how the current state developed.
The most visible interface problem may not be the root problem.
A request for another button, filter, or dashboard may originate from unclear ownership, missing information, or a broken process.
I investigate the surrounding workflow before selecting a solution, ensuring the design addresses the cause rather than only the symptom.
When users keep assembling information manually, the interface needs to become more connected.
This pattern has appeared repeatedly in operational products where users must understand a situation before taking action.
Users moved between multiple areas to understand one operational issue.
They reviewed current status, previous activity, documents, messages, and location information before deciding what to do next.
The product reflected separate features instead of a connected decision.
Each area worked independently, but the overall experience required users to remember details and reconstruct context themselves.
Related information was brought into one prioritized workflow.
The redesigned experience surfaced alerts, history, documents, status, and supporting context around the user’s primary task.
A repeatable framework for turning patterns into product decisions.
Patterns are not solutions on their own. They become useful when connected to user needs, business context, technical constraints, and measurable outcomes.
Record behaviors, quotes, questions, errors, delays, and workarounds without jumping immediately to a solution.
Compare findings across participants, roles, tasks, and research methods to determine whether a larger pattern exists.
Define the underlying information, decision, expectation, or workflow the repeated behavior represents.
Translate the pattern into information architecture, workflow, interaction, hierarchy, or content changes.
Test whether the revised design reduces friction and helps users complete the task more confidently.
The industries change. The human behaviors are often familiar.
Similar research patterns can lead to different interface decisions depending on the user, workflow, risk, and surrounding product environment.
Dispatchers searched across tools before responding to a changing load condition.
Decision context was distributed across status, map, history, documentation, and communication tools.
Create a unified operational view organized around load status, exceptions, history, and next actions.
Prospective students explored programs through several different mental models.
Students searched by academic interest, career goal, degree type, and preferred learning format.
Introduce multiple discovery paths supported by clearer taxonomy, filters, and consistent program information.
Teams struggled to distinguish urgent exceptions from routine information.
Every item received similar visual emphasis, increasing scan time and reducing confidence.
Prioritize exceptions, clarify status, and organize actions around operational urgency.
The right questions help separate symptoms from root causes.
Before changing the interface, I use research to understand why the behavior exists and what users are ultimately trying to accomplish.
What information are users gathering before they make a decision?
Which steps are part of the official workflow, and which are informal workarounds?
Where are users forced to remember, compare, or manually transfer information?
Which problems occur across multiple roles, and which are unique to one context?
Is the interface creating the friction, or is it exposing a deeper process problem?
What would users need to see, understand, or trust before acting?
Research informs the design. Testing determines whether the design works.
Even a well-supported pattern remains an interpretation until the proposed experience is tested with users and measured after implementation.
Better patterns lead to better product decisions.
I use research to understand how people work, identify recurring friction, and design enterprise products that support clearer decisions and more effective workflows.
