Assessment Automation Multilingual Templates
How did we become aware of this issue?
The Multilingual Templates project came from our Aha! Ideas portal
where it was the #2 top voted idea for the entire product from our clients and stakeholders worldwide and #1 within the AA module.
Clients chanting, "We want translations! We want translations!"
Who does what?
AA has three main user roles (they may vary depending on the organization):
- Assessment Launchers: They create templates and send out assessments; usually security councils, compliance officers, etc.
- Assessment Respondents: They respond to assessments; can be any user from security officers and program managers to external users.
- Assessment Approvers: They review and approve (or reject) assessments based on a variety of criteria; usually security teams, legal teams, etc.
The "user" for the bulk of this project refers to the Launchers.
Uhh .. so how does the platform work today?
In AA, assessments must be launched using a template. The user must first create a template, then launch and send assessments using that template. Below is a generic flow illustrating the process from creating a template all the way through sending out an assessment to the respondents.
User flow diagram for how templates connect to assessments within AA
OneTrust is used by thousands of companies worldwide, so our users use many different languages in their workflows. The GDPR, for example, is an EU regulation, so every European country (with over 24 official languages) must abide by it. Currently, users only have the ability to create a custom template in one language. If the user wants to create a translated version, then they would have to create a separate template in the different language. This can be time consuming and inefficient having to track multiple templates in different languages for the same assessment. Questions are created manually, so translations must be made manually, as well.
Because questions are created manually, they must also be translated manually.
How do we measure success?
Based on the insights from Aha! and additional discovery sessions with users and the PM, we concluded with two main goals we needed to accomplish:
- Provide users the ability to build and manage multiple language versions of an assessment within a single template
- Allow respondents to view and respond to an assessment in any language configured within the template
What do we actually need to consider and make?
After several feature planning meetings with product management and the development team, we fleshed out the technical elements needed to meet the success criteria and address any potential technical hurdles. These are tangible requirements based on the success criteria.
What do we actually need to consider and make?
From a UX perspective, it's important to ensure each of our criteria aligned to usability heuristics
. As a UX Designer, I had my own two goals, which I also aligned to usability heuristics:
- Make sure this is a streamlined process. Translating an entire template into multiple languages is already tedious, so I want to ensure I don't have any extraneous steps (Flexibility and Efficiency of Use, Minimalist Design). As with any enterprise software feature, it needs to be scalable.
- Ensure the process is clear to the user. Like I said, this whole process is pretty tedious, so there's lots of room for error and confusion. The tricky part here was balancing clarity and concision. (Help and Documentation, Error Prevention)
Below is a brief (and non-exhaustive) list of some of the criteria:
1. Provide users the ability to build and manage multiple language versions of an assessment within a single template
Allow users to set a default language in order to map the template keys to a language
Allow users to download and upload translation Excel templates (this is common industry standard)
Flexibility and Efficiency of Use, Consistency and Standards
Allow users to update uploaded translations
User Control and Freedom, Error Prevention
2. Provide respondents the ability to view and respond to an assessment in any language configured within the template
Allow respondents to set the assessment language
User Control and Freedom,
So how do I drive this thing?
I created a flow diagram to organize my thoughts and better understand the actions the user needs to take and in what order. (Surely the user needs to download the template first before uploading it.) I am also able to determine what new elements need to be added and what old elements may need to be updated or enhanced to seamlessly fit this new feature. For instance, I need to ensure that our pre-existing "Create Template" flow includes our new "Template Language" field so that new templates moving forward can streamline the process of adding translations.
User flow diagram for adding translations. "Oh, so this is how you drive this thing"
Drafts and Iterations
Let's try this out
The bulk of this project revolved around the first goal of our success criteria: "Provide users the ability to build and manage multiple language versions of an assessment within a single template." How does the user download the translation templates and upload them back onto the platform?
Throughout each iteration, there were two main focal points:
- Description: How do we ensure users know what to do without overwhelming them?
- Language Selection: When is the optimal time for users to map their translations to a language?
First iterations of our "Add Translations" modal. Almost there but not quite.
A LOT to consider for a medium-sized feature 😅
What'd we end up on?
Lots of feedback sessions and technical discussions later, I landed on this final design, which successfully completes the first success criteria (including the associated acceptance criteria) and refined the two main focal points:
- Description: Using clear headers and splitting the descriptions into two steps more clearly informs the user exactly what they need to do and in what order. (Thanks to the UX Writers for bearing with me here!) This also shortened the description per step, thereby reducing cognitive load. This met UX Goal #2: Clarity.
- Language Selection: Letting the user select the language after uploading each file provided the most flexibility. The user can send out the generic template to each translators and easily map them to their respective languages at upload. Both steps happen within this one modal. This met UX Goal #1: Streamlined Process.
Left: Draft modal, Right: Final modal. Sleek, ain't it?
Completing our second success criteria (Allow respondents to view and respond to an assessment in any language configured within the template) was a lot less exciting and just a matter of adding a "Language" selector (3) on the assessment sidebar -- abiding by pre-existing patterns in our platform.
The respondents only see a new "Language" selector. They don't know about all the work I put into this!
Challenges and Compromises
It wasn't easy getting here ...
As an MVP, of course this project was shaped by several challenges, constraints, and compromises:
- Time: As a highly requested feature among nearly all of our clients, this feature was highly anticipated and thus, on a fairly quick deadline. Originally promised to be delivered within 2-3 weeks, I was able to negotiate about an extra month of time (on top of my other work!). The time crunch also made it difficult to get intermediate feedback from clients so we had to rely on our initial customer requests.
- Technical constraints: Along with time, we had to cut some "good-to-have"s due to the software architecture already in place. Criteria like asynchronous download and upload were scoped in primarily due to technical limitations that meant uploading files could take as long as a few minutes. Some de-scoped criteria included tracking and warning users about any translations that uploaded with errors (below).
Scrapped "Missing Translations" designs due to technical limitations
This isn't the end of me!
While we did some great work for this MVP and we will continue to monitor customer feedback for this feature, we have also had some great ideas for enhancing this feature in the future. While we did as much as we could with technical and time constraints, one of our goals as a company is to streamline all our processes. In a future state, we would love to have a way for users to input translations within our platform, as well. This way users don't have to rely on another software and take extra steps to compile all the files together to be uploaded. Instead, each translator can log into the system and input the translations directly to the platform, which can also reduce any issues when uploading. We also hope to add in some of the de-scoped criteria mentioned above to improve error handling for the users.
Keeping it in the family.
What'd I learn?
In each project I've worked on at OneTrust, I've noticed these common themes which have helped me grow more as a designer:
- Scalability: As with any enterprise software, features must be scalable. We have thousands of clients around the world, so our product needs to work successfully across a wide variety of business use cases. Business use cases also tend to involve LOTS of data, so all actions must be as streamlined as possible.
- Clarity First: We frequently think that "less clicks is better," but that isn't always the case. We should prioritize guiding the users to achieve their goals first. Sometimes over-streamlining leads to poor information scent.
- It's not JUST UX: In an ideal world, we would be able to implement "perfect" UX for each feature, but realistically we have to work within technical, business, and design constraints. Negotiation, compromise, and prioritization are very important skills when working on any project, especially in a cross-functional team.