A bit of context
TL;DR - localization of multimedia projects has a lot of moving parts and pieces.
Localization companies often face significant challenges when handling multimedia projects due to the sheer size and number of files involved, which can make it difficult to manage and organize the content effectively. Customizations for different languages and cultures also require a high degree of precision and attention to detail, which can be time-consuming and labor-intensive. Moreover, the wide variety of services required for multimedia localization, including translation, voice-over, subtitling, and graphic design, must be expertly mixed and matched to ensure a cohesive and high-quality final product.
The specific problem at hand
Users and stakeholders have expressed concerns about the manual and time-consuming intake process for multimedia projects, which is prone to errors and lacks consistency. Different Project Managers setting up the same project can lead to inconsistencies, while the lack of standardized pricing across different company squads further exacerbates this issue. Inconsistencies and lack of standardization can lead to longer project turnaround times, decreased productivity, high turnover, and lower customer satisfaction.
So we just need to go consistently…
Proposed solution
Project intake needs to be simplified by creating a centralized and standardized system that minimizes errors. PMs can easily input new project information or build a new project based on a previous project. The system auto-populates necessary data fields to ensure consistency and reduce errors.
For this to work, the Finance team must also be looped in to create a streamlined pricing sheet.
UX can be improved by providing clear instructions and automating tasks like field population.
Research phase
To begin a project of this scope, we need a way to organize the basics and brainstorm collaboratively. While the tool matters less than the process, I chose to begin with an Invision Freehand board. If you’d like to see the full whiteboard, let me know.
Articulating the problem of the dreaded “Super Program”
Multi Media localization for this client is a very large program with no constraints on which tasks are available. One side effect of this is that each Multi Media project must currently be custom built from scratch, every time, from ALL available services.
You might think of it like this:
If the problem isn’t immediately apparent …
Then let me explain it another way. Imagine you’re setting up a new project. You’re accustomed to having limited options to choose from because the system is smart enough not to open all the gates at once. For example, if you’re translating patents, then you have no need for subtitles. If you’re suddenly presented with ALL the various options for subtitling your Patent project (e.g. open, closed, burn-in, marcom, lower thirds, etc), then you have a problem.
Ooooh. Ok, that makes sense. So what might we do?
We might instead break apart the current multi media super program in favor of a limited set of multi media programs.
Simpler, yet with more flexibility built into the system.
We have some background research to consider
Some of it’s pretty high level, but it’ll help us to better understand the constraints as we go.
Next we’ll examine any existing artifacts to see where they succeed or fail. Maybe something interesting will shake out.
But first, we should probably take a short vacation. Personally, I like the beaches of the Pacific North West.
Mmm. Raw oysters on the half shell! Let’s go to the coast!
Examining the original project intake flow...
One core problem here is a lack of consideration for Information Architecture. Much of what exists could be improved dramatically with a combination of IA and progressive disclosure of UI.
Briefly: Organize and nest all information appropriately. Then only show what is needed at the moment it is needed.
Now take a deep breath. Deeper…
Messy, yes. But it actually helps us clarify many things.
We can see that what's intended could be represented using a directed acyclic flow. It doesn't currently function that way, but just knowing this allows us to begin considering a UI based on progressive disclosure.
Now it's time for the stakeholders to help choose the desired user type(s) for the MVP.
Before entering prototype mode, here’s another consideration.
The MVP solution must account for two scenarios:
A. Client requires a new project similar to a previously completed project.
B. Client has a new, non standard request.
So let’s drop a quick flow chart to work against.
Now we prototype (rapidly)
For this particular project, I produced four clickable prototypes illustrating different levels of complexity and automations. Here are highlights from one of those.
P.S. Just ask if you want to actually see these in action. It’s a little more dramatic that way.
In retrospect
If you’ve reached the end and feel like something’s missing, that’s because there is. This study shows only a small portion of the notes and documentation as well as limiting the final presentation to one of four distinct prototypes. There’s more info still on how engineers are included in the process. Feel free to ask me if you’d like to see more details or to discuss the ins and outs.