Domain Knowledge: What You Need – Or Don’t Need – To Know

Here’s what I’m not.

I’m not a pipe fitter. I’m not a garage door salesman. I’m not a software engineer or a big box retail executive or a business journalist. I’m not a butcher, baker or candlestick maker. Damn it, Jim, I’m not a doctor NOR am I a mechanic.

As content strategists, we are expected to help our clients communicate the concepts, benefits and advantages of their company or industry. But we are not who our clients are. We do not possess the same amount of knowledge about their business.

There’s a knowledge gap that we need to bridge.

Or do we?

The Dilemma of Domain Knowledge

Imagine: you’ve just pulled in a big project for Major Academic Ornithology Organization (MAOO). The organization has big plans for standardizing its academic papers and providing a richer experience for its members, all while providing a lasting impact on modern ornithological study. It’s a big deal – they want to pay you lots of money, in REAL DOLLARS, for an overall content strategy plan.

You assume you should bone up on your ornithology. But how much do you need to learn?

Herein lies the dilemma. You’ve been hired to help with this project, but you can’t tell the difference between a Western Highland Warbler and an Eastern Georgia Jumping Jay, let alone use that knowledge to develop an effective search and navigation taxonomy.

But wait. Do you NEED to know about ornithology? Or is your expertise in content strategy enough to get the MAOO and their scholars to the next level?

So. What do you need to know?

(Let’s define a few things, quick. Throughout this post, I will refer to industry-specific knowledge as “domain knowledge.” I will refer to your content strategy methodology as “method knowledge.” Somewhere in between, you’ll find organizational workflow – how a company handles content with regard to process.)

You Need to Know What You Need to Know. (I Know.)

The simple answer:

You need to know as much as you need to know.

What an awful answer. I hate it. HATE it.

We can’t get around it, though. Because the answer is that you need to know ENOUGH, and outside of recipes and swimming pools, there’s no real way to define what “enough” is.

Let’s shift that, though. Instead of focusing on how much, let’s focus on what. Let’s refine it to:

You need to know WHAT you need to know.

And here’s what you need to know:

The company’s business objectives

Understanding your client’s business objectives gives you and your client both a basis upon which to make decisions and a fallback for when discussion begins to stall.

Learning more about business objectives means asking a lot of questions. Who makes decisions? What drives profits? Etc. James Kalbach’s recent post on his Business Model Canvas provides an example of how you can gather goals and objectives from a client. It’s a great read, so I’ll leave it at that.

The basics of the industry/field

Enough not to look stupid, essentially.

For example: when you’re working with a local pizza place, you should at least know the difference between different styles of pizza. Nothing will deliver a bundle of stink eye faster than referring to Tony’s 20-inch thin crust pizza as “Chicago style.”

On a larger level, you should be familiar with at least:

• Major competitors
• Industry trends
• Industry (and company) history – what has worked (or failed) in the past
• Significant ideas or personalities in the industry

Do you need to know the difference between pipe fitting sizes? Not unless there’s a reason to do so. And your client will let you know that reason when it comes along.

A contact number for a reliable subject expert

Go ahead. Research your little heart out. But know one thing: you are an outsider, and you need help – and, ultimately, buy-in – from a respected subject expert. It might be your client contact. It might be someone at the company. It might even be a handful of books and blog posts. Whatever. Consult them, become their friend, and never look back.

The company’s content and organizational workflow

We’ll touch on this later.

Your Client is a Partner. Use Them Accordingly.

The reason we as content strategists can get away with shallow domain knowledge is because we have the client to fall back on. Content strategy – and user experience in general – depends on the partnership between client and practitioner. They use us to enact organizational change, and we use them to better understand our project.

The worst thing we can do is assume we know everything about a client’s line of work. Sara Wachter-Boettcher says it perfectly: “We all hate it when a client suddenly decides she’s a UX expert one week into the gig, so why should we pretend we’re [fill in the blank] experts either?”

So our clients are our partners. Use them to your advantage. You already do as much when you perform:

• User interviews
• Card sorting exercises
• Insight into industry trends
• Checks for understanding

Above all, set up expectations. Be honest. Remember: we are not hired for our knowledge in the domain. We are hired for our ability to communicate that knowledge in a way that’s both usable and useful for that domain’s audiences. And we do this by relying on our relationships, not by diving into a project all guns a’blazin’, all the answers predetermined and worked out.

