WPML - New Feature

Context

WPML is a WordPress plugin that allows making your site multilingual. WPML was initially introduced in 2007 and is consistently evolving ever since.

Business Goal

Increase revenue on translation credits used to pay for machine translation.

Problem

WPML already provides support for translating content using machine translation. Users have the option to either translate the entire content of their site in one go or utilize machine translation on individual articles, translating them one by one.

Furthermore, there is a workaround available to translate multiple articles in bulk. However, the discoverability of this option is currently extremely low, making it challenging for users to find and utilize this feature effectively.

My role: UX Designer & Design Lead in cooperation with UX Writer and Researchers

Time scope: 1 month

Solution

Enable users to submit articles in bulk for machine translation. While deciding on what to do with the chosen content, add a sub-option asking how to translate.

And that's it?! That's the case study worthy project?!

Well… Yes, if you dive into constraints, PILES of dependencies and user testing results.

Buckle up!

Research

UX audit

I decided to conduct UX audit to assess plugin functionality and identify potential issues.

Known problem: Low discoverability of machine translation feature.

Right before this project, we welcomed a new designer to our team and I assigned her the task. I wanted to leverage not only her UX expertise to document the existing workaround, but also her fresh eye for capturing the challenges and frustrations faced by someone encountering this task for the first time.

As a result we had a clear picture of a current state of the product.

On-line survey

Given our budget and time constraints, we decided to use the survey to identify suitable interview candidates as well as gain valuable insights into our clients’ motivations, usage patterns, and areas for improvement.

Strategically crafting and optimizing proper survey questions was one thing, but contacting the exact clients we wanted to send this survey to was a separate challenge. 

That required cooperation between the design team, the systems team taking care of the mailing system and the translation editor team taking care of selling translation credits. We needed a list of emails belonging to clients who spent certain number of credits during the last three months. 

It turned out creating such a list was a challenge for the development teams at first. Fortunately, we managed to persuade development teams that such a need will come up much more often, and they developed an in-house tool allowing for easy data extraction. 

Thanks to that initiative, we gained access not only to qualitative interview data but also quantitive data from our own databases.

Cooperation between cross-functional teams brought us to a survey-success. We had results and a list of suitable interview candidates.

Remote User Interviews

Remote interviews were held by our UX designer and UX researcher. As a design team lead, I was consulting the interview scenarios and gladly took part in part of the interviews as an observer.

Research Report

Normally, after each interview session, we gather to share notes and pinpoint the most important insights from the talk. Additionally, after all interviews, I organize a summary meeting where we highlight the most common and most surprising findings. By the end of such a session, we have a list of actionable tasks to be done during the next sprint(s) – no reports needed.

This time we were asked to prepare a report, which was rather surprising but doable. We dusted all our reporting knowledge and crafted a straight-from-the-book UX report layout. It got finished by the UX designer and from the usability people perspective it looked just right.

We went to the previously planned meeting with our boss. My colleague presented the report and… it got ugly. The boss was absolutely disappointed with the kind of insights that he was served. “You are wasting your and my time here!” he complained. “How could let that happen?!” he directed this question to me.

I approached this situation calm and explained that there probably was a misunderstanding, concerning the type of report that he expected. I assured we have loads of data from the interviews, and we can prepare another report approaching the topic from a different angle, but we need to know what information he would like to get from us. 

Indeed, it turned out we understood very different things by “UX research report”. For me and my UX colleague, that meant 

  • a list of insights and problems that need to be addressed 
  • highlighting the importance and scope of potential changes. 

For our boss, it meant getting business information about 

  • who the users are, 
  • how much they spent, 
  • how likely they are to spend more.
Fortunately, we had all this information in our notes. We just needed to craft a very different report. This task was assigned to our UX researcher – she worked in the company much longer and had a much better understanding of what information is interesting for that stakeholder.

Lesson learned for life

Never assume. Ask. Research brings all kinds of insights and discoveries. Naturally, different aspects are interesting to different groups of stakeholders and in-house stakeholders should be treated similarly to outside clients: first get to know their needs and context and only then jump into action. 

I will never again simply assume what kind of UX research report I should craft. Bootcamp templates are not always suitable for a real-life companies.

 

