Design & Content Systems au service de l’hypercroissance Produit @ Mirakl

[00:00:09] For the modal button, do we put 'save' or 'confirm'? I don't know which label to choose for this parameter. On the form, do we need a save button or is it autosave? And in the APIs, what is this status called? Haven't we already asked ourselves these questions last week?
[00:00:32] And you too, have you ever found yourself in this situation, this situation where you often feel like asking yourself the same questions? Well, that's good because today we're going to talk about the solutions we've put in place at Miracle to avoid these situations in a context of hyper-growth and product redesign.
[00:00:52] My name is Anaïs Delgado, I'm a Product Design Team Lead at Miracle. I work with my team on the experience and user interfaces of our products.
[00:01:02] And I'm Maëlle Gauthier, hello everyone. I've been a Product Manager at Miracle for 2 years, and my role is to develop new solutions to meet the needs of our clients.
[00:01:12] And I'm Sabine Berland, I'm Product Content Manager at Miracle, also. Uh, product content, a discipline that may uh, speak to you. So it's everything that concerns uh, the content related to the product. So, the documentation, we think first of all, online help, but also uh, the description of the APIs, the review of these APIs, and also the interface texts.
[00:01:35] Interface. I'm blocking on the interface text, we're getting straight to the heart of the matter. So let me come back in a few words on what Miracle is and what its activity is. So Miracle is the heart of most marketplaces, so we're talking about online commerce here. So what we provide is a SaaS platform to our clients to allow them to develop online commerce. So to onboard quite easily sellers, and then uh well, we address both B2B and B2C. B2C is perhaps easier to grasp. I think you've all experienced it, these are clients like you and me who go shopping online. We have for example as clients Maison du Monde, Carrefour, Decathlon, a little bit everywhere in Europe, a little bit everywhere in the world. On the B2B side, these are professionals that we will put in touch with each other, for example, Coca-Cola or Airbus. Professionals will put online on the platform the spare parts to supply the production chains of other operators.
[00:02:38] So Miracle is the tech, of course, but not only. It's also the expertise and the ecosystem that comes with it, and we support our clients in their digital transformation. These are, therefore, thousands of daily users, all over the world, but with thousands of users, there's a big challenge, these are also millions of orders to manage daily. The platform must not crash, and it does not crash.
[00:03:05] Uh, digital transformation is really something quite uh, current. It's in full development, in full boom, I think you haven't missed it. And so, for us, it comes with challenges and strong growth. Miracle has given itself the means to achieve these ambitions, to be able to respond as much as possible to its clients and uh and to all their needs. And as a result, we've recruited a lot, a lot lately. So for my part, I joined Miracle 6 years ago. We were 70 people. It was a small startup. Everything was fine. Everything is always fine, I assure you, but today, it's more than 800 people, 800 collaborators worldwide. So in 6 years, we have experienced very, very strong growth, and as a result, there are many challenges that accompany this strong growth. So we have the challenge of onboarding all our new collaborators. They need to be able to adapt to the culture, appropriate the company culture, adapt to the company's processes, but they also need to be able to understand the product well. The product is quite complex due to its richness and flexibility. We respond to many use cases. And so, it's necessary that our consultants are able to understand the product from A to Z, that our department uh labs, the R&D, is also able to understand all the impacts and all the interactions there are between each functionality.
[00:04:35] So, we grew very fast. And indeed, we're going to show you uh, so here I was talking about all the collaborators. The idea now is to zoom in on the product team. So, the product team.
[00:04:50] Wait, sorry, I got the side wrong. Hop! There you go, the product team has also scaled enormously. Over the past three years, it has tripled. And so, uh, it has tripled and we need to be able to support uh, this growing team. We were very much in startup mode until now. Priorities were uh distributed among the teams, according to the affinities, the availabilities of each one. We continue to work in agile mode, but on the other hand, we paced ourselves on quarterly roadmaps. A bit like a service desk mode that allows to go very fast, that is to say, the one who is available uh will be able to be there to respond to uh to development needs and suddenly everyone, we were quite versatile on the product. And so we could uh, well we had a wide functional scope finally to master and acquire. It works well, it allowed us, for example, this year to, just on the first three quarters, already to release more than 170 functionalities. It's going well, it's going fast, but it's even going very fast.
[00:06:01] And yes, and sometimes it can even go a little too fast. Uh, so this uh, this very agile structure where everyone intervened uh, at every moment of the product development cycle. Uh, well, that's what allowed us to uh to grow. In fact, I'm not at all in the right direction.
[00:06:21] It's hard to click actually.
[00:06:25] There you go. It's the demo effect, I'm used to it. There you go. Uh, so actually it allowed us uh to have the successes we've had. But in fact, uh, this mode that allowed us to go fast, uh, meant that sometimes we wanted to go too fast. And uh, this structure had a few drawbacks that became more and more evident as uh more collaborators joined us and as our functional scope expanded. So to give you a few examples of our annoyances, uh, on the team side of Anaïs, in design, the main annoyance is that there was a lack of concrete and shared guidelines by everyone. In fact, it was mainly a tool problem, the design system was a bit outdated, it had technical constraints, so it was about updating it. Furthermore, uh, on the content side, so in Sabine's team, the main annoyance was that we always came to solicit the content team at the end of the line when it came to naming concepts in the application. So that means that the content writer had a very limited time to do their benchmarks, find the right feature name, the right translation, and it was in fact this impression of always being late. And finally, on my side, product and tech side, uh, well the annoyance was that uh we often changed decisions at the last minute, and it's never very pleasant. Because uh sometimes, to avoid inconsistencies, just before shipping the functionality, uh we would undo what we had done to redo it, and sometimes we would delay our go-live for small details. But in fact, uh a behavior that's not good, uh a naming that's not understandable, it's not a small detail because we can pay dearly for it once it's in prod. So, uh, all these little annoyances mean that we often found ourselves in this situation. That is, the rush. Uh, it's chaos. Who's available, please help.
[00:08:37] So, at this, at this stage, uh our challenge was to maintain our agility without it becoming chaotic. In fact, we realized that all the little pebbles we had in our shoes internally, they could bring risks externally, and we absolutely wanted to avoid them. The first risk was uh that our product would lose consistency. We are more and more working on perimeters that are more and more different. Uh if uh we come uh to sell a functionality uh to a client under a term, that we document it in a different way, that it's still different on the interface, we've lost the client. And in fact, uh, this, Sabine explained it, our software is used by hundreds of marketplaces daily, by thousands of sellers. Uh, if there's an inconsistency on, for example, importing your product catalog, managing an order, it can really impact the sellers' revenues and us indirectly. And moreover, it could potentially really increase the support costs that we could uh that we could have. So, to avoid. And the second potential risk we had identified is that, uh, well, we are many people working on many projects, but ultimately our features are not necessarily adopted, little or not adopted, because not accessible. Uh, if there are inconsistencies everywhere, and you need three pages of documentation to explain a functionality, well, it's a fail for the user experience. It costs us, and uh it's also a bit of a poisoned gift for the enablement teams. Enablement at Miracle is uh the sales and consulting teams who are uh directly with the clients to get our new functionalities adopted. So, uh, at this, at this stage, in fact, uh, it's not that we couldn't work together anymore, that wasn't the case at all. It was more that given our size, we needed to find the right structure, the right processes and especially the right tools to manage this hyper-growth and manage to speak with one single voice from the moment we sell the functionality until the user uses it.
[00:10:52] So, we started by reorganizing. Uh, so what we did is on all our different products, we came, uh, I'll let you have time for the photos, we came, in fact, to cut our products by functional domain. So an example of a functional domain, the order, the catalog, uh the setup of the platform.
[00:11:13] And we organized ourselves into squads. So a squad at Miracle is one product manager and a tech team, and uh we came to base this squad mode on the content and design teams. So as you can see on the diagram, we have about, uh, a designer and a dedicated content writer for three squads.
[00:11:35] Uh, and that means we always have the same contact person. So we switched from the agency or service desk mode that Sabine was talking about, to a one-on-one mode, and uh we really appreciate this mode. Firstly, because it allows everyone to develop a certain expertise, to go in depth into concepts, to have a bit of automation on a daily basis, but also, uh, and this really comes from agility. It's that, given that we always work with the same people together, we are able to do retrospectives on our processes, uh to uh to really develop our work routines together, and it's super appreciated. And it doesn't mean that we're actually stuck in a functional domain, it's clearly planned in our career paths that if we want to change domains, if we want to change squads, it's totally possible and everything is open.
[00:12:28] So that's for the structure, and we also came uh a little bit to rework uh our process. So, uh, we laid out uh the entire product creation process, which is rather classic, we go from discovery to delivery. And uh, and we took this process and we came to do a RACI. So I don't know if there are any here who have already done the RACI exercise. Yeah, it's never a pleasure, but uh it's really an exercise that is tedious but absolutely necessary because it really allows to have a matrix of everyone's roles and responsibilities at all stages. And for us, in a phase where we were recruiting heavily, it means that any collaborator, even from their first day, knows what is expected of him or her at what point in the product development cycle.
[00:13:22] So I'm going to talk a little bit about how our design, product and content trio works at each of these stages to make it a bit more concrete.
[00:13:32] Our first step is the discovery. So at that moment, the product manager will collect all the customer insights to define the problem we are trying to solve. And also to highlight the business value we are looking to create. And there, in general, we will do a kickoff with the design and content to uh, well, to align, uh to agree on uh the objective, what we are trying to solve. And this kickoff is also a very important moment for everyone to be able to gauge the extent of the work. So, on the design side, which screens will we touch, are there any new screens to develop? On the content side, uh, do we develop a brand new use case and we'll have to benchmark, or is it an improvement of something existing, etcetera, etcetera? So, very important phase to agree a bit on what we do and a priori plan the workload. The second step is the definition of solutions. So in general we will have several possible solutions. And there we think about user interface paths, but also API paths. So for the user interface paths, the design team will prototype different paths. And at this stage, there will always be a pass by a content writer on uh the what we call the microcopy, so all the texts of the interface. And that's pretty cool because it allows us to do user tests where we're going to test our paths, but also the understanding of the concepts. Often it's something we only had at the end of the line, we said, ah, too bad, the user doesn't understand what we want to tell him. Now it allows us to see all that well upstream.
[00:15:18] On the API paths, so that's rather the product manager and the tech team who will see them together. And we will always do a pass with the content writer to make sure that there are no spelling mistakes in the API labels, that it means something and that we don't overlap with existing concepts.
[00:15:36] So that's for, uh, that's for the definition phase. And when we are on a truly important functionality, that is to say, one that will transform uses or functionalities that we will monetize, we can at that moment also make a pass with product marketing. To make sure that we have a name that works both in sales and in the user interface. So that's also super important for the consistency of the sale until the use. We now move on to the development phase, so the tech team is ready to code what we want to do. And what was super structuring for us is to agree on a single definition of Ready for Dev. The definition of "it's ready to be developed" was initially very different from one tech team to another, from one PM to another. So we listed all that to clarify it. I'm not going to give you all of it. But what's important to know is that for it to go to dev, the mockups are finished with all the nominal and error cases. The labels, all the microcopies have been validated by the content writer, and everything is on the mockup. The developer relies on the mockup, he doesn't have several places of reference. And moreover, uh the designer will make available to the developer what we call a developer handoff, uh, so a file where there are all the paddings, the detailed behaviors, the spacings, and that's what allows us to do it, it's notably uh our new design system that Anaïs will talk about a bit later.
[00:17:13] And finally, uh, we arrive at the delivery phase, uh, the feature is coded, it can, it will soon be able to go into prod. So we have a fairly thorough quality process at Miracle, there are several code review passes, there is quality assurance, so QA. Uh, but you have to know that for all the functionalities that touch the user interface, there will systematically be a PM acceptance, but also a designer acceptance. Same, at the time of the QA and the PM acceptance.
[00:17:42] We will check each, each of the microcopies. So it's a bit like the game of 'spot the difference' to make sure there are no typos, everything is okay. At that stage, uh, for the product, we have a, uh, we have a rather thorough collaboration phase with the content team to also document the functionality. So the content writer will write it, the PM will review it, and another content writer will validate it to make sure it's done correctly. And finally, at the delivery stage, we can sometimes do in-app communications, and there again our trio works together to define the message.
[00:18:21] The visual, but also program the communication. We have a shared calendar to avoid that uh, the four squads communicate at the same time and the user is bombarded with new features to test in the application.
[00:18:36] So that's a bit of our whole process and how we work together. Well, there's a bit missing uh the arrows because of course we iterate, we do continuous improvement.
[00:18:46] But really to clarify our roles and what is expected of each one at each of these stages, that's what allowed us to work a bit more like that. That is, in rhythm and in balance. And our goal is for this hula-hoop uh to fall as little as possible.
[00:19:03] So that's for our structure, our processes. And we're going to explain a bit now the tools we've put in place to arrive at uh to synchronize a bit better at each of these stages.
[00:19:14] Well, as Maëlle said, the biggest challenge was to speak with one single voice.
[00:19:22] And for that, we started with the basics. A year ago, we launched into the redesign of all our platforms with a new design system 2.0. It had been 10 years that our old design system, it was, our product was live and our old design system was starting to become a bit outdated, the governance was getting more and more complicated to manage. And so naturally, there was a design debt and a front-end debt that were starting to accumulate, and so it was time to start again on a healthy basis to perpetuate the work of all the teams. This new design system, its goal was already to continue to allow the product to grow efficiently. While keeping uh, while bringing coherence across all our products, finding UX concepts that are similar from one platform to another. As a designer, it also allows us to focus much more on expertise and uh research, for example, high value-added tasks, and less on the craft of the mockups, no longer having to always ask ourselves the same questions about the type of component to use, the color of the buttons, etcetera. And finally, uh the biggest advantage of this new design system was to provide uh to all teams a common framework for work, so that we can work efficiently and serenely, have usage patterns and really common guidelines. to increase efficiently. While keeping, while bringing coherence to all our products, finding UX concepts that are similar from one platform to another. As a designer, it also allows us to focus much more on expertise and research, for example, high value-added tasks, and less on the craft of mock-ups. No longer having to always ask the same questions about the type of component to use, the color of the buttons, etc. And finally, the biggest advantage of this new design system was to provide all teams with a common work framework so that we can work efficiently and serenely, have usage patterns and really common guidelines.
[00:20:47] It was to make a design system, it's really teamwork. And it was really our first step of working together. The components, the guidelines, etc., they were built with, in collaboration with the product design team, obviously, but also the front-end team and Sabine's team, the content writer team. Once the machine of this new design system was launched, it allowed us to move on to our second major step, which was to put the microcopy at the heart of the user experience. So, as Sabine explained, microcopy is the text we find on the product interfaces. And at Miracle, we've always been convinced of the importance of words and the importance of UX writing, but the ownership of the subject was not always well defined. And often, it happened at the end of the design journey, and we sometimes questioned the mock-ups, the choices of components that were made upstream. So regarding ownership, it seemed obvious to us that the content team should handle the subject, but then the question arose of how to work better and more efficiently between product designers and product content. Already, what we can see is that these two professions are based on very similar expertise. The two teams have a very vast knowledge of the products, of our products, because they are completely transversal teams. And where the designer will be able to do user research, the content writer will be able to do terminology research. Where the designer will take care of ergonomics. The content writer will be able to take care of information architecture, etcetera, etcetera. So,
[00:22:31] The idea was to really reintegrate the content at each step. So here we see the famous double diamond process that you surely know. And so, to reintegrate the content at all stages of the design process.
[00:22:50] The idea is that we don't expect the designer to provide the final experience at the first iteration. It's as we go along that the experience will improve and that in the end we will have the perfect user experience. And so it seemed completely normal to us that on the content side it would be similar. Until now, we would ask the content writer for help at the end, and we would tell them, "Well, the mock-ups are ready." "Can you help me with new phrasing, etc.?" Whereas the content writer didn't really have the full context of the project, of the feature. And so it was complicated.
[00:23:33] Once we said, "it's important to reintegrate the content at all stages," we had to think about the tools we were going to use. Naturally, we turned to Figma because it was the tool, the tool used by product designers, on which we create mock-ups. And we started by creating a project template with different pages and sections, and the idea was to be able to centralize all the necessary information from the same place. We also defined our high-level nomenclature for the pages. So that each product, each team, whether product or dev, can find their way around and know the progress of the subject.
[00:24:12] Then, we had to support the content team in getting to grips with the tool. Getting started with Figma, our design system, how components work, overrides, etc. And at Miracle, we also use the slots technique.
[00:24:27] I don't know if you're familiar with that, but it's a technique that consists of creating slots in large components that we will then override with other components and that allows us to save time in iteration, to avoid having to detach components, etc. And it also allows the content writer to It also allows the content writer to modify, to edit the microcopy in a single place and for it to be reflected on all the screens of the project. So, You understood, several people working on the same project can be complicated on the same screens at the same time, it can quickly become a bit of a nightmare. And so for that, we started using
[00:25:12] Figma branches.
[00:25:29] There we go. I'm going to find it. No. Go to the. Oh, that's better. Sorry.
[00:25:44] The joys of live, of the demo effect. It's perfect.
[00:25:52] We're going to go back down this way.
[00:26:04] So. So, we started using Figma branches. And how did we use these branches? So, after the discovery phase done in a trio between PM, Design and Content Writer, as Mathilde explained,
[00:26:24] The designer will start working on wireframes or low-fidelity screens. Once he has advanced enough in his subject, the content writer will be able to create a branch in which he will start editing the microcopy. And when I say edit the microcopy, it's not just putting back S's where we forgot them or reviewing the grammatical structure. It's also about working in tandem with the designer to propose a better use of certain components. For example, adding a help text at the level of a form field that would potentially be misunderstood. Or adding a small information banner for some more complex functionalities to handle.
[00:27:09] Once he has started working on that, we do a first validation phase, always with three people. And we're going to merge the branches. And then, the designer will start, will be able to continue to iterate, to go on more hi-fi mock-ups. Again, the content writer will be able to create his branch, re-modify the content, etc. So that in the end, we merge, we make a final merge that is, in fact, a validation of the overall user experience, both the journey and the UI, but also the content of the mock-ups.
[00:27:48] So, there are several advantages to involving the content writer as early as possible in the process. First, it allows him to understand the functionality as a whole, to have all the context to work as well as possible on the functionality and on the microcopy. It allows the designer to very quickly have real content and to be able to adapt the UI accordingly by using the right components for the right content and not the other way around. And finally, well, no more fake text in the mock-ups, we directly have intelligible content that will allow us to really appropriate the functionality and the experience, and very quickly we will be able to organize test phases.
[00:28:33] Once all these things were put in place, naturally, the question of a content system, in parallel with our design system, came to us, and I'll let Sabine tell you more about it.
[00:28:47] Indeed, so you will have understood, the content is really present at all, no, wait, it is really present in the product creation process. So it is important to finally set up references. So that we can feed the collaborators and that we stop asking ourselves the kind of questions you may have seen in the introduction that Anaïs was asking us. So yes, the microcopy, for example, you may know it by the name of label or strings also in some companies. So yes, microcopy, for example, you may know it by the name of label or strings also in some companies.
[00:29:14] So before being able to centralize the content and the design. Here's the kind of situation we could find ourselves in. I'll let you get acquainted with the different modals.
[00:29:37] And in your opinion, what strikes you, what surprises you, what comes to mind?
[00:29:48] Is it something satisfying? No, I heard some no's anyway, that's good.
[00:29:56] What's wrong? What's the problem?
[00:30:01] Indeed, I hear, we have differences in color. We have red on the main action button, we have blue. We have differences in size, we have differences in wording also, so the words. When we go into detail, so even just at the title level, we see a difference in punctuation. When we go into the detail of the help text, we see that we have different terms. Here too, so terms, it's not necessarily a hyper jargon concept. It can be for example, well the difference between, if it works, changes, edits.
[00:30:29] Changes, edits, what are we talking about exactly? And ultimately, what message do we want to convey to the user here? Well, that's simple, we want to tell them that, be careful, you haven't saved your modifications, you risk losing them. Well, that's simple, we want to tell him that, be careful, you haven't saved your modifications, you risk losing them.
[00:30:44] So the message is clear, it's simple, it's unique. Simply, we have four different ways to say it there. So we could say, "Bah, it's not a big deal, the client, the user won't see it, it's on different pages each time." Yes, of course, they won't see it all at once like that, we've laid them out flat on purpose, of course. Simply, well, it also has a business impact, actually. So it has an impact on the user side, finally. Because well, when we see a red button, we still think twice before clicking on it. In this case, does it have to be red or does it have to be blue? And then on the business side, in fact, it's that Miracle's interface is 24 languages. And then on the business side, in fact, it's that Miracle's interface is 24 languages. We translated it into 24 languages.
[00:31:24] So just these four little words, these four little texts, it's already 280 euros of translation. It's not much. Okay, we're talking about four here. We have 10,000 microcopies in the interface. I'll let you do the math.
[00:31:43] So of course, the content system became necessary for us to limit these unnecessary costs for the company, and that's where, in fact, we're going to come in addition to the design system. An add-on, finally, to the design system to explain how to use such and such text, what pattern. We have patterns that are defined quite easily, we saw it previously anyway. Um, but we will be able to centralize everything in one single place and accompany each component of the design with recommendations on the content. So we come in addition to the design system because in fact what we want is to have one single source of truth. So we come in addition to the design system because in fact what we want is to have one single source of truth. That we stop asking ourselves these questions everywhere and and then well, that we have everything in one single place, that it's easy, usable also for our collaborators. A kind of single spot where everyone will find the answers to these small questions that we don't necessarily like to ask ourselves and that are recurring in general. A reference, it's practical, it puts an end to a lot of discussions very quickly in general. And it will also allow to make our content writers more autonomous, more efficient, also autonomous the designers and the product managers because well, we talk about functionalities, but all functionalities do not necessarily go through the discovery phase. We will, if we need to add a modal or complete a functionality that is already well in place. We don't necessarily need to do all the big discovery research to develop the content and yet we have to go fast and we have to do it. It remains indispensable for the customer experience. So, as a reminder, the design system, well, I think you all know more or less, you understood the principle. So, as a reminder, the design system, well, I think you all know more or less, you understood the principle. So we have a library with components that we will find in the interface.
[00:33:28] We will find the guidelines on how to use these components, what margin, what padding, what pixel, what size, etc. And the visual language, which icons, which illustrations to put in place. On the content system side, we were talking about similar skills earlier. Here we also find ourselves. On the content system side, well, finally, we will find the same thing. On the content system side, well, finally, we will find the same thing, a library with all the microcopy strings of the product and guidelines that explain how to write them.
[00:34:00] It also allows us to anticipate this kind of question that we might have had earlier, or as Mathilde explained, we have an API that is developed, and then finally in the user interface, it's something else, so for the ease of getting started with the product, it's not the ideal.
[00:34:19] It also allows us to focus on tasks with higher added value for each role, each discipline.
[00:34:29] So the theory is nice, but how does it work in practice? So I'm going to give you a little focus on Zeroheight. So Zeroheight is a system that allows you to create collections of components and norms that integrate with design systems, well, design tools, sorry. And in fact, it's on Zeroheight that we based our design system. And in fact, it's on Zeroheight that we based our design system. So quite naturally, it's in Zeroheight that we added the information about the content. So now when we arrive in Zeroheight, we have the list of our components.
[00:34:58] The way to use them in the design and a content part, how it works.
[00:35:07] I'm going to make a quick focus on the illustration actually that you have there to really make things concrete. We see that we have, well, we try to see, it's an empty page, it's the empty state.
[00:35:16] We try to see, it's an empty page, it's the empty state. The famous empty page. Nobody likes an empty page in a software product. An empty page is a fail or something doesn't happen. It's an unused product. So we don't want an empty page. The idea is to encourage the user to fill it. Sometimes the user is not to blame. The page is empty because they don't have any content yet to fill this page. For example, if we take our salesperson, they haven't created an order yet, they haven't received an order yet, it would be empty. The idea is to be able to reassure him. Don't panic, continue your normal workflow and so we'll have a small help text that will say, "Well, it will be filled as soon as you have data, everything is fine." So far so good. However, we can get empty pages because the user has not performed all the product configuration, he does not use it in its entirety. And in that case, well, in fact, I was showing you earlier the different modals. We also analyzed, on the content side, all the situations, the possible use cases of in which situation we can find ourselves on this empty page. So when we realize that the page is empty because a configuration is missing from the user. So when we realize that the page is empty because a configuration is missing from the user. The idea will be to put a small text to tell him, "Yes, it's empty for now because you haven't configured such and such a thing yet." And behind, on the design side, we complete by putting a call to action button. Configure and fill your page. The advantage of having all this information, you might say, in an empty page, well, it will ultimately increase the user's efficiency. He will avoid breaking his workflow. By going to find the consultant who sold him the product, "Yeah, it doesn't work, your page is empty." Or by going to search, I hope, from time to time, in the online help.
[00:37:00] Why doesn't it work? Or even worse, interrupt his colleague next door in his work, in his workflow, in his daily task, say, "Hey, explain to me why it's empty." No, we don't want to interrupt the user, so we give him the info he needs, when he needs it, where he needs it. No, we don't want to interrupt the user, so we give him the info he needs, when he needs it, where he needs it. In the content system, we will therefore find these editorial rules per component, grammar and typography to avoid knowing if there is a need for a question mark or not in the titles. The glossary, when we really have a big new concept to document, having it from the beginning of the product's creation, it allows us to effectively align all the teams, what we were telling you earlier, at least we speak with one single voice internally. At least we speak with one single voice internally and so the concept is anchored from the start in the minds of all collaborators. And finally, we have UX writing principles.
[00:37:47] So UX writing, well, that's typically these little tips, what do we tell the user on this empty page? UX writing is also practical because it will move us away from a problem we can have from time to time. UX writing is also practical because it will move us away from a problem we can have from time to time, that is to say that if we don't put this help text, this good practice finally of UX writing of giving a little more information and context to the user, we often tend to stack everything in a button. The famous call to action, we're going to fill it, it's going to be super huge, or we're going to want to put a maximum of it. So it works well in English, but when you translate into 24 languages. So it works well in English, but when you translate into 24 languages, you should know that there are languages that have a fairly significant expansion coefficient. Expansion coefficient is the length of the text in the target language. And so, for example, that avoids you having your design all broken because the German translator came through and it no longer fits in the box.
[00:38:42] So, I'm also talking to you a bit about translation because the idea is to go further for us too. So it's still a reflection in progress, well, it's more than a reflection because we already have good mock-ups and we're in the process of implementing it. For now, we don't have the results on this point yet. But to go further, we wanted to put all the microcopy strings, the content system library, at the disposal of our collaborators. That is to say, we looked around everywhere on the market, we didn't find any tool that met our needs. That is to say, we looked around everywhere on the market, we didn't find any tool that met our needs. So we're going to create our own CMS, that is to say a kind of, well, not a kind of, no, no, completely, a central directory with all the microcopy strings in English. So the microcopy is important for development, for example, because we will have the developer will need the key to call the text. So the microcopy is important for development, for example, because we will have the developer will need the key to call the text. But in fact, that's all he needs. Then we put the text we want, he doesn't care, as long as he has his key, it's good. So the idea is to have in this directory, the microcopy key.
[00:39:37] The value in English, and to go further, what we are currently working on, the associated translations. That way, we will allow product managers, content designers to be even more autonomous on functionalities that would not need discovery, on functionalities that are a little trickier that they will want to test, perhaps with non-English-speaking clients. So we will be able to easily retrieve the content. And so we make this directory available to all collaborators, whether technical or product.
[00:40:11] Okay. I think I've covered the tools. It works well. So I was telling you, since the beginning of the year, we've delivered more than 170 functionalities. And but it's still a lot of work.
[00:40:28] Indeed, it's a big investment that we've put in place for a year. It wasn't simple, it required time, iteration, etc., but it's really the investment that will allow us to support the growth of the product. It's really the investment that will allow us to support the growth of the product and expose them to future challenges. There has been a change management support for all teams. There has been a change management support for all teams. With a lot of communication, coaching, we also systematized the process, we documented it in different places so that we have a common reference. And obviously, it's a completely iterative approach. So regularly, we get feedback from the teams, we do retrospectives, we ask ourselves the question of whether it works and we're especially not afraid to say, "Well, maybe this little idea doesn't work, we put it back to square one and then we start on something new."
[00:41:32] That's it for us. I hope it gave you some ideas to potentially do the same thing on your side or help you with your own problems.

Transcript (Translated)