.png?width=100&height=100&name=bd%20(2).png "bd (2)")
HubSpot is known for a unique and engaging brand voice. I helped define that brand voice in HubSpot's earliest days, working with a small, awesome team of marketers, salespeople, and product (that was me). Our main task in those days was to create a unified house style guide that would govern all content across the whole organization, inside and out. My focus was creating our first voice and tone guidelines. Once that was done, the challenge was how to get folks to use it.
As the only UX writer on the product team, I was most interested in how we could ensure that all product content was in line with our style, voice, and tone guidelines. Mostly that just meant not sounding overly formal, making a few lighthearted jokes, and above all, not using too many exclamation marks.
Most of the time, devs wrote their own product content, only asking me for help when something was a particularly tricky thing to convey. Most of it was pretty straightforward — field names, help text, that kind of thing. But you'd be surprised how easy it is to go off the mark on even apparently "straightforward" content. I was constantly finding little bits of text that needed to be made lowercase, acronyms that needed explaining, or had a typo in it. It was a small thing for me to open up Github, find the mistake, fix it, and create a pull request, but what I really wanted was a way to prevent those mistakes from getting into the product at all.
It would have been absurd (and counter to our company values) to insist that All Product Content Must Be Reviewed By Me. First, I'm only one person. Second, 90% of what folks were writing was perfectly fine. So creating an autocratic human bottleneck was obviously a no-go. I would have hated it, and so would everyone else.
But automation? Now you're talking. I was pretty sure I could automate checking product content at scale. All I really wanted was to ensure that everything that ended up in production was error-free, not embarrassing, and didn't generate a bunch of support tickets because it confused the users. As for matching our product brand voice, most of that could be accomplished by writing in a clear, straightforward, jargon-free style. Contractions help things sound human. A very little humor goes a very long way.
People just needed a tool that would meet them where they worked, and give them real-time reminders of those rules of the road.
I'd heard about an open source linter (Alex.js) that could check any content for insensitive, inconsiderate writing. It came with a bunch of different rulesets that would check for things like non-inclusive language, profanities, jargon, hedge words and cliches. Not all of its recommendations were right for us, but most of them were spot on. And it was easy to edit Alex's built-in rulesets, then take our own style guide and rule-set-ify that, too.
Then I worked with an engineer (the delightful Chris Freeley) to set up Alex on our internal tech stack. Then we built a simple web app (that lived behind a HubSpot VPN login) and then a Slack bot (ditto) that allowed you to paste in any content and get quick, useful, occasionally sassy feedback.
I think it was Chris who started calling it Bethbot, and lo, the name stuck. So I found a cartoony image that I was told looked like me (uncanny, really!) and made that the favicon, slack avatar, and so on.
And thus began several years of looking at a cartoony version of myself in my own toolbar and Slack.
But the real win was when we set up Bethbot as a build test in Github. We made it so that any language string in the product needed to pass the Bethbot test before it could be shipped to production. You could override Bethbot on a line-by-line basis, but in general people respected the guidance, made changes in the string before shipping, or posted a question in the Bethbot Slack channel to suggest a change to the ruleset if they felt the rule wasn't right.
Devs, on the whole, loved being able to make edits to their language strings without asking for help or approval. They also loved knowing the reason behind the edits Bethbot wanted them to make.
Other, non-technical folks across the company started asking to be able to use Bethbot in their usual workflows (AKA not Github), so we built a Bethbot Chrome extension (beloved by marketers, the legal team, support, and even sales), a Sketch plugin (for those pre-Figma designers), and souped up the Slack bot for everyone else.
Then I ran a series of internal workshops across the organization to make sure everyone knew that Bethbot existed and how it would help them create content that was consistent with the HubSpot house style. Or at the very least, was written in a way that was human, humble, clear, and concise.
Bethbot spread across the company like wildfire, and mostly by word of mouth. It turns out almost everyone wants to be a better writer. Bethbot just made it super easy to learn how — without slowing you down.