Build Your Digital Writing Toolbox

Scott Kubie is a senior content strategist at Brain Traffic, a Minneapolis-based content strategy consultancy. Scott has worked previously as a digital strategist focused on early-stage startups, and was the first UX content strategist at Wolfram, makers of Mathematica and Wolfram|Alpha.

We asked Scott a few questions about the idea of a digital writing toolbox — how it helps writers get better footing, and how it facilitates collaboration — as we get closer to his workshop, “Build Your Digital Writing Toolbox.”

When you talk about a “digital writing toolbox,” what specifically do you mean? Do you mean concepts and processes, or do you actually mean tools, like specific spreadsheet templates or audit programs?

So when I talk about the toolbox, the most important part ends up being the drawers and sections of the toolbox, so to speak. My experience has been that folks who don’t have a background in writing don’t feel confident as writers — they don’t have any sort of personal process for getting writing done. It’s like, “Okay, I have to write a thing, so I hit New Document in Microsoft Word and I guess I just start typing?”

A digital writing toolbox is about helping individuals understand that there are more steps to writing than just writing, while also giving them options and ideas for tools — like a particular spreadsheet, or a framework, or a questionnaire or mad lib — that they can keep handy as part of their process.

I find that when individual writers feel more comfortable, writing as a team and writing as an organization gets easier as well.

How did you come up with this concept of a toolbox, and how did you build your own personal toolbox?

A jumping off point for me — when I started to think about all this — was probably around 2009, when I was working at a small startup company. We did iOS app development and custom web development, and there were two really smart technical co-founders at the company. We made a commitment to create a company blog, to raise our profile, and one of the co-founders — a developer, who is just fantastic and one of the smartest guys I know — came to me one day and asked very plainly, “How do I write a blog?"

And I was like, “Oh, so, do you not have a login to the CMS, or …”

His answer was, “No. Just, how do I do it? Like, what is the first thing that I do?”

And I realized that, while I guess I knew how to write, I had never thought about how to explain the process. So I gave him an outline of what the writing process might be. I realized that he was stuck because he was smart enough to know not to just start typing, but he didn’t have his own process for approaching a task like this. Or know that he might benefit from creating an outline, or that he might benefit from things like free writing, where he sets a timer and just writes and writes.

In explaining that process to him, I now had my own little toolbox in my head. Everything else I knew about writing started to fit into that toolbox.

Do you ever run into any issues of rigidity, like the toolbox is too structured and defined to allow for differences within a new project?

Yeah, absolutely. The biggest thing I run into is attempting to plug into an existing process. You have an organization, and this is how they get their content done, and the tools they use, and maybe they have some specific applications or an outline on how their project is facilitated — but there’s something in how the process is set up that makes me feel handcuffed as a writer or a creative person.

That’s not to say that the process is bad — it may be a great process! But if I feel that the only tools available to me are the tools that are prescribed from on high to match a rigid process, it can be really hard to get my work done.

So one thing I coach people on a lot is to develop a personal workflow and look at how that relates to the organizational workflow, or the way the client likes to work. I see this in my own work — Brain Traffic works with large enterprise organizations, and they tend to like Microsoft products. They like to get things as Word docs or Powerpoint. I personally don’t like those tools at all, so I don’t work with those tools until the very last step. I have a step in my own process that allows for translation from my format into their format, which to me is a lot more fun than fighting with a tool that I don’t like all day.

I find a lot of people just don’t realize that they have permission to do that. They feel that if the end output is one thing, they have to use that one thing the whole time, even if they hate it and it drives them crazy. You hear, “I hate writing in the CMS!” Well, then, don’t write in the CMS. Write somewhere else and put it in the CMS.

You talk in your workshop description about the complexities that come with collaboration. Do you have any examples of this complexity and how it affects the process, or even the content itself?

Sure. I think a really common complexity when collaborating is understanding or clarifying what type of feedback you have received. Think about Google Drive, or the Google Documents format — they’ve started baking in this idea of suggestions vs. revisions, which is a subtle but important distinction. But not every tool has that included, right?

Sometimes I’m guilty as an editor or collaborator, where I will take a wishy washy stance. Like, “You know it might be better if you tried writing it this way.” And then the person receiving that feedback wonders, “Are you telling me to say it that way? Are you in charge? Who gets to decide how this is written?” (I have an opinion about that.)

