Anyone Can Get Words Right: Content Patterns 101

Kalina Tyrkiel at UXDX Community: Scaling UX: Clear Content, Smart Testing. Video: https://youtu.be/fDYapjDmfVs

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Who I am and why content patterns matter

[00:00:09] Let's jump right in and let's talk about all the behind the scenes, as AJ has already mentioned, of how we make the products that we work on better and scalable. In my case, I will be talking about how this happens through content and through getting content right. I imagine we probably have some content designers, UX writers. These two terms are used interchangeably. We probably have some of these content people in the audience, but I believe we also have some product designers, UX designers, people coming from all fields, hopefully excited to hear how to get the content part right.

[00:00:48] So here I am to give you a little sneak peek, some actionable tips as well, on how these things happen, and I will be speaking from my experience as a content designer. I currently work at a company called Zendesk, which you may be familiar with. It's a customer service company, but it's much more than that. It's a huge complex system, also in terms of content, covering a lot of AI features that we work on right now. I am working mostly on AI features, so there will be a little bit of an AI sprinkle in my talk.

[00:01:20] I have previously worked at different companies, and the one that I will be referring to today is called Docplanner. It's the perfect company for booking your health appointment, and for doctors as well to manage them, which, as you may imagine, comes with a lot of patterns and a lot of content to strategize and work around. Apart from these things, I'm also a UX writing trainer and a university lecturer, which again gives me the perspective of a person who's teaching other people how to do these things.

[00:01:55] The way I structure my courses, the way I structure my classes with my students, is now largely based around how to get things right on a larger scale. And these things are shifting with AI entering the field. I will be telling you a little bit more about how things are working right now and how you can plan your work around it. On top of that, I am also a team member. I wouldn't be able to manage the words, the content in all these systems alone. So I think it's crucial, it's important to reiterate at the very start that all of these things you'll be seeing are always a team effort. And I will be telling you a little bit more about how to plan this work as a team effort as well.

Three content design breakthroughs

[00:02:39] Jumping into the main thing, the gist of it: I will be talking through a lens of three content design breakthroughs. Three major moments that happen during your content design career, during your work life, during your trajectory of development as a design professional. First you start as a UX writer, you land your first UX writing job, which is really exciting, and then you're really happy because you can design microcopy, you can design all these small words in the interface, you can design buttons, you can design error messages, and you can see how this makes people's work easier.

[00:03:22] To come back to this banking metaphor that was used in the intro, you have warning messages in the app. You get hints at the very right moment. You know what to say and when to say it, and you see that it actually helps users. So this is exciting. You gain your first impact as a designer. You're really happy to do that. And the even more exciting thing happens when you finally join the content design team, when you are not the only UX writer, the only words person on your team, but you can do it in a group. So you have these really smart, cool people also working on content and you do it all together. You finally can participate in crits. You can ask for feedback. All of this is great.

[00:04:07] At one point you realize that your team does a wonderful job as well, but other people, other designers, other developers, other people working on digital products, they do it in a different way. And you're faced with things like this. This is an example from my previous company, Docplanner. You're faced with different formats of the very same message. This example I often use to talk about content patterns is an empty state example. An empty state is a piece of content. It's a pattern that appears in places when the user can see some information, some items like documents, health records, requests. Messages are also a typical kind of object that lives in this space.

[00:04:55] They see an empty state. There is nothing here, but there will be some things when you add them, and as you can see, they look very different across the product. The format is different, visually they are very different, and the experience is not the best. It's very inconsistent, it can be problematic at times. You have to decide what kind of actions you want to include at a certain moment. And your job as a UX writer, as a content designer, is to work around that. Sometimes it's also your job when you're a product designer. You have to think about all these recurring patterns and how you want to structure them.

Writing is designing: treat words as a design problem

[00:05:32] This is where you get to a point when you realize that writing is impactful designing. So why not treat it like a design problem? It's not really an original thought. You may have heard about the book Writing Is Designing, which I highly recommend if you haven't. It's a wonderful read. But it's a fact. Writing is designing. So then we sit at the drawing board and we think about how we could design the words, so we don't have to do it all over again every time there's an empty state pattern, an error message pattern, or any kind of pattern that's quite content heavy, that comes with words.

