Estelle Landry - Comment perdre sa surcharge featurale ? (FR)

[00:00:15] So, well, thank you, thank you again for your introduction, Sébastien. And I also thank all the participants for coming on a Friday evening of lockdown, to spend some time with me. to talk about feature overload. So you've understood, it's not a technical talk. It's really a talk that will talk about the product, but which is as much for developers, for all the R&D team, for the PO, for the UI designer. It's really something that can be shared with the whole team, but suddenly, I don't know if some people have misread between the lines. But I will not talk about overweight, that's it. I made a little joke, I'm sorry. Uh, but on that, we'll be able to start.
[00:01:02] Before going a little further in the conference, I will introduce myself very quickly. My name is Estelle Landry, so product owner at Pix, a state startup in the digital field, uh we create a platform to test ourselves, to test our digital skills. Uh so if you don't know it, I invite you to go there and go test yourself. Uh I am on Twitter uh at the handle uh Estel Landry, so don't hesitate uh to follow me, I will share the slides uh on Twitter. Uh I am part of the Duchesses. So what is this group? It's an association that tries to promote women in tech. Whether you are a man or a woman, you can uh uh take part in it and help us, uh, with little things, mentoring or sponsoring young people.
[00:01:48] Or simply go give uh uh uh conferences in colleges and high schools, so that's a bit our goal.
[00:01:56] And also in my spare time, when I have some left, I am uh on the organizing team of Sonitech. So like for La Flocon, a conference, well I hope not online, even if it's in June 2021, I hope it won't be online. And it's in Montpellier. That's it for the presentations. Uh, we're going to be able to start uh in the heart of the matter, but first, I'm going to tell you a little story.
[00:02:20] Yes, yes, I'm going to tell you a little story. Uh there was once a young developer who discovered IT and especially the world of development. She developed, developed, developed all night, and she was super happy. She spent her time on it, she found a great mission and uh she loved developing with her colleagues on uh hyper varied functional domains. Uh she sometimes had a lot of people who came to ask her questions about her work, uh they often told her, oh, listen, it would be good if you did that like that, don't you think? It would be interesting, huh? So our developer, she often didn't know how to answer. Uh she also had other people who arrived and said, hey, listen, I heard you say that certain users would like that. So our developer, always the same, she didn't know how to answer. We kept asking her questions, and sometimes even more difficult questions. Listen, to validate this big big prospect, I absolutely need this feature. Well, our developer, she was, she was really, really stressed by all that, all that was happening to her. Uh, well, she tried to do her best, to add functionalities as she could, uh she also had comments like, but why did you do that like that? Well, there she took even more questions, more questions. And sometimes they even told her, listen, your button there, you made it too big and too blue.
[00:03:47] She, sometimes she ran out of breath, she was quite stressed. Well, she did her best. Until the day when finally she saw arrive, you know this feature, you see it and you know it's the too much feature. You know this feature that looks enormous. Uh and you imagine adding it to an over-inflated program, to a huge application. So our developer, she saw that, she said, okay. So let's be uh let's be down to earth, I'm going to try to look in my data model to see where I could add these new concepts. Okay. Even putting on glasses, it was difficult for her to say, okay, uh where am I going to add that in my database, uh it's enormous, I can't see anything anymore. I hope that, well, I don't know about you, but I've already experienced that. Uh so our developer, stunned, said, okay, well, maybe I'll ask for help. Uh I'll maybe also look at the UI side, how it's going to happen.
[00:04:48] And then, UI side, uh yeah, it was uh ah, it didn't work out too well. I bet you missed a super, a super GIF. Well, it doesn't seem to activate. Ah, yes, it's good. Uh so our developer says to herself in her application, but where am I going to be able to add this functionality in these 80-something navigation bars, in all these blinking elements, my God, how is that going to happen?
[00:05:20] So you understood, our protagonist was at the bottom of the hole, she didn't know where to start and she said to herself, okay, I'm going to go see my beloved project manager. who always has solutions, I'm sure he's going to revolutionize the world for me and find the right solution to my problem. And the project manager tells her, but listen, why don't you do rewriting, refactoring.
[00:05:45] I don't know about you, but I, when I did that myself in my past developer career, it never really worked. Or maybe I was just really bad, huh? Anyway, I'll say that. Uh so there, our developer, she says, okay, I'm going to follow what my project manager told me. Imagine her, she's super worried, but her project manager tells her, listen, rewriting. It's really going to help you to see things clearer, to remove the things that are not going well, etcetera, etcetera. Well, she did that, but our developer, unfortunately, she couldn't, she corrected a lot of things, but it didn't correct the problem that there were always problems everywhere and that she had trouble finding her way. So she went back to see her project manager, who told her, listen. Now, we're going to start something that almost no one has ever done in this company. We're going to manage our technical debt. You know this magnificent fashionable term, uh and suddenly our our our young developer says to herself, okay, well, I'm going to follow the advice of my project manager. I'm going to try to update the frameworks, improve my architecture, review some elements of my domain, improve certain performance, etcetera. But our heroine, she quickly realized that she still had this monstrous complexity that kept growing and growing. She asked herself the question why. She searched and she realized in fact that there was not only one complexity, but several complexities.
[00:07:11] She realized that there was an accidental complexity, the one we create by adding code. And there was also this essential complexity. You know this complexity that is not related to the code, it is the one that is related to the problem that the software is solving. That is to say that it is simply linked to the complexity of the business problem. The more complex the business problem is, the more complex the tool will be.
[00:07:35] Besides, if you if you are very interested in this topic, there is a great article by Arnaud Lemaire, uh so I advise you to go see it, I will share it in my slides. So, faced with that, faced with this new definition, our protagonist said to herself, okay, so if I understand correctly, me, uh while I was trying to solve my accidental complexity.
[00:07:58] Well, my essential complexity, it kept increasing. Uh okay, so she said to herself, uh maybe some people have already encountered this problem, this problem, did it have a name? She searched, she searched, and she found nothing. So she said to herself, well, okay, I'm going to call it functional overload. Well, she didn't find a definition, so she made one up, she said, well, what is overload? It's an additional load to the normal, feature-wise, of a function or of functions implemented in my system.
[00:08:28] which allows the user to do something. Okay, so faced with this problem, uh which was very little documented, our developer was a bit lost, she said to herself, what am I going to do? Well, first solution, I'm going to remove functionalities. That's it. There are too many functionalities, what do I do? I remove some. But beware, she told herself that she was not going to delete just any one. She was going to try to remove the functionalities that either have zero usage or a very small amount, but these functionalities that are also very difficult to maintain.
[00:09:01] And she tried to do that, to untangle a bit all this package, all this bag of knots, and she said to herself, okay.
[00:09:09] Even if I do that, finally I realize that adding features is quite fast, whereas removing them, to untie my bag of knots and remove my feature, it's still very complex. It takes time. In addition, you know very well, when a functionality is implemented in our SI, in our application, there are a lot of functionalities everywhere, depending on our architecture, etcetera. This can be very complicated to remove, same for the user side, how to do it? Do we need to communicate to all users or simply to users who still had some use for this functionality? In short, there were a lot of questions she was asking herself and it was taking time. And then, in addition, I let you imagine our developer in front of a meeting with uh big bosses, as we call them, saying, well, listen, I'm very proud of myself, I managed to delete three functionalities this month.
[00:09:58] I'll let you imagine the room and the looks she must have gotten, saying, but why is she happy, that one, already?
[00:10:07] In short, that's where our hero said, well, that's it, I can't do anything anymore, I'm going to, I'm really going to throw in the towel, uh and so I'm going to give up, that's it, too bad. And it's always there where you know, it's like in Disney where uh where the heroes are very sad, but they still manage to find a little idea. That is to say that, as if by chance, our protagonist, she continued to read articles, she said to herself, ah, but there is perhaps another solution. The solution is maybe to let my application die and start another one. Because she read the story of Fogbus. I don't know if you know Fogbus, if you have any ideas in the chat, don't hesitate to put them. In fact, what our developer learned is that she learned that Fogbus, which was an old tool that had been around for years, which was, therefore, on aging technologies, uh it was a tool that allowed to manage ticketing, so you see it quickly, uh there were files, lots of tickets with statuses, etcetera.
[00:11:07] It wasn't very attractive, they had trouble maintaining it, and they said, okay, that's it, we're going to drop it. But that's where our main character had a glimmer of hope, that is to say that Fogbus, they didn't stop there. They said, okay, we're going to redo a product, but we're going to try to listen to our users right now and take into account the new user needs they would have now, this present moment, instead of going back to the initial needs we had with Fogbus. And that's where they created Trello. So Trello, a solution that you know, which is extremely used. And uh and indeed, they did well because uh they gave up, by abandoning a solution, they managed to create something even better and uh and which is really something that has revolutionized a little bit our to-do list. Okay. So finally, our heroine, she says to herself that this moral, finally the moral of everything she experienced, is that well, life is a virtuous circle and that finally, all things have an end and that it's a perpetual renewal.
[00:12:13] Okay. Well, our story is over now. Uh so imagine a developer, she wanted to add features, she had a feature to add, she said, okay, and the moral of this story is, we drop our app and we redo one. I don't know about you, but I say no. I don't really like this ending. Because uh it makes me think, you know, about the end of Dexter, for those who know the series, where when you watch the last season, you say, oh, it's a bit, it's not, it's not great. By the way, I don't know if you know, but for Dexter, they're going to redo an ending, uh, there you go. Uh for Dexter fans. But even I have the same feeling, that is to say that I don't want, I don't want my story's end to be to let my application die after X years, if it turns out that the application has only been born for two or three years, there is still value to bring to our users, we haven't tried everything.
[00:12:57] So there, I, Estel Landry, when I saw this story, uh I tried to keep it in mind and especially at some point, I saw a documentary on France 5. Which uh was called Hyperconnected: The Brain Overloaded. There, we are explained that uh smartphones, computers, tablets, connected game consoles, connected watches, connected scales, connected fridge soon, uh all that makes us connected to the world continuously. And in this in this show, it was said that all these connected tools, well, they ultimately increase productivity at work, huh, it increases a lot of things, it's great. But there are also studies that showed that uh this overabundance of digital technology, it invades us as humans, it invades our existences and it leads us to even decrease our cognitive capacities, or even put us in overload, or even put our brain into overload. because of all these notifications. And uh in this documentary, they explore a lot of solutions to avoid that. Uh based a little bit on uh well how, in short, to try to manage a kind of burnout. And that's where I said to myself, okay, if our brain can be in overload, why not our application? Are the solutions that we use on humans and on the overload of our human brain, can they not be transposed to our application?
[00:14:21] You'll surely tell me, Estelle, what did you take to have this idea? No, no, really, I really believed in that. And I said to myself, uh following this documentary, that could be an idea. Why not apply what we apply to ourselves as humans, to applications or to project management? Okay. Well, listen, I went to consult the best in the field of psychology.
[00:14:43] Uh so of course, psychology magazine, uh there you go. No, I'm kidding. Uh I went uh I went to consult a lot of books, articles about burnout. I watched this show again and again. And uh I've taken out a little bit of the four rules to use in case of burnout or application burnout. We'll see. The first, big suspense, we are told, it is necessary to erase everything. and start from a blank page. That is to say that you have to make a void in your life and you have to make a list of everything you have uh put in place in your life, so your work, your commitments, your objectives, your groups, your hobbies, your meetings, all that, all that. And uh you're going to try to see what takes up your mental energy and you're going to remove those that ultimately don't correspond to your vision of life, to your to your life, to what you want to do with yourself, to your goal finally.
[00:15:39] I said to myself, okay, I'll take that, I'll transpose it to the application side.
[00:15:45] What does that give? Well, in fact, often when we have a question to define the product vision, we often think of Simon Sinek and especially of the fundamental question of why this person, this organization is more innovative, more influential, more profitable than another. Why is one product better than another, in terms of loyalty, uh, well, for example. And uh Simon, he saw that there were people like Martin Luther King, Steve Jobs, the Wright brothers, who had little in common, but they all started with the question why. In fact, they realized that people don't really buy a product uh as long as they haven't understood why this product exists. What will it bring them?
[00:16:31] That's why Simon, what he says is that before starting a product, and especially to define the goal of the product, so like our goal of our life. It's starting with why, the start with why. It shows in fact that leaders act and communicate all in the same way, that is to say that Simon will call it the golden circle. That is to say the golden circle, for him, this framework, that allows to build products that are guided by the why and thus especially that people can be uh well will will love, will be inspired. So what happens is that at the very beginning we start with the why, the why. That means describing a little bit the mission, the cause, the belief of a company or a product. We're not going to talk about money in the in the why, but we're just going to try to ask ourselves the question why does this product exist? Why does the company exist? What does it bring? Then, we're going to try, once we've defined that, to move on to the how, that is to say, all the actions, the values taken to fuel our why. Uh that is to say the process to reach what, okay, what does that mean Estelle? No, it's simply what allows companies to distinguish themselves from the competition, from each other, while respecting of course, ethics and the strong culture of the company and which will promote innovation. Once we have these two blocks, once we have answered these two questions, what we are going to do is that we are going to try to describe the activities of the company uh in the what of and especially we are going to try to describe the services that will be rendered by the product to our user. We go into the what. Okay.
[00:18:06] Uh so if I want to apply that, if I want to try to extract the why for my for my for my company or for my my service, for my application, uh there are quick techniques that exist, if you want to test them. There is the fact of being able to complete a try to complete this sentence.
[00:18:22] Uh it's what's called the value proposition. Uh our product uh helps users uh to do that by providing that. Okay.
[00:18:34] Uh there are also other ways, there is the Business Canvas or what we also call, we can also find it under another form called the NABIC, the Needs Benefit Approach Competition. What that allows is finally to find our why and to define our goal, so our objective. Now that we have defined the why, that is to say our objective, our proposition value, we are going to try to move on to the how, that is to say all the actions, all that would allow us to explain our why, all that could distinguish us from the competition. Okay. For that, I tried a very nice workshop called the Cover Story. I don't know if you know it. Uh in my old company, we were lacking a why, we were doing a tool that seemed good to us and then we didn't really know where we were going. It was at that moment that the Cover Story, I created the Cover Story with them. So it's an activity that allows to define where our society or our product will be in 5 years. Why will newspapers talk about us and our product? why, that is to say our objective, our value proposition, we're going to try to move on to the how, that is to say, all the actions, everything that would allow us to explain our why, everything that could distinguish us from the competition. Okay. For that, I tried a very nice workshop called the cover story workshop. I don't know if you know it. In my previous company, we were missing a 'why', we were making a tool that seemed good to us and then we didn't really know where we were going. It was then that I realized the cover story with them. So it's an activity that allows defining where our company or our product will be in 5 years. Why the newspapers will talk about us and our product. It's an activity that is ultra creative, I admit it, you have to have a bit of creativity, it allows people to dream of the potential success of the company, it allows us to come back to what will differentiate our product, what will why are we going to talk about our product? And for that, we're actually going to try to define, to define together, excuse me, it's the weekend soon. It allows us to define together, we're going to define together, excuse me, the cover, uh, the headers of the subject, uh, the quotes, uh, the images, uh, that will appear in the article, uh, the, well, you know, the parts, the sub-paragraphs, etc. And so I did that in a very collaborative way with a few people from the company, so we put up all our post-its, we agglomerated all our ideas, and we came out with a kind of journal, with a cover, with big headlines, with all the words that were recited around the product. And in fact, it did us good, it's something that we, we have printed well in our premises, it did us good because every time we were going to add a functionality or other, we knew if it was going to go in the direction of our company in 5 years. So that's it, we have defined the why, the how, and now let's move on to the what. The what often is what, uh, it's, it's finally what the product, what we're going to try to bring to the user. Okay, there I played a bit of a crazy game all by myself. I told myself, okay, to better understand its users, we create personas. I think you all know personas, they are objectives, they are methods that allow to put a human face on target users. And there I told myself, well, listen, why not define an applicative persona of our product, in order to finally list the what, that is to say, list the actions we are going to perform in this product. that would correspond to the why and the how. And I had fun, I did this all by myself, really, I took a bit of the classic persona blocks, that is to say, a bit of the story of our persona, the goals, why users will use it, I tried to describe a bit the brakes and fears of the tool, and I built, therefore, Terra l'octopus, which was the persona of my former company, or rather the product of my former company. And what was quite interesting is that by doing that, I also put it, of course, in the Open Space. And what's interesting is that every time we had a new user need expressed or a new business request or whatever, we would look at it and ask ourselves, okay, does it really fit the Terra universe? Does this functionality really correspond to what we listed, to our goals, uh, does it not reinforce the fears that we have concerning our tool? So that's it, these were the first, let's say the methods, the first methods we used to define, from a blank page, to build a bit our goal, our objective.
[00:22:40] Then, I turned the pages, I read in my books, and it is often said that once we have the blank page, we will try to simply add the activities that we like to do, but that we really like to do. That is to say, those that are very priority. compared to our tool, not just any. So for that, I told myself, well, finally there's something that really exists in our product, R&D, development team. it's the card, that is to say that every time we have a new sprint, that is to say, new functionalities that arrive, we try to put them in common and to prioritize which ones we are going to add or not. So there in our new Terra tool, what we did is we really did the card sorting, the card sorting. Moreover, I don't know if you know it, it's the card sorting was created at the beginning for cognitive psychology. And it was used in 1946. Sorry, I'm currently reading the bit from Wikipedia that I listed, but it was created in 1946 to identify cognitive disorders. As if, I told you, humans and applications can be very linked. Uh, I'm coming back to my card sorting. What we do with a card sorting is that the principle is to know how to sort, classify, group, name the functionalities. in order to really understand the user's need. So that is to say that you can do it as much with your user, you can do it as much with your team product. It's up to you. For those who don't know quickly, you try to list all the functionalities you can think of. So in this case, I created, you create as many post-its as you have, as you have, as you have ideas, sorry. Either you do an open card sort, that is to say we have all the cards and we are going to try to group them together as we wish and we are going to give a name to this grouping later, or you decide to do a closed card sort. And there you define the names of the groups beforehand, and you just place the cards in the groups. What it allows to do, it allows above all to see if these cards that you add as you go along, these post-its, well, it corresponds well to each of your groups. You can prioritize them, you can delete those that have nothing to do with it, especially that. To avoid things like that, with stuff all over the place, in short. And above all, after a card sorting, you can do a dot voting, that is to say that you give the whole table four points per person and you ask them to prioritize, to put these four points on the functionalities that you absolutely want to do. And these are these functionalities that will go into your backlog and into your sprint, uh, and these are the ones on which you will spend time. And you have to do this card sort very often to be sure that we are going in the right direction throughout the design of the product. Okay. I also have another idea. That is to say that I read that, okay, you did everything you could, like Estelle, your burnout, you managed your parts of your blank page, you added what you could add. But often, there are lost causes, and yes, imagine me, Estelle burnout, sometimes we can need the help of a specialist, an expert, a psychologist, to help us because well, it may require a bigger, bigger job. You see what I mean. Well, in our situation, having a psychologist with us to help us with card sorting, no thanks. However, having a UX designer or someone who tries to represent a little bit the UX philosophy in our team, it can be a good idea. That is to say that the UX designer, his utility is to make sure that the functionalities we add correspond well to the user's need and are well added so that the tool is usable. Okay. So we'll say that our UX designers are our tool. And that finally the UX designer workshops are a bit like therapy sessions. No, I'm going too far, I agree, I'm going too far. Brief, let's get back to it. UX designers, we're going to say they're full of techniques to try to understand when our tool is going wrong, if users can't find their way, if they can't understand your HMI, your UI, it means there's a problem. So his job will be to offer you techniques to help you prune or return or simply add the right features at the right time for the right users. Okay.
[00:26:43] So what I'm going to try to propose to you now is that I'm going to try to show you three user workshops that I myself have realized, and that will allow you in fact to know very quickly if you are in the right if your user understands if your screens are readable. uh, to see a bit what the user feels by taking your tool in hand, is it fast, does he manage to get by alone and above all to see if he manages to do, well, classic use cases. And for that, I'm going to present to you three workshops, so the 5-second test, sentence completion and the UTT, so the UUT, sorry, unmoderated user test. I made a small mistake in the slide. The first one is the 5-second test. So, it's very simple. 5-second test, it's a method that allows to collect the first impression of users really from the first seconds. That is to say, we're going to show a screen, then poof, we're going to hide the screen after 5 seconds and we're going to ask our users to redraw the screen on a piece of paper. So yes, it seems strange, but we're going to do that after 5 seconds, we're going to ask them to draw, then we're going to show the screen again for 10 seconds this time. Bang, we're going to hide it and we're going to ask our participants to redraw the screen, and then we're going to do it a third time with 15 seconds. The goal of this workshop is to know the impressions of your user on the screen. to see if the user has understood the objective and the use of the screen, and to know what he thinks of the overall aesthetic as well. If he manages to find the interface elements. It will allow you to show you, therefore, and to avoid that we find ourselves on the example that I showed you earlier, of this incredible site where we had stuff everywhere. So I did it with a friend of mine, a colleague of mine, on a tool that was a tool, one of our competitors. And we were developing a page that was a page for creating advertising campaigns, to tell you everything. And I decided to do this workshop on the same page of our competitor. So I showed him the screen for 5 seconds. I hid it and I told him, go ahead, try to draw. So there quickly, hop hop hop. You saw, he managed to find the functional groupings of the screen. The functional grouping of the navigation bar at the top, the blocks a bit where he put percentages, well, he thinks it's a dashboard and a table. That's the first thing to see after 5 seconds, if you don't have it, there's a problem, that is to say that the user must, at a glance, be able to find the functional groupings of the screen. If that's not the case, there might be a problem. Or if it's not clear to him, if it's very blurry, it's maybe a problem. I'll come back to that later. Then, I did it with 10 seconds. And there you saw, a small 'new line' button was added and he completed the table a bit, he completed his dashboard a bit, even the navigation bar, he knew there was a logo. So at the end of 10 seconds, normally it's at this moment that we are supposed to try to start taking aesthetic bits of the screen, and we are especially supposed to have the primary buttons. You know, these primary actions that we put forward, creation, deletion, well, that's normally what you must absolutely have after 10 seconds. If you don't have it, still the same, it may mean that you didn't put it forward well, not in the right solution, not in the right way. And if there are too many, the user will perhaps not go up the most important ones, so he will go up a lot of them, he will make you a lot of diagrams. But above all, you have to know that a screen has a well-defined use with a well-defined primary action button, one or two, but that's it. And again, I redid the test again for 15 seconds, and there we really enter into a slightly more detailed screen where my colleague found the elements a bit, I asked him to add colors to have the aesthetic, so the green, the red, he even found in addition all the navigation system, even the sub-navigation system, he even added secondary buttons, secondary functionalities, as in the table, well, he had done it earlier after 10 seconds, but he added the search field, the filter field, he saw that there were possible actions on each box, in short, he went into detail and at that moment when I asked what the screen was for, he knew exactly how to tell me its use. So that's for the first, the first example, that is to say that with this workshop, you have a quick way to know if your screen is understood or not by your users. Of course, you have to be careful, you have to invite people who fit into your initial persona, and you also have to, that's something you have to be very careful about, take screens that are quite explicit as a base and that are a bit the heart of your application. If you see that there are too many things, that the buttons were not found in time, that the graphic design was not understood, that the functional grouping is a bit messy, what I propose there is to start from scratch or to try to go back to basics and to put on your screen the rule number one and what seems most important to you, what seems to correspond to your objective, to the objective of your product. Second method, uh, it's the user test and uh it makes me laugh a lot because uh I really like uh Commi Script who says that in fact the user test is a bit the ultimate goal to know if a user will crash your application or not. So you know that very well, it's the main thing, that is to say that as soon as you have a prototype or as soon as you have pushed a version to prod. The best way is to put, like Commiscrip, a lady in front of the PC or a gentleman and ask him to use it. Well, you see the person, the lady, she's struggling a bit, upload, what does that mean? Why can't I close it? It's buggy, well, it doesn't work, well, it crashed. And in the end we realize at the last moment that we will have to redo all the UX or even a little more. We don't want that. So what we want to do is we're going to try to set up UTs, I was telling you about, so user tests. And for that, you can do UTs that are, therefore, unmoderated, that is to say that you have no control over them at all. So you give a brief to your user. You tell him, well, create your account, with such and such information. Go look for the product that interests you, that's called that. Go add it and go make the payment. And above all, it's the moment when you stand behind him in shadowing or if you are remotely, you take a capture or a video of the person's screen. And you try to study as finely as possible the movement of the mouse, you try to ask your user to describe what he does, to speak aloud, to think aloud and to ask all the questions he has. Attention, the goal is not to help him at all, to let him do it completely. And that's where you'll realize if your tool is usable or not, and if even despite your brief, even if you make a detailed brief, he can't manage it, there's a problem. And I would even add that even if he gets by and even if it's something that remains a success, you can then go into detail with the mouse movement to see what, what we saw quickly. You can also time the detail of the session to see on average how long it takes to just put an item and buy it. These are super indicators. And to finish, just quickly, what I do after a UUT is that I do sentence completions. So, once we have done the user test part, it's often good to have a report, to have a bit of the mindset of our user. So I ask him to give me some of his phrases, like, 'Using your product is...', 'The features of your product are...', 'Your product is not suitable for doing that' or 'it's the best for doing that'. And with that, you're going to build a kind of word tree, where you'll be able to see what, what we say about your product and what, what's missing, what's irritating and see if there are elements that are repeated. And the goal is to do that as you go along, all the time at each end of the user interview. Okay, I hear some of you telling me, 'Yeah, but Estelle, it's too much work, what you're telling me.' Plus it's qualitative, that is to say, I'm going to have to process the lexical field, etc. I see you coming, because I'm like that too. In these cases, to avoid wasting time, you can do SUS, so System Usability Scale, that is to say usability scales. It's quite rapid actually, it's a questionnaire that allows to have a very quick indicator on the usability of your system. You have 10 questions, each question is rated on an indicator that goes from 1 to 5. I have the translated version if you want, in any case, I, I read it in my super book and bible that I will show you a bit if you have questions in UX method design UX. And in fact, this, this scale, it allows you, once the user has completed and has put these indicators, well, has chosen a number, it allows you to have a quotient between 0 and 100. If you are below 60, it is not acceptable, in inverted commas, we say that the UX is not satisfactory. If it's above 60 and especially 70, it means that the UX is quite well done and your user will have, will not take, excuse me, will not have any worries when he takes your tool in hand. Likewise, it's an element that you can do every time, every end of user test. It will allow you to see if there is a positive or negative evolution according to the mock-ups you had given it. I say that, I say nothing, it can be done tomorrow, from Monday, if you feel, if you wish, and if you have questions about that, don't hesitate, I will be able to answer just at the end. Last step, uh, which we mostly see in books, after an expert's help, etc., we are told above all, above all, now Estelle, when you have done these three steps. To avoid being overwhelmed, you have to, as soon as you see something that in your opinion will overwhelm you, you have to avoid it. You have to try to avoid all overload, everything that will come to take up your space and your time. Okay. So you're going to tell me at the human level it's a bit vague, it means I don't have to accept everything I have on hand, okay. Uh, it also means that I'm going to try to be vigilant. It means that every time I'm going to be offered something, I'm going to have an automatism that will say no, not for now, I don't know if I really want it. Okay, so if we start from this concept of vigilance and automation, well, on the product side. we know that nothing is better than our analytics tools, I think I'm not going to reinvent the wheel by telling you that. That is to say that you have tools like Google Analytics that allow you to have a lot of elements to know if your users are still present. stay a long time on your site, what is the average of the sessions, uh, see what are the most used functionalities. It's a very powerful tool because finally it allows you to really know if your users are happy and want to stay on your platform and if they really have added value to use your product. Uh, what also exists, is the, the maps, so how would we say that in French, the heat maps, or the heatmaps. Uh, I used Hotjar which is a very powerful tool that allows you to know based on mouse movement, even sometimes if we do tests with our eyes, to really know what the user will see the most, where he will go the most. And it allows you above all to know, well, like if I display a, a product page of the showcase site for example, where the user will stay. Will he scroll? Will he stay at the top? Or where will he click at the beginning? Uh, I admit that I had done a test with a start-up in Montpellier, we had connected it to their showcase site and we had noticed that the user never scrolled right down the site and yet, when we scrolled, we really had promos, reviews, who uses it, we had a lot of things that allowed well the completion, the purchase. And so, what we said to ourselves, and thanks to Odjar, thanks to these heat maps, we said to ourselves, okay, since the user tends to buy more when he sees who uses our application, since we are a small start-up, we are going to try to move this paragraph up a bit. And by doing that, we increased the scroll by more than 70%, well, people stayed much longer on the tool. So clearly, I recommend it to you, in any case, it's very, very powerful if you can have it.
[00:36:15] Okay. It's been more than 35 minutes that I've been boring you, that I've given you four pillars of simplification. I think it's time for the assessment. Uh, I don't know if you saw it, but finally these four good practices that we brought out, uh, I'm going to call them the four pillars of simplification. Because finally thanks to these rules that we put in place. Uh, we realized that our product, we were going to make it finally usable, we were going to avoid overload thanks to these, thanks to these pillars. Just to remind you, the first pillar, you know, was why we make our application, what are our values, we try to refocus on the objective of the product. It was really an analysis and empathy phase, we tried to understand what we wanted to do. Then in the second phase, in our second pillar, it was a bit generating ideas, prioritizing ideas, making choices in accordance with the first step, so finally we already entered into the definition, into the idea generation, so into ideation. Then we moved on to the third pillar, so there I told you, okay, you have to have the help of a UX designer to get feedback. Uh, so to be, so to do tests, so we were really on prototyping. And last pillar, so it was to avoid any future overload by remaining vigilant. So finally, by trying to have a feedback loop to finally come back and correct what we would have. I don't know if that makes you think of anything. Uh but uh these four pillars make me think a bit of design thinking. So for those who don't know design thinking, it's an approach from UX, from user experience. that says that basically, as a UX, if you want, in my life, I use it all the time to effectively drive the addition of new functionalities. Design thinking is a method that allows to create, to saturate, to really understand the user's need and that we are going to bring value and that we are sure that we have succeeded in this objective by doing tests and prototyping for example. Uh, you have design thinking in three, five or seven steps. But the principle remains the same. And I don't know if you saw it, but these five steps look finally like our four pillars of simplification that I presented earlier. All this to tell you that if you want to add a feature, you really have to see if that feature. corresponds to a user need and corresponds to the soul of your product, to your product vision. Uh, it's very important not to add anything and everything and to make sure that what we do is in the same vision and in the same line. as what we have, as what we have defined at the vision level. That's really what I want to finish on. Uh, I hope I was very clear, uh, gave you the desire to put all these methods in place and I thank you and I'm ready for questions. A big thank you to all!
[00:38:30] Thank you.

Transcript (Translated)