TL;DR: Linguists wanted an easier way to navigate across documents, especially in bigger projects. We went through a couple of iterations and landed in the place that made them happy and successful. Satisfaction up from 7.8 to 8.0, % of projects marked as done without PM intervention up 20%
User interviews, surveys, success metrics, design & prototyping
1 PM, 1 Designer, 1 Engineer (Front-end)
As the only designer on the team, I worked with the PM on developing the problem definition through user interviews, surveys, and reviewing session recordings, as well as designing, prototyping, and user testing selected ideas.
- Lilt is a company that runs a two-sided marketplace between organizations needing localization and a pool of freelance Linguists who specialize in certain languages and usually have solid background in a very specific niche (e.g. technical content)
- Organizations create Jobs that usually have a single source language (e.g. English (US)) and need their content translated to multiple languages. Jobs are split into single-language Projects that get assigned to Linguists.
- The three-level project structure that Lilt offers (Documents within single-language Projects within multi-language Jobs) turned out to be too time-consuming and complicated for Linguists who are generally employed for single language projects, which leads to them having to spend a lot of time navigating the structure rather than focusing on translation when project has multiple documents
- The problem was exacerbated by translation projects coming from the API which might create projects that have a hundred documents each containing a handful of strings to translate
- All this navigation took time and was constantly interrupting Linguists’ work, which lead to drop in productivity and required a lot of context-switching
- Persona: Linguist
- User jobs
- Navigate between documents within a project without leaving the Editor
- Navigate between projects without leaving the Editor
- [Potentially] Marking multiple documents as done without leaving the Editor
- Metrics impacted
- UMUX-lite (usability and usefulness)
- Projects marked done on time
- Time to deliver (Project)
I tend to evangelize the Shape Up method popularized by Basecamp within the team to communicate early ideas - this allows us to focus on the structure and the bigger questions without jumping straight into design. This wasn’t different in this case, and we continued to iterate and brainstorm on some of those early sketches and ended up settling on a couple of initial ideas.
Our first idea was to implement a multi-document view, in which all documents would be available within the Lilt Editor as a stream of content that loads as the user scrolls, similar to what social media platforms offer (”infinite scrolling”)
After initial round of testing and stakeholder feedback, this idea got rejected as technically unfeasible, as well as cluttered in larger projects.
While exploring other solutions to the problem, we came up with an idea to introduce a pagination-like mechanism that allows the user to jump from one document to another as soon as they reach the end or the beginning of the current document. This ended up being the solution we went with, as it was very simple to implement and had a large upside potential.
After launching, we got a large amount of feedback telling us that while navigating from one document to another definitely helps, there’s also a case of marking things as done in bulk - it turns out Linguists don’t mark their work “done” as soon as they’re done translating, they tend to translate a larger batch of documents and then re-read all of them to ensure consistency and populate older translations with some newer ideas they had. We also had internal project managers come to us saying that people forget to mark documents as done, prompting extra work from their managers.
The solution we came up with was adding the ability to mark documents as done as well as see all documents within the project at a glance in the Documents sidebar.
It is an excellent feature, thank you for bringing it back! I am using the 'open next document' button. But the tab is also useful. It would be great if we can see from that tab what is marked as done, and not just a percentage.
I used it while working on small files, I love it!
- Usability and usefulness (UMUX-lite) score for the Editor: 3.7 → 4.0
- Projects marked as done on time: ~60% → ~80%
- Quick wins are important - releasing something quickly that already helps the users is a great way to move forward and gather more feedback for improvements
- Getting feedback from all stakeholders (including Engineering team) early on is very important and can very quickly cut out some solutions that seem common sense due to limitations like technical feasibility
- Rapidly launching minor improvements can have serious impact on usability metrics