Lokalise Flow - Onboarding / Setup
97.4%
80%
How it started
Flow, or as we called in the beginning - Autopilot, was pure PLG product that was never supposed to have any form of sales driven by humans cold-calling. In that case our priority was very simple, from the very beginning - ensuring our future users immediately understand value, need to spend very little time to get to it, and fine the experience delightful. I mentioned already in the previous post about how was Lokalise Flow created that the beginnings were quite hectic, and then it never slowed down. One of the first real projects within that product, however, was onboarding and setup experience.
What we were/are trying to achieve
Our goal was to have an AI-driven product that’s ready to use within minutes, without any prior knowledge in localisation. You know, one of these magical one-button experiences where the user clicks on a big button and everything happens in the background for them. Ultimately, we were focused on short time to value, immediately understanding product value and quickly reaching the wow-moment for ensured conversion. No-code automated solution in minutes after installation, and after that the user would only see our logo on the invoice, while smoking cigar on their yacht because internationalisation brought them success they never dreamed of. So, in short, perfect PLG onboarding.
There were, however, a few interesting problems to be solved:
- To perform high quality translation, the AI requires hours not minutes. Time to value is insanely long.
- The user couldn’t see output immediately, and to make matters more complex - after the translations were generated they might not love all of them. Unclear and confusing user value.
- Leading to another challenge, as post-install changes to style guide or glossary, which are driving how translations look like, resulted in another day of waiting for AI. Reaching AHA-moment wasn’t in seconds or even minutes, it was literal days.
How it went / is going
Since setup experience was such a complex piece of user journey, it was one of the most scrutinised pieces we built to date. Before the first line of code was written and any additional designers were added to the team, I ensure to pave the way for a solid foundation by creating revisions as often as possible. By revisions I mean “I’m starting pretty much from zero, different idea this time”. Reasoning for such quick and big changes was that as I was working on system logic from user perspective, other stakeholders were performing discovery on tech, business, potential, USP etc., creating new knowledge and assumptions with every passing day we collected more data, feedback and ideas. Even though it might not sound optimal to continuously rework something that theoretically already works (and product managers were of that opinion) it has given us extremely well laid foundation for future with very little cost, apart from my sad face every time I recycled. Ever since engineering began coding, I was no longer in the mode of “crazy changes a week”, in favour of a more responsible approach that brought on iterative changes, as we could test with real users, on real use cases. It was also a time for when alignment with product went much smoother - we were able to make decisions based on more data, while in the beginning I had to make decisions much more based on experience and gut feeling, which is not favourable by majority of product stakeholders I know. Ultimately over the 1.5 years of building the product, 3 significant strategy shifts and pivots, ICP changes, etc. we made 9 versions of onboarding, 6 of which were very distant from each other from perspective of both user journey and visual design.