UX RESEARCH / COMPLEX PLATFORMS

I study how experts make decisions inside complex technical systems.

Even in leadership roles, 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.

EXPLORE THE RESEARCH ↓See how research becomes an idea →
EXPERIENCE
More than a decade in industry
  1. ProQuest
    • Research Companion
    • SIRS Discoverer
    • CultureGrams
    • RefWorks
    • Pivot
    • Intota
    • Assistant
  2. Socrata / Tyler
    • Open Data
    • Government Cloud
    • Tyler Data
  3. PitchBook
    • PitchBook Credit
    • Institutional Investors
  4. AIWhat I made ↗
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
    Search for a debt deal
  2. 02
    Advanced search
  3. 03
    Set deal criteria
    • Choose asset class
    • Size & scope
    • Risk profile
  4. 04
    Filter & sort results
    • Narrow types
    • Sort spreads
    • Filter range
  5. 05
    Review a specific deal
    • Review skeleton
    • Download data
    • Save access
  6. 06
    Save a deal to return to
    • 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
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?

  1. Obtain the data
    • Request a dataset
    • Review existing datasets
    • Extract from a database
    • Set up a connector to DB
    • Find / write metadata
  2. Explore the data
    • Identify / find outliers
    • Analytical review
    • Extract available insights
    • Track down questions
    • Add more data
    • Add content / context
  3. Model the question
    • Identify relations
    • Make new relationships
    • Categorize / bucket data
    • Encode information
    • Set base visualizations
    • Refine and clean up story
    • Shape data
  4. Visualize it
    • 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 departmentProgramTemplateProgramTemplateProgramTemplateDatasetsModelsAsset 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

  1. 01
    Extract
    • Transform
  2. 02
    Load
    • Transform
  3. 03
    Dataset metadata
    • Fix errors & refine ingress
  4. 04
    Column metadata
    • Fix errors & refine ingress
  5. 05
    Publish
    • Automate ingress
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

  1. 01
    Government data
    • Land use
    • Permitting
    • Budget
    • Neighborhoods
    • Asset management
    • Code enforcement
  2. 02
    Land parcel
  3. 03
    Questions
    • Makeup of neighborhood?
    • Density of neighborhood?
    • Food deserts?
    • Transit gaps?
    • Avg. rent? Home price?
    • Vulnerable populations?
  4. 04
    Planning needs
    • Predicted growth
    • Scenarios
    • Outreach priorities
  5. 05
    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 periodProjectionMarchAprilParametersIllustrative scenario from the research artifact
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.
  1. 01
    Plan

    Frame the research questions, select an appropriate method, and decide how the work will be synthesized.

  2. 02
    Conduct

    Use shared guidance for qualitative methods, quantitative methods, and usability testing.

  3. 03
    Report

    Turn observations into findings that product and engineering teams can understand and use.

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

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 represented within it.

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 rigorous enough to trust.Always useful enough to act on.

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.

Learn more about my research.