buttons
UX research

UX RESEARCH / COMPLEX PLATFORMS

I study how experts make decisions inside complex technical systems.

Rigorous research is the foundation of my practice. I work to deeply understand the experience of a user, a customer, or a person navigating a complex system. I also generate ideas directly from the research I conduct—using sketches, proposals, and prototypes to make findings tangible and easier to act on.

SCROLL TO EXPLORE ↓
EXPERIENCE
More than a decade in industry
EDUCATION
MS, Human Centered Design & EngineeringResearchDesignEngineering
FOUNDATION / PRACTICE
Grounded theory → Research through delivery
EvidenceClustersPatternsTheorytheoryInsightIdeaAction
01
Financial data

PitchBook × Private Credit

Users
Private debt investor and the team supporting them. Deal leads and advisors were compared in the research.
Timeline
2022–2024
  1. Aug–Nov 2022Discovery research
  2. Jan–Mar 2023Domain research
  3. Apr–Jun 2023Contextual research
  4. Jul–Aug 2023Usability testing
  5. Nov 2023Customer feedback sessions
  6. Jan–Feb 2024Editorial research
Research questions
PitchBook acquired LCD, bringing together qualitative analyst commentary, specialist credit data, and an existing financial-data platform. The integration question was not simply where to place the new information. We needed to understand how credit professionals used it differently depending on their role, institution, authority, and the stage of a live deal.
Studies / investigation
I conducted contextual inquiry, phone interviews, working-session replays, and complete-deal walkthroughs. I compared the work of deal leads and advisors, modeled roles and decision points, analyzed private-credit transactions, and studied how editorial and customer taxonomies aligned. One taxonomy study involved 30 editors and 20 customers across more than 40 categories.View the card-sort study →
Findings
What began as a single user became a team of dedicated roles. Team hierarchy and a person’s position on a deal changed the information they needed and could access. These differences had critical implications for the interface: which data to show, how to organize it, and how to support the decisions each role could make.
  1. 01
  2. 02
  3. 03
    • Choose asset class
    • Size & scope
    • Risk profile
  4. 04
    • Narrow types
    • Sort spreads
    • Filter range
  5. 05
    • Review skeleton
    • Download data
    • Save access
  6. 06
    • See changes
    • Explore from base
    • Remove from list
A model of searching, evaluating, and returning to deals in the debt market.
Evidence → decisions
Time constraints tied to the acquisition of LCD from S&P made prioritization urgent. Focusing on the CLO market helped us improve and integrate the most valuable data for key accounts before expanding across private debt. The research shaped the credit dashboard, deal-sheet information architecture, CLO data architecture, and the sequence of the wider integration roadmap.
OPEN CASE STUDY ↗
02
Civic technology

Socrata Open Data

Users
Program owners, data stewards, IT teams, platform administrators, publishers, and downstream public users.
Timeline
2017–2022
  1. 2017Mixed methods and action research with government programs and program managers
  2. 2018Domain inquiries: transportation, housing / land use, and permitting
  3. 2020CDC response research and public data analysis
  4. 2021UX program planning: Product User Group
  5. H2 2021Voice of Customer data collection
  6. 2022Tyler research repository and data-sharing program
Program structure
UX program across four quartersA repeatable program structure; illustrative sequencing. Select an activity for details.
SwimlaneQ1Q2Q3Q4
Questions + alignment
Research studies
Synthesis + reporting
Product + delivery
Research operations
Research questions
Government data could pass through source systems, spreadsheets, program owners, data stewards, IT teams, platform administrators, and public users before becoming useful. When something failed, the visible error was often separated from the decision or transformation that caused it. We needed to understand the entire publishing system well enough to help teams diagnose and repair it.
Studies / investigation
I analyzed 30–40 hours of inherited interviews, conducted additional interviews, reconstructed publishing and ingress workflows, and examined product analytics, NPS evidence, system logs, and advisory-board feedback. I worked across transportation and other government domains, built architecture and service models, and used scenario testing, design spikes, and prototypes to make the emerging system concrete.
Technical research: database structures
Database relationship map examined during technical research into government information workflows.
We examined database structures to understand how changes to the backend could enable features in high demand among larger governments. This map then helped us trace how a program manager gets information from a centralized IT group. The source is dense; it is included as supporting evidence of the technical investigation.

