Goals, not features are the key to product success

I start every project by clarifying the intended outcome, then determine what needs to change to achieve it. My approach adapts to the product, the team, and the uncertainty involved—from clarifying the problem to defining behavior and working through implementation.

Process overview

Diagram showing steps in UX design process including definition, discovery, design and development. — An overview of definition, discovery, design, and development. Diagram courtesy of Nielsen Norman Group (NN/g).

Goals before solutions

I work with stakeholders to turn broad ambitions into actionable goals: making permissions easier to understand, helping learners assess their skills, or giving care teams visibility across a patient’s journey. Those goals guide scope, priorities, and the design effort we commit to.

The response may be an interface change, a new capability, or a better operational process. I choose the approach around the outcome instead of assuming every problem needs a new screen.

Research that informs a decision

I investigate what we need to know when uncertainty could change the direction of the work. The method follows the question:

Interviews reveal priorities, expectations, and mental models.
Observation reveals behavior and workarounds people may not think to describe.
Documentation review helps establish existing system behavior, constraints, and domain knowledge.

I document findings separately from interpretation and connect them to the decisions they inform. In discovery research at O’Reilly with Ariana Brandao, we examined an opportunity to improve engagement through highlights. The research did not confirm the assumption that seeing other people’s highlights would encourage users to create their own; I kept that distinction explicit in the recommendations.

Research questions and assumptions are linked to findings and their sources.

Research findings and recommendations

Findings and insights are documented separately so readers can distinguish evidence from interpretation.

The research report records the evidence used to evaluate the opportunity.

Assumptions remain explicit when the research does not establish a conclusion.

Requirements that define behavior

I work with Product, Engineering, and other partners to describe what the system needs to enable, who needs it, and why. Clear requirements make scope and dependencies reviewable before they become interface decisions.

For complex domains, I examine requirements for completeness, contradictions, and missing relationships. The format matters less than whether the team can understand and act on them. Requirements quality is part of that review.

Requirements example

A water-filtration example illustrates how requirements define system capabilities beyond software.

Requirements for a conversational learning experience, co-authored with my O’Reilly Product partner Miranda Mota.

Search requirements developed with my Kong Product partner Nathanael Shermett define expected behavior and capabilities.

Concepts that make the direction concrete

I translate goals and requirements into an experience model, then choose the clearest way to communicate it: a flow, a wireframe, an annotated design, or an interactive prototype.

An experience strategy connects the text-based course concept to its learning goals.

Reviews bring stakeholder knowledge and technical constraints into the design. Where possible, I test concepts with representative users. When schedules limit testing, I make the assumptions and risks clear so the team understands what it is building on.

Annotated search states communicate how the Kong Dev Portal widget should respond.

System behavior and enablement logic

Enablement logic defines the conditions under which identity-provider team mapping is available.

Search behavior and logic documented during discovery at Kong.

Design intent through implementation

My specifications cover flows, states, interactions, edge cases, and feedback. I organize them so developers can find the behavior they need to implement, alongside the relevant screens and components.

Shift Board specifications are organized by user flow and screen size.

The Compass Digital healthcare library’s date picker, developed with Engineering partner Abhinav Vinnakota.

I stay involved through release, answering questions and working through implementation details with Product and Engineering. When decisions affect other functions—such as Legal, Compliance, Analytics, or Marketing—I bring those partners into the conversation.