Categorizing feedback and knowing what to do with it can be really challenging, especially when working with people who aren’t clearly in a writer or editor role — or an editor-in-chief role, where that role is responsible for making the final decision. A lot of times, feedback is a group effort, which can be nice — and necessary — in some organizations, but is frustrating when it comes to actually figuring out what the final text should.

So when you say you have an opinion on who gets to decide, are you specifically talking about an editor-in-chief? Or does that depend on the project?

Yeah, it does depend on the project. My preference is to be clear about who is going to be the writer and clear about their responsibilities. For example, I can say that you, Corey, are the writer for this project. To me, that means you need to own the text. You have to make the initial decision on how to treat feedback. And then, hopefully, when that text comes back around for something like a final approval, we’ve seen that you as a writer have taken all of this various feedback from collaborators or soft editors and turned that into something that we can say with confidence, “This is the text. Do we feel comfortable with this text? Speak now or forever hold your peace.”

I think that’s where a lot of processes break down — especially if people kind of get sucked into the writer’s role. Maybe they’re more typically a designer, or they’re a front-end developer who just has to write a couple of headlines to get the job done. They try to keep the text at arms length, and they have all of these apologies — ”I’m not really a writer. I don’t know what this should be.”

Just own it! It gets so much easier if you just own it.

To get back to the question, I do feel that an editor-in-chief role — especially for something like a larger website, where we’re going to have lots of pages with content on them — is very necessary. This, again, is where a lot of organizations fall down. “We can’t hire an editor-in-chief!” That’s fine. You don’t need to. But look around — out of all the people on the team already, who can be named editor-in-chief? Make them a little hat that says “editor-in-chief” that they can put on when they need to. But someone needs to fill that role.

What advice do you give when it comes to prioritizing your content production plan, and how do you delegate that prioritization?

You know, It’s great to have all these ideas — but working as a consulting content strategist the disappointing feedback we sometimes have to give is that their content production plan — a plan that’s very exciting to them, and it does look really fun — shouldn’t take precedence over all of the cleanup work they have to do. When you think of it — and this is a ridiculous metaphor — it’s like putting up decorations, but ignoring the roof that’s blowing off in the storm. They may have all of these articles that are out of date, and they need to patch that roof.

Looking internally at the organization is a good place to start. User needs are important, sure, but also take a look at things like “What do we have to sell this year?” Does the content plan include all the information and content to support the goals an organization is trying to accomplish. Then, after you’ve thought about yourself, think about your users. Think about your functional needs, then think about their questions and what they’re looking for.

As far as delegating your plans, I think that really works best in a workshop meeting environment, where you can put calendars on the wall, or on the computer screen if you’re working remotely, and get everyone together in the conversation at the same time. Partly, this is because you need to make sure people are paying attention — that they’ve really opened their calendars and made sure that the plan works, so there’s no sudden sabbaticals in June when they’re supposed to be producing a blog series. Collaboration is really key to that production planning process.

You’ve written a lot about content ecosystems in the past few months. Explain what you mean by “content ecosystems,” and how does that fit in with this idea of a content toolbox?

When I talk about content ecosystems, I’m talking about the world that your content lives within, or the world that your content exists to support.

When I do content ecosystem mapping with an organization, what I’m trying to do is put the hard ideas and the soft ideas on the same canvas. So there’s the hard ideas: the brand, the teams within the organization, maybe some of the roles like an editor-in-chief. And then there are soft ideas, like policies. We pull in writing guidelines, or accessibility policies, or a formal QA process.

Taking everything related to the brand and its content —including the processes connected to them — and mapping it together, seeing it all at once, helps people understand how vast the content empire really is. I’ve never run into anyone that overestimates how much they have to support — they tend to grossly underestimate it.

So, as an example, putting everything out there may help them see that if, say, they have an app to support, that they’re also going to have to support app store updates, and that means updating change logs and creating support materials, and since they may be on iPhone and Android they’ll need to also support that for two different stores. That’s a whole channel — those app stores are channels that need content, and those apps are products that need content, and it’s possible for a team to have never considered that as part of their content ecosystem.

If you put it up and scope out the ecosystem, you might be able to visualize decisions like “Maybe there’s not room for the Pinterest account this quarter, because we have a whole lot of stuff to manage.” Ultimately, it kind of meshes together the hard realities of what your content is with how you might want to move and play within the roles and products and tools you’ve created.

Great, thanks so much for your time!

Okay, thanks a lot!

Scott Kubie will be presenting his workshop, “Build Your Digital Writing Toolbox.” at Now What? Workshops on April 25-26, 2018.