How to make LQA Design official

In last week's post, I explained what LQA Design was and shared with you some of the reasons why I believe that LQA should happen in the Design phase, not after the release.

In this second part, I will give you some ideas on implementing the LQA phase.

Moving from post-release to pre-release

Consistency and quality are central to a good user experience; for this reason, it is fundamental to consider LQA from the start by explicitly including design review and design QA in the product development process.

View fullsize

Source:Luminary.com

The first thing to explain when making an LQA Design official is that we move it from after-release to pre-release. More importantly, we move it from being considered a one-time activity to approaching it as a conversation.

This is a major shift in mindset and way of work so you should clearly explain to your stakeholders the impact of doing LQA in the Design phase.

LQA Design is a conversation

Good LQA design is a conversation between Localization professionals, Developers, and Designers. Just as it is a good idea for designers to show their ideas to developers so that they have a chance to get a feel for what they will have to code, it is also a good idea for designers/developers to show the Localization team their ideas, long before it's ready to ship.

By doing that, if there are inconsistencies between what the designers/developers want to implement (and ship) vs. what constitutes a good user experience in the different markets, these inconsistencies can be solved in the design phase in a much more agile way.

3 tips to LQA Design success

When it comes to making LQA Design official, there are several suggestions I would like to give you.

1.- Include a shared definition of what quality means as an acceptance criteria

Everyone needs to have the same quality expectations; if that does not happen, it will be complicated to implement LQA in the design phase. For example. Quality expectations might be "localized fonts are rendered properly".

To move LQA to the design phase, teams must agree on quality acceptance criteria before anything gets built.

2.- Have a Design LQA Checklist

A checklist that collects all the aspects that have to be ready from a Localizibility readiness perspective is fundamental also when making LQA design official

Examples of what to include in such a checklist might be

• Are all the language strings externalized?

• Is currency treated in a way that will translate?

• Are there any images or illustrations with text within them?

• Are any strings broken up by UI elements that will present difficulty when translated?

• Are there any concatenated strings?

• Is the language used inclusive?

• Are there any pictures/content that might be offensive for a particular market?

3.- Look for design and development tools that can be connected to Translation Management systems.

Nowadays, the world of connectors has dramatically facilitated the possibilities of bringing LQA to the design phase as it is possible to connect different tools together.

Several tools allow you to do this. The one I follow most closely is Lokalise.

The graphic below summarizes perfectly how the LQA phase fits into the design phase and how Lokalise connects to different tools through an API.

View fullsize

Source: Lokalise

In Conclusion

Many of the mistakes found in the traditional LQA phase are based on the fact that developers, designers, and localization teams work in silos. Still, that mentality in today's agile world where the most important thing is to deliver multilingual content at a fast pace is no longer valid. The key is to break down those silos and establish a conversation.

Most of the challenges in product design and development can be solved with mutual respect, open communication, and clear expectations.

I hope these posts have been helpful and have given you some ideas on organizing LQA in the design phase.

Enjoy your LQA-Designing!

@yolocalizo