Libraries love putting their buildings in their logos. I understand why. The building may be historic, beloved, or one of the most recognizable places in town. But being meaningful does not automatically make it a useful logo.

In fact, the more architectural detail a library tries to preserve, the less useful the result usually becomes.

A picture shows what something looks like. A logo identifies an organization. Those two jobs are not the same.

A Logo Has to Work Much Harder

A photograph of your building may look perfectly fine at the top of your website. It may also work well in scenarios like a brochure, annual report or social media post. But a logo has to work with much less forgiving conditions, such as:

• On a library card

• On a mobile screen

• In an email signature

• On a printed envelope

• In black and white

• On a sign viewed from across a parking lot

• On a pen, tote bag, button, or name badge

A detailed photograph or architectural illustration usually falls apart when it is reduced to the size of a postage stamp. I have seen library logos that include every window, column, tree, stair, and lamppost in front of the building. At website-header size, most of that detail disappears. Many details turn into visual clutter and the image may become little more than an indistinct blob. A logo should become simpler and clearer when viewed at a small size, not harder to understand.

Recognition Is Not the Same as Identification

Library staff sometimes defend a building image by saying, “Everyone recognizes our building.”

Maybe they do. But which everyone?

Longtime residents may recognize it. New residents may not. People who use digital library services but rarely enter the building probably won’t. Visitors from a neighboring community almost certainly won’t.

A person shouldn’t have to recognize the building before the logo makes sense. The logo is supposed to create recognition.

Your Library Is More Than Its Building

There is also a larger problem with using the building as the logo: it defines the library by its real estate.

A public library is not just a physical place. It provides crucial services, many of which can be accessed online. When the building becomes the library’s primary symbol, it quietly suggests that the physical place and what it provides are the same thing.

They are not. The building houses the library. It does not define the full scope what the library actually does.

Your Building Still Has a Job

None of this means you should stop using photographs of your library building. Good building photography can still help people to recognize the location and feel more comfortable before visiting.

Use the building on your website’s location page. Feature it in community stories. Include it in historical materials, reports, or social media posts. Just don’t ask it to be your library’s logo.

A photograph documents a place. A logo identifies an organization. And, your library needs both! It just should not confuse one for the other. Remember: Loving the building is not a design strategy.

In libraries, we love the word “resources.” We have electronic resources, community resources, research resources, local history resources, homework resources, genealogy resources, business resources, legal resources, and probably at least a dozen other flavors of resources hiding somewhere on our websites. And, that, folks, is the problem.

“Resources” has no true specific meaning. To us, “Resources” may feel like a useful umbrella term. But, to users, it often translates to: “Here’s a mystery option. Good luck!”

What the data says

Users rely on navigation labels to decide whether a click is worth the effort. In user experience (UX) terms, those labels provide “information scent.” A strong label gives users a reasonable clue about what they will find if they follow it. A weak label makes users guess.

NN/g’s research on how people read and scan online notes that users are usually trying to finish tasks quickly and with minimal effort. They scan for meaningful links, headings, and other cues that help them decide where to go next. When the words on the page offer weak information scent, users are less likely to keep reading or follow the path in front of them.

“Resources” is a very weak scent. It doesn’t tell the user what they will find. Worse, it can mean different things on different library websites, so even experienced library users cannot reliably predict what is behind it.

Our meaning is not the user meaning

Inside libraries, “resources” is a comfortable word. It sounds broad, helpful, and professional.

But users usually come to a website with a task in mind:

• “I need to renew my books.”

• “I need homework help.”

• “I need ebooks.”

• “I need the library’s hours.”

• “I need a study room.”

• “I need legal forms.”

• “I need to print something.”

Pretty much nobody comes with “I wonder where the resources are.” That mismatch matters. Good navigation is not about what staff call things internally. It is about what users recognize when they are trying to get something done.

Poor navigation labels like “Resources” can significantly increase the cognitive load. Now the user has to spend time trying to interpret something, which is an obstacle to completing the task they came to do. Interpretation takes takes time the user doesn’t want to spend.

When a navigation label requires that much interpretation, it’s not helping anyone. Instead, it’s offloading the website’s organizational problems onto the user. And users are not on your website because they want to admire your organizational structure. They are there because they need something.

What to use instead

I think we’ve established that simply using “Resources” is terrible. That might lead you to ask: “Well, can’t we just use “Genealogy Resources?” That’s certainly a step up, but doesn’t really solve the problem. Let me ask you this: what’s wrong with simply “Genealogy?” Or, “Homework Help?” What is truly being added by tacking on the word “resources,” when studies are pretty clear in that it’s a poor navigational aid?

“Resources” is one of those words that feels clear only because library staff have been using it forever. But familiar is not the same as useful.

A good navigation label should help users make a confident choice. It should point toward a real destination, not gesture vaguely at a pile of possibly useful things.

