Case Study: Website Redesign Cook Hospital

Redesigning a Hospital's Digital Front Door

Cook Hospital is a key rural healthcare facility in northern Minnesota. Its coverage area exceeds 2500 square miles, with a low density population. The hospital website was text-dense, outdated, and slow to update—implementing changes took anywhere from weeks to months.

"I've stopped asking for website updates. Sometimes it takes weeks"

UX RESEARCH - PRODUCT DESIGN

The Problem

The hospital website was nearly a decade old. It was text-dense, outdated, and slow to update—implementing changes took anywhere from weeks to months. The newly-formed Marketing Department took over management of the website with a goal of turning it into a strong platform to support service line growth, patient pipelines, and a source of general wellness education for community members.

Users & Audience

  • Current and Future Patients who were searching for information regarding procedures, contact information, and access to the patient portal.

  • Providers & Staff Members who wanted a platform to share news and relevant expertise.

  • Healthcare professionals who were looking for information about career opportunities.

Roles & Responsibilities

This was a true end-to-end design project, with the constraints of limited staff and an even more limited budget. My role included:

  • Product Strategy

  • Project Management

  • IA, UX/UI, and content

Other stakeholders included:

  • IT team

  • HIPAA consultant

  • Department managers & healthcare providers as SMEs

  • Executive team for business goals and success metric conversations

Scope & Constraints

  • "We needed this website yesterday" - Executive Team

  • Small budget which prevented work from external contractors

  • Regulatory requirements, which ranged from HIPAA constraints to .txt file compliance

Process

Research

I ran three distinct research phases:

  1. Internal audit of all screens

  2. Surveys & interviews with service providers & department managers

  3. Interviews & testing with community members

Key Findings:

  • “I don’t think you have the right info on your website. Last time I was on, I saw it still had Doctor X listed.” - Community Member
    A text-dense website with limited navigation led to high bounce rates and low usage from community and patients. It eroded trust, rather than built it.

  • “It takes [tech team] so long to add anything to the website, I’ve stopped asking.”
    Internal process ownership and lengthy change process (which went through 2 contractors) was a roadblock for internal staff members who were willing to provide updated material.

  • “Should I add more to the [department page] with the new services? Can we do that?”
    Internal perception about the role and capabilities of the website pages lacked direction and focus. Ultimately, even with a full website redesign, there would have to be an internal campaign to teach non-tech providers about the doors that this could open for their services.

  • I use it to see my results.”
    Primary use for patients: accessing their medical records via the Patient Portal.

Design Decisions

1. Should we structure the IA around patient queries—or an org chart?

The internal structure was tidy: every service filed neatly under its department. The problem was that patients don't think in org charts. Our Outpatient Clinic alone buried services three clicks deep—users were hunting for care through a structure built for administrators, not for them.

The decision: restructure the navigation around what patients actually search for—find a doctor, pay a bill, ER and directions. Leverage internal organization for service “categories” on a main services page.

2. Outsource the rebuild—or bring it in-house and leverage our unique user insights?

Faced with a 52-page hardcoded site and a massive overhaul ahead, outsourcing looked like the obvious shortcut: hand it off, save time, move on. But an agency can't build around research it doesn't have access to—and I was running patient and user research that was reshaping how the site needed to work, not just look.

Bringing the rebuild in-house meant the architecture could evolve with the findings instead of being locked into assumptions at kickoff.

The result: a flexible WordPress build using the Bricks theme, replacing the hardcoded site with a responsive, accessible foundation—plugin integration, SEO optimization, WCAG alignment—and cutting the content update cycle from roughly three weeks to 24–48 hours on business days.

3. Patients or referral partners—who gets the top of the page?

Every service line page had two audiences pulling in opposite directions: patients arriving uncertain, scanning for reassurance and next steps, and referral partners arriving with a clipboard and a mission, hunting for exactly one thing—a fax number, a scheduling line, a requirements list.

