CASE STUDY · UX ENGINEER TAKE HOME
LIVE ON VERCEL
From arXiv data to a working research explorer
For a UX Engineer take home, I was given an arXiv dataset and asked to build an interface for exploring research activity. I spent about four hours understanding the data, designing the experience, and deploying the app.
I started with the data because the way I counted and grouped it would shape what users took away from the interface.
I spent the first hour reviewing the data and the next three designing, building, and deploying the app. I kept records and unique papers separate, added filters, and made the source data easy to inspect.
The first design decision was what to count
I spent the first hour exploring the dataset in a notebook. Each row linked a paper to an affiliation, so counting rows as papers would overstate research activity. Names such as “MIT,” “M.I.T.,” and individual departments also appeared separately. I kept record and paper counts distinct, and affiliation names visible, so the explorer would not imply a definitive ranking of institutions.
Turning those findings into an interface
With those distinctions clear, I designed a path from a broad dataset to individual records: narrow the results, understand the overall pattern, then inspect the source. Each step needed to make clear what the results represented.
With over 100,000 affiliation strings, I chose text search over a long dropdown. Subject and year filters provide other ways to narrow the results.
Record count, unique papers, and date range appear before the charts and table. This gives users context for how their filters changed the results.
// short queries match whole tokens, not substrings
if (query.length <= 4 && !query.includes(" ")) {
return normalized.split(" ").includes(query)
}
return normalized.includes(query)Carrying the data decisions into code
I built the interface in React and TypeScript, keeping filtering and aggregation in separate functions. This let me refine the presentation without mixing it with the counting logic. I used the remaining three hours to build, clean up the code, document the decisions, and deploy the app on Vercel.
src/components/ FilterPanel · SummaryCards · TopList
· ActivityByYear · RecordsTable
src/utils/ normalizeRecords · filters · aggregations
// pure functions, kept apart from rendering
src/types/ typed arXiv model, end to end
notebooks/ 01_data_exploration.ipynb
// understand the data before any UIABOUT 1 HOUR EXPLORING THE DATA · 3 HOURS BUILDING AND DOCUMENTING
Deciding what could wait
Getting the explorer deployed meant deciding what to finish within four hours. I prioritized clear counts, useful filters, and access to source records. Affiliation grouping, pagination, and automated tests remained unfinished, so I documented those limits and kept the logic separate to support the next round of work.
What I would carry into a larger project
The strongest part of the exercise was connecting data exploration to interface decisions. The biggest open question was whether those decisions supported the way researchers actually explore this data.
HOW I CONTRIBUTED
Owning both design and development let me connect the data findings directly to the experience. I set the scope, built the filtering and aggregation logic, and documented the limits so someone reviewing the app could understand its assumptions.
Within four hours, I turned the dataset into a deployed explorer with clear counts, more precise search, and access to source records. Starting with the data made those choices possible. For me, UX engineering includes the logic behind what people see, because the way we count and match data shapes the conclusions someone can draw from an interface.