So yes, your library has resources.

That does not mean your website needs a link called Resources.

Hick’s Law is a simple idea with big consequences: the more choices people have, the longer it takes them to make a decision. I often explain this by asking the person to imagine they need to buy ketchup, and now they’re standing in the ketchup aisle at the grocery store. If they’re not already committed to a specific brand or type, how many options do they have to choose from? The answer is almost always “too many.” It can take them more time to determine what might be the best choice for their needs.

Library websites are especially vulnerable to this problem because libraries do a lot. Catalogs, databases, events, meeting rooms, research help, library cards, ebooks, museum passes, genealogy tools, printing, outreach services, and on and on. Every one of these things matters to someone. But when everything is treated as equally important on the homepage or in the main navigation, the result isn’t helpfulness; more likely, it’s outright chaos.

That does not mean every website needs to be stripped down to three giant buttons. It does mean that when we throw too many options at people at once, we make them work harder than they should. This is what UX (User Experience) pros call “too much cognitive load.” Think of every additional option as an overload tax on your site users’ brains you probably didn’t mean to collect.

This is where Hick’s Law becomes useful. A homepage with twenty competing calls to action does not give users “more access.” It gives them more decisions to make before they can even get started. Which button is for ebooks? Is “research” the same as “databases”? Is “services” where printing lives? Each unclear choice adds more friction. Enough friction, and users typically give up and assume the site does not have what they need.

For library websites, the answer is not to hide everything. The answer is to organize choices around what users are most likely trying to do. Put the highest-demand tasks in predictable places. Group related items. Avoid turning the homepage into a bulletin board for every department. Navigation is not dumping ground: it is entirely a decision-making tool for the user.

Hick’s Law reminds us that “more” is not automatically better. More buttons, more homepage panels, and more menu items can create the illusion of usefulness while actually making the site harder to use. A good library website doesn’t make users admire how much the library offers. It helps them find the thing they came for, quickly and without needing to decode the interface first.

Maybe you or your PR person spent a lot of time on that flyer. Perhaps it required several rounds of proofing and approvals. It might look absolutely stunning. But, no matter how good it looks, it doesn’t belong on your library’s website.

Posting a flyer as a PDF may feel like the fastest way to get event information onto a website, but it creates significantly more problems than it solves. A flyer is designed to be glanced at on a wall, bulletin board, table, or on a social media feed.

A website is different.

People come to a website looking for specific event information: what the event is, when it happens, where it is, who it is for, whether registration is required, and what they need to do next. When all of that information is locked inside a flyer, especially one designed as a visual poster, the website isn’t being helpful: it’s acting like a filing cabinet. One that almost no one is going to bother to go through. And the problems for users begin to pile up.

• PDFs are inherently inaccessible, especially when they are mostly images of text. If the flyer was designed in Canva, Photoshop, or another design tool and then exported as a PDF, there is a good chance the actual event information is not real, selectable, properly structured text. That creates barriers for people using screen readers, people who need to enlarge text, people using high contrast settings, and more.

• PDFs are a mess on mobile. If you’ve ever had to deal with a PDF on your phone, then I probably don’t need to elaborate here. It’s an awful user experience. A poster that looks decent when printed often becomes a tiny, pinch-and-zoom nightmare on a small screen. Users may have to scroll sideways, zoom in, zoom out, and drag the page around just to find the date or registration link. That is not a minor inconvenience. Personally, I’ve gotten to the point where I almost refuse to open PDFs on my phone at all.

• Mobile users are not special edge cases anymore; they are often the majority of your site’s audience. That means that users with disabilities not only have all the usability challenges inherent to PDFs, but it all becomes exacerbated on mobile. WCAG 2.1 partially addresses this through Success Criterion 1.4.10: Reflow, which is about making sure content can be presented at small viewport widths without forcing users to scroll in two different directions. That means PDFs are almost always going to violate 1.4.10 on a mobile device.

• PDFs are terrible for search and SEO. Search engines, site search tools, and users all do better when important event information exists as HTML directly on the page. A page with a real title, headings, date, time, location, description, registration link, and contact information is far easier to find and for search engines to scan. If all of that information is locked up in “preschool-storytime-at-the-library.pdf,” it’s not exposed to outside search tools. At all.

Your website should not make people decode a poster. It should give them the information they came for, in a way they can access it. I know you really liked the flyer’s design but, remember: Libraries are about providing information. If people can’t access our information, what are we even doing?

There are some websites that are useful. There are some websites that are pretty. And then there are websites that stare directly into your soul and say, “Congratulations, you are now approximately one million years old.”

Welcome to You’re Getting Old!, a funny yet slightly grim website that turns your date of birth into a personalized report on how much time you probably don’t have left.

TIME wrote about it back in 2014, describing it as a site that calculates detailed age-related statistics from your birthdate and shows world events from your childhood/lifetime.

