With Pablo Lloreda, Localization and Accessibility Manager at Roku

---

Below is an automated transcript of this episode

Stephanie Harris-Yee: 0:00

Hello, I’m Stephanie Harris Yee and I’ll be your host today for this episode of Global Ambitions. And today we are joined by Pablo Lloreda, who is the manager of localization and accessibility at Roku.

Pablo Lloreda: 0:12

Hi everyone. I’m Pablo Lloreda Operations Manager for localization and accessibility at Roku. To give you a quick summary of my journey, I went to school for illustration and design as well as software engineering in the Canary Islands where I grew up. When I was 23, fortune helped me land the localization world by way of becoming a Castilian Spanish LQA for video games.

I have since then, worked for over 20 years in the industry spending most of my time before at Blizzard Entertainment and Riot Games. I’m still a gamer at heart but I also, I’m a movie buff, so I’ve been fortunate to work in industries where I really enjoy the output, which I’m very incredibly grateful for.

Stephanie Harris-Yee: 0:47

Nice. Very cool. Always better to work for someone that you enjoy the output for I would say. So let’s go ahead and jump straight into the topic then. Today we wanted to talk about shifting left. Now this is one of those concepts that’s been floating around the localization industry for a while. And it’s something that a lot of localization professionals face as a challenge where it’s hard to get that momentum. So I wanted to ask you. For you in your situation at Roku, what does shifting left mean? And can you give us a little bit of background?

Pablo Lloreda: 1:20

Absolutely. So shifting left in the development cycle means basically picking up the portion of the pipeline that you own and plugging it back at an earlier stage. And the goal of doing this is to improve either cost, speed, or quality or all of them. And the reason why it works is because making changes becomes more costly and disruptive, the more to the right you are, especially post code implementation.

I found that shifting localization from its usual spot to the middle of the design stage is probably the most rewarding shift you can attempt because it moves all three levers of the localization ecosystem favorably, which is awesome. I’m sure we’ve all experienced trying to address a long list of log bugs during the QA phase and an already implemented code and have suffered the consequences.

So here’s how shifting left impacts those three levers that we just talked about. First, cost. Cost is measured in hours worked, but it’s also measured in revenue lost for a delay release. Addressing log bugs during the design phase can consume a designer’s hours when compared to addressing them in an already compiled code at the end of the cycle, enforcing additional builds for several engineers are involved. You have to do more QA, et cetera. Number two, speed. It is noticeably faster to move a couple of pixels around in boxes in Figma to accommodate German than to rewrite a code, trigger a new build, run it through LQA and hope that it works. Especially if your engineers have already moved onto the next project.

Let’s say they have already finished this cycle and then move on to the next thing. You have to call them back. So now you are delaying this sprint and the next one at the same time. Lastly, quality. When you bring up a localization bug during the design phase, you can negotiate the real estate you need for all languages to look neat. And it also drastically reduces the number of times someone is gonna tell you or ask you, can you just make the translation shorter, right? Which generally reduces quality. We’ve all been through this. Plus you get to implement best log practices directly on the design system, which in the long term makes you, makes your designers more localization aware.

Stephanie Harris-Yee: 3:20

So it sounds like this is the ideal situation. We all wanna be there but it does remain a huge challenge for a lot of folks. So for you. How are you meeting this challenge? How are you getting to that stage where you can take advantage of all those things from being further towards the beginning of the process?

Pablo Lloreda: 3:40

So let’s get to the fun part. I wanna share this as a step-by-step walkthrough for those of you thinking about implementing this solution. Although it will obviously be a little bit broad because every company structure is different, but. I’ll try my best to give you something that you can just plug and play or follow through.

Stephanie Harris-Yee: 3:56

Awesome.

Pablo Lloreda: 3:57

First, let’s talk about what you need first, you need a plan. You need to learn exactly how your design cycle works. Identify a stage where you can enter your process with the least disruption to them. Making sure that you’re working on text and visuals that are as final as possible, but also that you still have enough time before the design goes to engineering.

With those parameters, you can then design this new pipeline section that you will plug into its new location and you lay it down visually, step by step so that you can pitch it to the team. Designers love visuals and so do I, so that works pretty well. And remember to add a layer for bug fixing at the end of the design process and before engineering implementation. These are a key component to eliminate or reduce log issues later, and it helps you address them in a much cheaper way. Second, you also need a tool or engineering support, either or can work in an ideal world. Your TMS has a robust connector to your design tool. For example, a good Figma plugin that it connects to your Smartling, Lokalise, whatever it is that will gather the strings on the design page. It’ll package them along with the visual context. It’ll turn them into a translation request and then return them to Figma as a new translated pages for each language.

