 Hello, everyone. Welcome to the workshop on top things we need to learn about UX. My colleague, Bhandila, and I would be co-presenting today how to unfold UX. We will walk through Jacob Nielsen's UX principles and then dive into some examples and exercises to try our hands on to apply these principles for the products we develop. At the end, we'll be happy to answer the questions you may have. But before we get started, here's a brief introduction about us. My name is Shweta and I'm a part of the RelDocs team. As part of my job responsibilities, I'm involved in understanding product features to easily explain complex things, writing end user documents, reviewing and suggesting UI text. I collaborate with cross-functional teams to understand the user requirements, structure the doc contents to address user stories, and improve usability of product documents. Outside of work, I enjoy baking, yogiing, going to nature walks, exploring places, making new friends and getting to know different cultures. With this small introduction, I will now hand it over to my colleague, Bhandila. Okay, hello. I'm Bhandila. Welcome to my living room and who I am. I'm a huge fan of minimalism in technical writing, in UX design and life in general. However, as a mother of three kids and passionate reader, books, legal toys, it's all everywhere and it's hard to keep minimalism around. Professionally, I've been in various roles connected with technical writing for many, many years because I strongly believe that the written word is the king of the world of internet, web and social media. And not only written words, these days it's also about video content. However, being able to express yourself precisely and without wasting people's time, being able to explain complex things easily is crucial. And today, we would like to share our passion for words with Shweta and talk about UX writing and about connection between UX writing and user experience design. Thank you, Bhandila. You will wonder why we are elaborating so much on our responsibilities and interests. If you notice, a single person can play several roles. Think of many users and the roles they would be playing. Now, consider if all of us plan to use a single application or a single product, how challenging it would be to satisfy the needs of all users. As professionals, our experience, interest, ideas and values aren't necessarily the same as that of the users. But we still need to step up and step into the shoes of users, build a product that would satisfy the needs of most of the users. But how do we achieve this? For that, let's first take a look at our goals as professionals. Now, irrespective of the domain and the product that we develop as professionals, our goal is to create and improve customer satisfaction, loyalty and of course reach business goals. Now, over the number of years, we definitely learn that to achieve our goal, we must first understand and meet users' needs. We must develop features that they haven't even asked for and of course build easy to use functionalities to solve the pain points. But do we know how our products can satisfy the needs of most of the users? This is where we need to consider user experience. So what is user experience? User experience is an overall experience that a user can have with the solution, a product, a website and so on. It has the ability to build or erode customer loyalty and consequently the customer base. The importance of user experience depends on the company size and how aware the individuals are. Fred Bitcher, who is a senior manager of design at Best Buy, discovered UX in 1998. He mentioned that we need to humanize technology and heuristics help us to do that. Heuristics are a practical approach to problem solving. They don't dictate and are not perfect, but they give you a base to build your work on. Vendulia will now briefly cover what UX writing is, what the usability heuristics are, and we will also take a look at how these heuristics are applied in some of our products. Yes, Shweta just explained what is user experience and I'd like to continue with UX writing and usability heuristics. First, what is UX writing? UX writing is a form of communication, communication between you and the product on application. UX writing is the practice of crafting texts, which is directly used in user interfaces to guide users and help them interact with their app. But now let's move to these heuristics because I'd like to show you how it is connected with UX writing. Jacob Nielsen is a web usability consultant and a PhD in human-computer interactions. He analyzed 249 systems with usability issues and based on these analyses, he published an article with 10 general principles for usability interactions. These principles are now used as usability evaluation techniques that are applied before, during and after a product release. If these principles are not applied well, you are left in a situation where you can be stressed, frustrated or angry with using your app and we know this all right. This might lead to not using the product, uninstalling it and certainly not recommending it. So, while each of the heuristics play an important role and have impact on customers, today we will focus on these heuristics that are connected with, directly connected with UX writing. Consistency, error prevention, error recovery, and help and documentation. Let's start with consistency and standard. Because users should not make their qualified guests, if two different field descriptions or differently labeled buttons are the same thing. When using terminology, please don't forget to check widely used standards as RFEs, IETF and other standardized organization, because it can happen to you that you will use incorrect abbreviations, acronyms or terms. As an example, I want to show you two versions of one acronym, IPSEC. It happened to me that I started automatically to use what I saw in graphical user interface as a technical writer. I use IPSEC with capitalized S. My technical corrector got back to me and said, okay, there should be minor S, because it is in RFC like that. Developers use capitalized S and I want to use the same what is in graphical user interface. I know it's minor change. It's a small thing, only capitalized S, but it can make a difference and customers may start to think, okay, is it the technology I wanted to use or is it something different? So we changed it throughout all organization, throughout all content and graphical user interface. So be careful and really use and try to fix also these small minor glitches. Names of new features, the same problem. How often your marketing department developed new fancy name after the application was developed or the new feature? So graphical user interface and command line, they use the same old name because first you used it in the graphical user interface and marketing changed the name afterwards. Again, example that happened to me, marketing uses very often next generation firewall or unified treatment management. But if everywhere in application or in graphical user interface, it's just firewall. So people may have doubts if it is one product or two difference, especially if they are not people from IT environment, they don't know that it is the same thing. Page elements, layouts, actions. How often you wanted to try different grid when your JavaScript framework or a different button? But you need to stay consistent, right? And use the same grid for all screens because it is important for consistency. You need to give users feeling that the environment is familiar and easy to use. The same principle is used in UX writing to use the same words again and again. OK and cancel buttons really should stay OK and cancel, no matter which operating system or application we use. And I have one example for you now. In the left screenshot, you can see create network attachment definition and also in the left menu is network attachment definitions. But when you want to add network interface, you see only network definition and level of uncertainty raises. Is it the same thing or not? So it's really, really important to keep the same labels everywhere. Commonly used spaces for graphical elements. It simply means we should group objects into logical units and use blank space wisely. It creates context and navigates users where to start and how to continue in the screen. And again, I have a small example for you. Here you can see quite a nice example how objects are logically split by blank space. All file system things are put together. Everything that belongs NFS is also grouped together. You clearly see what you can do with quasi targets, right? So blank space is important. It's invisible, but important part of communication with your customers. Command. I don't want to avoid this topic. Command line programs need design too. Commands usually use the same pattern. And it happened to me shortly after I joined Red Hat that developers wanted from me writing guidelines for command line help because they used a different command pattern and users needed extra help for it. It means I had to write help how to use help in the command line. So command line communication has rules too. And this was a very poor design and a bad example of wrongly used creativity. Next one is error prevention. You all probably know that programming is about dealing with exceptions and corner cases, right? I know that eliminating possibility that your application freeze service stops to be working or preventing errors if you're daily work. You try to protect users from unexpected situations. However, you can go further and let users know in advance what can happen. You can let them know what to prepare or that they made a mistake that can be fixed before something really bad happens. To be able to do this you need words. You need to clearly, concisely and without jargon explain what is going on on the screen and what are the next steps or how to fix an existing problems. Without blaming users. A user should never feel like the error is their fault. And please avoid language like you did something wrong. People like always these people are your customers and consider who is your target audience. It is a system admin teenager high school teacher. You probably need to adjust your language to people who will use your applications. Therefore, because I know this is not easy to keep all these rules in place. Invite professional writers into this process and to read guidelines for UX writing. By using right words at the right place, you can really decrease or completely avoid to users frustration. And this is a very good example how to let users know what to do to avoid entering a week password. The dialogue box prevents from adding a week password that would be rejected by server and what is more, it prevents users from creating situation that could lead to a security breach. Anyway, look at the picture again and watch the color. It's green. It tells you everything goes well. You would see the red color when your password has only four characters, right. And, but not only text. That's the important message. You also need to use color font grouping and using blank space. And that all should lead users to correct actions. Now let's move from error prevention to what happens if an error appears. Users start to be nervous level of frustration raises. Therefore, the process of diagnosing and recovering from errors must be as simple as possible. When emotion arrays, we tend to stop thinking clearly, right. So all actions must be as clear as possible. Therefore, technical writers can help with minimal and precise texts. What it means to write a minimalistic and precise text. I will discuss later. I will show you differentiate color fonts structure. And give your users one simple path to recovery. And now I would like to show you one great example of recognizing, diagnosing and recovering from error. This is a short screen cast from the cockpit web console in Fedora, which is a user interface for managing system settings like storage networking system updates or virtual machines for example. I absolutely love how the system navigates me to fix a service that didn't start working after the system restart. So let's do it now. You can see in the overview tab which opens just after start that one service has failed. And you can see it also in the left menu. And if you click to the failed service, you will see what happened that the service just failed to start after reboot. And you can see that you can automatically starts it. So you simply click start service. And everything is green up and running again. Okay, next screen. It's not so easy. Good. I'm there. So now, what if we do everything we can to make application easy to use for users, but it's not enough. I still deal with the with one sentence. Nobody reads documentation. Right. Or does it is documentation something that gives you additional value. And if so, where is the right place for documentation and how it should look like. So first, documentation must be easily accessible. Days of long PDFs and printing books are definitely over. Documentation must be online and findable by search engines. And ideally, documentation should be accessible directly from your application in form of tool tips or some short explanations and learn more links that takes you directly to the documentation. Important note is what can be explained in graphical user interface, explain in graphical user interface. Don't rely on documentation. Graphical user interface should be designed in a way that simple concepts are understandable at the first site. However, especially if the topics topic is complex, and almost everything is complex in the Linux server world right networking storage clusters containers development tools. This all can be pretty complex. So it's important to write and offer high quality documentation that is accessible to everyone and visible at the right places in your product. And I have again example from the fedora web console. So we added help button to the upper right corner that takes you to the overall documentation, but also in some specific cases we added question mark button. And you can open it, read small overview and click learn more link that takes you to the topic based and oriented documentation. So it's connected it opens directly article specifically written for bond settings. Okay, perfect. And before I give a word back to Shweta, I'd like to define more or explain more what I meant by simple concise and minimalistic text. Shweta prepared great exercises for you. Therefore, I need to give you some basics of using special form of English. We as technical writers and UX writers use the most important part is sentence structure. It must be as simple as possible. Each word in the sentence increases complexity and decreases good user experience. I have some examples for you data feeds dogs subject verb object or from technical writing. The cockpit web console manages system settings. Another rule computers doesn't know past and future. So please use present tense as much as you can use imperative imperative starts with verb. Examples. Enter the host name of the identity management system, or click the edit button, or avoid passwords that are easy to guess on, or used on other websites. Ambiguity. That's the problem. If you can avoid adjectives and adverbs, because adjectives and adverbs bring ambiguity into texts. If I use word small, how small it is. I don't know precisely or enough free space on the hard drive. What is enough? How much is enough? So use data, facts, and don't use adjectives and adverbs. If you see complex sentence structure, if you use complex sentence structure user experience will not be good for non native speakers. And if you translate your products, you will increase possibility of incorrect translations. So keep, if you see a lot of sentence throughout three lines of text, it definitely should you should break it into into smaller sentences, shorter sentences. Repeat the same words and phrases. This is not a school essay where you must use 10 different verbs with the same meaning. On contrary, you need to use the same verb again and again throughout the entire application. And okay, this was the last rule. I hope I shared with you something new. And let's ask Shweta now for some real life examples and exercises. Thank you and you love introducing the usability heuristics and for showing us some live examples that relate to the usability heuristics. It is also going to know how teams can work with the technical writers to build a positive user experience. Here are a few additional examples of some work on UI text and error messages that show how writers have helped to improve the usability and have contributed to positive user experience. Next slide. This is a screen from rel web console commonly known as cockpit, which is the management UI from rel systems. Now the user function on this screen is to add a new host to the web console so that the users can start managing it. What happens is a user logs into the web console and proceeds to add a host. Now when we were reviewing the original screen, we noticed that one there is no helper text. So user may be unsure of which user name is expected here. Should he enter an admin user name or just the login user name. Second, for the host to be added, the input was valid in multiple formats like IP address, host name, alias name, or a unique resource identifier for the SSS destination. But none of this was clear without the helper text. A writer could step into the shoes of a user and identify these gaps and at the same time suggest proper text. Let's take another example. Next slide. This is another example from rel web console. This time an error message. I'm sure most of us would feel what's wrong with the original message and this feeling is perfectly fine. We might feel that because we assume that users already know that certain things that we are aware of, but that may not be the case. Like in this case, the original message said not connected to the host and the assumption here was the user would know that the login has failed. Now there's a difference between not connected and login failed. For not being connected, the reason could be like the machine is not powered on or the network is down. But the case here was the web console wasn't able to log into a particular host. And the reason was when the host was added to the web console, the user had not specified the SSH key for auto login, or maybe the key was unauthorized, or maybe it was password protected. Also, as the very next step to get out of this situation is to manually log in. But instead, the original message said you may want to set up your SSH keys, which leaves the user clueless. The user would not know how can that be done? Is it required to exit the console, set up an SSH key and then get back? Or will this screen redirect him or her to create an SSH key? Now a writer could spot these gaps and could suggest a better message. And that's because the writer was the first user. With the writing skills, the writer was able to suggest a better error message. I hope these examples gave you some insight on how a UI can be improved for better user experience when one steps into user shoes and how writers can partner with you for improved UI text. Now that we have a brief background about what your sticks are, how they influence the usability of a product and how writers can help to improve user experience. Let's try our hands on some quick exercises to have some fun field learning. We will have five minutes for each exercise and at the end of five minutes, a buzzer will blow. We can share our answers in the chat. So let's get started. This is a tooltip that you see when you click the question mark next to the LUN type. This tooltip is so large that you cannot see the original dialog box. The content of the tooltip is also not helpful. The tooltip is supposed to help the user pick a LUN type for computer storage. You need to rewrite the tooltip to make it shorter and useful. Your time starts now. You can drop your answers in the chat and we will monitor your answers. Two questions in the Q&A section. Ah, there is. Yeah. Okay. Oh, it's about lightning talks. Yeah, I don't think it's related to this workshop. Yeah, yeah. And I don't know how lightning talks work. Unfortunately. I think it seems to have answered that question there. You have two talks here, event and session. If you go to session talks. Ah, session talks. People on Q&A. Yeah. We have here some. Okay. Hi Erka. Are there perhaps some automated ways to detect UX flaws in an interface or a document going through hundreds of pages of docs or parsing an interface piece by piece seems rather ineffective. Wow, that is great questions. Automative ways to detect UX flaws. I don't know about anything. I remember we wanted to take screenshot new screenshots from graphic user interface automatically and automatically update screenshots in documentation. But that was the last, that was the only thing I've ever heard something automated. We at Redhead have UX researchers and they takes manually our graphical user interfaces and documentation to our customers and evaluate, but something automatic. No, I don't know about anything. Shweta, would you know. Not really. I need to take a look at it give some thought. And we have 30 seconds. So, Vladimir, I read your question. Example with the service. I read it as controls should be linked from places that mentioned or need them and information and controls for making a decision should be visible together. Is that right? Yes, it is right. And also in the screen, you can see, oh, oh, okay. You, I can see what happened and I can see the next steps I can, the next step I can take. So I don't see, okay, what to do and now I need you to go to the documentation and find how to fix it. But there's always hint how to continue. And that's what I like. I immediately knew what to do, and didn't feel frustrated. So, by the way, it happens to me with the same, with the same service after each restart of my computer. So, I should find some permanent solution, I guess. So, if anyone has the answers ready. Can you put them in the chat. That would be nice to see some possible answers. Okay, no one. No one. Okay, are we are we going to tell them. Okay, let's go considering the time I think we need to. We have five minutes. Okay, so here's one possible way to rewrite this tooltip. In this version, all the explanations begin with a verb and up parallel with each other. We have simplified the wording and have left out some of the details. Also, because the tooltip is much shorter, you can see a lot more of the dialogue box behind it. Now, let's quickly jump into exercise two. And here's a dialogue box again from rel web console. Now, what you need to do is you need to think if this text on the screen is intuitive. Can you, can you spot any changes required and suggest some improvement. Your time starts again now. I think we'll have to cut down on the time when you look for this exercise because we just had five minutes. Let's let's show the results. If you don't mind guys we can play this exercise later on but considering the time I think we can jump to the answer right now. So as you see the proposed changes again use action words which make it fairly simple for the user to understand what action needs to be performed. Also in the proposed text the label for the checkbox is removed because there is just one checkbox we don't need a label to it. Additionally, a label automatic login would have checkboxes like yes or no indicating whether or not does the user want to set automatic login. In this case the purpose is to generate and authorize an SSH key for auto login. The text in the gray box appears only if a user selects the checkbox. The proposed text is better phrased to simplify how would the web console function. With this exercise we come to the end of this workshop today. Thank you all for participating in the workshop. We hope you have enjoyed it. We look forward to working with you to improve the user experience for the products we develop. Just to summarize and to note a couple of takeaways from this workshop always apply usability heuristics to improve user experience. Partner with your writing buddies for UI text error messages tool tips and so on and always use pattern fly guidelines to craft the UI text. We would be also happy to have you tomorrow at our talk on giving user interfaces a voice. There we will be talking about our collaboration with the UXD team and share some examples from our projects where this collaboration led to the positive user experience.