[00:06:04] So we can sit and look at how other people did that already. And this would be my first piece of advice. There are so many great design systems out there and you can use them as a reference. I know it might be more or less exciting to some people, depending on your preference probably, but I personally really enjoy looking at other companies' design systems just to get some inspiration, just to see how other people do this stuff, see how they structure, how they work on similar problems like the one I'm facing right now.

[00:06:41] This is an example of an audit that I did in my previous company. I just looked at the design systems that I could access and that I know are working. I used to look at the Shopify design system a lot. There's plenty of different systems you can access, there's IBM Carbon, Primer from GitHub, there's plenty. And if I can give you one more piece of advice, it's really cool to actually have your own original list of design systems you stumbled upon and really like, so you can come back there whenever you need to and just compare how other companies do it.

[00:07:14] It's true, but I don't think it's a good idea to have one favorite and then just do everything as that company is doing it, because you may also replicate their mistakes, which is great. But having a collection to refer to is incredibly helpful.

Building a content pattern: mandatory, optional, reusable

[00:07:31] So then you do this audit of how other people do that and you come up with the first proposal for yourself. Another thing I want to bring to your attention when you build this proposal of a content pattern, any kind of design pattern: it's good to think about which pieces of the pattern are mandatory and which of those are going to be optional, because it's quite common that these patterns don't always look the same. Some bits will be appearing in every use case. Some of these bits may be optional. So it's good to take that into account at the very start.

[00:08:08] So then you have a few mockups showing how things could look, and then what I do at this stage is to come up with some example content, some example copy. So I have a real life use case and then I try to see how this is going to look with the proposed pattern. First of all you build a prototype, then you try to see how this is going to look in real life. And the one step I would never omit in this process is design crits. You prepare something and then you invite your team and ask them for critical feedback, and this is where the magic happens. This is the stress test bit, when you see if your content is going to work in real life. And this is, I think, the best way to say this is a team effort. We are all team members. We cannot really do it alone.

[00:08:58] So this is a behind the scenes look of how I do it as a content designer, how we can work with words as a design problem. In fact, here's another example. I can show you very briefly how I describe these patterns in the documentation. For headings, empty state headings, we also discovered two use cases. They can describe the current situation. The other bit that was in this description: there were examples, the length was defined, also some notes about the punctuation. And very similar for the second use case. So we have the second use case, when the heading describes what the feature is doing, also some examples and some notes on the punctuation. As you can see, there's a pattern for patterns. The pattern description is also following a pattern. This is what I propose. This is what I leave for you today as a source of inspiration. You can also try and use it in your own patterns.

[00:09:54] To recap this part, to sum up: it's good to mark mandatory and optional components. Also I think it's important to highlight that some components can be reusable. They can be always the same. So for instance, we can agree that we always use the go back button, and this is the format that's copy and paste. We don't think about it, we just reuse the same thing. And patterns are made of different kinds of components. So as you see, you have mandatory and optional, but this is more complex. Some things can be very simple, we can just reuse them. We don't need to reinvent the wheel every time.

[00:10:31] There are some candidates that make great reusable components most often. Basic action buttons like select or duplicate or send: this makes a great component most of the time. Some repetitive interactions like leave without saving, also a great component candidate. And this kind of repetitive question works really well when just being used in the same format. And some disclaimers. What you see a lot in AI tools, in AI products, there's a disclaimer when you have the generative AI chatbot, of course ChatGPT, and this is like "AI can make mistakes, review results for accuracy," something along these lines.

[00:11:12] If you're looking for patterns like this that have to do with AI based products, I highly recommend this website called Shape of AI. Plenty of great inspiration out there. If you want to save it in your tabs, I highly recommend it. I use it a lot. And also I would recommend focusing on good examples instead of the bad ones. I think it's better to help people build good habits, and this is what I would put most focus on. Of course, if you want to prove a point and tell people why they shouldn't do something, it's okay to include bad examples as well, but good is better, good is even better. This is based on my experience with that.

The third breakthrough: AI joins the team