If you don’t have access to a tool like this you should first question your TMS. They should be looking to develop this. This is I think a standard right now. Alternatively, if you have access to engineering support for localization tools, they should be able to build this for you. I don’t generally promote building internally but this is something that can really benefit you in the long term. So this is one of those things that might be worthy unless you wanna switch TMSs, which is a large effort,

Stephanie Harris-Yee: 5:32

Yeah.

Pablo Lloreda: 5:33

In modern localization pipelines, they’re very heavy on engineering. So if you don’t have engineering support, it’s probably time to start advocating for that in your company. But that’s a whole other episode that we can talk about later. So now that you have tools, you need stakeholder buyout. You should partner with your design leadership to pitch your idea. You come at them with a study of pros and cons. Definitely try to estimate an approximation of cost savings, engineering hours saved. And how does this change the the design cycle it itself?

Because you’re gonna be adding a little time to them. If you have hard data is always best for leadership. It doesn’t have to be terribly accurate, but it should reflect how impactful the change will be for them. It is not very easy. I’ll tell you this was the hardest part to go tell a team that they need to add more time to their cycle to accommodate you.

But overall, this is a winning strategy. And a good leader will understand I think, very quickly If you need to, you can also work with your boss to bring it up the ladder and get support from the design and engineering leadership at the same time as you explain the case to them, they’ll be able to trickle it down more easily.

Stephanie Harris-Yee: 6:37

Yeah, that, that buy-in from leadership is really super, super important.

Pablo Lloreda: 6:41

We work in these modern companies where they’re so autonomous and everything is so horizontal that we sometimes forget that leadership can help. But yeah, definitely lean on them.

Stephanie Harris-Yee: 6:50

Yeah. Yeah.

Pablo Lloreda: 6:52

So next I would recommend finding a high level designer that favors localization. Hopefully you have one of those. I have some of those, which is very nice. They can be your ally in, in your corner because they’ll be able to explain your vision to the team in their own language, which is very important. And if needed, you can also partner with an engineer that can help explain the pain points of having to address all those bugs. In the current way.

Stephanie Harris-Yee: 7:15

Yeah.

Pablo Lloreda: 7:16

I’m personally a huge fan of connecting people. I like putting people together, painting full pictures for them. In localization, we usually have the advantage of working with many disciplines, which is great. So we are the best position to promote cross collaboration because we usually know where all the bodies are buried since we’ve been stepping all over them to build our own workflows.

Next you need an experiment. So point it out with a designer once again and wrap this pipeline that you just built and run it in a couple of small projects that they may be having. Whatever they can identify as something that is good to, to test. You use these more runs to observe any potential roadblocks. You iron any kinks. And make the final pipeline as efficient as possible. Especially remember to measure the log box reported during the engineering phase after and before running these processes. Ideally, that would be the biggest measure you can show to your leadership to tell ’em how you have reduced the cost, the time, and or the number of bug or all of them.

Stephanie Harris-Yee: 8:15

Yeah.

Pablo Lloreda: 8:16

Once you’re happy with it, you put together a package to present to the whole team. And with the help of leadership, you just make this a mandatory step in the cycle of design. And ideally that’s the end of that. That becomes your new normal, and now you have successfully shifted left.

Stephanie Harris-Yee: 8:31

Nice.

Pablo Lloreda: 8:32

So some of the concepts I share are abstract, so let’s run a granular example of what it looks like step by step. It’s gonna be very simple, but if you’re trying to implement this, I think it would be very helpful. So a designer gets close to a final design, no more visual changes, no more text changes, only minor adjustments. So he is ready for launch. Someone triggers the localization process through the connector tool that we talked about, either your TMS, something you develop, et cetera.

This can be the designer themselves, it can be yourself, it can be a project manager in your team, your vendor, whomever is the best suited for it. The strings, after this connector has been run, the strings show up in your TMS, they’re packaged in a task and you run your translation process as usual. And then after that, someone imports the translated strings back onto your design tool, usually via the same connector tool. And this, again, can be performed by whomever, is whomever has the easiest time doing this basically. And this changes over time. It doesn’t matter.

