01 / Case study / 2024 — Present
Penn ISC
The front door to IT for an entire university — rebuilt from Drupal 7 to Drupal 10, and then taught to serve two audiences at once.
The situation
Penn ISC is the front door to IT for the whole university — a student looking for a password reset, a researcher looking for storage, a department looking for security policy. The site had grown on Drupal 7 the way institutional sites do: one urgent need at a time, each fix layered on the last.
By the time we started, the theme had accumulated a decade of patches. Editors had learned to work around the layout instead of with it, and every new section meant another template nobody wanted to touch.
The approach
We rebuilt on Drupal 10 around a component library rather than a set of page templates. A page is assembled from parts — an audience gateway, a resource card, a featured story, a service promo — and the composition holds up no matter which editor is writing it.
The custom theme, upennisc, keeps the markup semantic and the CSS legible. That sounds like a small thing. It is the difference between the next developer extending the site and archaeologising it.
The build
Twig templates and a deliberately small set of paragraph types cover the whole site, which keeps the authoring experience shallow enough to teach in an afternoon.
Navigation leads with what people actually arrive to do — Get IT Help, Resources, Security, News. The resource index lets someone narrow by audience before they ever reach for a search box. PennKey login, site search, and system status stay in the header, where they belong.
Two audiences, one site
The harder design problem was internal. ISC staff needed their own space — org charts, staff profiles, strategic goals, the things an employee looks for and a student never does — without splitting the site into two properties that would drift apart within a year.
So “Inside ISC” became a distinct layer rather than a separate site: its own navigation that reads differently from the public menu, extended sidebars on any section with more than one page, and enough visual separation that staff know which side of the house they are in. Same ecosystem, different room.
Documentation as infrastructure
The other thing I built was a habit. Every project gets a runbook — what changed, why, what to check if it breaks — kept alongside the work instead of in someone’s memory.
The test is simple: could a colleague answer a question about this site while you are out for two weeks? On an institutional site that outlives the people who built it, written-down context is not admin. It is part of the deliverable.
What changed
The site now runs Drupal 10 on a theme the team can extend without rewriting it. Editors compose pages from components, so a new section ships in hours rather than sprints.
The markup is semantic and keyboard-navigable throughout. That matters more here than almost anywhere: an inaccessible help site fails exactly the people who need it most.