Three Things I've Learned About Writing Abstracts

Recently I've joined the developer advocate team at Confluent, which is full of highly experienced speakers who have mentored me as I craft abstracts.

I'll be honest; when I began writing abstracts I thought, "How hard can this be? I've written plenty of blog posts, technical articles, and the occasional haiku. Abstracts will come naturally."

Reader, they did not! The art of writing and fine-tuning abstracts is challenging, but learn-able. Luckily, I've gained a lot of knowledge from my teammates and now I feel a lot more comfortable with writing abstracts. I wrote this post to hand on a few of the things I've learned.

1. Connect with your audience in the first sentence.

Let's start with this abstract that I've written up for the purpose of this blog post:

"Come to my talk about choosing React frameworks. We'll learn how and why to choose the framework that suits your web development needs. You'll learn criteria for choosing a web development framework and how to apply them. By the end of my talk, you'll know more about the React ecosystem and have the tools to get the job done."

The first sentence, "Come to my talk about choosing React frameworks," is a nice invitation but it doesn't really hook the reader. In order to connect with the audience, it's a good idea to start by mentioning their pain point. In this example, a good first few sentences might be more like the following:

"The number of React frameworks in recent years has reached an overwhelming height. Social media debates run fierce. There's only one consensus: choosing the right framework for the job is of paramount importance. But how, exactly, do we pick a framework?"

2. Position your pronouns thoughtfully.

Take a look at the abstract once more.

"The number of React frameworks in recent years has reached an overwhelming height. Social media debates run fierce. There's only one consensus: choosing the right framework for the job is of paramount importance. But how, exactly, do we pick a framework? We'll learn how and why to choose the framework that suits your web development needs. You'll learn criteria for choosing a web development framework and how to apply them. By the end of my talk, you'll know more about the React ecosystem and have the tools to get the job done."

There's "we", "you", and "my" here. Consistency is key in all writing, but for talks, you might choose "we" over other options to reflect a sense of comraderie with the audience.

3. Let your solution for the audience's pain point be clear.

Currently, the solution that the speaker offers is vague:

"We'll learn how and why to choose the framework that suits your web development needs. We'll learn criteria for choosing a web development framework and how to apply them. By the end of the talk, we'll know more about the React ecosystem and have the tools to get the job done."

In fact, all you can really tell is that the speaker is offering some kind of solution. There are no hints as to what it might be.

Here's a better way to express the speaker's intention:

"We'll distill the criteria for selecting a React framework into three crucial questions. Then, we'll walk through a few use cases together to garner some experience making these decisions. What does the decision making process look like for building static portfolio sites, large e-commerce sites, and mobile game apps? By the end, we'll feel ready to critically appraise React frameworks, familiar or unfamiliar, for our own projects."

This gives some detail ("three crucial questions", and the use cases) without giving everything away. It also communicates the value to the audience: a confidence in their choice of framework.

Now the whole abstract reads:

"The number of React frameworks in recent years has reached an overwhelming height. Social media debates run fierce. There's only one consensus: choosing the right framework for the job is of paramount importance. But how, exactly, do we pick a framework?

We'll distill the criteria for selecting a React framework into three fundamental questions. Then, we'll walk through a few real-life use cases together to garner some experience making these decisions. What does the decision making process look like for building static portfolio sites, large e-commerce sites, and mobile game apps?

By the end, we'll feel ready to critically appraise React frameworks, familiar or unfamiliar, for our own projects."

I think this version sounds a lot more interesting and clear, don't you?