OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we shared a month of content on how our UX/UI Team tackled this project while building and implementing their very own Product Design System to create a delightful experience for all users.

As part of this series, we interviewed our UX/UI Team Lead, Andreia Mesquita, about how OutSystems built its UX culture, Runtime Experience Team Lead Miguel Nicolau explained why accessibility is even more important now in these Covid times, and Front-End Developer turned UX Engineer, José Rosário, talked about his career move and work as part of the OutSystems Design System Team.

Here, Team Lead Marina Calado walks you through the process of establishing a UX writing practice.

“What’s in a name? That which we call a rose
By any other name would smell as sweet.”

So Shakespeare said, right? Well, I’ll tell you what’s in a name: user experience. You see, when we hear or read the word “rose,” most of us can actually see a rose in our mind’s eye. Maybe we can even smell it. The word provides us with an experience based on our memory and perception of roses.

Companies do this thing where teams move around, responsibilities change, and if you’re lucky to work in a great company, people grow, and their skills evolve. It was the summer of 2019 when, in one of those moments of change, the Product Content Team at OutSystems realized there’s something called “UX Writing,” which we had to figure out as it is actually pretty important for the experience of users. We needed to understand what exactly UX writing was and how we would go about it.

Making Space for a UX Practice

In reality, our small team of three content writers had been doing UX writing, but we just called it “helping teams out.” Whenever someone asked us to review a message or think of a description, we’d give them a hand.

Essentially, we were using our language and writing knowledge, but something else was happening: we were asking a lot of questions. At the time, we didn’t know that was part of the UX writer toolbox. But we would soon find out.

We asked one of our writers, Rachel Kellond, to figure out this practice during one very focused month. She read many blog posts and books, listened to podcasts, googled endlessly, and delivered the first version of the OutSystems UX Writing Guidelines.

First, we had to understand and explain UX writing. We didn’t want to come up with abstract or complex definitions — so we simply put it as “this is how you talk with the users inside the product.” Simple, yet effective.

Our attempt at explaining UX writing in simple terms

We also had to explain what a UX writer does and their responsibilities. It’s not just about knowing how to write. It’s about knowing how to write in a given context, with a specific goal and a specific audience in mind. Writing for users is mostly about communication and getting a message across — a message that should be as clear and simple to understand as possible. As a UX writer, you also need to be at least one step ahead to think (and write) for the users’ decisions. Sometimes, we also need to write to guide users on what they should do.

As it turns out, the user was very much at the core of this practice. The writing was simply the means to reach them. So, we created our guidelines with this in mind: how does one talk to users and connect with them through a product? Our guidelines reflect our approach in terms of experience, language, and what the OutSystems identity is.

Lessons learned:

  • Give it time. You can’t just wake up one day and decide to establish a new practice in your company. I mean, you can, but it takes work, patience, and dedication. Be prepared not to see results immediately.
  • Carve out space. To create a practice right, you need to work towards it. If it’s important enough to exist, it’s important enough to have focused people and dedicated time.
  • Build the foundations first. We could have just continued to review messages and call it a day. But that’s not how it works. By creating time and space for the team to research, talk it out, and discuss, we could start on a better footing and feel more confident in our conversations with fellow UXers and teams.

Being Part of the UX Design Process

Before we go any further, there’s something I need to make clear: I never really had to pitch this practice to our UX leadership team. I can say I had buy-in since day zero. The fact that we had a manager who had our back, and wanted us to work and evolve on this practice, helped a ton!

But one thing is having management buy-in. Getting people to play along and remember to invite you to design meetings is quite another — I know UX writers all over the world feel this pain.

We presented our practice, we created writing principles to support the design process and experience, we asked everyone to involve us in discussions and share their work. And it kind of worked!

Our UX writing principles

Creating material and guidelines is not enough. People knew we existed, understood our scope and responsibilities, but sometimes didn’t really know what to do with us or when and how to bring us into conversations. We were still feeling left out. We were still asking, “Can you invite me to that?” a few times a day. If you’ve set up a UX writing practice, or if you’re the only UX writer in your organization, you know how it can be.

Luckily, at OutSystems, we have a Product Design System with the purpose of encompassing all the pieces that make up an OutSystems experience. We were included as one of those pieces, and suddenly it wasn’t just us talking about UX writing. After presenting this idea to the Product and Engineering leadership teams, the conversation began to change. We didn’t have to keep our eyes and ears super open because people started coming to us, asking us to participate and contribute. It was a good start.

However, presenting this material and telling people what we can do is not quite the same as showing them, or better yet, having them do it. So we created our own UX writing workshop, where we dive into our UX writing principles, talked about some best practices, and included exercises so that everyone could get their hands dirty.

