Lessons learned launching an award-winning,* enterprise-level website


This past year has reminded me that the life of a website developer is that of a life-long learner. When working in an industry that is always growing and changing, nearly every project presents an educational opportunity to the developer. And my latest project was no exception.

The mission:

  • The task: Move an HTML website to Drupal, a content management system (CMS).
  • The client: The oldest, and largest, community college in the state. Its website was out of date and was a poor first impression for visitors who have never been to the campus in-person.
  • The deadline: 9 months.
  • The details: Well… I soon discovered that there were no project guidelines, just that I had to use Drupal and it needed to go live later that year, in time for the fall semester. I would be the one to make a plan to make this happen!

I was eager to dive in, and felt fortunate that I got to make the plan and all the big decisions. I was up to the challenge.

Research. Plan. Research and plan some more. And be open to revising your plan.

A project like this could have been overwhelming, especially for a Team of One, but it was a detailed, research-based plan that saved me several times in the months to come, especially on those days where I felt like I just had “So. Much. To. Do.” If I couldn’t decide what task to do next, I would just review my notes and consult my sticky note timeline (see below). I also credit a speed reading of “The 4 Disciplines of Execution,” a book suggested by a friend when I first started the project. I was really drawn to the concept of a Wildly Important Goal.

Project planning tools don't always have to be high tech. In the early stages of this project, I went through a lot of sticky notes and erasable pens.

Project planning tools don’t always have to be high tech. In the early stages of this project, I went through a lot of sticky notes and erasable pens. These tools also allowed for flexibility in when putting my plans on paper.

For the first few weeks on the job, I didn’t even touch Drupal. Instead, I split my time between maintaining the current site (which helped me get an idea for what type of content I’d be working with), and researching best practices in higher education web development. And I visited a LOT of websites for 2-year and 4-year institutions.

Though my research didn’t stop after those first few weeks, before long I had a better understanding of a few key concepts that helped this website go on to win an award just a few months after its launch.

Who was the website for?

I identified my primary target audience (prospective students), as well as secondary target audiences (current students, faculty and staff, the community, and alumni and donors).

 What kind information do people look for / what pages were people visiting?

Unfortunately, there wasn’t an easy answer to this two-part question, mostly because there was no tracking code on the website when I started. So I had to rely on research, conversations held around campus, and my plan to put Google Analytics on the new Drupal site so I could evaluate it more effectively than I could the HTML site.

Is it easy to find information on a wide variety of given topics?

Oh, and shouldn’t it look good, too?

Even with the most attractive of designs, the new website would not be a success if it wasn’t easy to use – it needed to provide a good user experience.

The new site would absolutely need better navigation and content organization. The repeated theme of conversations with various stakeholders across campus was that, with the HTML site, it was hard to find what they were looking for.

So I came up with an appealing design that was more collegiate and modern… but was also… wait for it… research based.

I ran first-click tests to compare the effectiveness of two versions of my homepage mockup. First-click testing is important because a user who clicks the correct link the first time is twice as likely to find what they are looking for. And with a complex site structure, it’s important that a user’s first click is on a link that will get them closer to the info they want, even if they have to navigate into the site a little further before finding the answer. They’ll continue on for as long as they feel like they are on the right path; but the moment they feel lost, they’re off to Facebook or a competitor’s website.

Needless to say, the homepage design was important. But it was also a challenge because it had to serve a variety of target audiences. Furthermore, studies showed that our primary target audience, prospective studies, would tend to think that everything on the homepage was for them. So I was very selective about what would appear on the homepage. But I didn’t want to disregard our other audiences, and so I made custom landing pages for each of our primary and secondary target audiences.

During my research, I was also reminded that you never know which page a visitor is going to first visit – a Google search result or social media post could reference a link to an internal page. Top-level and other popular pages would need to be engaging and provide a clear call-to-action, whether to “request more information” on a program page, or “sign up for a tour” on the Visit Campus page.

Do we really need thousands of pages?

I needed to do a content audit. Desperately. But with thousands of pages and a tight deadline, I had to figure out where to start, beginning with identifying what type of content was more of a priority. For example, I determined that I would begin with looking at pages about academic programs and other information for prospective students. I knew that I wouldn’t be able to take a critical look at every single page before the launch, but I needed to start somewhere, and so I created a content audit plan that would continue on past the launch.

Isn’t a website done once it’s launched?

The short answer? No.

The long answer? It will probably never be “done,” in the traditional sense of the word.

Just like a vehicle needs routine maintenance to keep it running, so too does an enterprise-level website need constant maintenance to best serve its audience and its owner.

And so the moral of the story is…

The devil’s in the details.

You can’t anticipate everything, but if you have a decent plan that has actionable steps and you are flexible so that you can to take an alternate route to address an issue you didn’t anticipate, you will still succeed.

Wait, but what about…?

  • So how many pages did I end up with? (Around 800, down from 2,000+.)
  • Did someone say content strategy? Well, let’s discuss that… another time.
  • How did I set up an editing interface for about 30 contributors across campus, so they could update page content but not change a page’s layout or add fonts or text colors outside of the website’s branded stylesheet?
  • How did I deal with Drupal’s not-the-greatest default file storage system?
  • How did I handle contracting out some work at the end of the project, when we were close to deadline, and how did that impact meeting that deadline?
  • How did I survive the transition from the old website to the new one?

More lessons for future blog posts, I suppose!

Or you can reach out to me — whether you are a developer or website owner, enterprise-level or not — the web dev community has been so helpful to me over the years and I’d be happy to pass that karma on.


* The award was from the National Council for Marketing & Public Relations (NCMPR).

No comments yet.

Leave a Reply

Montana website, graphics and print design