 Hello, my name is William. Today we will learn how GitLab provides collaboration tools to product teams that work not only with source code but also graphic assets. It is very difficult to keep track of all the iterations derived from the designs and discussions and having to switch context from tools and remember where everything is. So in this case, we don't want to go through the same pain when creating a web application to test the performance of an object recognition system in a self-driving car. The story starts with a GitLab issue. Here, Parker, the product manager, is creating an issue explaining the idea and assigning it to the designer, the one who is expected to start iterating on mock-ups along with Parker. So the product manager assigns this issue to Presley, the priority designer, and here we can see they can start a discussion around the idea and details about this on the same issue. When Presley gets notified about the issue, he goes through it and before he can start working, he realizes he needs the description of the task given as a user story. So in the same discussion, Presley opened by Parker, Presley the designer as the product manager to express his idea defining who, what, why. So everyone can work together to find the best how. Not surprisingly, they discuss, discuss, and discuss until the designer has a clearer idea in order to create a low fidelity mock-up. A cool aspect about all of this is that when the conversations start building up, everything is being stored within the GitLab issue, making it easier to keep track of all the decisions made and recap at any point in the discussion throughout the task. Well, and after all the discussion, what was the result? The PM expresses his idea as follows. As a data analyst, I want to assess the quality of the image recognition engine for a self-driving car, so I can generate risk assessment reports and suggest improvements to engineering without the need to execute Python scripts but in a friendly UI. So we have defined the problem. Good. Having all the inputs required, Presley the designer now will start working on a first iteration of the web application design. A low fidelity one, just to validate his understanding. To do that, Presley uses Figma and its GitLab plugin. From here, he can create designs and quickly upload them directly to the GitLab issue, avoiding this way to manually export the file or share it via links over email. Once the low fidelity design is on GitLab, Presley can select specific parts of it and start a conversation with Parker, the product manager. He can tag Parker and bring his attention to this specific part or component, for example. Parker, the product manager gets notified and after reading the comments on the design and taking a look at it, he's satisfied with Presley's understanding. So he gives the go to him to move on onto a more elaborate design. So Presley, back in Figma, creates a second version of the design. And once again, thanks to Figma, GitLab integration, uploads it to the issue in just two clicks. Here in GitLab, in the design management section, we can see the components coming from Figma are under version control. And we are working with the latest version. Presley opens the design and again selecting a specific areas of it, starts a new thread with Parker to get further feedback and keep rolling iterations. We can all imagine the collaboration and discussion is rich. And lots of changes can be expected. All the back and forth conversations and designs versions are being stored in GitLab, serving as a single source of truth. All right, after a new round of fruitful discussions and design changes, product manager and product designer are satisfied with the common understanding they have of how to solve the problem. Without understanding, Parker is ready to involve into the conversation the developer who will make the first prototype, Tagging William, in the issue discussion. Now in the issue, we can see the whole team that is collaborating and will be working under the same context. The developer joins the conversation. He can quickly read the latest messages in the discussion and get an idea of the why, what and who he will be developing for. In addition, he gets the latest version of the design he will be coding. All right, time job here. Let's assume he worked very hard and now he is ready to create a merge request with an initial code for this prototype of the self-driving car of the recognition app. Okay, so I am William. I commit to GitLab the initial code from this prototype. And as we can see here, I am using GitLab CI and this commit has started a pipeline with my build, testing and review app steps. Also, to merge this code, I will need approval and feedback from the product manager or the designer in this case. The job is finished and the app is allocated in a dynamic environment where, for example, Parker, the product manager, can access it and try it. Play with it and have a better sense of how it looks and behaves. So William assigned Parker this merge request. From there, now Parker can click on view app and try it. How awesome, right? The app is just one click from the product manager to try it. And thanks to that, he gets even more ideas on how to improve the web application. So through these reality checks, actually trying the application, he can provide more feedback to keep the iteration rolling. Now Parker wants to use this blank space to display a way to set up the confidence level for which the machine learning task should operate when running classification on images. On top of that, now he wants to display an additional image on the app, one showing the manually annotated data and the second, the one we already have, with the output from what the self-driving car will detect. And guess what? Those changes will bring more discussions around the design and this initial version of the app. Once the new round of discussions, this time including the developer, are over and everyone is on the same page, here we have the final design. So the product manager and the rest of the team are happy. The model box in the front of the application has been added and the ground through the image has been added as well. And with everything in order, Parker asked William the developer to work on a new iteration with all of these new inputs and the newer design. Then he creates a new merge request for this issue as the required changes. And again, GitLab CI does its job and provide us with a dynamically allocated environment to review the app. So now Parker can review the application, he tries it, we can see we have the box with the model confidence as discussed in the design, the green colors for the detected objects, ground through, and finally, a very easy to use web application fulfilling the initial user story of we want a data analyst being able to assess the quality of an image recognition algorithm in a very friendly and easy to use UI. It takes time to get it right. Using GitLab as a single source of truth is having one place where we can find all the work that has been done, making it easier for the different team members to provide feedback and collaborate. And of course, create awesome products. Stay tuned and let's continue learning at GitLab.