[00:11:55] So there we have these two main breakthroughs as a content designer, and the third one is happening right now. It's happened already for some people. Some people are only entering this space right now. Whether we want it or not, AI is now part of our teams and we need to think how to work around that and how to work with that, which is also what I recommend. So let's have a closer look at how not to do one thing well just once and then rely on other people on how to do that. We can leverage AI to help us scale these patterns, and this is what is happening a lot right now. I can give you a little peek into how I do it as a content designer and how you can do it as well.

[00:12:40] We build patterns that work both for humans, like the patterns I just shared with you, and also for large language models. So empower the teams to make the best use of AI, because you can just use the LLM to ask it, "Oh, rewrite something for me," but the results are not always going to be that great. So let's have a look at how we can make it even better.

[00:13:04] So this style guide, the style guide as we know it, may look like this. This is coming from my wonderful colleagues at Zendesk that created something that circulated around the internet. Even before I joined Zendesk, there was this beautiful matrix for our voice and tone. But this is definitely for humans. If you share this with AI, a large language model won't probably be doing super well with reading this. So we had this very classic design system list of words we use, words we don't use, how we should speak. But this again is how humans see it. You've probably seen things like that as well.

[00:13:42] And this is how the LLM sees it. This is the same kind of content guideline but formatted for the LLM. And what's happening here is that when talking to an LLM, when creating instructions to tell the LLM these are the guidelines and the pattern you should follow, we use formatting that's more LLM friendly. Usually the recommendation you see in a lot of documentation is using Markdown. Instead of having something that looks like this, mostly human focused, or also like this, we just format it more in this direction.

Making guidelines LLM friendly

[00:14:18] One thing you can do to make it look more LLM friendly is to just paste your human facing guidelines and ask the LLM, "Can you rewrite this into Markdown, or a more custom instructions friendly format?" And it's going to do a wonderful job for itself, because the LLM knows what the LLM wants. I think this is another golden nugget, a piece of advice that really changed how I work with AI. And if you want to dig deeper, if you want to actually learn Markdown, which is honestly not that complex and is a nice thing to add to your toolbox just to know what's going on, how to communicate better, I highly recommend this book, The Markdown Guide. It's available out there on the internet. Short and sweet, really great, and also really empowering in the age of AI, I believe.

[00:15:12] So we are answering the same questions, only in a different format, which I think is giving us a lot of hope. We just need to change the language a little bit. Some of the things that I use the most often when it comes to scaling patterns and giving people the resources to work better with AI, to create better AI generated content or just to know what patterns we should follow: the most common type of question, number one kind of question, is what kind of verb are we using? Are we saying turn on or enable? Are we saying sign in or register? So having a handy guide to words, or well structured instructions on which words you're using in the product, this is working super well. I would say this is the number one thing to start working on.

[00:16:01] Second thing is a glossary. A little dictionary of the words you're using. To make sure, are we calling this thing a recommendation, or will we be calling it a suggestion? Having a single place, or again, well structured instructions for an LLM. So second thing I would start with: action words, verbs first, second the glossary, and the third thing, formatting. Are we using nouns, am I using full sentences instead, and punctuation guidelines. This is something that goes into the basic instructions for every product. So a guide to verbs, a glossary, words we use and words we don't use, and formatting. This is where I would start when it comes to creating instructions for a large language model.

Limiting hallucinations

[00:16:46] And you may ask yourselves, this sounds amazing, but we've all seen LLMs hallucinating, we've all seen them making mistakes, just like humans do, to be honest. But it's absolutely a point that when you have an assistant, you want it to be reliable. So there are ways to work around hallucinations, and I'm not saying if you implement this it's going to be completely hallucination free. It's work on the product, it's an iterative process, but there are some tricks I will gladly share with you on how to limit the hallucinations when working with LLMs.

[00:17:25] You can add instructions like "only use information found in instructions and attached files." It's not going to limit the LLM's creativity 100%, they do tend to get creative, but this is a sort of guidance and it's going to make it more focused. So it's one thing that helps a lot. This is one way to put it.

