Designing for the Library Website

What is needed for designing large web-based systems?

What is needed for designing large web-based systems?

In 2013, I joined the Design & Discovery team in the Library Information Technology (LIT) department at the U-M Library to help develop plans for the the future redesign of the library’s website. I previously worked with a startup focused on archiving, sorting, and displaying analytics for social media. My other past experience includes creating applications aimed at improving employee work experiences in markets such as real estate, architecture, and in classrooms.

These experiences all presented their own set of challenges. Every interface tackled was a complex, multi-faceted, and dynamic product. Projects of this nature never have an end-date, or completion point. In this kind of environment it is possible to continually improve functionality and design, but it is also easy to become paralyzed by the amount of decisions presented.

Identifying the challenges

The library website presented all of the challenges I had experienced on past projects, and several new ones. I began by defining the potential problems with designing a large, technical site:

  • The current website is not mobile friendly and carries a lot of technical debt. This means that making large design changes or updates can be quite tedious.
  • The library website contains a lot of content. This includes a plethora of staff-generated content, services, and guides along with records of millions of books, articles, and other cataloged content.
  • The search experience is a fragmented process. e.g. to search databases, articles, or books in a catalog a user may have to access three totally separate interfaces—all with different design cues and functionality.
  • The website must be ADA compliant or accessible to any type of user. The foundation must allow people with accessibility software to easily navigate the site. This includes visually or physically impaired users that rely on software to help them navigate the site.
  • A typical approach, such as a templating scheme would not cover all the needs of the site. The variety of content and data is simply too rich.  

The framework approach

With all of this in mind it seemed creating individual mockups for each section would be a tedious process without much flexibility. Thinking through the work needed helped provide clarity of a better process that is flexible and interchangeable to suit not just a singular project, but other projects in the future. This is where the idea of a framework came in.

Many open-source framework templates, such as Bootstrap, are available online. We used Bootstrap as a blueprint and altered it to fit our needs. This provided key elements and helped keep front-end developers from doubling work for commonly made elements. It is important to note this wasn’t a quick re-skinning of Bootstrap, but really a deep-dive into the system of colors, styles, and elements that are going to be used going forward.

To understand this better, reading Brad Frost’s writing on Atomic Design helped break down the different elements of our website. The document starts with the most basic component or element of what you are dealing with. If the designer is making a “search results page”, they would start by working backwards:

What sections are on the page?
  • Header
  • Footer
  • Sidebar navigation
  • Result options
  • Result list

Step 1

To get more specific, let’s focus on the Sidebar. What’s in it?
  • Section buttons (different data stores such as articles, catalog)
  • Filter buttons
  • Auxiliary buttons/filters (those that depend on the data store)

Step 2

Finally, what makes up a section button?
  • The name (Articles, for example)
  • Icon
  • Size of button
  • Color
  • Animation states (Hover, click, pressed etc)

Step 3

When you break down the design elements like this, it becomes easier to manage what makes up those elements and find similar styles throughout the site. Another benefit is the ability to start small and begin building general elements that can be used for any project or instance, now and down the road. Interestingly enough, the work that has been done on the search interface designs has carried over quite well to the upcoming Deep Blue Data repository (research data repository provided by U-M Library Research Data Services). Part of the success has been the granular approach to designing assets rather than full pages.

Moving forward

As the search project marches on, and the data repository starts to be fleshed out, it is important to see how the process of managing assets grows more complex, from both a designer’s perspective and developer’s perspective. Moving forward won’t be a problem of what to create, but rather how to manage what we already created.