Lilt: Expanding the project lifecycle with Workflows
🎢

Lilt: Expanding the project lifecycle with Workflows

Worked on
user research
product discovery
design
👀
TL;DR: The standard workflow of Translate + Review was not enough in enterprise and government context. I worked with the team on understanding what exactly is needed, what is the minimum version of what we can test, and designing & prototyping the solution.
Scope
User & stakeholder research, workflow design, prototyping, user testing
Tools & methods
Figma, user interviews, ethnographic research, usability testing
Team
Engineering squad + 1 PM + 1 designer (+ countless people interviewed and poked for broader understanding of the problem)
My role
As the only designer on the team, I worked with the PM on developing the problem statement, brainstorming potential solutions, as well as designing, prototyping, and user testing selected ideas.

Problem

Since the beginning, the only workflow supported inside Lilt was Translate + Review. Over time we heard from customers on the enterprise and government side that this approach is limiting their use of the platform because it doesn’t reflect the reality of linguistic projects.

Discovery

During the discovery phase, I spent a lot of time with our Product Manager interviewing stakeholders and user representing each user archetype:
Linguists - who do translation or review work on each step
Production Managers at Lilt - people responsible for making sure linguistic projects are done on time and at a certain quality
Enterprise Managers - whose entire job is to manage linguistic projects on the customer side
We ended up defining major workflows that we need to support per persona, jobs to be done, as well as certain stages, goals and actions per user persona. We also built a lot of process charts explaining how the biggest possible solution might look like, to later radically cut what majority of users isn’t likely to use:
Potential “biggest solution” going through all the discovered stages of a linguistic project
Potential “biggest solution” going through all the discovered stages of a linguistic project
Example lifecycle diagrams that we created in the process
Example lifecycle diagrams that we created in the process
After categorizing and grouping the feedback, we decided to tackle a couple of discrete problems with managing workflows:
Assigning a workflow for multi-language jobs - this would be the default workflow for all language pairs in this job, cascading down to projects
Overriding workflows for certain language pairs - in our research and discovery process we determined that certain language pairs are more prone to mistakes and need e.g. an extra review step
Tracking the project state - given that every language pair in a job can have a different workflow, there needs to be a way to track projects in flight
Tracking the document state - we ended up concluding that it’s documents, not jobs or projects, are what the users care about the most. They would be the ones going through the workflows.

Learning from the competition

As we worked on our Workflows functionality, we looked at how the competition solves the problem. It ranged from rather simple to very complicated solutions, including custom workflow builders. We’ve decided we want to stay on the simpler side and build from there, given that we’re not a large team.
Example Workflow Builder screen from a another product.
Example Workflow Builder screen from a another product.

Designing the moving parts

As I mentioned earlier, we decided to tackle the project in a couple of discrete flows. We iterated over prototypes with both internal and external stakeholders to make sure we’re on the same page. One of the early ideas, for example, was to allow the user to auto-assign the linguist for certain stage (based on the information we have on them in our CRM), which we ended up simplifying a lot after a couple of feedback loops with the users.
notion image
notion image
notion image
One of the issues that came up in testing was that the users didn’t understand which step of the workflow a certain item is at, which obscured how long might it take and is it on track to completion or behind. We ended up solving this by using “Workflow Overview” tooltips that would explain where the item is:
notion image

Simplifying the model

After some more discussions with the users, we’ve realized that assigning workflows to documents is enough to test our hypotheses, while projects and jobs will only be able to have three simplified states:
Not started
In progress
Done
This was also well received by the stakeholders, as it keeps the ability to track detailed movement on the document level without overcomplicating the project & job layers and avoiding creating complicated rules about which states mean what based on document states. We decided to go with that, accepting the limitations that it brings, in favor of simplicity.

Lessons learned

We spent the majority of the time in this project in the discovery stage - with a project of this size, understanding goals, stages and potential pitfalls turned out to be very important
Drawing out the entire process diagram and then radically simplifying helped us define the “MVP” stage that still works for the majority of our users, allowing us to rapidly test our hypotheses
Looping in lots of different stakeholders helped broaden the understanding of the scope, making sure we are solving the right thing