Major takeaways

  1. Discoverability of machine translation feature is very low. Plus, bulk machine translation is almost impossible to find.
  2. Translating pages one by one using the currently available “automatic translation” option is not time efficient for big sites.
  3. Most people do not want to automatically translate their entire site, they would rather choose particular pages to translate.
  4. People who managed to find it were afraid of poor quality machine translations being immediately published without human proofreading.
  5. Bulk machine translation is well-needed for big websites owners who want to translate them to many languages – e.g. e-commerce shop owners.
  6. Owners of small sites (blogs, small businesses, NGOs) do not really use the bulk translation option and they most probably wouldn’t start doing that for machine translation because they are afraid of the high cost of translation. They use machine translation, but they prefer to translate pages one by one and have full control over the quality of translation.
  7. Agency clients do not need our additionally paid machine translation feature – they already use their own solutions.

Ideation

What might we do?

I organized a meeting with our team to brainstorm ideas for delivering easy-to-use bulk translation to our clients. The most promising ideas were:

 

  1. Create a separate page for human translation and machine translation
  2. Add a new type of “Bulk Action” to the WordPress posts listing page
  3. Utilize the “Automatic Translation” tab that already exists in the system
  4. Add a button in each table line to quickly machine-translate the article
  5. Redesign the well-known action table at the bottom of the translation management screen

Evaluating ideas

I organized workshops with developers and supporters to run the ideas by them and get to know what would be technical constraints for each idea and if there already are some user insights from the support forum that would be helpful for this case.

Then I ran the ideas by current plugin users. There were 2 groups of users:

  • Owners of sites with lots of content
    • Where would they expect to see the new option?
    • Which of the ideas would have the best discoverability
  • Agency expert users, constantly translating hundreds of websites
    • How will the new design influence their workflow?
    • Won’t we make their work slower or less convenient?

As a result, we knew the pros and cons of each idea and were able to pinpoint the main problems with implementing each of them.

Too low discoverability: 1, 2, 3

Problematic to develop: 2, 3, 4, 5

Problematic when translating to more than one language: 2, 4 

Both users and developers turned out to be most happy with the idea #5: 

Redesign the well-known action table at the bottom of the translation management screen

Prototyping

The requirement was to make the change as small as possible from a development perspective. Our clients needed this option soon, and dealing with legacy code is never fast or bug-resistant.

The bottom section of the Translation Management page was never designed in a prototyping tool. Rather than spending time redrawing the entire screen, I used screenshots and added only interactive and new elements in Figma.

This allowed me to perform user tests, save time on prototyping, and ensure that the development team receives the exact views they need to work on.

Based on my experience, when a designer needs to re-draw an outdated screen, they are tempted to improve it by making it more visually appealing and modern. While it is important to strive for a great UI, this can often lead to serious delays in product delivery.

Because of additional UI changes that are not in the scope of this project, developers might be forced to spend time on time-consuming refactoring and rewriting old code. Instead, the focus should be on improving functionality without making extensive changes to the UI.

 

To play it safe, if there are no previous designs and parts of the existing interface should not be altered, it is more effective to use screenshots and fake clickable layers for testing and presenting purposes.

Apart from keeping this new feature small, there were also other requirements:

  • Manage mixed translation methods when multiple languages are chosen at once.
  • Consider communication with our SaaS product.
  • Handle previously translated content.
  • Avoid over-promoting machine translation due to contractual obligations with manual translation services.
  • Ensure that the current flow does not slow down for large agency clients, who translate hundreds of websites daily.
  • Adjust all texts on that screen to the new workflow possibility: bulk machine translation.

Action section solution proposals

Currently, the Translation Management page looks like that:

Changes were focused on the action section:

#1 Simply a new action option

I added a new option to the action part of the screen. It turned out to be problematic, though: 
  • Overwhelming layout: Five radio buttons with long descriptions in each line looked very chaotic.

  • Problems with responsiveness: Too many options were problematic on smaller screens. Of course, switching layout to more vertical was an option, but providing a super long list of options combined with possible many languages would make this part of UI hard to use.

#1.5 Different UI for a new option

This solution was indeed cleaner and more modern looking but user testing showed a series of problems:

  • Too many options at once were confusing to users
  • Nice UI matrix was hard to read and was causing hesitation on which radio option is for which action. 
  • The possibility to choose “Machine translation” for some languages and “Manual translation” for others created another problem: Different next step for each case and user confusion.