The decision: patients first, always. Patient-facing information and referral contact numbers lead each page; partner resources sit at the bottom.

The rationale came straight from the stakes. A patient arrives at the page at a disadvantage—anxious, comparing facilities, one confusing screen from choosing a competitor. A bounced patient isn't a lost session; they're a lost admission. A referral partner, by contrast, arrives with a specific purpose and will scroll to find what they need—we can assume persistence in a way we never can with patients.

In practice: patient info and referral numbers above the fold, partner resources below. Respecting both audiences meant ranking them, not splitting the difference.

3. How much information does a patient need at once?

Fifty-two pages of healthcare content, and each one had to serve two readers at once: the anxious patient skimming for "can I call, where do I go" and the prepared patient who needs to know what to bring, who it's for, what happens next. Answering both at full volume meant answering neither well.

I structured each page with progressive disclosure—contact information and the service line summary above the fold, the deeper detail (who this is for, what to bring to your appointment) layered beneath. Plain language throughout: patients arriving worried don't have bandwidth for clinical jargon.

I opted to use progressive disclosure in the content design of each page: the contact information and service line summary was kept above the fold, followed by more in-depth content (who is this for, what you need for your appointment, etc.).


🗒️ One user interview revealed the cost of unclear content: a patient whose insurance didn't require a referral for a colonoscopy called the hospital to schedule—and was refused, because an internal process nobody had communicated said otherwise. The website never shared this requirements, and patients carried the consequences.

The fix was small: referral requirements surfaced directly in the contact section of applicable service line pages. But it took user research to find an information gap the organization didn't know it had.

4. Component Based Templates & Patterns

One of my key concerns with the website rebuild was the issue of scalability. I had no real knowledge of how much growth was in the immediate future for the hospital, but wanted to ensure that we had a system that was efficient in the short and long term.

To accomplish this, I created a library of component-based templates and patterns, built into the website code and reusable page layout features.

This helped me move faster during iterations, while preserving product coherence.


🗒️ I used Figma primarily to illustrate initial design decisions with stakeholders. Since I was both product/content designer and developer for this project, I opted to iterate directly within the staging site itself, which allowed me to move the project forward with high efficiency. However, it did create a documentation gap that needed to be solved retrospectively.

5. Notes on Accessibility & Compliance

One of my concerns was accessibility, which I leaned into in a few different ways:

  • Reworking the brand colors and typography to align with WCAG requirements.

  • Incorporated an Accessibility Widget for ADA, EAA & WCAG readiness, which provides additional support for text size, reading focus, screen readers, and more.

  • Created a full audit and implementation strategy for updating all image alt text and headings.

HIPAA & Regulatory Requirements

This was my first major project that touched on HIPAA /regulatory requirements in healthcare, and it was a great learning experience. I took a HIPAA & Marketing Analytics course to do a deep dive into HIPAA-compliant website tracking strategies, as the hospital team was unfamiliar with that area. I also worked closely with our compliance specialist and Senior Leadership to ensure that key pages and TXT file links were properly updated and in compliance.

Outcomes & Lessons Learned

Leadership buy-in for broader digital strategy:

  • Board of Directors endorsed the redesign as a foundation for expansion across digital channels.

Internal usage increased:

Frontline staff expressed relief that they could direct patient queries to the website for service line information across departments, and know that the contact information was readily accessible

Faster content updates:

  • We reduced the time to implement changes from ~3 weeks to 2 days for page updates

SEO & Analytics

While allowing for some numbers discrepancy based on the change in how we utilize analytics on our website, the updated design produced some immediately quantifiable results:

  • ~30% increase in organic traffic over 3 months (this was with no additional content/pages adde, as we did not have the bandwidth for content creation at the time)

DESIGN & STRATEGY: MARIA MYRE
COPYWRITER: MARIA MYRE
STAKEHOLDERS: EXECUTIVE TEAM, BOARD OF DIRECTORS, & DEPARTMENT MANAGERS