In my $dayJob, I am a technical writer for an educational technology company. Our product is a big, highly customizable software package with tons of options and ability to turn on and turn off features for everyone or specific roles of people. As advocates for helping our clients do their best work, we create help content in the form of user journeys in knowledge bases. The content contains tasks for answering How Do I questions, conceptual information about what the feature or tool does and the benefits of using it, and reference information for how to set configuration variables and permissions, and how to pull the data points they need for a ton of different analytics. That boils down to a giant repository of information

Earlier this year, we started a massive undertaking to fundamentally shift how we do things. We made decisions based on over a year’s worth of needs analysis of customers and internal users, and process analysis on how and where we provide information, and who provides it – the Knowledge writers, training, learning and creative services, sales enablement, support, technical account managers – everyone wants to help clients get the results they want. Everyone wants to speed up time to value. In the old world order, we had a giant repository rife with good things, but it also meant that we were duplicating effort, providing (sometimes) conflicting information, we weren’t removing old, obsolete information, and our search results became questionable because of the choices we provided. We were, in trying to help, making it less helpful.

So we’ve found ourselves in conversations about how to provide a single source of truth. And how to display that information in a way that is highly digestible for client consumption. As my team has been creating tables of contents for specific roles, we had a few parameters imposed on us from I’m-not-sure-where:

• Tables of contents shouldn’t be more than 3 levels deep.
• A single topic should have a full workflow (not just smaller pieces of a workflow that may or may not be also performed separately)
• The reader shouldn’t have to scroll more than two pages to read everything.

These are all good guidelines, but they cannot exist in the same pristine, perfect workflow. There’s just too much information to share. So when we’re sending content for review, we’re getting feedback that the topics are too long. But if we separate them into nested topics, then there’s more than 3 “clicks” to get to the content. We can’t just ignore the content, so do we break the 3-Click rule or the 3-Scroll rule? What’s a writer to do??

This is the classic conundrum of going around the mountain or over the mountain. If you need to get to the other side, those are your choices. With our mountain of information, if you don’t like to click more than 3 times, then you’re going to have to REALLY love to scroll. Don’t love scrolling, then prepare yourself for the clicking. Those are the choices, right?

I get it, decision paralysis is hard, especially if neither option is right or wrong. We aren’t going to make everyone happy. But we still want to provide a good experience for everyone who shows up in our knowledge base. Sometimes, you just have to listen to what they want, which might not even be what they *say* they want.

During Advent, may I listen to what others need with an open mind. May I understand the difference between needs and wants, and may I respect that sometimes it takes different paths to get to the same destination.