#2 Complete redesign of the action section

The second idea was to add a new option to the action part of the translation management screen that would allow choosing only one option and the time.

User consultation showed that: 

  • Individual users found that a good and understandable workflow
  • It was more compact than the original one and possible to use on small screens – easier than the version currently on production
  • Expert users’ work was made significantly harder and slower

Although results for this particular sprint were satisfying, we could not afford interrupting expert users.

#3 Different UI for a new option

Third approach was a super raw additional suboption for a “Translate” action which asks the user: “How would you like to translate”.

I must admit I did not like this design. It looked very “straight from the database” style to me, but user testing showed that it was fully understandable, not bothering current expert users’ workflow and solved the problem of translating content using different methods in one go.

Running the chosen prototype by developers

Was that it? Ideated, prototyped, tested by users, so ready for development? Of course not.

The design was as minimalistic as possible, so there would not be any problem with legacy code, but we still had to deal with WordPress Plugin ↔ SaaS application communication, edge cases and multiple variants of product configuration.

The biggest questions we still needed to answer were:

  • What about content that is already translated?
    • Discovery: now WPML simply ignores it, which is confusing for the users (as support forum shows)
    • Discovery: even if the already translated content is force-sent to translation editor it uses “Translation Memory” instead of translating from scratch, which results in the very same translation as before
    • Solution: Ask the user what to do and change the way WPML and the Translation SaaS tool communicate with each other.
  • What about communicates when the user chooses Translation AND Content duplication?
    •  Discovery: now, the message shown after such mixed action is confusing. 
    • Solution: Craft entirely new messages that are understandable and supportive.
  • What if the user chose “Machine translation” and does not have translation credits (so cannot pay for the translation)
    • Discovery: It is possible to use SaaS product API to buy more credits right on this screen
    • Solution: Inform the user about the situation and let resolve the problem right away.
  • Can we ease the pain of small users and show them the translation price before sending content for machine translation?
    •  Discovery: Only the SaaS product can establish the cost of translation, and before the content is sent such calculation is not possible.
    • Solution: unfortunately, we do not have a solution to that problem in this sprint.
  • How can we assure the user that they will be able to review the machine translation before publication?
    •  Solution: When the user sends their content for machine translation for the very first time, ask if they want to publish the translation right away or would rather review it first. Make sure that messages shown to the user after sending content for translation mention reviews.

Oftentimes while working with a complicated many-levels product, careful ideation, prototyping and user testing is not enough. Close cooperation between Designers, UX Writers and Developers is crucial to solve more technical problems that arise during the development process. 

Crafting a bulletproof testing scenario covering all possible product options combinations might be impossible. This does not mean that the designer is exempt from the obligation to consider edge cases and clear messages to the user in each case.

Final solution

The final solution is seemingly simple and not complicated at all. In reality, it covers:

  • over 15 different scenarios for the action section
  • 8 different success scenarios
  • 3 different in-flow problems

Check out Figma prototype:

Results

The new version of WPML was released just recently. I am collecting data about exact results of this project.

Takeaways

1. Treat in-house stakeholders similarly to the outside company clients. I know that before jumping into action, I need to perform workshops and research not only with product users but also with business, marketing, sales and all other in-house stakeholders who also needed something from that project.

2. Consult the project with developer as early as possible. Especially if the project needs to be done on a connection of two different products. The best thing is to gather developers from both projects in the same room (remote or live). I learned that the fact that they work in the same company on products that are closely connected to each other it does not mean they normally communicate with each other and such communication has to be facilitated to have a successful product.

3. Engaging people from different company departments (like support) allows discovering many project issues quicker and cheaper than organizing user testing. Thanks to that, tests with users can be performed on projects that are internally agreed.

4. While adding a new feature to the product, it is of course crucial to think about users of this new feature, but it is equally crucial to think about the non-users. The perfectly good workflow of the later cannot be disrupted by new features. 

5. My designer’s nature, and my design team opinions often push me towards reinventing interfaces, making things more aesthetic, more modern and more sexy, but at the end, business’ needs and client’s satisfaction are much more important.  It might be counterintuitive, but sometimes the easiest and “ugliest” solutions work best in well established products.

Scroll To Top