Product Talks - Product design - with Salvatore Mezzatesta

Estimated read time: 1:20

Summary

Salvatore Mezzatesta, Senior Product Design Manager at Lebara, shares insights on product design and collaboration with the WeRoad Monkeys team. He emphasizes the importance of communication and building a robust design system to ensure consistent user experiences across different markets. Salvatore also discusses design leadership, the significance of understanding business needs and user experiences, and the necessity of iterative design processes. The session touches on balancing business priorities with customer needs and explores best practices in user research and design system management.

Highlights

Salvatore Mezzatesta highlights the vital role of communication in product design collaboration. 🔉
Building a strong design system is essential for consistent user experience across markets. 🌍
The session emphasizes the integration of business goals with user experience in design. ⚖️
Design leadership involves guiding and facilitating effective design processes in teams. 🧭
Iterative design and user research are critical in continuously improving product offerings. 📈

Key Takeaways

Communication is key in collaboration, especially between product and technology teams. 🔑
A robust design system acts as a foundation for consistent and efficient product design. 🛠️
Understanding both business goals and user experience is crucial in product design. 🎯
Iterative design processes help adapt and refine products to better meet stakeholder needs. 🔄
Balancing business priorities with user needs often requires negotiation and flexibility. 🤝

Overview

In a recent session with the WeRoad Monkeys team, Salvatore Mezzatesta, who is currently serving as a Senior Product Design Manager at Lebara, delved into the essential facets of product design. He opened up about his journey in building a design team from scratch and underscored the power of communication within product and engineering teams to drive success.

Salvatore expounded on the critical role that a well-structured design system plays in maintaining brand consistency and enhancing user interactions across various platforms. By sharing his experiences, he illustrated how aligning business goals with user-centric designs can lead to more impactful product solutions.

The engaging talk explored the importance of iterative design processes and the necessity of balancing business priorities against user needs. Salvatore shared best practices from his vast experience in user research, design leadership, and managing design systems, highlighting the importance of flexibility and adaptability in product design strategies.

Chapters

00:00 - 01:00: Introduction and Welcome The chapter introduces a product talk organized by the Tekken product team, focused on sharing knowledge and experiences with professionals from other companies. Salvador is welcomed as a participant. The introduction highlights the goal of mutual learning and exchange of experiences.
01:00 - 02:30: Guest Introduction The chapter "Guest Introduction" begins with the guest expressing gratitude for being invited. The guest then provides a self-introduction, stating that they work at Lebara as a Senior Product Design Manager. In this role, they are responsible for managing the design team and the broader design function. The guest works closely with the senior leadership team and reports to the head. The chapter sets the stage for further questions and discussions with the guest.
02:30 - 08:00: Collaboration with Teams The chapter titled 'Collaboration with Teams' centers around the experiences of an individual who reports to the brand director and works closely with the Chief Commercial Officer (CCO) as part of the commercial team. The narration highlights the dynamic collaboration with both the technology and marketing teams, particularly focusing on brand design efforts. The narrator joined the organization, Leata, three years ago and played a pivotal role in establishing the design team from the ground up, being the first member of this team.
08:00 - 14:00: User Research and Data Usage The chapter titled 'User Research and Data Usage' discusses the transformation undergone by a business following a change in ownership. Post-acquisition, the design team was established, including setting up the entire design function and foundation, such as the design system. Throughout the transformation, the digital ecosystem platforms have been overhauled. Currently, the role involves balancing team management and close collaboration with senior leadership. The speaker, involved in design, UX, UI, and digital design, provides insight into their professional journey and the changes within the company.
14:00 - 30:00: Design System Discussion The chapter 'Design System Discussion' begins with an introduction of the speaker's experience in the startup ecosystem over the past decade. The speaker recounts their journey beginning in Italy at Nana Bianca, a startup accelerator where they collaborated with various startups. The speaker reflects on the rewarding yet challenging experience of founding their own startup, which provided them with a deeper understanding of business and the complexities of building something from scratch.
30:00 - 42:00: Team Dynamics and Resource Management The chapter 'Team Dynamics and Resource Management' delves into the intricate processes of collaboration within a team, particularly focusing on the interactions between product designers, product managers, engineering managers, and other engineers. It outlines how these roles function together during both the discovery and delivery phases of a product. The chapter begins by addressing collaboration questions, emphasizing the importance of effective communication and coordination among team members to ensure successful product development.
42:00 - 53:00: Closing Remarks In this closing chapter, the author shares insights from their experience in design leadership. They emphasize the importance of constant communication in collaboration and stress that in product management, it's crucial to ensure that team members share information openly and never withhold it from each other. This approach fosters better teamwork and more effective product management.