After those strings are back into I suppose Figma or whatever other design tool you bring your LQA team in, you give them access to this design tool. They’re gonna open this file, they’re gonna find translated new pages that are created, and they’re gonna run QA directly on Figma. So when they do this, they either if you trust them enough and the design team trusts you enough, they can fix the design themselves. Or they can address text themselves if they consider that a different translation can be a little better or they can file bugs in whatever platform is visible to your designers, whatever they prefer.

And then they can address ’em real quick. Sometimes there’s visual is involved, sometimes the text is stylized, so a designer might be necessary. Once the changes are made, the designs are sent to the engineering for implementation. And after implementation, during the regular QA functional that they will run anyway. You should still run a quick smoke check yourself to make sure that the, what you observe in Figma actually translated correctly into code. Because it’s not an exact science. They still have to build it manually, somewhat but ideally, if this happens, you should see that your bug are very few or zero.

And then engineers, designers and yourself you can move on to the next feature. You reduce release friction and localization is not seeing as an obstacle to a release date, which I’m sure, I know for sure I have experience when you have a bunch of engineers or someone looking at you like, you are the one delaying this train, right? So this is what we want to avoid. Uh, And that’s it. This is how we run the localization for the Roku OS at the moment.

Stephanie Harris-Yee: 11:04

Yeah. Yeah. Thank you for giving both the concrete example as well as the list of step-by-step what people should look at. Is, from your experience, since you’ve gone through this whole process of setting this up, is there anything that you would caution people against? Don’t worry about doing that, or make sure you don’t do that? Any, anything that you can share.

Pablo Lloreda: 11:24

Absolutely. I have some details to keep in mind that I found very important during the first iterations and that really smooth the process out. So first of all, make sure to turn every stone and truly understand the design process of your company because you’re about to disrupt it. If you try to push a change to a cycle like that, you come in like you don’t know what you’re talking about, or you don’t have the right language, or you don’t know the chaos you may be producing, it might not end well. So make sure to partner with a good designer, show them what you’re doing and make sure that they understand and they help you and they tell you if you are about to introduce a change that will be too disruptive. Also, make sure to connect your vendor or linguistic team to your design team directly so they can reach each other and move information along. Like they’re gonna need a Figma file link. They’re gonna need access to that Figma file. They’re gonna need a designer’s name.

They’re gonna need to know where to file those bugs. And you want those things to happen without you. So make sure you connect them together. Otherwise there’ll be confusion and you just might not be saving any of the time that you should be saving. And lastly I wanna talk about, quickly about pseudo translation.

Some of these connectors have a feature that allows you to preview text with a longer or shorter percentages of expansion to account for languages like German or Chinese where suddenly your design can look very crowded or quite empty. So this is a very quick programmatic solution. Usually is one button push. And it in inserts some gibberish characters into your design just to give you a visual idea of what the composition would look like if the language was a lot longer or a lot shorter. If you have these available, you can get designers to use it whenever they want. Give them the freedom to play with it. They should feel empowered to use it and make adjustments themselves ’cause maybe they can’t even address those potential issues before you even see them. So that’s a very powerful step as well.

Stephanie Harris-Yee: 13:11

Yeah, for sure. Okay, that’s about all the time we have today, but to close us out what’s next for you and any final thoughts to add?

Pablo Lloreda: 13:20

Thankfully at Roku the work is never really done. There’s always a new product, a new feature, a new season of content, or a new experiment cooking. That we need a localization power and design specifically for it. And I live for solving puzzles, so we’re getting much better at building plug and play pipelines after we’ve built so many that the next one, there’s always something that we can reutilize.

We building with minimal maintenance so that once they’re built, it’s up to our partners to drive them and then we can move on to the next thing. But there’s always something new to think about, especially now with generative content. Playing a new role in content creation and whatever else is quickly evolving in future will bring, which is, which has been incredibly fast lately the types of new content and things that come our way. So I’ll stay here for as long as they’ll have me. Or until I feel the call to go back to Spain and relax by the ocean, which I think I’m starting to hear faint whispers already.

Stephanie Harris-Yee: 14:14

Yes. Yes. Alright, thank you so much for joining us, Pablo, and I think there’s some great insights here for our audience, so really appreciate it.

Pablo Lloreda: 14:23

My pleasure. Thank you for having me. It was an honor.