The site is very much still around, providing birthday-based data visualizations with a hefty dose of nostalgia (with no AI, btw).

When I first found this site, I thought, “This should be fun!” And it is, mostly. But then I got to the part about the total number of candles that have appeared on my birthday cakes over the years, and that silly number made time feel a little more real. That’s what makes You’re Getting Old! work so well: it starts out as a goofy little diversion, then quietly hits you with the fact that, yes, the years really are piling up.

Maybe we should be eating more cake?

Hopefully, by now, everyone understands how important search is on a website. For many users, it is the last resort when they can’t find what they need in the main navigation. (And, in my experience, library navigation labels are often not especially helpful.)

For other users, search is the starting point. They skip the navigation entirely and expect the search feature to act as an answer engine.

Either way, a website’s search function is a mission-critical feature. But simply having a search box on your library’s website is not enough. There is a lot of research about what makes site search effective, and in this post I want to focus on one issue I see libraries overlook all the time: search placeholder text.

If you’re not sure what I’m referring to, take a look at this image:

The text in the red oval is called “placeholder text.” It’s any text that appears in a search field before the user has typed anything. For years, I included this in my own designs. I assumed, probably like most others, that this text was helpful to users. Turns out, it’s definitely not.

In 2014, The Nielsen Norman Group studied how users interacted with placeholder text. Across the board, it found that placeholder text caused more harm than good, with at least seven (7) negative consequences for users, both with and without disabilities. In addition, for users with disabilities, three more problems are often present:

1. The color contrast of placeholder text against the field background is often not strong enough to meet WCAG requirements;

2. Many problems in the original seven are magnified for people with cognitive or motor disabilities, and

3. Some screen readers don’t read placeholder text at all.

With all of these problems, why would any library keep using placeholder text?

As far as I can tell, there are only two reasons:

• They don’t know better.

• They don’t care.

That’s it.

If you are reading this, the first reason is no longer an excuse. The second is up to you.

It’s doesn’t take much effort to find out where a famous person was born. Or even to get a list of famous people born in a specific location. But what about if you want the most famous person from that place?

There is data to answer that question, but who likes plain, old, non-visualized data? Notable People turns it into an interactive visual experience, helping you explore the answer and much more.

Supported by Wikidata and Wikipedia, this interactive site lets you explore notable people around the world by location. Spin, zoom, and scroll through the globe to see results at every level, from countries down to individual cities and towns.

If you click a person’s name, you’ll get a link to their Wikipedia article, their “notability rank,” gender and whether or not that person is still alive (this last one is not always a certainty. Take a look at Charlize Theron in South Africa).

Even without a particular question you need answered, this is the kind of site that rewards aimless exploration. Enjoy!

“Click here.”

For years, I have been telling people that that phrase makes me want to drink. Here’s why.

First, some backstory. In the early days of the web, everyone was learning how to use it. Nobody knew what a hyperlink looked like. The blue link text with underlining was just beginning to be acknowledged as the normal indicator and we were all figuring it out together. Often, web page creators helpfully included the text “Click here,” just in case someone hadn’t gotten the memo about what a hyperlink was.

But, here’s the thing: we’re about thirty-odd years out from the advent of the graphic internet. People who don’t know what a hyperlink is are now the outliers, not the norm.

When people write link text using that phrase, they’re not helping anyone. In fact, using it negatively affects both usability and accessibility:

• Think about how most people read a webpage; they don’t! They scan the page for things that stand out, like hyperlinks. When a link only says “click here,” it tells the user nothing about where the link goes or what it will do. To understand it, they have to stop scanning and go back to read the surrounding text for context.

  This is an even bigger barrier for people using assistive technology, which may present links out of context. That is why WCAG 2.1 Success Criterion 2.4.4: Link Purpose (In Context) requires link text to identify its purpose. Think “click here” versus a link that says “More bestsellers.” The second one tells you very clearly what the end result will be if you click it.

• We no longer need to teach people how to use a hyperlink. Your library may still offer “Learn the Internet” classes, and those can be valuable. But using “click here” in everyday web content does not support that goal. The rest of the web has largely moved beyond that phrasing. People who are still learning to use the internet benefit from links that clearly describe where they lead or what they will do. Making library links less descriptive only creates another obstacle.

• At a minimum, “click here” can be considered ableist. It assumes that everyone is using a mouse, which is not the case. Many people navigate with a keyboard, voice controls, switches, or other assistive technology rather than clicking.

  It is also not especially accurate. On a touchscreen, such as a phone or tablet, people tap a link rather than click it.

So the next time you are tempted to write “click here,” stop and ask yourself: what is someone actually going to find when they activate this link? Put that in the link text instead. Your users will have a clearer, faster, and more accessible experience. And I may be able to put down the drink.