I’ve always said that one of the hardest parts of being a writer is that at some point in their lives, everyone has written a sentence. People use words everyday, so the impact and importance of having the right content for a situation is often overlooked. It’s just words, how hard could it be?

I feel like I shouldn’t have to say this, but working with content is different than writing—although that’s part of it. Personally, I hesitate to even call myself a writer. Yes, that’s often the output of my job function, but I’m not the type of person who “feels the words” or “has to write to get the words out”. I don’t write in my free time. I don’t just make things sound pretty. I’m not a wordsmith.

I think more accurate—albeit more verbose—titles would be “Customer empathizer” or “Flow clarifier” or “Contextual information presenter”. Just like any other part of product design, I’m recognizing both the customer’s goals and our own goals, empathizing with the current state of the customer, understanding our technical constraints, and creating an output that guides the customer in a way that they can easily understand. Oh, and don’t forget taking into account character count limitations, localization best practices, tone and voice guidelines, accessibility considerations, and tight deadlines.

So when the term “wordsmith” gets used (even endearingly so), it focuses only on the words. Saying something needs “wordsmithing” or asking a Content Designer to “wordsmith this” is similar to telling our Product Designers or UX Designers to “make it pretty”. Or telling an Engineer to “just code this real quick”. Or telling a Product Manager to “schedule some meetings”. There’s so much more that goes into every one of those job functions. To use the very tired iceberg metaphor, the words are what you see, but there’s much more under the water.

So in the spirit of not just complaining about something, a recommendation: consider the work you don’t see.

For my role, the words that end up on screen are the result of reading research, understanding our customers, understanding our technical limitations, considering the design flow, following our guidelines, and more. At the very end of all that, the words happen. Similarly, with every role, there is so much work done outside of the things we see. It’s easy to think of outputs as the work, but when you think of planning, research, drafting, modeling, etc… The output becomes an important—but relatively small portion of the overall process.

Something I started recognizing early in my career is who isn’t invited to certain meetings. I’ve been told I was left off meetings because the conversation was “more strategic”. I often see Support or Localization left out of early meetings since those things “aren’t affected” until much later in the process. Sometimes Engineering is left out of design decision meetings. Then later, we find out that Support doesn’t have the capacity to handle a new feature launch (but they could’ve with proper planning), or translations will take weeks, or designs aren’t actually possible based on existing code structure.

When you begin considering the full scope of work that needs to happen for the output to be effective, you start to recognize that even though a meeting may look “expensive”, the context it provides contributes to an overall better product.

Part of doing what’s best for the customer includes working in a way that sets us up to produce the best results. We have a responsibility to the business, the customer, and to each other to understand how each role fits into the larger picture. Just because a role is performed a certain way at certain companies, doesn’t mean it works the same way everywhere else.

Anyway, TL;DR:

Take the time to learn what your coworkers' roles actually do in the context of your work, and on the flipside, if you’re feeling misunderstood, be bold and educate others about what you do.

Any single project that ships is the culmination of hundreds (maybe thousands?) of individual decisions made by any number of contributors. When that many decisions are being made by so many people, how do we know that they’re the right ones? Moreover, how can we know? Most decisions are based on a combination of intuition and data—however, data an be interpreted differently and intuition can vary greatly between people.

Eliminating (or at least minimizing) these variables can help us make faster and more accurate decisions. so how do we do that?  For any project that’s going to have a significant impact on our customers and require coordinated decision-making, we need to have a set of tenets.

What are tenets and why are they important?

At their core, tenets are a common set of “facts” that can help guide decisions for a certain project. They serve as an agreed-upon foundation that decisions can be based on, compared to, and measured against. Tenets achieve this by:

• Creating agreed upon “truths” – When everyone is working with the same set of facts, it’s easier to evaluate decisions. As we’ve all noticed over the past few years, facts can have alternatives, so agreeing on things that don’t change can help eliminate these alternative facts from coming up.

• Building a framework for decision making – Whether a decision is large or small, having tenets gives you something more focused to compare the outcomes of your decision to. We can always compare our decisions to OKRs or company/team principles, but sometimes those feel too “30,000ft” to help. Tenets are a way to narrow the focus to a single project.

• Keeping projects on track and in scope – Scope creep is real, and tenets can help keep the project in line with its original goals. Conversely, it can also help you decide when adding scope is necessary.

• Adding objectivity to subjective decisions - Some decisions aren’t based on data and instead are based on opinions and experience. By having a set of tenets, you can add a set of objective “checkpoints” to subjective decisions. Additionally, having tenets can help eliminate subjective influencing factors, like charisma and organizational hierarchy.

How are these different than guidelines and principles?

Throughout Atlassian, there are pages outlining guidelines and principles. There may be some crossover, but I consider them to be slightly different.

Guidelines – These are created in order to drive consistency across products and features. For example, one guideline Atlassian has is “Sentence case everywhere, all the time.”

Principles – Tenets fall under principles. Principles should be treated as broad pillars that inform everything we do. For example, Trello has these principles.

Tenets – Tenets are more specific—think of it as principles for a project or feature. In a given project, if have two options that both would align with your overall product principles, tenets are the more focused parameters that can help you make a decision.

TL;DR -

Guidelines = drive consistency

Principles = align the values we deem important for the overall product

Tenets =  guide specific project decisions

How to create them and best practices

When to make them:

Tenets should be considered before any key decisions have been made. Ideally, tenets are the first thing you create post-kickoff.

Where do you put them:

