Building vision of an AI-first Lokalise Flow

There’s a lot, so here’s a tl’dr

Product I was supposed to build out and upgrade was quite stubbornly difficult to work with due to legacy architecture and a lot of “this needs to be the way it always was because big customers need it that way” type of challenges. I figured my talents will be spent best if I slowly build and strategise out the legacy product, while in the background I work on a vision to start fresh and excite the company.

To build a sensible vision that everyone could follow I started with high level stakeholder alignment, first just listening to everyone’s (tech, sales, support, business) biggest pain points, and then presenting very opinionated way to fixing them - infused by my knowledge of user and design pains.

As that was done and accepted as conceivable future by senior leadership team, I workshopped with majority of stakeholders, this time having a little better defined path of what and how we’d like to achieve - short, and long term in terms of potential for user experience, growth etc. With progress being done in this space and cohesive vision was formed, a small team started working on delivery plans - business, engineering and design.

During a timeframe of below a quarter, I reset much of what we did a couple times to ensure a very strong foundation for the future. I strongly believe that in case of this new product, vision was hugely driven by design, as was building of the strong future-reaching foundation.

With leadership and board of directors buy-in, company switched to dual-product mode, and we started our work on the actual thing, instead of just conceptual work. With 70+ engineers, 4 more designers and a researcher, I’ve had a team to push this project as if tomorrow didn’t exist. Within the next year we’ve managed to build a good, strong foundation for our main vertical, while ensuring that any pivot brought on by strategic / economic / investor shifts can be accommodated.

During beta user testing a lot of what we did gets UX praise, even if UIs are still (purposefully) quite spartan. Underlying system logic makes sense for most of the users, onboarding we built ensures that hands-off PLG approach is attainable, and the simple UI can be destroyed and rebuilt quickly enough to react to user feedback.

Now, if you’d like all of that but in a much longer form, I invite you to the rest of the article.

How it started

Legacy architecture was blocking rapid development of app used for developing, maintaining and serving translation by varied group of users with different sets of goals. While we knew their pain points it was nearly impossible to cater to them due to technical limitations. With AI looming on the horizon, I felt that threat of being left behind is just too great so I created a side project to make the next generation of Lokalise. After initial high-level conversations with some of the leaders and a bit of creative work, I was able to put my foot in the door of next generation Lokalise.

What we were/are trying to achieve

By combining power of emerging technologies around LLM and neural networks with deep industry knowledge, we were aiming to solve multiple problems in one light package - to get high quality contextual translations fast at a good price, while remaining a powerful tool for professionals to take care of their brands in detail.

User experience that’s B2C and B2B in one package

UX-wise, we are working on an app that scales from “I only see the invoice, the rest just works” to one that allows professionals granular control over translation outputs. Simple and accessible UI, almost B2C lightness to it to decrease cognitive load on casual users, that provides enough clarity for end-goal that translations professionals don’t need to wonder where are their settings/tools.

Business that scales from sales-led enterprise grade to PLG approach

From business perspective our goal is to broaden our ICP to non-professional translators who want to enter new markets, while not alienating our current customers by giving them tools they require for absolute output control. The end goal changed a couple times, but ultimately we’re headed in that direction still.

How it went / is going

It’s always interesting to build a greenfield project, building one with already established knowledge is like building a super cool Lego set but you also have entire manual in your head already. There’s a huge amount of information you can already rely on, from all around the organisation - CSMs, Sales, Support, Product, Founders, and then there’s TONS of metrics and data you probably already understand. So it’s a clean slate, and you can build something that fixes all the woes of the current product. Or at least that’s the theory.

First, align stakeholders to ensure common direction

Continuing with the Lego analogy, imagine you want to start building that amazing set, but you have a lot of people around who also want to build it. They also love Lego. At the same time, their idea of how it should be is oh so slightly different. I strongly believe at that point everything you know as a product designer, leader and combination of both is absolutely insanely crucial. Psychology, usability foundations, stakeholder management, glue-ing business, engineering with user benefit, agile feature build-up, user delight and many others seemingly clashing priorities are there to be taken care of, and from my experience, it’s product design that has the best chance of doing that. Keeping that in mind, having workshops led by design in the first stages of the project, actually allowed us to form common direction rather quickly. That also formed all of the important problem-solving hypothesis right at the beginning, as all of they voices were truly heard in an unbiased way. From support, through marketing, finishing with sales, we heard what people wanted, and how they wanted it. All of that deep background knowledge coming from so many sources lays incredible foundation to not only form real information driven hypothesis to solve user problems, but also allows you to be very nimble down the lane, extrapolating on that knowledge and using it along your gut feelings.

Psychology, usability foundations, stakeholder management, glue-ing business, engineering with user benefit, agile feature build-up, user delight are what pushed workshops led by design in the first stages of the project, allowing us to form common direction quickly.

Hit reset as many times as you have to, but be quick about it