In June 2020, we held our first UX writing workshop. (Our team was called “Product Experience,” hence the “PX”.

This workshop really changed how our UX peers saw what we do, how we do it, and how much goes into it. It was a real game-changer — and we’re still running it regularly.

Still, it wasn’t the end. There was something we hadn’t truly explored: the UX part of UX writing. As I mentioned, at the time of defining this practice, we were a small team of content writers. UX and design weren’t something we had learned or done before. Sure, we had caught a few things here and there, but we weren’t exactly experts.

That meant we couldn’t always have good enough arguments to challenge an experience or even justify our decisions other than, “It’s just written better, and it’s easier to understand” — which, by the way, are very valid reasons.

That said, the daily interaction with UXers did push us and forced us to learn more and more. We’re still not exactly UX experts today, but we’re learning. We’re training for it, and we’re hiring people with complementary skills to be stronger as a team.

Lessons learned:

  • Challenge the status quo and be patient. People who have been working a certain way will struggle a little with a new practice. It takes perseverance to make it happen. In our case, the OutSystems culture immensely helped because challenging the status quo is deeply ingrained in our DNA.
  • Believe in your skills and the value you bring. You’ll find yourself asking, “Has the team looked at that?” a lot. You have to be patient and deal with the minor frustrations of missing the train by getting to the station a few seconds too late. Stick with it, continue to ask your questions, continue to believe you are, in fact, bringing something different to the table. Believe your skill set is worth a dedicated space.
  • Teach what you know, and learn what you don’t. Embrace the learning curve. Just because you learned it, and are doing it, doesn’t mean you’re an expert. Don’t be afraid to be challenged and invest in your training.

Grow, Adapt and Evolve — As a Practice and Team

We started in 2020, still a small team of three. By the summer of 2020, we were five, and by the end of 2020, we were six. One of our UX writers even traveled across continents during the pandemic to join us.

Our last in-office team reunion, shortly before we hired our last 2020 team member

When we welcomed two team members in the summer of 2020, we realized there was still a lot of work to do. Five people don’t work the same way as three. We once again paused and did a massive “deconstruction of the team.”

This meant:

  • Reviewing our processes as a team and inside the UX group.
  • Reviewing our team ceremonies and our attendance of product teams’ meetings.
  • Understanding the direction we wanted to take the UX writing practice.
  • Refining the UX writer’s role.
Plan of the “Deconstruction” series

Out of these sessions, we made two critical decisions:

  1. We needed a stronger voice in the UX process.
  2. We were dealing with “content writing” leftover scope from the time we were all content writers.

We ended up addressing these issues in 2021.

Lessons learned:

  • Review and negotiate your scope. You can’t keep what you had always done, and add something new. Say “yes” to what drives your mission, say “no” to what doesn’t. More people in the team shouldn’t necessarily mean more work. Sometimes, better work is the way to go.
  • Rethink ways of working and organizing. We are fortunate to have a team of resilient people who are open to change and propose change themselves. They want to do better, deliver a better product, and work in a better way. This played a key role in our establishment, but also as we evolve and grow.

The End of the Road is the Beginning

2021 has been a transformative year for us as a practice. I could have ended the “establishing” of this practice in 2019, but that wouldn’t be right, and it wouldn’t do justice to the amazing work this team has been doing. And yes, I am highly biased.

This year, we have strengthened our practice by forming stronger partnerships with some product teams and working even closer with the product designers embedded in product teams. This really strengthened our position in the design process, which was something the team had brought up before.

We are now more and more involved in the process, and we are an active part of the conversation. We are no longer doing “content writing” stuff. We’re feeding our UX mission. More recently, we’ve picked up a core topic: terminology and taxonomy. In our highly technical and specific space, the words and concepts we choose to represent objects and define actions are so fundamental that we decided to launch this new capability with dedicated people and focused attention. And we just got started.

I guess that’s my bit of not-so-good news for you: you never really stop establishing a practice. You’re always making sure it’s well-fed, heard, and respected.

The complete 2021 team — for now. Our next colleague arrives in four weeks!

It’s been nearly two years since we began wrapping our heads around this UX writing thing, so now I can say we do have an established practice. And I can also add that it’s just the beginning. Stick around as we share more about UX at OutSystems. There’s so much to tell and so much more to come!

OutSystems Engineering has a lot of interesting things to say! Be part of our conversation on Twitter or Facebook, or check out our job opportunities here.

Want OutSystems Engineering blogs delivered to your inbox? Click the Subscribe box below.