How do we model a government problem?

    • Request a dataset
    • Review existing datasets
    • Extract from a database
    • Set up a connector to DB
    • Find / write metadata
    • Identify / find outliers
    • Analytical review
    • Extract available insights
    • Track down questions
    • Add more data
    • Add content / context
    • Identify relations
    • Make new relationships
    • Categorize / bucket data
    • Encode information
    • Set base visualizations
    • Refine and clean up story
    • Shape data
    • Plan visualizations
    • Consolidate presentation
    • Reshape data for needs
    • Automate / systematize
    • Iterate on assets
We used this simplified outline to shape discussions about the problems governments are asked to take on: obtaining and exploring data, modeling the question, and visualizing it. It helped connect the stated problem with the work required to investigate it.
Findings
Open-data publishing was distributed work. Program owners understood the meaning of the data; technical teams understood its infrastructure; publishers were responsible for its public quality; and downstream users depended on provenance and consistency. Most failures appeared at the handoffs between those responsibilities. Teams needed visibility, lineage, and correction—not simply faster ingestion. We also found that users cared about specific assets, but the term meant different things across the user base. Understanding what each person meant was essential to modeling the program and its information.

Program assets

The departmentProgramDomain-Specific TemplateProgramPerformance TemplateProgramStand-aloneDatasetsModelsAsset partsAudienceViewsDerived viewsPublishingViewer consumptionInsightsInsightsCreator consumptionCommunication
Users cared about specific “assets,” but the word meant different things across the user base. This model makes the relationships between datasets, models, views, publishing, and the people creating and consuming them explicit.

Add a dataset: roles and handoffs

Extract ↔ Transform ↔ Load ↻ Review and refine together→ Metadata → Publish
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
I created this DMX workflow model to show where work passed between users in complex agencies. Following a dataset from extraction through metadata and publication made the handoffs—and the work of fixing errors and refining ingress—visible.

Housing affordability as a program

Government data
Land parcel
Shared geographic context
Questions
  • Makeup of neighborhood?
  • Density of neighborhood?
  • Food deserts?
  • Transit gaps?
  • Avg. rent? Home price?
  • Vulnerable populations?
Planning needs
  • Predicted growth
  • Scenarios
  • Outreach priorities
Audiences
  • Planners
  • Residents
  • Mayor
  • City council
  • Renters
  • Prospects
From our research into government programs, I mapped clusters of data and the people who use them alongside program needs and the questions they receive. This housing-affordability example connects land use, permitting, and neighborhood data with planning scenarios and audiences.
Evidence → decisions
The research informed error-correction capabilities and the longer-term direction of Socrata’s data-management and ingress platform. I carried the workflow model and product narrative with product management and worked directly with engineering as the findings became releasable software.
Whiteboard prototype developed from a research debrief about a program manager in a specific government department.
Research leads to ideas. This whiteboard prototype grew out of a research debrief about the program manager role in the context of a specific department. Sketching made the findings concrete enough to discuss possible workflows and interfaces—a step from understanding the work toward proposing how to support it.

From key results to a scenario

Observed resultsCurrent periodProjectionMarchApril

Illustrative scenario from the research artifact. Controls demonstrate possible changes, not a measured forecast.

Research used directly in design. This working artifact captured a discussion about government key results and how a data scenario played out. Although dense, it helped clarify the specific features that overlapped in that scenario. My design lead made direct use of it.
Released data transforms interface for wrangling and standardizing data during ingress.
Ingress research showed that technical users repeatedly encountered the same errors. We built transforms that let them automate error identification and reuse data-cleaning logic during updates, bringing recurring work into the publishing workflow.
Historical Tyler launch slide announcing general availability of the new Socrata data pipeline experience.
We used prospective feature mockups to start customer conversations, then worked backward to understand their needs in the import process. That research became a shipped feature that continues to shape government data publishing across the broader Tyler platforms. This historical launch slide documents the released experience.
OPEN CASE STUDY ↗
03
Academic research

