Websites exist for people. Humans define the goals, design websites to meet them, and build them to reach other humans. And behind every content management system (CMS) project, especially large-scale projects, are people making it all happen. They write and organize the content that eventually becomes public-facing.
However, teams often build websites without a clear audience in mind. Experts talk to other experts, aiming at some abstract “end user” that’s floating in the sky somewhere. If they’re lucky, that hypothetical “end user” might even resemble the real audience.
Luck isn’t a strategy, especially not for large-scale CMS projects where time, money, and reputations are at stake. To get it right, we need real people to help us define the solutions.
Enter human-centered design.
What is human-centered design?
Human-centered design (HCD) means putting users at the center of your design process. It's about understanding how people interact with your system and making sure it works for them. A product isn’t well-designed just because it looks good. If users are confused or find it difficult and tedious to operate, the design has failed.
Instead of designing in a vacuum, HCD creates a constant feedback loop: talking to real people, watching how they interact with the system, and then refining it based on the learnings.
HCD also considers different types of users, because the “end user” isn’t some amorphous blob. It’s people using assistive technology, those with older devices, and individuals accessing a website on their phone while walking to the store with spotty Wi-Fi. Great design works for all of them.
Why large-scale CMS projects need HCD
Large-scale CMS projects often serve multiple audiences. Consider a university website. It must cater to the diverse needs of prospective students, current students, parents, faculty, and alumni. Without a clear focus on users, everything can become a jumbled mess that serves nobody or serves one audience to the detriment of all others.
As humans, we're vulnerable to our own biases. We can't just rely on our instincts to build a great product. We need that research to make it great. This is especially true for large organizations where internal stakeholders may have been working with their systems for years and have lost sight of what it's like to be a newcomer.
And it’s not just about the public-facing website either. The editorial interface, where content creators and editors spend their days, often gets treated as something that needs to be functional. But if you create a backend that's easy for authors to use, that's less time they have to spend fiddling around with everything. That’s money saved. And it means content gets updated more frequently and accurately.
The stakes are high. Fixing design problems early is far cheaper than trying to correct them later. Once a system is in development, fixing an issue can cost roughly 10× more than resolving it during design.
A real return on investment
Research shows that every dollar spent on UX yields a 10-100x return on investment.
Testing and prototyping upfront with simple wireframes and real users mitigates costly wrong turns. A bit of upfront research ensures solving the right problems and building the features people actually want.
Studies also show that improving usability from the beginning can drive efficiency gains of 700% or more. For content authors, this could mean the difference between a task taking 30 minutes versus 5 minutes. Multiply that across dozens of content creators over months or years, and the productivity boost becomes enormous.
Overcoming pushback
The most common pushback we hear is "We don't have time for user research" or "We don't have budget for this." Here's how to reframe that conversation:
- Show the data. Benchmark current performance. For example: “30% of users aren’t completing this flow. Let’s aim to improve that by 50%.” Stakeholders love measurable results.
- Position HCD as a time-saver. A short round of user testing prevents build-break-fix cycles later and reveals features that need simplified requirements.
- Ask the tough question. “How do you know if you're solving the right problems?” Not doing research often results in costly, beautiful designs that no one can use.
Remember the disastrous launch of HealthCare.gov in 2013? It had severe usability issues—confusing navigation, hidden calls-to-action, and a clunky registration process, which caused users to abandon the site. Somebody could have caught them with even a small-scale usability test. Instead, the team had to do emergency user research while under public scrutiny.
A practical approach to HCD
The good news? Human-centered design doesn't have to be expensive or slow. Here’s how we bake it into our projects:
- Start with discovery. Talk to users and stakeholders early to uncover pain points. Watch real people use the system—seeing their struggles is more valuable than a hundred assumptions. Use techniques like Toyota’s “Five Whys” to uncover the underlying needs behind surface requests.
- Test early and often. User testing isn’t a one-and-done step. Test scrappy wireframes and prototypes, as well as fully built sites. Even interviewing 3–5 users per sprint can reveal valuable insights.
- Build a user panel. Recruiting participants can be time-consuming, so create a standing panel. For example, Massachusetts has a 5,000-user panel they can filter by age, services used, and location for quick recruitment.
What success looks like for HCD
How do you know if HCD is working? Look for these indicators:
- Fewer complaints, more leads, and more conversions
- Higher accessibility scores
- Positive feedback from users
- Faster task completion and fewer support tickets
- Higher adoption rates (some organizations have seen increases of 200%)
A shining example is Gov.uk, which won the prestigious Design of the Year award. By prioritizing user needs and accessibility, they transformed hundreds of scattered government sites into one clear, intuitive experience.
Aim for progress, not perfection
Human-centered design isn’t about creating a flawless system. It’s about building something that works for real people in real-world situations while improving it over time.
Start small. Add testing checkpoints. Iterate. This approach leads to better websites, saving money, time, and frustration down the road.
Websites are for people. Let’s make sure they actually work for them.