Beginner’s mind and empathy in writing educational content

I have a newfound enthusiasm for cooking, an activity that, in the past, has caused me great frustration. I have boiled a few good eggs lately after years of not using an oven hob. With my excitement for cooking, I went online to find recipes that I could cook. What is a good recipe to make when you feel confident about making a boiled egg but not so confident to make something like paella or a stir fry or a burger? I have struggled to find an answer on recipe websites.

This has me thinking about “beginner’s mind” and how writers assume knowledge. Assuming knowledge is a necessary part of being a writer; doing it well is what distinguishes great pieces of writing and pieces that are hard for beginners to understand.

“Easy”?

I have seen recipes that are significantly beyond my current experience level positioned as a “recipe for teens.” I didn’t realise a “braised pulled pork shoulder” with 10 ingredients constituted an “easy” recipe for teens.

Herein lies a problem: The material I have read thus far from searching is making too many assumptions. When I read “easy” or “for teens”, I, as a reader, expect something approachable. A guide that requires little prior knowledge or familiarity to understand. I feel out of my depth when I am reading many recipe sites right now.

After some searching, I found my next recipe to make: panckes. I figure I’ll give frying a try.

Whereas it may be easy to assume that a dollop of butter or boiling water to a simmering boil are well established facts, everyone starts at a different level. Some people make dinner for family and can put together nice dishes; other people can’t cook (like me!) but want to learn; others still can make amazing desserts that impress people.

This post is not about my frustration in finding a new recipe, but in the pattern it brought to mind: I am intrigued about cooking, I want to learn more, but I have struggled to find a good resource that is not too far ahead of where I am.

Positioning and understanding “beginner’s mind”

If your guide is self-described as “easy”, everything from the tone to the vocabulary used should be carefully considered. Is 10 ingredients easy? For some, perhaps; but not for the masses who are looking for something to make that meets the two main reasons why one may be looking for an easy recipe: it is low effort, or it requires little expertise to make.

But, I think “easy” is reserved for a particular kind of content. An “easy guide to Python if statements” is not appropriate. “if statements” cannot be assumed to be easy, despite their being one of the first things you may need to learn about Python. Instead, as a writer it is your job to know that you have to shift how you write for the audience. The reader will likely have little to no programming experience. What is easy to you is not necessarily not easy to the reader.

It is hard to understand “beginner’s mind” until you start learning something from scratch and you end up in a position where you know you want to do something, but you cannot find the resource that is the next step ahead of where you are. If and when you find yourself in that position, take notes. What are you struggling with? Why? This will help you articulate how you search for information, and improve your ability to communicate exactly what you want. This can inform your own writing.

I would argue the advice “use a beginner’s mind” is less valuable than thinking explicitly about the challenges you faced when learning about the subject about which you are writing. This allows you to build empathy and reframes the advice as “given what I have read, how can I make a resource that I would have found more {approchable/intuitive/etc.}” Ask yourself: What resources did you find unhelpful when learning the subject you’re writing about? What was valuable or not valuable about each of them? What did you wish was or was not covered?

Considering the audience in technical writing

As a technical writer, I make assumptions about the experience someone will have reading my content. If I am writing a piece on Python if statements, I can assume no knowledge of control flow. I can’t assume someone knows what “control flow” means. It is my job to get a reader to a level where program flow starts to make a little bit more sense.

In contrast, consider a more complex piece, such a building a defect detection system. Any given piece cannot start from scratch. Here, I can assume someone is:

1. Interested in defect detection, but, crucially;
2. May not have a background in the exact solution I am proposing (computer vision)

Thus, I need to be careful in my assumptions. I need to define the problem clearly and explicitly link how my solution solves the problem. I cannot assume familiarity with jargon terms pertaining to computer vision, because someone coming to the guide – the audience – is likely to be more familiar with defect detection than computer vision.

Knowing what to say and how to say it in technical writing involves thinking critically about exactly what someone needs to solve a problem. I need to ask myself questions like:

• If someone finds this post, what concepts are they likely to know?
• Which concepts do I want to focus on introducing in this guide?
• Is it likely the reader will know what {word} is? Maybe I need to add a sentence to define the topic?
• Have I introduced a lot of dense information (i.e. a complex code snippet)? I should explain it step-by-step.

Sometimes, you will take a leap in logic. It happens. I recently asked some technical writers how they feel about their past work, and the consensus was that everyone sees their work improve over time. Empathising with your audience is a long-term muscle to be built. Considering your audience and using that to start to build empathy is something you can do right away that will help you make your writing more tailored to your target audience.

Helping people find the guide for their experience level

Writing a guide tailored well for a beginner is not enough. Helping someone find the information for their experience level is essential, too.

I wish recipe sites, and many other educational sites, had a “101” or variant thereof, with a list of resources that someone with little to no experience in the subject could use. The writing should be simple and allow progression. In the case of recipes, linearity should not be assumed; someone may skip to the recipe that looks tastiest from your selection of “101” recipes. If they do, the reader should not feel out of depth. The context is 101. The content should be written as such.

A recipe site that had a “how to fry eggs” guide which followed the following order would have been extremely helpful for me.

1. Oven hob basics (what low vs. medium vs. high heat means)
2. Do I need to use butter or oil? Are there other options?
3. Crack an egg into a different bowl (so you don’t get egg shell in your pan)
4. Start frying the egg
5. How to tell if your heat is too high or your egg is about to be overcooked

I was starting at the point where I didn’t know what heat levels were. I’m sure many people have been in that position, too.

After all, everyone is a beginner at some point; elevating beginner information is valuable in repositories of information. In programming, the equivalent is a “Quickstart”, which has one aim: get you using a piece of software as soon as possible. Quickstarts should be written without assuming the author knows anything about your software. Quickstarts are regularly high up in the information architecture of a website. They are written as an entry point and given priority in navigation elements as a result.