Alli Pane
In The Hudl
Published in
5 min readOct 29, 2018

--

Here’s the thing about creating a brand new design system: Documentation is the most important part.

We learned that the hard way.

There was no rhyme or reason to our first set of guidelines (as mentioned in this super cool article from Michael). You could find design resources in one spot but the code lived somewhere else entirely. It was all valuable, but completely ineffective because nobody could find anything.

So we sat down to start fresh with Uniform and made the actual documentation our top priority. It seemed easy enough— a lot of the components and their guidelines were already over a year old, it was just a matter of giving everything one central location.

If what we designed was meant to reflect product design, why shouldn’t our writing do the same?

But we quickly realized effective documentation boils down to well-organized words, and we had zero standards on that front. Sure, we could have created our own rules — rules for that squad and no one else — just to ensure the guidelines felt uniform. But if what we designed was meant to reflect product design, why shouldn’t our writing do the same?

Ghosts of Product Copy Past

In July 2017, when we began documenting Uniform, our product design team consisted of 20+ designers and 0 writers. I was officially on loan from the marketing team purely for the sake of this documentation. I’d created plenty of resources on behalf of the brand, centered mostly around voice and tone, sales materials and social media, but product copy?

Because product design had little in the way of copy resources, marketing editors received the occasional request to proof one interface or another. There was no formal process, and even if there had been, it’s a whole different ballgame. Product knowledge and familiarity with our users’ journey is key.

So, while I’d love to confidently proclaim those early interactions between product designers and marketing editors had a snowball effect and we ultimately had an influence over the words in every corner of Hudl, that was never the case. We all did our best, but the relationship never panned out.

Enter: the opportunity to create resources specifically for our product. I was giddy, but holy smokes was there a lot to cover.

Considering Each Component

The copy requests of old often focused on an isolated interaction within the product, so even before starting with Uniform, I had a feel for the nuances of writing for a button vs. a tooltip, etc. Now, seeing as we were already creating and documenting individual components, including microcopy guidelines for each seemed like a decent place to start.

The Microcopy anchor is mandatory for any component that may include words.

Not only did it save us from thinking too big right off the bat, it also sent the message that we really do care about the words in our product, and provided quick, relevant tips for better writing.

Whether they knew it or not, every person we talked to was laying the groundwork for Words.

The best part? Designers noticed. We knew as much because the squad was fielding questions and requests like nobody’s business. Sometimes a guideline didn’t quite fit what they were trying to accomplish, or they had a component we hadn’t covered yet. Product copy conversations were becoming a regular thing! With more detail than ever before! And whether they knew it or not, every person we talked to was laying the groundwork for Words.

The Inception of ‘Words’

Our decision to give Uniform a full-blown writing section had less to do with my obsessive nature and more to do with the bad habits we spotted throughout the product.

Very rarely were those habits contained within a specific component. It was always a matter of time and place, where things could be styled any number of ways — title case vs. sentence case, period vs. exclamation, “your” interface vs. a more neutral label.

And to be clear: This was nobody’s fault. There were no existing guidelines to reference, not one person to rely on for product copy, and a lot of designs to get out the door.

So we pulled together the most common struggles, like writing out date and time, when to title case, and the impact too many exclamations can have. For trickier items, like Hudl’s voice and tone, we took a (figurative) page from Components and provided visual examples.

Some concepts are difficult to get across without added context.

Slowly but surely, it all formed a larger resource created specifically for designers and developers. We added pages and subsections based on each topic’s recurrence within the product, and examples were almost always pulled directly from the wild.

Thus, Words earned its place alongside Components and Visual Guidelines on the Uniform homepage.

The finished product allowed us to clean things up with one fell swoop, rather than snipe here and there with nothing to reference along the way. We hoped that as more teams implemented Uniform-the-design-system, we’d find more instances of outdated or inaccurate copy to fix.

We were mostly right.

The Slow Demise of Robots

(Maybe not actual robots, but robot speak.)

When we started building Words, we had about a dozen components built out in Uniform. The design guidelines we’ve added since were prioritized largely because they featured a lot of words. Tooltip was a big one, as were alert and modal.

Now we’re starting to think about patterns, like empty states and on-boarding, and we fully expect Words to evolve with each addition. Because no matter how hard we try to sound like actual people, our adherence to “clarity over cleverness” can make personality hard to come by.

A shot at brevity where we may still be missing key info.

One thing that should make this a little easier is my transition from Borrowed Marketing Copywriter to Full-Time UX Writer. It’s allowed me to become more involved in product design as a whole and spot where the copy itself is most prevalent. I’m no longer creating guidelines on a component-by-component basis, but finding full-blown patterns in the words we use, determining what’s right or wrong, and building a new set of resources to help the team understand why.

Not just why we choose one thing over another, but also why it’s better for the user. It goes beyond choosing this color or that type for a more cohesive design to communicating exactly what a user can do for a more effective experience.

In other words, Words is just getting started.

--

--