Product Talks - Product design - with Salvatore Mezzatesta Transcription

00:00 - 00:30 okay so welcome to salvator to our product talk um we are organizing this product talk in our mon team which is the Tekken product team to have some sharing knowledge with other professional from other companies so that it will be easier for us to learn and to of course share experiences on both side um as I said thanks Salvador to to joining our session uh I will start briefly Maybe by introducing
00:30 - 01:00 yourself before going directly into questions there are a lot of questions of course well first of all thank you thank you for the invite I really appreciate to be here today um well I can give you a bit of an introduction by myself um I work at lebara as a senior product design manager I am responsible for managing the design team and I would also say the design function at this point I work closely with the senior leadership team so I report to the head
01:00 - 01:30 of digital um I also report to the brand director and I work very closely with the CCO who uh who basically falls under the the commercial team uh we work very closely with technology team of course but also with marketing because we have people in our team who work on the brand design uh I joined leata three years ago I was in charge for building up the team from scratch uh I was the first person joining the design team because the
01:30 - 02:00 business went through a a change of ownership and since then we basically built the design team the design function uh all the foundation so design system we have R transformed all our digital ecosystem platforms and now I'm basically between managing the team but also working very closely with the senior leadership so this is where I am now I've been working in design uh ux UI but also in digital design in the past uh I've been working
02:00 - 02:30 in it for 10 years now started in in Italy uh at Nana Bianca a startup accelerator working with different startups I also had a chance to build my own startup for couple of years very challenging uh very rewarding but also really hard really really hard so it was it's a it was a good challenge for me to learn about business more in depth and also building something from scratch and
02:30 - 03:00 you know learning step by step nice so I would start with the questions I try to um cluster them into micro topics um I will start with the collaboration one um the first uh question would be around as a product designer how do you work with the product managers the engineering managers and any other Engineers within the team both on the Discovery and the delivery faces of a of a product yeah so
03:00 - 03:30 I can give you my experience from a uh design leadership because at this point I am working on on leader on a design leadership level uh I think one of the big biggest challenges uh of collaboration is making sure that people communicate constantly there is never a moment where people keep things to themselves when it comes to uh product management to share the
03:30 - 04:00 right requirements uh clarifying any any doubs that might arise from the team from both the design team but also from technology team because we work very closely with product managers but also with technology so we consider ourselves always in between and from our side to make sure that we communicate the details of what we're doing and how our design has been designed and if there are any uh any doubt from technology we
04:00 - 04:30 need to make sure that we are able to provide them these details when it comes to interaction points when it comes to experience overall uh we try to do our best to provide guidelines to provide prototypes um when it comes to product management and not just product management because considering that we work in multiple countries we have to operate across different nations we need to make sure that we can also present our design in the way that stakeholders is expecting that to be done so if they
04:30 - 05:00 provide requirements we need to make sure that we can explain where the requirements are going to be uh covered in each and every design so different Journeys For example so I I see the really important matter here is always communication communication communication communication okay the the big the big word okay um continue with um the the collaboration part and
05:00 - 05:30 you were talking about to say how to present the information to the stakeholder um do you have any schedule Ceremonies for example design critique or any specific design session that you do with a product team before going to the stakeholder before and go into the development team with h with the final design yeah so we do it in different ways uh we don't have one one size fit all is more about if we are talking about a small task so usually we work
05:30 - 06:00 with tickets uh what we usually do is if there is a senior designer working in these ticket I usually don't need to review that from my side from my side I don't I feel like I I no longer need to do that uh they can just make the design present it to the stakeholder to the requestor of course reviewing it first with the product manager and the product owner and then if all the requirements are in place then they can present it to
06:00 - 06:30 the requestor If instead we are talking about a project so let's say we are working on something bigger then what we usually do is we have our own internal design reviews which can be on a weekly basis or on a for nightly basis depending on the size of the project and then we usually go and check What's the progress and if we need to make some adjustments to timelines if we need to make adjustments on the way how we are operating on that specific project so it
06:30 - 07:00 really changes depending on on each each activity but I think uh overall what I usually always recommend to my team is uh communicate to each other even with uh even outside those design reviews make sure that you can exchange feedback and you can ask feedback from someone else from your team because each person has very clear responsibilities and they have a very specific perspective on something which can be from ux to UI to branding so I always want everyone to be
07:00 - 07:30 involved in these reviews sure good and um let me see if there's something related to this and uh and regarding you say communication and feedback from from the different teams so always focusing on collaboration do you have any advice on the organization level how to improve for example synergies between the product manager manager and the product
07:30 - 08:00 design team on this aspect of finding a um a solution together yeah so there is always challenges sometimes when it comes to certain requests uh probably the the main conflict comes from business because you usually business has very specific requests and from a ux perspective we think more about the customer and the user experience so sometimes we need to trade off so what we usually do is we try to understand
08:00 - 08:30 what is the the reason why business is pushing back on something we usually also have the product manager being in between us between between business and and our team so we try to negotiate what we think could be the best solution to give customers the best experience but also uh satisfying the business request and this is how usually we do is uh is having conversations with product managers uh potentially also with business as well
08:30 - 09:00 and then there is a point where we need to literally negotiate what can be the best solution we provide multiple options and then we we agree on going ahead with one option and then potentially making iterative improvements once the you know functionality rather than the page Gone live by doing AB testing um I guess there might be a question right like about options do you your strategy usually is to go with with a a
09:00 - 09:30 preferred option and then have like the backup option uh if some requirement become more like important to the stakeholder uh while you are like discussing the solution that you're proposing or you just present like kind three option and you let them digest them and understand which one is yeah so usually what we say is we we go and provide the preferred option from our side but because we already know potentially from the request there might
09:30 - 10:00 be a push back we also provide an option b we don't usually provide it immediately we keep it on a side just just because we know that otherwise we're not going to have enough time to work on this again and then if we need to trade off we show also option b and we try to understand why we need to move to option b if we have to go ahead with that option then we just we just provide that option and potentially we try in the future to to slowly move towards the optimal solution from a ux point of view
10:00 - 10:30 okay cool thanks yeah but I don't see usually this doesn't happen necessarily too often only when there are sensitive business decisions behind where we need to just accept the fact that we're not going to be uh really focused on the on the user at that point yeah and maybe you don't have enough data to back the your your main your main solution yeah it's usually easier to demonstrate it once it goes live and doing AB testing than doing it before yeah
10:30 - 11:00 yeah cool thank and still on on collaboration and communication uh more on the US ux research part um do you have any recommendation on some best practices you are following to um share fundings and communicate what you have discovered throughout the ux research to other team members like product managers to
11:00 - 11:30 Engineers well in our case h I would say user research is a quite challenging space because we need to operate uh through the markets that we work with so they are usually the ones having the resources and from a group level which is where I sit I can only orchestrate these activities however what I usually always recommend is because I know about what the business want to see is bring back the value of every activity that you run especially when it comes to user
11:30 - 12:00 research so don't do a user research only to validate one of your hypothesis but rather collect feedback and try to bring them back as a Improvement for the platform which then can become an action which then you can measure and you can demonstrate the value of that action so by starting with one user research do you then enable to create multiple activities that could bring value back to the business otherwise it's really challenging usually like we need to find
12:00 - 12:30 uh the best solution to not waste our resources because we have not sure about other companies but we have limits and we need to work around these these limits of budget yeah so you're basically starting with uh with the sort of problem and you find as much opportunities as you can to then test it fast and and go on yeah well usually there's always some priorities coming from each market so because each market has the you know the the opportunity to
12:30 - 13:00 test to do user research or uh individually I can only recommend do it on the areas that you think are like a priority for the business especially during the year every year we have different goals so don't don't waste time and energy and resources on something that right now is not important even though we might consider that being important but is not important for the business sure yeah and then of course there are side activities that we can always run which are uh
13:00 - 13:30 audits that we we run for example um we work with the data team as well so we try to balance between quantitative and qualitative data and we try to use them in different ways usually for me uh the quantitative side can give you some quick wins while if you want to go deeper then you need to go through user research okay uh this let last bit of information gives me to the second B macro topic which is data usage so uh do you have as a as a um a design team kpis
13:30 - 14:00 or product metrics that you are referring to and if yes are you using it in your process at the moment we are not uh simply because we have to support from a group perspective each market while each market has kpis of course we as a business have kpis that we need to follow but usually we don't necessarily have to stick to that in
14:00 - 14:30 terms of measuring for example uh okrs that is not something that we usually do it's more about knowing what the goal is and then supporting each area of the business to to achieve them okay and regarding inste still more now qualitative data so do you perform any user interviews or usability tests and how do you make these uh kind of data readable to other to other people
14:30 - 15:00 interested in what you have discovered uh again that is something that we as a group don't do uh we do it through each market and what they usually do is sharing with us uh different type of researches that they might have done uh in the past or new activities that they would like to run and then we discussed them to we discussed together about the insights from these researches and we try to find out what could be the best actionable points from from these researches it
15:00 - 15:30 really changes you know like U we worked a lot on creating something new and now I always say we need to start doing more and more research otherwise we risk of just walking blindly without knowing what customers really want from our platforms sure um okay uh regarding the discovery part so trying to find the best solution uh to a problem you want to solve uh do you have any framework that you use
15:30 - 16:00 during your Discovery phase and if yes do you have any internal tools that you're using any tools that allows you to say to follow the the discovery process um so Discovery itself is something that we didn't touch for a long time because the because the the point where we are right now on the you know on the development of our platforms is more about iteratively adding something new but something really small
16:00 - 16:30 uh however we approach to um doing some activities internally which I consider like part of the discovery phase and what I usually do is for example as a really easy starting point for example running a brainstorming session uh just to collect ideas from the stakeholders usually I tend to do this starting from design team and then inviting also other people to the brainstorming sessions and
16:30 - 17:00 first is for example we discussed about how we could integrate AI into design processes and each person of course has different perspectives on how depending on the area that they are working on so we try to collect first some keywords which can re can can relate to uh Ai and design uh then we start taking these keywords and try to create some sort of uh ideas let's say and then from there we create some
17:00 - 17:30 action so we try to give some process behind this brainstorming uh something that I am trying potentially for the future depending on whenever is going to be the case uh I'm approaching to design Sprints which is usually uh done in eight days and each day has different activities to be run but it's not something that we are actually doing at the moment I'm just just making some researches around
17:30 - 18:00 it sure um and still once you have let's assume that you you have done this brainstorming session um how do you validate if an idea or an hypothesis that you have identified um it's good for development or not so how would you say okay I found a solution uh to to what the business is asked for but how can I say okay this is the right
18:00 - 18:30 solution to go for yeah that's a good question so uh because we need to work with different departments including development it could be marketing can be business com commercial we need to understand whether each of these ideas which then become actions can be beneficial for someone specific of course or if it's just a good idea but is not going to bring any value um once we evaluate that then what we do
18:30 - 19:00 is try to understand what is the impact of this action and what is the outcome of course if it's a positive return for the business rather than an improvement on the operations or uh maybe in terms of Saving Time something that we did for example is developing a internal portal where we provide the documentation about design system because that is going to save time from meet from having meetings so there is no like a monetary value behind which could be potentially be
19:00 - 19:30 calculated because you save time from having meetings but it's more on the time that you save on a daily basis so um for each of these ideas and actions then once we understand if it's valuable or not we share it with the people who should be involved in making these decisions and potentially be involved in working on these activity and then we understand if they could be potentially interested or not and if so then we try to prioritize it on our timeline
19:30 - 20:00 okay yeah and usually we uh we we tend to at least from my side from from my team we tend to prioritize that during the summer time which is usually a good time for us we know in terms of having a stable number of requests while before and after we go into after we go into the winter season before we know it's still too early uh to work on them so usually we dedicate some bandwidth during summer time okay makes sense and
20:00 - 20:30 regarding that all these processes that you're following uh you you told us that now you're working on small iteration of existing products but did it happen to have any side projects where you need to create a a product from scratch that need to be integrated to an existing product and if so did you follow any different approach to find okay these are the minimum number of features this new product have to to
20:30 - 21:00 have um well I would say probably all the platforms that we now use have been uh redeveloped and redesigned from scratch because we went through a digital transformation but I would also say those that were already existing so we worked on existing requirements while a platform in particular that I think is a really good case study that I also actually uh wrote for my portfolio is is a an internal platform called EPC it's a
21:00 - 21:30 uh it's an acronym for Enterprise product catalog that we use to basically create products for our portfolio and before this was uh used from a third party provider so we decided to create that internally to of course save money and also have more flexibility for marketing and sales uh team and we worked on a MVP uh working with the product manager ERS and sales and
21:30 - 22:00 marketing uh teams collecting requirements uh assessing them analyzing them working on very structured process which is wi framing reviewing uh adjusting designing uh prototyping doing usability testings internally and then understanding if there was something that needed to be fixed from a ux perspective and also from a tech perspective because we had some limits that we needed to to to to consider from
22:00 - 22:30 a technology point of view also from a Time point of view because we needed to make sure that we could go live with something that was usable even though we we wanted to add something new and then uh once we were okay with the MVP then we started working similarly to other platforms which is based on request so we receive a request and we implement the new functionality on the platform okay so it becomes uh agile pure agile product
22:30 - 23:00 development in regarding the requirements collection so I move away from from the discovery part and just focusing on when you receive a request for a new feature uh do you have any flow that you're using is the design team highly involved in requirements collection or is mainly the product manager in in your reality that collects the requirement and then discuss it with the with thect the designer um so what we usually follow is
23:00 - 23:30 a very took a bit of time to get to this point but we now have a fully defined and working effectively working process which is the requestor creates the request provide requirements the product manager reviews the request uh sends back feedback asking for more requirements if needed or to make adjustments or to clarify uh the request then we discuss it on a weekly call so
23:30 - 24:00 on a weekly basis we talk with the requestor usually it's specific people from each market uh we ask for more details if needed uh if if no if no details are needed then basically the design the design team so my case someone from my team is assigned to work on the ticket they work uh on the design if they don't have any additional question questions they just go ahead and create a design
24:00 - 24:30 if not they have uh calls internal calls uh I might be involved or not depending on the on the complexity of the request or also on the importance of the requests and once the design is ready we review it internally if needed if not they review it with the requestor and the product and the product manager it's it's very uh fast process usually we work on a weekly basis on these requests because we need to make sure that we can go ahead for technology mhm so we
24:30 - 25:00 usually work two weeks ahead uh two weeks ahead of technology so we anticipate the next Sprint so then the design is ready to go to be developed and um usually when it comes to requirements I think the the challenge is not receiving clear requirements or receiving requirements that we think are clear but then in reality when it comes to the design the requestor realize that this is not what they wanted or maybe something was
25:00 - 25:30 missing and no one realized that so we are involved in the anal in the analysis of the ticket but we are not involved in the creation of the ticket because there is not something that belonged to us and it would also take additional time it's just because of the nature of the business and how the organization is structured we don't we don't we are not involved in the creation of the ticket itself sure and regarding the duux part you told us that your work in different
25:30 - 26:00 markets so I guess there there might be requests coming which are very different one from from the other how do you keep consistency across these different markets and if yes if you have any approach that you're following any any suggestion on on this uh I think that at least for us this is how it worked so far and it seems to be working is having a solid foundation
26:00 - 26:30 which we call Design system so because of our design system we are able to deliver consistently and efficiently in every Market having same experience or nearly the same experience same branding um from a management perspect from a design management perspective uh we have we use figma and we have different teams in figma which are for each market for each market we have different folders that uh are basically
26:30 - 27:00 each platform and then we divide that into Journeys so we know exactly which journey is related to a market and we can compare that to another Market if needed but we know that most of the components are shared across every market so that makes our life easier when it comes to delivering quickly and also for de for development to be fast in Implement in the implementation um probably we connect to this uh design system part because it's
27:00 - 27:30 something that we have discussed internally um I suppose you're using just one design system for all your different platform do you have the different approach so you have a design system for one specific platform so how does it work on on your side the design system uh we have one master design system but we also have subd Design Systems which are specific to different platforms so the main design system
27:30 - 28:00 contains all the atoms that are then reused in most of the platforms but we also have Design Systems where there are certain components that are not used in other platforms so by doing that we know that the share components from the uh main design system are going to be used across every platform and then we know that the components uh contain in specific Design Systems are only used in specific platforms and we don't mix
28:00 - 28:30 them and of course with figma it makes just life easier to just go to the main component and figuring out where this is contained what we are also doing now is because of the sides of the design system at this point we are also splitting each component into a separate file so we can easily maintain that component in the future and we can also eventually quickly dismiss it while before we used to have one single file which was becoming too much to
28:30 - 29:00 handle and um regarding the design system part do you have a dedicated team who taking care of the design system or each team contributes to the design system we have one uh one dedicated resource to design system however he operates together with other designers and the contribution doesn't come only from his side it comes also from ux designers um but usually we have a sort of like a
29:00 - 29:30 guardian of the design system who makes sure that everything works in the way that we initially envisioned it because the risk of having multiple people working on the design system is that then things get could get lost very easily and so we decided to keep a very solid and safe uh methodology of working for the design system specifically okay and other teams can propose and new components inside the design system so
29:30 - 30:00 there's a process with which you can approve or refuse a components into the design system that is actually something that we are approaching now and yes we are working on a process to make sure that we can introduce uh new components uh as long as these components are using the atomic components that are present on the design system because those are for us the foundation level of the design
30:00 - 30:30 system then we understand the need especially when it comes to the uh content pages so sales Pages or marketing pages to adapt them to the needs of every market so we cannot mandate something because we know that each market has unique characteristics and so we paid it off the fact that not every component is always going to be used but at least we know that the atomic component components that are present in a design system must be there
30:30 - 31:00 because those are going to guarantee consistency uh in addition to that we are also creating guidelines and rules around which components can be used and in which circumstances they can be used okay so we have adopted a very specific process for that okay okay I was saying before moving on to any other question I would like to know if there's anyone on a one um you said you're working on a process meaning you are constantly adapting your your
31:00 - 31:30 methodology and your your process when you say so you mean you like a top down you're thinking on new process and you discuss that with your teams or is some kind of collaboration between your teams like a bottom up where you discuss uh we could improve this process and then they you with them figure out how to how to so we have so far at least we have two different approaches one approach is there is no process we need to Define it
31:30 - 32:00 from scratch and we need to uh depending on who is responsible for that process I usually ask if it's the UI designer who is working on the design system I ask him to define the process because he's the one who is working on it then we review it together I raise any feedback from my end if there is some problems because I know the nature of the design system is going to be used by someone else I need to try and and think as the other person while I
32:00 - 32:30 know that sometimes that that is difficult when you are the owner of something and then adapt this to the each context and then of course sharing it with the people who are going to be involved in this process asking for feedback usually first time there are not really big feedback then once we share it and people start using it is where we have questions and then is where we need to review it so it's an iterative process is never going to be
32:30 - 33:00 defined sometimes it might last for one year two years and then we realize that actually things have changed now and we need to change the process and I think uh before at the beginning you asked me what are the challenges uh communication is the first but also process are really important and if you don't have clear processes and people are not really following these processes then is where you start seeing problems in the future well makes
33:00 - 33:30 sense and is there any other question on design system for people in the in the meet I know some questions have raised in the past so just to know if you have any any questions on that don't be shy shy go fa have you build your design system from scratch we did yes we designed our design system
33:30 - 34:00 from scratch and we worked so much on the design system that we consider it as a product at this point and we have a dedicated board for for that we we have a dedicated resource so that is for me Untouchable at this point as as much as any other platform we consider that as a as a product and it's so integrated in in our EOS in our digal ecosystem that at this point if
34:00 - 34:30 something uh is like if a design system is not using any of our platforms I think we would probably take 10 times more time than we do now and you realize that only once you have a fully defined design system at the beginning it probably can feel easier but there is a point depending on the nature of the business depending on how many Journeys you have to cover how many features you have to cover there is a point where you need to have a design system actually at
34:30 - 35:00 this point I really don't know how you could design without a design system I I would struggle honestly yeah I know it's a very very hard question to to answer but how in your mind how how how long did it take for you to see more advantages of having a a good design system in place compared to the time and effort that you have to spend on that system to build it because at the at the beginning it look like you're
35:00 - 35:30 spending a lot of time and and effort on be on building your own design system and it it seems like that you are like slowing down on important feature because at the same time you have to be to build a design system so it it is true sometimes is challenging because you realize that yes it's important to have design system but you also need to have flexibility and Agility in making some changes so what we did is we are okay to close one eye and say let's go ahead in this specific occasion for now
35:30 - 36:00 only for this time frame with something that is not a component but we are going to have it in our backlog to be created as a component and then you're going to be replacing it especially when it comes to AB testing we don't want to create a component before we know that that component is going to exist so we say go ahead as long as you're following the design guidelines that we provided and then if that is going to work we're going to create a new components or the other challenging
36:00 - 36:30 situation is when you want to enhance a design system component and you have five different markets with five different requests multiplied by five so you have a component with 25 different options and you need to choose whether you need to say no to some of these requests or you need to decide whether you want to split that component into five different variants and this is something that we are approaching now and it's challeng Ing and it's time consuming and also from a development
36:30 - 37:00 perspective it's a lot of push backs so yes yes it's I think there is a point where you when you realize that it be the design system becomes so big that you need to potentially do a step back and reassess the situation and find a a better way to to manage it but it's I think is in the nature of every product there is a point where it becomes so that you need to sort of redesign it and
37:00 - 37:30 simplify it absolutely other questions they just you no other questions I can I can add something on the design system you know uh on a personal note I I think Design Systems can sometime kill creativity BT because they uh standardize the
37:30 - 38:00 design and usually designers are creative people not necessarily all the designers I think ux designers might be less creative and more structured but still I think overall people think design should be something creative but if you approach it from a business perspective which is what I tend to do now I try to see the value of design for the business it makes a lot of sense to have a design system because it brings you so many benefits and it simplifies also the design
38:00 - 38:30 process so I personally always recommend to have a design system uh in place a proper one I personally think that you can be creative even if you have like a few bricks to use instead of having having a a completely white white paper in front of you at same time sometime you need you you feel that you need to refresh on a different level not just the way you build the components that you using in
38:30 - 39:00 your maybe there is a point where you where you actually feel that it's like limiting you in what you think you need to do in order to give you like to turn the page like can say and the other problem is because you have one single person working on it what happen is that that uh those people become too uh harsh on on either on themselves because they want to make it better or if someone ask to make a change because
39:00 - 39:30 they feel they own that they don't want to make changes so sometimes can be can be challenging but yeah I guess it's part of the day-to-day work yeah so if there's any other question any case we have time to to ask um I would go to one of the last question which is more about team dynamic uh so in um in we Ro we have just two
39:30 - 40:00 designers at the moment that are helping us on four different product teams um the IDE the question would be have you ever faced such a limited resources or time constraints a moment and if you have any suggestion on how you handle it even on for example on the ux research on the research part or even in uh in the design
40:00 - 40:30 phase there is a constant is not something that I ever face it's a constant you always have to negotiate in regards to resources and where do you want to assign them and when uh from a from a manager perspective you need to know your team very well uh you need to understand where they can be uh where they can bring the best uh and where they could
40:30 - 41:00 take instead longer where they are more comfortable depending not only on their experience but also on the period of the year because sometimes I always say every team is like a football team there are periods when like someone is performing better than others someone is not really performing as you expect someone is totally off so you need to make sure that once you really know well all of these aspects then you can prioritize they can you can assign them
41:00 - 41:30 according to what is the real priority and sometimes you need to trade off on something and postpone it eventually we have many activities that we run on a side sort of like side projects which don't have a deadline simply because we consider those to be secondary activities against the primary activities so that is usually for me my my way of approaching to this and of course there is a point where you can no longer negotiate this you need to be clear to the business and you need to demonstrate why and you can do it in
41:30 - 42:00 many ways you can uh for example you can compare the number of tickets that uh the team has worked in the past year versus the number of tickets that have been already requested and that you have uh you have a gap and this Gap needs to be filled by having one more person and usually you can do that by having someone full-time or uh you can eventually you know uh you can look into uh contractors or third party
42:00 - 42:30 providers so there is flexibility also from the business uh they understand this and it's something that we we consider on a I would say on a quarterly quarterly basis good so I've went through all the list so we leave sometimes to uh understand if there's any other question that we didn't cover so if you have any other curiosity I do have one but I leave the other
42:30 - 43:00 before because I already like wrote 10 of the the question that we already asked so three anyone One S okay one okay um not a specific question on anyb um do you have some decision uh that you made during the process of defining Your Design system and all the process with the team that you regret
43:00 - 43:30 and now is hard to roll back to a better decision that is a really good question I must say uh remember you recorded yes there is one and we actually uh we we are trying to implement design tokens into our design system which I'm not sure if if you're familiar with design tokens but basically they additionally simplify the
43:30 - 44:00 process of Designing and creating new components and mantaining design problem is you cannot do this just by yourself you need to involve also technology and because we have a massive design system that means you need to go through a sort of Redevelopment of every single component and you need to realize that Tech Team doesn't have those resources to help you on that so probably if I would have approached that now according to my now
44:00 - 44:30 past experience I would have changed the approach which is starting really small and almost like starting with an MVP and then slowly progressively applying the design tokens to every component while right now we are in a situation where we have design system figma tokenized design system in front end not tokenized so we are now in a bit of like a transitional phase and it this to much longer than we initially thought so yes
44:30 - 45:00 there are some situations where you you start with a lot of expectations but then in reality you need to you need to basically come back and say okay we need to change approach to this because it's not going to work okay thank you yeah go go now I I will go back to one of the first answer you gave about communication which is I agree super
45:00 - 45:30 important in order to make the process work as you expect but um what I ask what I want to ask you is H AP part the communication that are stly related to the process uh don't know if you see me because I see you Frozen Okay uh so AP part the communication that you you like have in place Street related to the process like uh validation with the stakeholders and so on uh with the rest of the company do you feel that is important communication on what you're
45:30 - 46:00 doing or when you think is is the right moment to Comm to communicate to the rest of the company what are you doing what have you done uh which impact that you had uh so what what's your ideal or what you doing your company at the moment so because there was no design function or design system or design team there was no design at all before at least when I joined the company we had to create this Communication channel and we try it in different ways at the moment we are
46:00 - 46:30 sending out uh uh every quarter we send out a design newsletter design design update newsletter where we share the latest from from our team to the people who are relevant for for us of course we don't send it out to finance because they would not be interested on that but because we also work very closely with brand and also with internal coms if there is anything that is relevant for the wide Organization for example new
46:30 - 47:00 templates for PowerPoint or anything that could be relevant for everyone then we discuss about sending out a communication that goes to everyone uh apart from that we uh we started also having monthly forums uh depending on the on the area for example can be user research can be cro we want the people who are relevant for that area to be involved in this calls and share the latest and do a bit
47:00 - 47:30 of a learning session where everyone can share results of you know uh recent activities so other markets can eventually apply those to to their own market and and we also try to involve um other stakeholders on a depend it really depends can be on a on a monthly basis can be on a quarterly basis can be only when needed but we try to share as much as we can it's difficult because it takes time it's a it's something in
47:30 - 48:00 addition to what everyone is doing so it's almost like asking for a sacrifice uh but I think is really important because it creates that uh environment that is uh more collaborative more about sharing and I always feel that is part of communicate Communications yeah yeah Mak sense thank you other
48:00 - 48:30 questions I have a quick one uh you you talked about AB testing so just wanted to understand how much the design team is involved in NB testing so what are the um Parts in which they are involved the most are the ones they Define the hypotheses what the test or and how they collaborate with the product manager and the the data team as well uh it really depends on the ab test so
48:30 - 49:00 sometimes we might not be involved at all because we know that whatever they're going to be testing is going to be based on design system we always have an eye on each AB test that goes live because we receive an email so whoever is working on the ab test is going to share an email to inform everyone there is a new Ab test coming out uh if we should not know about it then eventually we can adjust a trajectory and explain if something needs to be adjust
49:00 - 49:30 otherwise if there is design request involved usually we have a process also for AB testing everything goes into jira and there is a label that says UI ux so we we are informed if design is needed or design is involved and we can review it and and share our feedback if something is breaking the guidelines if something is not within our brand uh uh brand identity guidelines or rules then we can just push back and say we need to
49:30 - 50:00 fix this um otherwise yeah we it really depends on each case there is not one one case that covers every scenario totally makes sense and and if I can also add sometimes you just don't know sometimes there is no communication and something goes out without you knowing it and you just find it out once you open a website and realize we didn't know about this shouldn't be
50:00 - 50:30 there so sometimes you need to give up on what I think probably many designers are obsessed with perfection like you cannot achieve that Perfection it's never going to happen and is okay is in the nature of a business to not be perfect it totally makes sense um I would say if let me know if you have any last minute
50:30 - 51:00 questions go Fabio okay um if you had to um build again design system from scratch would you consider using something rade library or something like that and build on it or not the first thing I would do is do spend a lot of
51:00 - 51:30 time on assessing why we need to rebuild the design system because if we are doing it it means that there is a really strong reason of doing it and analyze what went well during this time what went wrong and also understanding where do we want to go and for how long we are planning to use this design system so doing a proper assessment and then creating a strategy a plan a road map and then start working
51:30 - 52:00 on it but before that I would probably change my Approach that before was we need a design system and we started we didn't have even the time to think about okay where are we heading with the design system we were just we were just doing it now the approach is changing at least personally and I feel like before doing something let's think not twice but three times four times five times and only once we are convinced because that is going to require a lot of resources and those Rec those resources
52:00 - 52:30 are money that are going to be spent by the business so we need to have a really strong case for doing that okay last last questions I try okay if there's no other question uh I will thank everyone to take part to this prod talk and thanks again salvator to to joining us today it was super
52:30 - 53:00 insightful to to know this big tips especially on design system which is as you might have noticed is a Hot Topic and there always going to be a Hot Topic even once you have it it's going to be a Hot Topic I can I can tell you in advance okay good I going to stop the recording of the video you can you can you can stay just a couple of minutes after after that yeah yeah yeah absolutely thank you all guys thank you
53:00 - 53:30 thank you you bye bye thank you thank you bye bye by