When we set out to redesign the Harvard Library website we knew we wanted this project to be different. We knew it had to be different if we wanted it to succeed.

Most of us on the web team have worked on other digital projects — both at Harvard and elsewhere. Some of those projects were successful, others we weren’t eager to relive. We knew we wanted to build a website that made research richer, learning fun and discovery delightful — a site that could transform our users’ assumptions about us.

It was with that experience and shared purpose that we developed our guiding principles — four guidelines to help ensure we build the right thing. Here’s what we came up with:

GUIDING PRINCIPLE #1: Put the user at the center of everything we do

We're committed to building a website that is intuitive to use and endlessly helpful — for both users and content editors. The only way to do that is to put the user at the center of everything we do — to constantly ask for feedback, test our assumptions and make improvements.

The Harvard Library exists because of, and for, our users. That’s why we kicked this project off with weeks of user research, laying the groundwork for extensive user testing throughout the development phase and beyond. And that’s why we’re committed to putting our product in front of users for testing early and often. We won’t hold onto anything until we think it’s perfect — because we know nothing is “perfect” until our users demonstrate that it’s useful to them.

GUIDING PRINCIPLE #2: Make information accessible, not just available

Our user research confirmed our assumptions that users were struggling to find the information they needed, that to them the library system felt disjointed, and that they weren’t even aware of some of the services and resources available to them.

That’s why our second principle — making information accessible, not just available — is so important. Our websites are filled with information — 6,036 pages' worth, to be exact. On top of that, our catalog HOLLIS holds over 200 million items. That’s a lot of stuff — which can make finding what you’re looking for a chore.

We need to improve discoverability. A huge part of that will be streamlining our web content — getting rid of what’s not needed and rewriting what is so that it’s easier for our users to understand. We will also develop writing guidelines and a governance structure that ensures the hard work we do now to make our content more accessible doesn’t fade away over time.

We’ll work to break down the barriers that only exist within the Library’s internal organization, simplify policies, and put information where users expect to find it — even if it’s from disparate parts of the system.

We want to inspire students and scholars to use our world-class library system to its fullest. Clear, concise content, written for the user and organized in a way that makes sense, has the power to do that.

GUIDING PRINCIPLE #3: The website will never be “done”

If we build the new Harvard Library website behind closed doors and only release it to the public when we feel like it’s “done,” we won’t be successful. We need to build a platform that supports continuous innovation.

Technology changes fast and so do our users’ expectations. To support that goal, we’re working closely alongside our partners at Velir every day. We’re learning about their processes and tools and we’re adopting them ourselves, so that when they move onto their next project our website doesn’t stop getting better and never stops meeting our users’ needs.

GUIDING PRINCIPLE #4: Open-source solutions and practices

Throughout this project we’ve looked to other institutions for advice and inspiration (Hello City of Boston Digital Team!). Even at this early stage in the process, we wouldn’t be where we are without the generosity of others who’ve been there before.

That’s why we’ve committed to making sure the hard work we do on this project benefits other digital projects at Harvard and beyond. We’re committed to using open-source solutions and contributing to the development community by open-sourcing our own code.

We also want the way we get the work done to inspire our colleagues. That’s why we’re writing these blog posts, and why we will consistently invite you to participate in the process — whether through demos, sketching sessions, or by providing feedback.