How UX writers can approach legacy products
It’s not uncommon for UX writers to be tasked to improve products that have been built before UX principles were even a thing. Commonly found in sectors such as banking and healthcare, these legacy products often have clunky UIs but serve a large user base.
Modernising an old product poses a very different challenge for UX professionals, as any change — even the smallest fixes — can be met with a lot of resistance from the organisation. I’ve faced this situation before, and I wished someone told me these things before I dove recklessly right into such projects:
Spend more time understanding the product and its users before thinking of solutions right away.
Never stop being curious, even after you think you’re familiar with the space.
You’re a problem-solver first and a writer second.
That would be the appropriate mindset to start with. Only then would UX writers be better equipped to untangle these common challenges associated with established products:
Multiple sources of truth
Knowledge gaps
Inconsistent terminology
Technical constraints
Users’ familiarity with the product
So where should we start? Here’s mix of strategies which I learnt from doing and additional reading…
Start by mapping out the high-level user journey
When onboarding to a new assignment — be it a large project or a small copy update — never start writing until you understand the path a user took to get to that point, and where they should go next.
As you start gathering materials and asking questions about the user flow, focus on their cognitive journey and the product’s information architecture would start to emerge.
Don’t get too distracted by UX design elements such as the interaction, visual hierarchy or colours in the early stages of getting to know the product. You can make notes on any design improvements that you might want to bring up to a UX designer, but as a writer, it’s more crucial to understand the narrative structure of the end-to-end experience.
Understand the users’ pain points and expectations
If you’re lucky, you’d have access to research materials that explains where and why users struggle to use the product. By studying past hypotheses and key learnings, you can make justified improvements for the users.
Also, by understanding what the users’ expectations of how the product should work, you can avoid making changes that create confusion. What might seem like an awkward design to you could actually be a pattern that’s deeply embedded in the users' mental model. Remember that you, with your ideas of UX principles and best practices, are not the user.
If no formal user research has been done on the product, reach out to your colleagues in customer service or sales — I’m sure they’d be able to tell you at the drop of a hat what users like about their interactions with the product, and what their biggest complaints are.
At this stage, you should already be making notes on what needs to be improved. For example, did you notice that…
users are using words and phrases to describe the tasks related to the product, but these words can’t be found in the customer touch points?
some terms are used inconsistently in different areas of the customer journey?
the voice and tone of some user flows diverge from the company’s copy guideline?
Gather as much context as possible around how the product was built
Now that you’ve gotten to know the users better, it’s time to pull pack the curtain and understand how the product is built and the people who manage it.
It’s common that asking simple questions like “why was it designed this way?” will open up unexpected cans of worms and endless reasons why something can’t be changed. To pursue answers, you’ll be referred from someone in your team to another colleague in another team, who might send you a bunch of old documents, put together by people who’ve left the company.
It can be frustrating and demoralising, but I urge you to embrace the mess and be patient. Your colleagues probably went through the same process when they first onboarded to the product, so cut yourself some slack and take your time to understand complex issues.
The way I go about doing this is to first have a list of questions or notes based on what I’ve understood about the users. Then I’d approach product managers, developers, and product marketers to fill in any knowledge gaps and also ask them about their main challenges with this product.
While we’re not expected to understand code, UX writers need to have some understanding of how copy is implemented in the system. As part of our first introduction chat, I’d ask frontend and backend developers how the most recent launches went, and what they think could’ve been done better. I would also want to know what the biggest technical constraints are, and if any major migrations are planned as that would affect how we think about future UX improvements.
Older products are a mashup of many smart folks making decisions which were right at that point in time, so it’s important to respect that. When learning about a seemingly outdated product, really get to know its inner workings before making sweeping judgements or proposing simplistic solutions.
If you’re feeling overwhelmed by the amount of information, grab a coffee with experienced UXers and ask them “what improvements do you think would make the biggest impact?”, or “what do you think is the biggest user pain point?”. Having these facts narrated back to you usually makes it more memorable.
How to start making copy changes
After you’ve gained deeper insights into the product, its users, and your teammates, it’s finally time to start solving problems with language.
Start with low-effort but measurable fixes
Take note of baseline metrics, such as time taken to complete a task, and monitor if there’s an improvement after changes to the copy were rolled out. Be it through A/B tests or other experiments, numbers are vital for it to be a proof of concept to push for larger changes. Small improvements doesn’t mean low impact either — see how microcopy can help a company make more money!Build a term library
Map the old terminologies to new ones, describe the rationale for these changes, add any research or data that supported the use of the new term, and whether this update had an impact on the product’s key metrics. Clear documentation lays a good foundation for the product and creates consistency going forward.Roll out changes gradually
Once the team feels confident with the results of the smaller fixes, start planning more incremental copy changes. (See some strategies for this in How To Improve UX In Legacy Systems). Writers should also think about a content strategy that eases existing users to the new experience. How might you gradually shift from using jargons to a more conversational language? How might you educate users on the updated terms without disrupting their experience too drastically?Get buy-in to clear UX debt regularly
When things need to be delivered quickly, it’s easy to brush issues aside by saying “let’s add it to the backlog” and forget about it. But Nielsen Norman Group highlighted some practical ways to track and prioritise issues in UX Debt: How to Identify, Prioritize, and Resolve. I like the idea of adding UX issues to the product jira board and getting the team to commit a set number of story points each sprint to fix UX debt.
Hope these notes help you to untangle the thorny issues found in complex legacy products!
