Integrating UX writing with the Agile Methodology
What it’s like to be a writer in tech
Including content in sprints
Having ownership of product content goes far beyond writing copies, managing translations, and uploading them to a CMS. It means providing the team with a content process -a whole strategy- that fits within the fast decision cycles of the sprints. Is it possible to do so? How to avoid clashing priorities? Can we skip obstacles and drive progress? Here’s what works for me: get involved in the overall process, build consensus, and make decisions.
Even though writing may actually be the most important part of our tasks, it only takes up a small percentage of our time. Besides the word choice, we take care of content handoff in a method that was first conceived for software development, and that’s not always easy. After more than 5 years of working in cross-functional teams, I find the following very helpful.
1. Control the content process from beginning to end
As a UX writer, you can be asked about any copy, in any language, in any placement of the user journey, at any time. Either in production or in progress, or maybe for an a/b test. And you have to be ready to answer. This is only possible if you control the process. That will also mean you’ll have to take responsibility for every last detail but, wasn’t this what we wanted? Now that said, how exactly can we manage to do that?
Murder lorem ipsum
The first step of the content process should be, of course, developing the source content. When it comes to product writing, the content-first approach brings (besides all the benefits we already know) the opportunity to control the content from scratch. It will always be easier to follow -up on something that came from you and your team in the first place.
This stage should ideally take place before the sprint is planned, so when the time comes for the team to evaluate and estimate efforts, they can do so having the final design and content and, in if any changes are needed, they can adapt better.
2. Provide the identifiers and be a part of the naming convention
Once the source content is decided, the second step is the handoff. Each small part of the content has its identifiers or, in other words, the way this content is going to be called from the code. If we want to be a real part of the process, we cannot confine ourselves to words. And at the end of the day, isn’t code a language?
While waiting for the translations to be ready, providing the team with the names of identifiers (also called keys or strings) -it will help them save time in development. This should be ready by the time they start coding and ideally left in the user story along with the rest of the requirements: technical documentation, source content, design and assets, workflow diagrams, etc. While this is something useful for the team in general, it also allows us writers to keep track of our content once it becomes code.
I find this naming convention part especially helpful. Since each platform usually follows its own rules, most of the times the same content has a different string for each of the platforms. However, when UX writers provide the strings, there is one single source of truth for all platforms, which reduces the effort needed to find content in the product, enable easier code reviews, helps to fix issues, avoids naming collisions, etc.
3. Move fast and test things
Whether you are using an in-house team of translators or you work with a translations software, upload the languages as soon as you get them. This stage also needs to take place during the development part of the sprint so the testing can be properly done. The QA team can even look for misplaced languages, spelling mistakes -if they speak the language, of course- or untranslated strings. Why lose the opportunity to test the content along with the functionality? We can even test the content ourselves, depending on the resources of the team. This way, by the time the release candidates are made we can be sure there won’t be any last-minute changes that will delay the process.
After that, the only thing left in the process is to start all over again (aka iterate). And each time it should get easier to find what to change and how, since we have being part of the process.
Consider problems from multiple angles
I warned about it at the beginning of this article: all these things go far beyond writing. Writing in tech means working in cross-functional teams. As UX writers and Content Strategists, we have to be aware of the needs that everyone has and work with them. Designers cannot start from a blank space and fill the prototypes with lorem ipsum. Developers need to have everything clear and decided by the time they start coding. QA teams need to have enough time to test the release candidate, especially for apps that have to be sent to the stores.
On the other hand, it is also necessary to promote an understanding of our discipline among the different profiles of the team. Having the ability to mentor others in the work we deliver can be as important as doing our work. Issues will arise but with empathy and communication, all of them can be easily solved.
Putting yourself in other people’s shoes requires being able to set aside the time and space to learn from other disciplines -and be willing to do so! The benefit that awaits is priceless, though. You’ll earn the respect of your teammates and you’ll grow as a professional along the way.
