Skip to content
ale@portfolio:~/portfolio$ cat README.md

portfolio

Every case study here answers one question: measurable outcome.

catalog-app.mdZapier

In-House Data Catalog App ("cat-a-log")

ShippedTeam: Data + DesignPhased
TL;DR

A data-to-English dictionary, search bar UX with e-commerce-style filters, so anyone could find, tag, and monitor data assets without switching screens.

Outcome

  • 16user research interviews
  • ↑daily usage & adoption company-wide
Saw It
  • The Looker-based catalog (v1) proved the need, but users still had to switch screens to search, tag, and monitor.
  • Open question was whether a fully custom in-house tool could match what 20 vendors offered, without the technical debt of a third-party dependency.
↓
Figured It Out
  • Evaluated 20 catalog vendors against real user feedback before deciding to build.
  • Ran 16 user research interviews across technical and non-technical users post-launch, directly reshaping the roadmap.
↓
Did It
  • Built a web-based search engine on top of the existing metadata ETL.
  • Added drop-down filters to avoid overwhelming users, free-text annotation, and role-based tag/ownership permissions with visible monitoring charts.

My Role

Owned the build-vs-buy synthesis from the 20-vendor evaluation, ran and synthesized the 16 user interviews into roadmap changes, and onboarded UX Research to mentor the team on interview technique, a deliberate investment in the team's discovery muscle, not just this one project.

Engineering Collaboration

Partnered with a designer to simplify the UI into drop-downs rather than exposing all metadata at once. The tradeoff was discoverability vs. overwhelm, resolved by user testing. Project pace was directly constrained by not having a dedicated full-time developer, a real resourcing tradeoff I had to manage.

Full breakdown

Problem & Risk

Feasibility RiskUsability Risk

The Looker-based catalog (v1) proved the need, but users still had to switch screens to search, tag, and monitor. The open question was whether a fully custom in-house tool could match what 20 vendors offered, without the technical debt of a third-party dependency.

Customer Discovery & Validation

Evidence

Evaluated 20 catalog vendors against real user feedback before deciding to build. Ran 16 user research interviews across technical and non-technical users post-launch, which directly reshaped the roadmap and confirmed the underlying ETL's data quality.

Context

Based on user feedback that switching screens caused confusion, the decision to build in-house was about control: full ecosystem coverage and zero third-party technical debt, in exchange for owning the build.

Timeline

git log --oneline⏱ shipped in phases
kickoff: 20-vendor evaluation confirms build-vs-buy casePhase 0
ship v1: search UI + filters live, built on existing ETLPhase 1
research: 16 user interviews, technical + non-technicalPhase 2
blocked: roadmap paced by lack of full-time developerOngoing

What We Did

Built a web-based search engine on top of the existing metadata ETL, with drop-down filters to avoid overwhelming users, free-text annotation, and role-based tag/ownership permissions with visible monitoring charts.

~ rough sketch, not an actual screenshot ~

filters

source, type, owner, team

search "page_path"

results + annotations + tags

Who Benefits

Flagged a significant number of unused legacy events and tables for cleanup, reducing structural confusion. Full data-asset ownership increased trust and simplified maintenance. Product teams gained autonomy over their own event data instead of routing through the data team for every question.

Next Steps

Prioritize the backlog of user-requested features; secure a dedicated full-time developer to unblock the roadmap pace.