[00:17:44] Another thing that I do a lot is to add this bit of text to the prompt that says "take a deep breath and think step by step." And you may be thinking, am I going to tell the computer to take a deep breath and think step by step? Do you really think it's going to work? And the answer is yeah, it's going to work, probably in your case. There are some research papers which I'm attaching here. It's a fascinating read when you look into this research that's been done, that computers really take it seriously if you follow the human metaphor. They really think slowly and more accurately and they come up with more accurate results if we just tell them to take a deep breath. So as funny as it may seem, give it a try and see how this works in your case, because there are some papers that prove it may actually work.

[00:18:41] Starting with this eccentric bit of advice, I hope I got your attention by now. Another trick I'm using is using capital letters. So just say ALWAYS use numerals, NEVER use spelled out numbers, with "always" and "never" in capital letters. The first time I saw it in prompts I've been working on with developers, I thought, "Oh, this is funny." And I was a bit skeptical, to be honest with you. I dug deeper to see, is it really going to work? Do I have to shout at the computer so it's going to work better, so it's going to listen to me? Apparently uppercase sometimes is all you need. And there's this really funny research paper that's written all in uppercase. I think it's a fun read because it's all caps shouting at you. Apparently uppercase really increases the accuracy at times. So you may want to dig into this step as well.

[00:19:34] What also works in a lot of spaces is adding examples. This one example is an example of one-shot prompting. I've only added one example to the instructions. And when you give the LLM an example of how you want it to write, it often performs better. Of course, there's the whole discussion of how many examples you should include, how much is too much, which is probably a topic for another talk, but again, examples are something to keep in mind.

[00:20:04] There are also some websites, resources I recommend when it comes to learning about these things. One of these websites being Learn Prompting. It's a rabbit hole. Once you get there, I would reserve some time to dig deeper, because this is a gold mine and I use it a lot. So another extra bit of reading I'm leaving here with you. And as I mentioned before, really don't hesitate to ask the LLM to refine the prompts for you. The tools really know what they need. So when you have a prompt, ask the LLM to refine it. Ask it for feedback. Ask it how can I make it better, how can I make it more precise, and then test it and see how you can improve it that way.

Build your own content design product

[00:20:49] So rule number one, already kind of hinted at: when you think about it, it's kind of like you're building your own content design product. It's building your own product. You're building products for a living. You're building digital products. You're building apps, banking apps. You're building e-commerce websites. You're also building products for yourself as a designer, for your team. So why not approach it as a design problem? I think it's a nice way to think about that.

[00:21:17] I also highly recommend to reach out to people in your organization and just work together on these things. This is great when you have more testers on board. You can run demos, you can invite people to co-designing sessions. It's a lot of fun building your own products, so I encourage you to do that.

[00:21:37] And if you're not a content designer, here are some other pieces of advice. If you are not a full-time person working on words in your product, I recommend having a place, like a single work trip[?], to document your content decisions. This is a great start. Other teams don't do that. If you just start doing this one thing, you're light years ahead, I guarantee you. Do embed content in your design system. Make it a part of the design system where all your components and patterns live. Put it there, make it easy to find.

[00:22:07] And the third thing, prepare your own instructions for both humans and LLMs. I highly recommend playing with custom instructions, having a separate custom GPT, a separate agent for content, because LLMs are generally good at stuff, but one size in the end doesn't really fit. The general ChatGPT doesn't really know your vocabulary, your glossary, doesn't know your product. It's going to make things even more messy in the end. So do play with custom instructions and see where it can get you. Because in fact, we're talking about language all the time, and you can't really take the language out of the language model, can you? So I like to think about it that way.

Keeping space for craft and creativity

[00:22:50] We're talking a lot about patterns, so just to close this really brief talk, I would like to talk a little bit about how you can implement patterns and still keep space for creativity and for the craft, which is what we do as designers. I think it needs to be stated openly that AI really sucks at first drafts, and when you ask it to create a first design, it's not really going to be great. But what it really excels at is being a design partner and a critic. And this is the way I like to use it the most.

[00:23:26] So instead of saying generate one example, I often ask it to generate 10, to generate 20, and then as a professional, as a beginner, I can pick three and I can remix it. I like to say that my work became more of a DJ's work recently. So I do the brainstorming bit with AI and then I can build based on that.

