Senior Product Designer · Enterprise Systems · Operational Workflows · AI-Assisted UX

From Interviews to Wireframes

Research-Driven Product Design

From Interviews to Wireframes

Turning user conversations, observed behavior, and workflow challenges into clear, testable product experiences.

Wireframes should not begin with screens. They should begin with an understanding of the people, decisions, information, and tasks the product needs to support.

Before the Interface

A wireframe is a product decision, not just a drawing.

Every screen reflects assumptions about what users need, what they should notice, and how the product should support their work.

Interviews provide valuable context, but the designer must still interpret what was heard, compare it with observed behavior, identify patterns, understand constraints, and determine which findings should influence the product.

Wireframes make those decisions visible. They give users, stakeholders, product managers, and engineers something concrete to evaluate before time is invested in visual design or development.

Research Inputs

Interviews are one part of understanding the product problem.

Strong wireframes combine what users say with what they do, what the business needs, and what the existing product reveals.

01
User Interviews

Understand goals, frustrations, and expectations.

Interviews reveal how people describe their work, where they feel uncertain, and what they believe would help them succeed.

02
Workflow Observation

See what actually happens during the task.

Observation uncovers workarounds, interruptions, dependencies, and behaviors users may not think to mention.

03
Product Analytics

Identify where users slow down, hesitate, or leave.

Behavioral data helps validate whether reported problems are also visible through navigation patterns and completion rates.

04
Business Context

Connect user needs to measurable product goals.

Business priorities, operational requirements, technical constraints, and compliance needs influence the final experience.

05
Support Feedback

Learn where the experience creates repeated confusion.

Support questions and training needs often expose gaps in navigation, terminology, system feedback, or product expectations.

06
Product Review

Understand what should change and what should remain familiar.

Reviewing the existing product distinguishes workflow problems from visual inconsistencies or isolated usability issues.

Research to Wireframe

Moving from conversations to testable product structure.

Each stage reduces uncertainty and creates a stronger connection between the research evidence and the proposed experience.

01
Prepare

Define what the research needs to uncover.

I clarify the product problem, known assumptions, audience, business goals, and decisions the team needs to make before scheduling interviews.

Questions
  • What do we need to understand?
  • Which assumptions need validation?
  • Who experiences the problem?
Outputs
  • Research objectives
  • Participant criteria
  • Interview guide
02
Interview

Understand goals, language, and working context.

I use open-ended questions to understand how people complete tasks, where they experience friction, and what information they rely on to make decisions.

I Listen For
  • Repeated frustrations
  • Uncertainty and hesitation
  • Workarounds and shortcuts
Outputs
  • Interview notes
  • Behavioral observations
  • Open questions
03
Synthesize

Turn individual conversations into meaningful patterns.

I compare interviews and observations to identify repeated behaviors, unmet needs, information gaps, decision points, and differences between user groups.

Activities
  • Affinity mapping
  • Theme identification
  • Evidence comparison
Outputs
  • Research themes
  • Opportunity areas
  • Prioritized findings
04
Map

Visualize the workflow and locate breakdowns.

I map the steps users take, the systems they use, the information they need, and the points where the process slows down or fails.

Activities
  • Task analysis
  • Journey mapping
  • Decision mapping
Outputs
  • Current-state workflow
  • Pain-point map
  • Future-state opportunities
05
Structure

Define what the product needs to communicate.

Before drawing screens, I define the information hierarchy, navigation, actions, feedback, and interaction priorities required by the workflow.

Activities
  • Information architecture
  • Content prioritization
  • User-flow development
Outputs
  • Page hierarchy
  • User flows
  • Interaction requirements
06
Wireframe

Make the proposed workflow visible and testable.

I create low- or mid-fidelity wireframes to explore hierarchy, sequence, interaction behavior, system responses, and responsive requirements.

Wireframes Explore
  • Information priority
  • Task sequence
  • Interaction behavior
Outputs
  • Core screens
  • Responsive states
  • Clickable prototype
07
Validate

Test whether the structure supports the real task.

I test wireframes with users and stakeholders to determine whether the workflow is understandable and where users still hesitate or lose confidence.

I Evaluate
  • Task completion
  • Navigation clarity
  • Decision confidence
Outputs
  • Usability findings
  • Revised wireframes
  • Validated direction
Evidence to Interface

Every wireframe decision should connect to a user need.

Research becomes valuable when it influences the hierarchy, interactions, workflow, and information presented in the product.

Interview Finding
“I have to look in several places before I understand what happened.”

Users are manually combining information from multiple product areas before they can make a decision.

Product Decision
Combine related status changes, updates, and activity.

Information is organized around the user’s decision instead of the product’s internal structure.

Wireframe Direction
Prioritize a unified timeline within the primary task view.

The wireframe tests whether users can understand the situation without navigating to another area.

What Wireframes Answer

Testing the product logic before visual design.

Wireframes help teams challenge early decisions while changes are still fast and inexpensive.

01

Is the most important information visible first?

02

Does the workflow reflect how users complete the task?

03

Are primary and secondary actions clearly differentiated?

04

Does the product provide enough feedback after an action?

05

Can users recover from errors or incomplete information?

06

Does the structure work across devices and product states?

Research in Practice

Different findings create different product structures.

The same research-to-wireframe process can support operational platforms, customer experiences, mobile applications, and enterprise systems.

Transportation Operations

Helping dispatchers understand changing load conditions.

Research Finding

Dispatchers searched across multiple areas to understand load status, history, documentation, and operational exceptions.

Wireframe Decision

Create a unified load view with prioritized alerts, current status, documentation, and a chronological activity timeline.

Higher Education

Helping prospective students find the right academic program.

Research Finding

Students approached program discovery through interests, career goals, degree types, and preferred learning formats.

Wireframe Decision

Introduce clearer filters, consistent program details, simplified navigation paths, and stronger calls to action.

Enterprise Platforms

Helping teams act on complex operational information.

Research Finding

Users compared multiple data points before determining which task, account, or operational issue required attention.

Wireframe Decision

Organize dashboards around priority, status, exceptions, recommended actions, and supporting details.

Wireframing Principles

What guides my early product decisions.

Wireframes should communicate the intended experience clearly enough to support testing, collaboration, and implementation.

01

Start with the task.

The structure should support what the user is trying to accomplish, not simply display available features.

02

Prioritize before adding.

Information earns its position through relevance, urgency, frequency, and impact on the user’s decision.

03

Design the entire workflow.

A successful screen connects to the steps before and after it, including loading, empty, error, and success states.

04

Use realistic content.

Real labels and data expose hierarchy and usability problems that placeholder content can hide.

05

Make assumptions visible.

Wireframes should show which decisions are supported by evidence and which still require validation.

06

Test before polishing.

Validating the structure early prevents teams from building visual design around an ineffective workflow.

The Value of Early Structure

Better wireframes create clearer conversations before development begins.

For Users

The workflow can be tested against real needs, tasks, expectations, and decision-making behavior.

For Product Teams

Product managers, designers, and stakeholders can align on priorities, requirements, scope, and tradeoffs.

For Engineering

Developers receive clearer workflow direction, interaction requirements, and responsive expectations.

Research-Driven Product Design

The best wireframes make user needs visible.

I translate interviews, observed behavior, workflows, product data, and business requirements into clear structures that teams can test, refine, and build with confidence.