It's time to make LQA design official
We do what we do in many cases without thinking about it, which has always struck me. There are many things in my day-to-day life that I do on autopilot.
Peach jam toast and coffee in my favorite mug while watching a YouTube video. I am using the same locker at the gym, so I don't have to learn a new number every time. I am playing a game of Fifa on the console against my son every Saturday after lunch.
All these types of actions (and many more) have become my habits.
I like books that talk about habits. Without any doubt, my favorite is Atomic Habits by James Clear. I love this writer. The way he writes lives up to his last name! You can't explain topics as complex as the workings of the human mind in such a brilliant and straightforward way as he does. The essence of habits can be summarized by saying that our life today is essentially the sum of our habits.
How in shape or out of shape are we? A result of our habits.
How happy are we? A result of our habits
How successful or unsuccessful are we? A result of our habits
How many Localization bugs does our software have? A result of our habits ☺️
If you think about it, how well or how poorly a digital product works is related to the habits of how the software is created. A “habit” in software development is usually called best practice.
But deep down, whether we call it a habit or best practice, the underlying idea is that if we do things right from the beginning, the end results will be good.
When we do LQA in our industry, I have always thought it is like using pills to treat a health issue.
Now that the weather in spain is splendid I can't resist to make BBQ!
If I have cholesterol, I have two options. One is to take medicines to help me get it under control (reactive approach), the other is to barbecue less sausage and eat more salads (proactive approach).
With LQA, or with a pill, we attack the symptom of the problem; but we do not attack the root of the problem. That is why I have always found the LQA phase a bit unnatural, since developers, designers, sound engineers, illustrators ... do their work, a build is created and then passed to the Localization QA team for evaluation.
The problem with this approach is that it is reactive.
If the LQA team has not had the opportunity to be involved in the design phase, all the bugs will show up at the worst time. Near the delivery date. When all the localization stakeholders are anxious to hit the publish button and close the project, we have testers reporting bugs.
This situation is often stressful as it requires reprogramming certain parts of the code, new builds, more retesting, etc.
It is a highly inefficient process that puts a lot of stress on both the development team that sees that they cannot close the project, as well as the quality assurance team that may perceive some hostility as it is the last hurdle that the product team must jump to release the product globally.
Source:Bugsee
LQA, at the end does not seem to be a good habit, so ... what would be the right habit in this case?
Bring LQA to the design phase.
The extra pounds we have can be eliminated in 2 ways: dieting when the situation is getting out of hand or having healthier eating habits. Either I fix it at the end, or I fix it at the beginning. The same with LQA, either I fix it at the end (traditional LQA phase) or fix it initially (create the habit of doing LQA in the design phase).
I will explain what LQA in the design phase is and the three main benefits we will get in the following paragraphs.
What is LQA in the design phase?
LQA in the design phase is a step in the process between deployment and design. It's a chance for the localization team to:
Review mockup screens to provide feedback about the UI (this will help to avoid potential truncations as the text will grow or shrink depending on the language)
Review support implementation for right-to-left languages
Review the use of proper glossary terms
Review the use of variables, concatenated strings, or hardcoded content that might introduce later issues in the traditional LQA phase
Review the copy to assess Localizability readiness
Why
If LQA design goes in parallel with the development phase, the product team will be aware of engineering issues early on in the process. Here are the 3 main advantages you can expect if you make LQA part of the design process.
Higher Alignment between the Product team and the Localization team.
Collaboration and communication are key aspects of developing a product. If everyone is working together, we are breaking down silos and increasing the opportunities to find solutions to problems that arise during the design phase. It will also make life easier for the Localization team to gather context, prepare style guides and make it easier for the translators to translate.
Saves time (and money!)
Fixing a bug in the design phase is much more efficient than doing it when a build is created. Also, by doing LQA at the end, we can have a domino effect in which fixing one issue might cause other bugs. By bringing LQA activities to the design phase, we might uncover potentially more significant unseen problems.
Better user experience
Localization is one component that helps create a good user experience in the different markets in which a product is launched. Moving LQA to the design phase allows the Localization team to give feedback on how the design (font, colors, images ...) is perceived by local users globally.
In summary …
Bringing LQA into the design phase is all about open and honest communication. Great products and incredible experiences are built when everyone on the team feels they can contribute and give feedback. And that is achieved by working side by side without any activity being considered an afterthought.
If you want to know more about LQA the following posts might be useful
Some reflections about the bad reputation of the LQA Industry and 3 best practices!
In order not to make this post too long, I will divide it into 2.
Next week I will give some suggestions on how to implement LQA in the design phase.
In the meantime, I wish you a happy week!
@yolocalizo
Localization is all about adapting content from one culture to another, from one market to the next. The tricky part is the thin line separating appropriation and appreciation. The challenge is to adapt content respectfully and give proper credit. It's easy to blur the line between appreciation and appropriation. My post this week reflects on that.