[00:23:45] And another thing I really love to do, and this is the ace up my sleeve that I shared with my students, with my course participants, but I will gladly share it with you as well, is the tree of thought technique of prompting, which goes like this. You tell the LLM: imagine three experts are answering this question. All experts will write down one step of their thinking. They share it with the group. Then all will go on to the next step, etc. And there's a really nice bit I really like: if any expert realizes they are wrong at any point, then they leave. So this is a little guard rail that prevents you from having completely wrong outputs. And then you follow up with the question, and then the LLM picks three experts that it thinks are fit for your question, and then you have your private board of critics thinking about your problem, which is fantastic.

[00:24:41] I highly encourage you to try it. Take a screenshot, try it, and connect with me on LinkedIn, whenever seems fit for you. I'm really happy to listen about your experience with this, but I do it a lot when I need to gain a different perspective and a different outlook on the problem I'm facing. I think this is one of the greatest prompts, nicest prompts, most useful prompts I ever stumbled upon. So I'm leaving it as a little gift for you just at the end of this talk.

[00:25:10] And when it comes to the adoption bit, which you might be wondering about, like this is cool, but how do I get people to use the thing that I'm doing? Again, think about it as building your own product, and think about how you would increase the adoption of a product. Just make a list of questions people usually ask, pin the answers, make it easy to find. And still keep thinking about it: it's not enough to do one thing well just once. So do the thing well and help others repeat your success.

[00:25:46] Thank you very much for listening. I hope this has been useful for you. My name is Kalina Tyrkiel, and this is the name I use on all socials, LinkedIn and all other places. I think LinkedIn is probably the best in this context. If you feel like digging deeper into the subject, if you have any questions to ask, questions you may not have the time for today, feel free to find me and connect so we can continue discussing this topic. I hope this has been useful for you, and thank you so much for your attention, for coming and for listening.

Q&A

[00:26:24] Host: Awesome. Thank you so much. That was really interesting. And we do have a little bit of time to answer some questions, because there's one burning question from Nadia as well that already came in, and LinkedIn is a bit behind from the live stream, so that's why it's always good to keep a bit going. But the first question that I got for you was a question regarding the LLM. Ask the LLM to rewrite it into a more LLM friendly format. What is the point if the LLM can rewrite it for itself? Isn't it able to understand human oriented format anyway?

[00:27:01] Kalina: It might be able to, but they are better and better at that, absolutely. What we're doing with this formatting is that we're gaining more clarity, we're gaining more control. So we are kind of limiting the opportunities for the LLM to hallucinate. This is what's happening: the entry barrier is lower and LLMs are better and better at understanding the intent, which is great news, but the more complex the system you're working on, there's still plenty of work to do when it comes to getting these instructions right.

[00:27:39] Kalina: So what I would suggest is to try just pasting your plain human facing instructions and then having a few use cases for writing, let's say microcopy, let's say in the microcopy space, and seeing how it performs with these human input instructions versus the structured ones. But then there are system prompts on the back end of every LLM. I really recommend looking at the Claude system prompt, because they make it public, so you can have a general idea how these things are structured. So the answer is yes, it's going to understand to some extent, but we gain so much more control if you make it more structured like that.

[00:28:22] Host: All right, awesome, very clear. Another question is, you mentioned that you do use LLMs for some elements, and AI for some brainstorming as well, and you use it a lot in your daily job. Are there certain tools that you prefer to work with, and how much do you use AI tools on a daily basis in your job?

[00:28:45] Kalina: So I think the first, most important thing to start with, what I see a lot when I do AI in UX writing courses as well: I see first of all that people at work are limited. They have to use the tools that are approved by the company. So this is the first thing, use the tool that's approved by your company, because the security layer is real. So this is number one.

[00:29:08] Kalina: I would say my setup is pretty simple. So apart from, let's say, Figma AI, all these AI coding and designing tools, for writing just use whatever you're using. It could be OpenAI tools, could be Gemini. So whether it's ChatGPT, Perplexity, any of these LLMs, I would say just try different models if you can, but I usually just use ChatGPT or any other model I'm supposed to work with on a project. But there's plenty. Figma writing tools are getting more and more advanced, so they're adding the custom prompting option as well. I would really explore that. But what's better about AI tools like ChatGPT is that you can add custom instructions. You have much more control over the output. So the answer is ChatGPT most of the time, depending on what your company is using.