Historical university web work
Arizona Admissions: Gatsby / Drupal
I owned frontend development for the earlier Gatsby and Drupal Admissions redesign after a technical-lead transition. This historical implementation is no longer live as I built it.
Problem
What needed to change
Admissions needed a public redesign for prospective students and families that also supported frequent updates by content editors.
Users
Who the system serves
Prospective students, families, admissions teams, marketing stakeholders, content editors, and university audiences.
Team context
Where I fit
Frontend technical lead · University of Arizona
Worked with designers, admissions and marketing stakeholders, content editors, and the broader university platform team; stepped into technical ownership after a lead transition.
Important technical decision
Letting editors assemble pages
I mapped Drupal paragraph types to reusable Gatsby components so editors could assemble pages without one-off frontend work.
Tradeoff or limitation
Reuse under a compressed schedule
The system needed reusable patterns and room for custom sections at the same time, under a compressed launch schedule.
Implementation
What I personally owned
- Owned the development side of the redesign and the full experience between the shared site menu and footer.
- Worked with designers, admissions and marketing stakeholders, and content editors on the production implementation.
- Took technical ownership of the newer stack after the original technical lead left.
Result
What shipped, and what changed
- Gatsby frontend using Drupal JSON:API endpoints and GraphQL data.
- Reusable frontend components mapped to Drupal paragraph types.
- Responsive admissions page experiences across desktop, tablet, and mobile.
- This earlier admissions experience launched, but is no longer the live implementation. Today’s university site does not demonstrate this Gatsby/Drupal build.
- Editors received reusable CMS-to-frontend patterns for subsequent admissions updates.
Technical scope