ProQuest RefWorks

Users
Students, librarians, scholars, faculty, graduate students, and discipline-specific research groups.
Timeline
2013–2017
  1. 2013Young researcher studies
  2. 2014Group studies with young researchers
  3. 2015Entity-wide contextual inquiry with advanced researchers
  4. 2016Shadowing research groups and labs
Research questions
RefWorks was established inside universities, but newer tools were changing researchers’ expectations. Librarians needed a product they could confidently recommend and support. Faculty, graduate students, and research groups needed something that could survive the scale, duration, and collaboration of serious scholarly work.
Studies / investigation
I led multiple phases of research with students, librarians, scholars, and discipline-specific research groups. The work included interviews, observation, contextual inquiry in labs and offices, diary research, surveys, coded NPS, competitive analysis, workflow reconstruction, co-creation, prototyping, and usability testing.
Findings
Citation management was only one part of the job. Researchers moved repeatedly between discovery, reading, annotation, experimentation, collaboration, writing, funding, teaching, and publication. Their needs also expanded as they moved from novice to domain expert and took on more responsibility for other people’s work. The opportunity was continuity across that changing research practice—not a longer list of citation features.
Evidence → decisions
The program produced personas, workflow models, explicit value propositions, and a five-year product horizon. It helped reframe RefWorks as a reusable research environment and guided concepts, features, usability work, and the institutional story communicated to more than 500 librarians.View the RefWorks presentation ↗
OPEN CASE STUDY ↗

RESEARCH OPERATIONS / PITCHBOOK

A research practice other designers could use.

At PitchBook, I built shared guidance for planning, conducting, and reporting research. It helped onboard UX designers to run their own studies while giving the team a consistent way to frame questions, select methods, synthesize evidence, and communicate findings.

VIEW THE WORKING OUTLINE ↗Early artifact—the structure is visible, but much of the instructional content is still missing.
01Plan

Move from the stakeholder’s request to an agreed question, a research plan, and a prepared kickoff.

  1. 01Business /
    Team Request

    Surface the decision and its context.

  2. 02Core Research Question

    Agree what the research needs to answer.

  3. 03Research Plan

    Choose the methods, people, and evidence.

  4. 04Review Session

    Check assumptions and align on the approach.

  5. 05Project Logistics

    Prepare recruiting, access, and scheduling.

  6. 06Research Operations Kickoff

    Confirm responsibilities and begin the work.

02Conduct

CARE

I use CARE to structure grounded theory projects, and adapt its collection, analysis, reporting, and evaluation cycle to quantitative and mixed methods research.

CAREPracticeQualitativeQuantitative
C — Collection

Collection

Establish a predetermined data structure so observations can be captured consistently and traced back to their source.

Interviews, contextual inquiry, observation, diary studies, and usability sessions.

Tools: Interview guides, session recordings, and structured observation notes.

Surveys, NPS, product analytics, transaction data, and system logs.

Tools: Survey instruments, data exports, and structured datasets.

A — Analysis

Analysis

Compare evidence through emergent and pre-coded qualitative coding, or the analytical approach appropriate to the method.

Emergent and pre-coded analysis, constant comparison, and workflow reconstruction.

Tools: Codebooks, evidence matrices, and affinity maps.

Compare distributions, segments, trends, and outliers across measures.

Tools: Spreadsheets, charts, and data queries.

R — Reporting

Reporting

Share incremental findings, bring them together in periodic reports, and refine the interpretation as the project develops.

Connect themes and models to traceable observations and participant accounts.

Tools: Research summaries, workflow diagrams, and evidence-linked presentations.

Explain patterns, differences, and uncertainty in the measures.

Tools: Charts, comparison tables, and annotated data summaries.

E — Evaluation

Evaluation

Conduct project meta-analysis, refine the system, create reusable templates, and return to unvisited research questions with continuing potential.