It’s not only making sure pieces come together, as a person responsible for product usability you’re setting foundation that will be there for a very crucial period: product validation, and looking for product market fit. Because of that it needs to be ready for constant and brutal pivots, while also ensuring users are comfortable using it, so we’re not missing out on potential growth due to subpar experience held by duct tape. That means when building your first visions along with other stakeholders, don’t be afraid to say things like..

Hey, this makes absolutely zero sense. It’s the same what we have, but with different name. It doesn’t solve our users problems. It doesn’t resonate with business problems. It doesn’t spark joy.

At the same time, don’t take too much time with saying we need to reset - having endless discussions without very good reasons are burning time you should use to build product that verifies reality. It’s a wild west where your experience really matters, as you cannot validate live with customers that quickly. Obviously there’s a ton of information I mentioned before, but when actually building the product, it’s all assumptions for problem fixes until verified. During the first quarter of the project we hit reset at least 4 times. It’s difficult, and sometimes painful when some things are already built to accommodate certain way of thinking, but ultimately necessary for increased chances of success in the long run.

We’ve reset this project 4 times. Between just “hey we can make it way better knowing what we know now” and “we’re looking at a different ICP now” to “company strategy needs to be adjusted to market realities”, being nimble and flexible, even in your mind, is key. Getting too attached to something that is dear to you will drain you very quickly, so you need to truly care to be able to drive impact and change, while having mind flexibility to cut anything that doesn’t make sense.

Experience being driven by a gut feeling is as sure as anything

Data is key. User feedback is indispensable. Metrics are king. Stakeholder opinions are very important. Measuring what you build is an absolute necessity. All of that is also impossible to get when iterating through product design vision that has no tangibles in the real world, but rather only assumptions that are created to solve for problems everyone and their grandmothers have different viewpoints on. I mentioned Sales, Support and CSMs in this article already a couple of times, but in this instance it’s especially important - they will all mention different sets of problems to you, all of them important, and only some of them will converge. Then still, that convergence won’t be ideal, as expectations to solutions will also vary greatly. Put business and engineering on top of that, and it’s a maze that literally cannot be solved in a problem that doesn’t exist when you’re trying to be superbly scientific. Trust in instincts of people with great experience.

Even if there’s problem convergence between groups like engineering, business, sales, support and others like marketing their vision of solution are often so vastly different it might as well be a different problem set. That’s where gut feelings and divergent thinking comes into play - those are things often dismissed by within our data-oriented communities, but ultimately quick data would probably tell you to get faster horses instead of building a car, while if you waited for true research data every time you unravel some sort of big bang type of information, someone else would already build it.

Reset doesn’t necessarily mean pivot, and that also happens a lot

Finding product-market-fit quickly is like a holy grail of the industry, and as it usually is with holy grails - not many get there, let alone quickly. As we’ve been learning about our potential market, how will it react to a new product offering while we keep the classic one around, and what can we actually physically build to scale immediately, our approach started shifting from having a new version of the classic, to having something addressing totally different market, to having a mix of the two, again to different market and finally back to maybe working as part of the bigger, classic product. All of that cannot mean a project reset - that’s exactly why foundations built in the beginning when resetting is essentially free is so important. That’s also where that entire approach for design being 1:100 cost of engineering comes into play, hard. There’s very little to loose beyond time pushing grey box pixels with a team of 3 people as compared to 60 engineers creating backend logic for something that never made any sense from the onset, but you didn’t actually have time or foresight to reset. Being ready to pivot means foundations have been strong and well understood, so that as long as you’re in the same industry horizontal you can reshuffle, dust off, and move on.

We pivoted 3 times during since the beginning of the project, changing strategy, shifting focus, and having major company restructure. It means pain, but it’s also how you find best niche for PMF that will deliver results you were hoping to achieve when you set out on the journey. At the same time, if your approach was divergent enough, the system you built should be ready for such opportunities without insane retooling.

Key learnings

1. With a greenfield product coming from well-established market leader, using that deep understanding of market horizontal is absolutely key for rapid growth. From conversations with CSMs, through input from sales, user feedback, concluding with product metrics you can fairly clearly understand what needs to be done first, what needs to be done last, and how.
2. Create vision around fixing of current issues with time to value, activation rates, retention woes, user feedback that’s constructive to make the next step, use creativity and intuition on top of that for a leap.
3. Constant, consistent alignment between Product, Engineering and Design is absolutely and insanely crucial for success, especially in highly chaotic, constantly shifting environment.
4. Having a common vision provided by design and long-term goals that design and product collaborate on with engineering allow for coherent UX, as even when teams are working “beside each other” they all go in one direction.
5. Obsessing over design output quality or building support systems (like full design system) is not having usual return on investment, quick iterations with proper metric/research coverage are key, however they are in initial phases. Build, destroy, rebuild better.
6. User data is scarce and limited so working with a lot of intuition is key to rapid growth, getting analysis paralysis with insufficient metrics is quite tempting, especially in heavily scientific UX, but using vision documents as counterweight is extremely useful in those cases.

Learn more by reading, in excruciating detail, how did we build onboarding for Lokalise Flow