A solution must be useful for first time users as well as those more expert in SEO

One of the most important questions for my RJI Fellowship project has been thinking about the user experience. Since my project is to build a Slack bot to help newsrooms understand SEO best practices, I have had to consider how newsrooms may want to utilize this tool and  how to make the user experience smooth and useful.

I am in the testing phase of my project, and if you would like to test my bot you can do so by signing up. I have found there is such a wide swath of user experience and knowledge in relation to understanding SEO best practices. There are users learning about SEO for the first time as well as users who are more expert in SEO than the rest of their teams. How can a tool help all types of journalists do their work better?

An SEO editor described the process he did in building topic clusters as building spokes on a wheel. Let’s say the center is a broad topic like the NFL playoffs. The spokes are the pieces that drive the SEO strategy, the items that relate loosely or tightly to the topic. If you think of the NFL playoffs as the center, the Super Bowl is one spoke, but overtime rules are another, and so are all the teams in it. Each item is an iteration of the topic, but is also its own content – and that helps users when they engage with content on a landing page, or click a related story within another story.

This idea of thinking broadly and then digging into the details is what I have looked to reflect in my use cases. When a user searches for anything, the data they see is typically a headline, link and long description of the story. Making sure that headline, what users see, reflects what is important in the story is key to earning that click. So the question I tried to tackle is: How does what is written in the story relate to the headline and description presented? Ideally, it would be strongly correlated. 

When I think about the process of these commands and tools, the ideas have come in a similar way: What is the thing we are looking to do? How can we take parts of that thing and give it more context, more relevance and show why it’s important?

Behind the use case

My first use case centered on this comparison lens: Why did one outlet beat our story? What did they do better than us? Why did they beat us? And from there I started to do more research, and learn more about what people consider important and what stood out to them.

While those interviews were happening, I worked on a flow chart describing how the service would work; this has since been improved upon while developing it. Notice this is just use case #1, because the ideas from all of the interviews have driven at least seven more ideas for use cases.  

This is the flow of what I thought about the process. The bottom stickies are supporting research from user research.

Even when this felt “done” it wasn’t when someone else asked me: How could I know that I am surfacing the right keywords in my story? How can we prove that? 

So, how can we prove that a word is relevant in our story and headline?  We can count the number of times it is in the story and look up whether it is being served in the headline, description or other metadata.

How that works in my SEO bot is to enter a slash command (right now it’s “/beta”) and then paste a URL or two or three in. The bot looks for the relevant data on the page, like the h1, the page title, paragraphs of text and other data that displays on the page. Then the tool tries to relate what is in the text to what is in the title, by using a natural language processing library to extract the information. 

For example, a story like Cowboys owner Jerry Jones responds to Lakers star LeBron James’ comments in the Dallas Morning News would pull out Jerry Jones and LeBron James as people in the keywords. Then in paragraphs in the story, Jones and James are mentioned, so you could compare and say how many times they are being mentioned in the story.

One of the most prominent things people said in research was that the headline is the most impactful place for us to affect others with our journalism. Making that the spot where we make sure the actions are done was my thinking for this first use case. 

Who are the users? 

This is a question that came up as I did research interviews and surveys. Each newsroom has a different process and workflow, and even though they all get to the same destination on the web, they get there in many different ways. So how can I create something that helps everyone? 

This is the user taxonomy that I have built as I come with my solution.

Since this bot would be a part of an established workflow in newsrooms, I am thinking about how it can help specific people with their day to day work. That is where I have made categories for certain types of users, such a web or digital producer, who may be in charge of changing keywords, headlines and tags post publishing. Another could be an SEO editor who is looking to see how page performance is being helped or hurt by their CMS. An editor may be looking for stories from Google Trends or looking for trends inside another story. A reporter, while writing the story, could be looking for keywords to use and what links should be added to the story. 

The idea of this “user” is interchangeable: Many of these roles in different organizations sit in different groups and have different people doing them. I showed this chart to a few interview participants and they said it reflected things at their newsroom, but that doesn’t mean it reflects every newsroom that would use this.

So if you think that you are a type of user here — you should join the testing for this Slack bot and see how it could help your workflow!