Revisit contradictions, compare studies, and identify unanswered questions.

Tools: Research repositories, retrospective notes, and reusable study templates.

Review data coverage and measure changes across time or groups.

Tools: Metric histories, comparison tables, and data-quality checks.

03Report

Reporting connects the developing model to decisions. I share incremental reports throughout the work, then bring the evidence together into a cohesive project report.

  1. Agree on touchpoints

    Decide with the stakeholder or client when and how findings will be discussed.

  2. Interpret together

    Use interim reports, debriefs, and working sessions to extract insights, challenge interpretations, and surface new questions.

  3. Build the cohesive account

    Connect findings across the project, preserve their evidence, and support the team in turning insights into actions.

I research decisions, not only screens.

I study who is involved, which information they trust, what limits their choices, and what happens before and after they use the product.

01

Grounded theory

I code and compare evidence across participants, roles, and situations. Collection and analysis evolve together, turning observations into a model a team can inspect and challenge.

02

Enter the work where it happens

I use interviews, contextual inquiry, observation, recorded-session replays, and concrete workflow walkthroughs to understand how people actually work.

03

Synthesize evidence

I triangulate qualitative findings with product analytics, survey and NPS data, market information, system logs, and technical constraints. Contradictions reveal the next question.

04

Model people, workflows + systems

The result might be a workflow, decision model, taxonomy, service map, or research-derived product principles. The model makes relationships and constraints visible.

05

Turn findings into decisions

Decisions

I work with product, design, data, and engineering to translate findings into requirements, prototypes, architecture, sequencing, and release decisions. I stay with the finding through delivery.

EMERGING PRACTICE

AI for research operations.

I’m exploring how AI can support the work around research: organizing evidence, tracing findings back to their sources, and turning questions into sketches and prototypes. The aim is to make research easier to use while keeping interpretation and judgment accountable to people.

This is an emerging direction that connects with BUTR. For now, I’m developing small experiments around concrete research tasks and documenting what helps, what fails, and what needs human review.

VIEW THE EXPERIMENTS →
  1. Evidence
  2. Experiment
  3. Human review

Writing &
working theory.

Selected reports, frameworks, and literature reviews that show how I frame questions, synthesize evidence, and develop a point of view.

01
THEORY + SYNTHESIS / 2018

Making Dimensions of Human-Centered Design & Engineering

A framework for locating human-centered work across people, problems, process, and purpose.

This piece maps human-centered work across four dimensions: people, problems, process, and purpose. It explores how practices move between individual experiences and larger systems, where disciplinary approaches overlap, and how making a framework reveals the assumptions of its maker.

VIEW →
02
RESEARCH PRACTICE / 2019

Penny-Wise, Pound-Wise

A practical argument for making smart tradeoffs in usability research without trading away the integrity of the evidence.

A response to Susan Dray and David Siegel’s 1999 article on cost-effective usability practice, grounded in my own experience conducting product research at RefWorks and Socrata.

VIEW →
03
CONFERENCE REPORT + PUBLIC INTEREST TECHNOLOGY / 2020

Building Community-Centered Civil Justice Open Data Initiatives

A framework for making civil-justice data open, useful, ethical, and accountable to the communities.

Presented with Abhijeet Chavan and Maureen Johnson at the 2020 Self-Represented Litigation Network Conference in Nashville. The session connected open-government practice, civil-justice reform, data governance, and community participation.

VIEW →
04
LITERATURE REVIEW + VISUAL ANALYTICS / 2018

Collaborative Sensemaking in Visual Analytics

A literature review examining how groups notice cues, build interpretations, and act through shared analytical systems.

Created for HCDE 548 at the University of Washington. The review systematically examined 22 ACM papers and additional cited literature across HCI, CSCW, and visual analytics.

VIEW →

My research process in a nutshell

Always be rigorous enough to trust.Always make research actionable.

I love researching complex people, technology, and processes. Understanding how systems actually work—and finding consequential questions that can change them—is where I find professional joy.