UX Engineering2023—2024
UX Portfolio & Dashboard Suite
Three working data dashboards shipped as products, not screenshots — usable on this page.
- Interfaces that outlive frameworks
- Notebook analysis to usable product
- Work-first information hierarchy
- Dashboards
- 3 live builds
- Open data
- 15+ CSVs in-repo
- Hosting
- GitHub Pages, no backend
- Longevity
- Framework-free artifacts
01
Overview
A dashboard suite where the case studies are the artifacts themselves: interactive dashboards for Formula 1 analytics, a Pokedex explorer, and an automobile dataset — each one a self-contained HTML build shipped alongside the raw CSV data that powers it, deployed on GitHub Pages and embedded live on this page.
02
Problem
Data-analysis portfolios usually reduce weeks of work to a static PNG of a chart. That throws away the thing that makes a dashboard good — the interaction. I wanted visitors to filter, hover, and explore the same views I built during analysis, without installing anything.
03
Goals
- Present analysis work as living dashboards, not screenshots
- Keep every dashboard self-contained and shareable as a single URL
- Ship the underlying datasets in the open so the work is verifiable
04
Solution
Each dashboard — Automobile, F1 Analytics, Pokedex — is built as an independent HTML entry point deployed to GitHub Pages, so it loads instantly, cannot break its neighbors, and can be linked or embedded directly (which is exactly how this page serves them).
The repository doubles as the data source: the full Kaggle Formula 1 relational set (circuits, drivers, lap times, pit stops, qualifying, standings — 15+ CSVs) plus the Pokemon and Automobile datasets live in public/, making every visual reproducible.
05
Process
- 1Analysis first in Jupyter (the F1, Pokedex, and Automobile notebooks in sibling repos), then translated the strongest views into interactive form
- 2Each view had to survive the promotion test: only charts that changed a conclusion in the notebook earned a place in the dashboard
Tooling
Tech stack
- React
- JavaScript
- HTML
- CSS
- GitHub Pages
Friction
Challenges
Dashboards that outlive their framework
Framework-bound dashboards rot when dependencies move. Building each one as a standalone HTML artifact means the F1 dashboard from 2023 still opens in one click today, independent of the React shell around it.
Serving relational data statically
The F1 dataset is a dozen linked tables. With no backend on GitHub Pages, the joins had to happen client-side — which forced deliberate choices about which pre-joined slices each view actually needs.
Takeaways
Lessons learned
- Static hosting is a design constraint that improves the design — every feature must justify its data weight
- A portfolio that lets the visitor do the analysis is more persuasive than one that describes it
- Keeping raw data in the repo turns a portfolio into a reproducible artifact
Roadmap
Future improvements
- Responsive redesign of the older dashboard builds — they predate my mobile-first practice
- Add the IPL and Game of Thrones work as dashboards four and five
- Lighthouse pass on the older dashboard builds
Rebuilt for this site from the original repository — source history