The best place for tenets to live is on a project page. Since this page ideally already serves as the hub for everything related to the project, it makes sense.

Who makes them:

While generally the Product Manager/Owner should own the them, tenets should be crafted as a small team, but agreed upon as a larger team. This team should include PM, Engineering, and Content/Product Design.

Best practices:

• 3–5 per project - Anything more can become unwieldy and confusing.

• Single sentence – A tenet should be a core truth, so it shouldn’t need explaining.

• In order of importance – Some tenets should matter more than others.

• Tension within tenets is ok – Sometimes parts of one tenet may conflict with another—that’s ok and invites discussion.

Tenets in action

Sample project overview: We’re sunsetting Trello Gold. All of the features in Trello Gold will be available in the new Trello Standard, at a slightly higher price point. We already have product principles, so now we created project tenets to help be more specific.

Project tenets:

1. Paying Gold customers are Trello champions. Don’t alienate them.

2. The standard SKU is the future of Trello and will be better for customers.

3. We’re ok with trading off short-term revenue for MAU and PEU preservation.

Explanation:

As you can see, the project tenets are specific to this project and set certain “rules” we can all agree on. They are more narrowed application of the overall product principles.

The first tenet sets our focus on who this will affect and how it should affect them. The second tenet acknowledges that we believe in the the long-term vision of our product, and need to respect that vision. The third tenet allows us to pass on short-term gains in favor of long term success.

You may notice that there’s tension between 1 and 3. We specifically say “don’t alienate customers” but then say “we’re ok with losing short-term revenue” (i.e. some customers). This tension helps us realize that there will be some people that our decisions negatively impact and that we should be ready to mitigate that impact as much as possible.

By introducing tenets into the project process, we can save time, increase collaboration, and reduce ambiguity around how we decide something is “right” for a project.

Give it a shot and see if it works for you and your team:

• Add tenets to your project poster (or wherever you’re documenting your problem space)

• Share your tenets any time you’re doing demos, walking through an E2E experience, or huddling on a design flow

• Revisit your tenets post-launch to see how the end results delivers on each of the tenets

Over the years, I’ve been grateful to have a few Content Designers ask me for guidance, advice, and mentorship. I love being a mentor and it’s something that I work hard to be decent at. A few times, someone I’ve been talking to has said “hey that’s good advice, you should write that down”, so that’s what this blog is.

Accurate expectations > technically accurate content 

So often I see people writing UX/UI copy struggling with creating content that’s clear and concise while being technically accurate. My take on this is it’s not about conveying information, it’s about setting the right expectations. If someone is able to take the correct path forward based on what you tell them—that’s a win! Don’t worry about all the details; you can explain those later or somewhere else.

Go in with an opinion and a path forward, but remember the goal is a decision.

Occasionally I’ll hear about situations where they are having a hard time moving forward because decisions aren’t being made, or that they aren’t getting the support they need from key stakeholders. My advice here is to always have an opinion and a path forward. Often, generating a path forward from scratch is hard—especially in team or group settings. With tons of people and ideas, it can be easy to punt the actual decision to another time or worse, end up in decisionless purgatory.

When you come in to this situation with an opinion and a path forward, you add guardrails and one of two things happen:

1. People agree with you and you move forward with your decision. Great!

2. People disagree with you, in which case you:

   • Ask why

   • Ask about alternatives

   • Agree on alternatives

   • Move forward with a decision. Great!

Being wrong is sometimes the first step to being right and moving forward.

If it's hard to understand, it'll be hard to explain.

More than once I’ve been called out as someone who asks a lot of hard questions. I think that’s because one of my super powers is making things make sense. I have a very analytical and logical brain that loves seeing how things work and how pieces relate to one another. When I can’t make things make sense, it’s because there’s a piece missing or the pieces don’t seem to fit together correctly, so I have to ask really simple and sometimes dumb-sounding questions

Throughout this process, I keep a tally in the back of my brain. If I’m having a hard time understanding this, trying to explain it to a user—who in all likelihood doesn’t care about why it’s so complicated—is going to be damn near impossible.

So what do you do? I think there are a few options:

1. Simplify. Make it less complicated. Sometimes this means adding or removing scope to the project.

2. Prioritize. Many times things are complicated because we’re trying to do everything all at once. Sit down with stakeholders and prioritize concepts/messages/etc… so that you can focus on the main thing.

3. Yolo. Sometimes shit sucks and it’s just going to be complicated. If you can’t do 1 or 2, there’s no sense in dwelling on it. Put your efforts toward the next thing.

Write billboards not books.

I started my career a long time ago in Advertising, as a Copywriter. I worked on all sorts of clients like HP, BMW, Hornito’s Tequila, and….Denny’s. Yes, Denny’s. Now, having grown up in the south, I am very firmly a Waffle House guy, so that already added some baseline complication to working on Denny’s, but I made do. Denny’s liked to do billboards in their media buys, so I got to spend a lot of time trying to make trash food sound delicious to someone driving 75mph down a highway. While I hated it at the time, I think it helped me practice being concise in my UX Writing.

• On a billboard, you have about 3 seconds or 7 words to make an impact.

• There’s a shitload of other things going on when a person sees a billboard (like driving), so you have to stand out.

• Every word has to earn it’s way on there. If a word isn’t required, cut it.

For UI components that need it (buttons, banners, errors, alerts), try to pretend you’re writing for someone who will be reading it while driving down the highway. You have just a few seconds to get the point across and make an impact, so don’t dawdle with making it too pretty.