Cutting the steps to launch an IU website by 71%

Every department, lab, or student group that wants a website goes through IT Services. Hosting, the content management system (CMS), the design system, brand review, and content review each had their own request and approval. When the process got too slow, users quietly hosted their sites elsewhere, and IU lost control of how its name showed up online.

A website touched a long list of services: hosting, brand rules for URLs, ADA compliance, privacy and disclosure review, content review, a university access management tool linking each site to a university account, and the web team's framework and accessibility checks. With so many teams involved, handoffs drifted between them, and the system came to rely on self-serve documentation. That meant more rejections, and slower launches. Nobody owned the process end to end, and the people coordinating it were short-staffed, so fixing it never rose to the top of the list. Retirement depended on the site owner starting it, so outdated sites kept piling up.

I ran stakeholder interviews with all seven approving teams as conversations between colleagues, not audits. That surfaced the workflow as it actually ran, not as it was documented.

The vision was one place to manage a website's whole lifecycle: a web app where site owners handle hosting, the CMS, accessibility reports, and retirement, rolled out one integration at a time. With a senior designer, I built a high-fidelity, interactive prototype on Rivet, IU's design system, so stakeholders could walk through the journey before anything was built.

Instead of assembling a team to build a custom tool, we decided to start with ServiceNow, which IU already licensed. I learned ServiceNow in depth, down to the difference between an incident, an interaction, and a request, and modeled the workflow as tasks inside it with a team of service management experts. No new tool meant far less change management. The tradeoff: a tool that needed a lot of customization to fit our goals.

Simplifying the requester's side was half the puzzle. The other half, arguably the harder one, was getting the people who run these workflows, some of them several times a week, to buy in. So we mapped the future-state service blueprint and walked each team through it in meetings, for first reactions and considered feedback. Once ServiceNow was chosen, we built a test form with dummy requests so teams could click through the process on their own. That showed teams would need a lot of scaffolding to feel comfortable in ServiceNow. So we wrote the documentation ourselves, and added in-place instructions at every step, saying what's expected of each person. A necessarily complex tool now worked in our favor, with less onboarding for people who would only use it now and then.

Retirement ran on email and depended on the site owner starting it, so 1,500+ dead sites piled up. It was the lowest-risk step with the biggest backlog. We piloted it with the help desk, iterated on how ServiceNow modeled the data, and the remaining steps are now built on the same pattern.

Requesters now touch the process twice: once to request infrastructure and once to go live. Retiring a site is one simple request, just like requesting infrastructure. That's 71% fewer steps, and it helped clear a backlog of 1,500+ outdated sites. A KPI dashboard tracks retirements and turnaround time, and internal teams use it to request work from each other. Retirement requests are up, though still below where they could be: many of the owners responsible for retiring sites have left IU or no longer maintain them. Clearing those up by hand is the last piece, but no single team has to carry that queue now, because ServiceNow handles it. The team is now building the other steps on the same model.

None of the seven approving teams reported to me, and some of them run their step several times a week. I interviewed every team, walked each one through the future-state service blueprint, and tested the new workflow with the people who would run it. The teams said yes once the new process took work off their plates, and seven steps became two.

These were established teams with senior people. Owning the research gave me the confidence to go talk to every one of them. I didn't yet have the confidence to own the redesign the same way: to say, this is the new process, tell us what you think, and expect small changes rather than a different process. I'd bring that same conviction to the design.