What’s more, we need to understand our role within the companies we work for. We are not web developers or advertisers – we are communicators. We provide perspective by bridging the gap between company and user.

“Don’t apologize for that external perspective,” Margot Bloomstein says. “It’s more of an opportunity than a liability.”

Collecting Domain Knowledge

There is only one real way to collect domain knowledge: you ask questions. Lots of them. There’s one problem: people aren’t always willing to open up and pour their hearts out.

Despite the fact that you’re being HIRED to help them work out their problems, many clients don’t actually want to talk about their problems. Funny, right? So, you need to go further in.

Erin Kissane, for example, passed along the following checklist of domain knowledge collection tasks.

• Site reviews (inventory and auditing)
• Competitive landscape reviews
• Stakeholder interviews
• User interviews
• Background research on influential executives, important mergers or acquisitions, organization history, published interviews, etc.
• Reading books/posts/articles by influencers

Along with this, Richard Ingram added the need to audit and test existing content for understanding.

That’s a pretty heavy list – but the issue has never been about finding ENOUGH information – it’s been knowing when to stop.

Is it a percentage? On two recent projects, we used 35% of proposal hours for the discovery stage, which includes user interviews, content audits and inventories, and a detailed list of audiences and site goals.

How much that went to actual domain research? Maybe only 5% of the total project.

Which is to say: on a 200-hour content strategy project, we would budget 10 hours of dedicated domain research. For a smaller project, we assume that the domain is not as detailed. For a larger one, likewise.

Is this realistic? I don’t know. I DO know that on our next project, we will be baking in a 5% domain research budget. Just to test it out.

Kissane says, “The answer isn’t that (we) become a peer expert in the client’s field. By the end of the process, (we) want to accomplish two things:

• Ask the right questions of the right people at the right time
• Identify patterns in client processes/problems and in (our) own scattered ideas about possible solutions.”

Knowing what to find. Knowing when to stop. We’ve got it all down, right?

So, What Was the Question Again?

Let’s be honest, here. We’re not even asking the right question when it comes to domain knowledge.

Remember earlier when I said we’d talk more about content and organizational workflow? This is it. It’s not about learning about ornithology or sports display systems or electronic medical record software, it’s about understanding a company’s organizational methods.

Our initial research should be connected to domain knowledge, yes, but it requires an intense look into a company’s workflows, governance methods and management structure.

“Having something to say requires that I understand the thing and the organization enough to say it clearly and accurately,” Nicole Jones says. “My work is not something that I can squeeze into a template.”

Want to know how we drive organizational change? Want to know how we get what we want in a project?

We secure buy-in. And we do this by admitting to the client that we don’t know everything, and that we need their help to make this work. We seek out project backers who are champions for the process – people who will help spread the purpose and importance – and if we can’t find those people, we create them within the organization.

Most of all, we understand that, unlike designers or developers, our job in the web process – and in the marketing process as a whole – is to consult and strategize. We drive change. We offer guidance. We shift understanding to a content-driven process that, at this point, requires an external perspective.

As our discipline becomes more codified, we will begin finding best practices – especially in those items that help define our project proposals. We know roughly how long it will take to code a site feature, and we know how many design revisions a client can get for a set amount, so why can’t we say, with certainty, that THIS is the amount we charge for non-deliverable domain and organizational research?

And when we get that far, we’ll be confident in replacing “We need to know as much as we need to know” with “We need to know THIS.”

Special Thanks

A quick note: obviously, this post applies to consultants and agency-folk. You in-house content strategists? You have no choice but to obtain a higher level of domain knowledge.

A billion thanks go out to the content strategists and UX professionals I reached out to for this post: Christine Anameier, Margot Bloomstein, James Callan, Meghan Casey, Georgy Cohen, R. Stephen Gracey, Richard Ingram, Nicole Jones, Jonathan Kahn, Erin Kissane, Karen McGrane and Sara Wachter-Boettcher. I asked. They responded.

Extra thanks goes to Deane Barker for bringing this up in the first place, back on the IAI discussion board on LinkedIN. And, I guess, for forcing me to find an answer.

Y’all rule.