About — Taryn Bipat, UX Research

About

Hi, I’m Taryn.

UX researcher. Most of my work comes back to one question: what happens when a single product is asked to serve many different communities at once?

Research in three languages Many communities, one product Mixed methods, qual and quant PhD, Human Centered Design & Engineering

Background

How I got here, not to scale

A not-to-scale map of six career and life stops Six numbered stops joined by a dashed path: Trinidad and Tobago, College Park and Greenbelt Maryland, three languages, thirty countries, Seattle for the PhD, and Microsoft. The same six stops are described in the list below this image. 1 Trinidad & Tobago where my parents are from 2 College Park + Greenbelt, MD French immersion from age five 3 Three languages EN · ES · FR 4 30 countries and counting 5 Seattle, WA one community, or 312? 6 Microsoft
Trinidad & Tobago. Where my parents are from, and a mix of cultures that taught me early that identity rarely fits a checkbox. It’s why I go looking for the people a system wasn’t built for.
College Park + Greenbelt, MD. Hometown, plus a French immersion school starting at age five. The beginning of thinking in more than one language at a time.
Three languages. English, español, français. Enough to notice when a translated experience is technically correct and still doesn’t work.
30 countries. Each one a reminder of how differently the same problem gets solved.
Seattle, WA. A PhD asking whether Wikipedia is one community or 312 separate ones. The answer is 312, and it changed how I look at any product serving more than one language or population.
Microsoft. Research on AI platforms and developer tools, and getting product teams close enough to their customers to act on what they hear.

How I work

Discover to learn, and back again

Five stages, and the last one feeds the first. The loop is the part that matters. A study that ends at the readout is a study nobody checks.

A five-stage research process that loops back on itself Stage one, Discover: understand users, customers, teams, workflows, constraints and the broader system. Stage two, Frame: turn messy inputs into clear scenarios, hypotheses, product needs and decision points. Stage three, Concept: explore interaction models, solution patterns, prototypes and product narratives. Stage four, Align: tell the product story so designers, engineers, PMs, leaders and customers decide together. Stage five, Learn: use feedback, product signals and real-world adoption to refine direction and outcomes. An arrow loops from stage five back to stage one, because what gets learned resets the question. 01 Discover Understand users, customers, teams, workflows, constraints, and the broader system 02 Frame Turn messy inputs into clear scenarios, hypotheses, product needs, decision points 03 Concept Explore interaction models, solution patterns, prototypes, and product narratives 04 Align Tell the product story so designers, engineers, PMs, leaders and customers decide together 05 Learn Use feedback, product signals and real-world adoption to refine direction and outcomes WHAT WE LEARN RESETS THE QUESTION

Two stages do most of the work. In Frame, the question I ask before designing anything is what would be decided differently depending on the answer. If nobody can say, the study isn’t ready. And in Align, the mechanic I rely on is having the team sort the raw evidence themselves, so the finding is theirs and I stop having to sell it.

Principles

Five things I believe

Feel the product

A finding you read is information. A finding you experienced yourself is conviction. I put teams in the room with the people they build for, regularly, without slides in between.

Research from day one

Research shouldn’t audit a product, it should shape one. Brought in at the end, it sands the edges. Present at the start, it decides where the edges are.

The people who never touch it

Those most affected by a product are often not the ones using it: the family member doing it on someone’s behalf, the interpreter, the staff member who absorbs it when the digital thing fails. Research that only talks to users misses everyone the design already excluded.

Make it teachable

I’d rather teach a team to sit with a customer than hand them another deck. I taught design thinking to 10-year-olds. Now I teach product managers and engineers to run the parts of research they can run themselves, and I spend my time on the parts they can’t.

Match the depth to the decision

Not every question deserves a three-month study. Some need two days and a caveat. I’d rather give a team a fast read they can act on than hold up a decision waiting for certainty nobody needed. The skill is knowing which question you’re looking at.

In brief

A few specifics

English · Español · Français PhD, Human Centered Design & Engineering, UW BS, Cognitive Science, Carnegie Mellon Taught design thinking to 10-year-olds 30 countries

If we end up working together: expect to meet the people you’re designing for early and often, including the ones who never open the app, and to be closer to that work than you were expecting.

Taryn Bipat · UX Research · PhD, Human Centered Design & Engineering, University of Washington