Portfolio: WPML Plugin – Case Study

WPML is a WordPress plugin that allows making your site multilingual. It was first released in 2007. I joined the team in 2014 as a front-end developer and since then, I am constantly advocating for a better understanding of WPML’s clients and their needs.

Today as a design team leader I’d like to share an interesting case study of one project within WPML.

Design Challenge

Make machine translations more popular and accessible to the clients.

At that stage WPML already supported machine translation, but not a lot of clients would use it even though this is the number one feature that they ask for.

It was already possible to automatically translate entire content of a website using machine translation and to translate individual pages that way. It even was possible to mark several pages to be machine translated at once.

The big question was: how to deliver the service that users really need.

Design Process

1. Research – collect information on current flows

1. UX audit of what is currently available in the plugin and what are potential problems.

One of the obvious problems was: discoverability of machine translation feature was very low.

We decided to reach clients who were determined enough to find it, and ask for the main reasons why and how do they use it and what is missing.

2. On-line survey identifying proper interview candidates, that at the same time contained questions already collecting information on client’s situation and translation habits.

Part of survey results helping to identify translation habits.

3. Remote user interviews.

Fragment of the research report identifying types of users.

I was a design leader, and in this part of the project my tasks were to:

  • perform the UX audit,
  • define questions for the survey,
  • oversee interview scenarios
  • take part in some interviews as an observer (and learn to delegate important tasks to other team members ;) )
  • review the results and coordinate crafting research report

2. Defining main problems

  1. Discoverability of machine translation feature is very low.
  2. Most people do not want to automatically translate their entire site, they would rather choose particular pages to translate.
  3. Translating pages one by one using currently available “automatic translation” option is not time efficient.
  4. Bulk machine translation is almost impossible to find – the flow is overly complicated.
  5. People who managed to find it were afraid of poor quality machine translations being immediately published without human proofreading.
  6. Many clients using the “translate everything mode” were surprised that they landed in this situation.

3. Developing design solutions

We sat down with developers and management and decided to span proposed solutions onto several next plugin releases.

The very next version was about to be focused on:

  1. Making it clear to the user when and how they can enable “translate everything mode” and what does that exactly mean
  2. Making it possible to easily machine translate posts in bulk

Making it clear to the user when and how they can enable “translate everything mode” and what does that exactly mean

Solving the first problem was all about improving communication.

After careful analysis of user’s feedback, we decided to go from this:

to that:

1. Explain exactly what each of the modes does to let the user make an informed decision.
Provide an opportunity to get help from an actual human being if they are not sure about their decision.
2. Extract “what next” decision to the separate step. Allow the user to make one decision at a time.
3. Allow the user to polish their content before WPML starts translating it.

Those changes significantly lowered users’ fears of making a certain decision or spending money on translating content that is not yet ready to be translated.

Making it possible to easily machine translate posts in bulk

The second problem was much more complicated to solve. I needed to figure out a way to incorporate a very new option to an interface used daily by millions of users very much used to the “old ways”.

Not only the interface was to be changed as little as possible, but also the currently existing flows behind it had a true maze of possibilities and connections.

Existing flow had a step in which the user needs to choose what to do with selected content.

How the interface looked like before any changes for this project.

My first iteration was about adding a new option to the grid of choices and make the grid look in line with the new plugin’s styleguide.

First iteration. Add new option and adjust looks to the new styleguide.

Well… This approach was not welcomed well. Not only the new layout of a choices grid turned out to be harder to work with, but also invited a very complicated scenario of user needing to go to very different places to finish two different translation processes.

The second iteration was all about not allowing to mix different actions with each other.

Second iteration – not possible to mix actions.

It turned out, this approach would meet a hard “No” from the users who are already very much used to the current flows and taking from them possibility to mix already existing options and hiding languages in a multiselect would make their work slower.

That one would also need quite a change from the development point of view, since this is one of the oldest and most legacy-code-reach area of the plugin.

The third iteration was much less compact and much less revolutionary. It literally adds one more layer of decision: “HOW do you want to translate the selected content?”

Final iteration – adding a new layer of decision. HOW to translate.

I must admit this was my least favorite solution. This fragment of the GUI not only was not cleaned up and simplified, but it rose! Yet, one more decision to make by the user. Most people do not like making too many decisions, right?

Well… It depends. In that particular case, this solution showed that everybody knew what to do (discoverability of bulk automatic translation is definitely much better now), there was no confusion on what to do next, and it does not disturb user’s existing flows.

Once again, we could clearly see that the design is not for the designer, but for the users.

Both of those problems were solved using a team effort of UX designer (me), UX writer and UI designer.

Want to take a look at the prototype?

4. Cooperating with developers

Next step for this design is to be implemented. Coming from a developers environment and being a front-end developer myself makes it easy for me to communicate with programmers and understanding any technical difficulties that might appear at this stage.

I am always happy to answer any questions or adjust my designs to the technical requirements.

If you take a look at the prototype, you will notice that on the left side of the Figma canvas, we have quite some variants of the seemingly simple GUI element. These are versions of the same element in very different scenarios that users might be in. I can uncover a secret that we discovered at least two more while developing.

Currently, the project in development testing phase and hopefully, it will be released to clients by the end of the month.

5. Measuring the results

Next steps for me will definitely be gathering statistics on the real impact of those changes. Will clients use machine translation more?

  • Design System
  • Figma
  • Product Design
  • User Experience Design
  • UX Research
  • UX Testing
  • WordPress Plugin


All \ UX Case Study \ WordPress Based Website \ WordPress Plugin \ Mobile App

Hire me!

Do I seem to be a good fit for your company? Do you have a cool project to work on?

Do not hesitate – e-mail me now.

E-mail: k.janoska@anoriell.eu