Managing hyper growth with the help of a design system

Hi everyone and welcome to another episode of Product Bakery. I'm Christian and again here with my co-host Alex. Hi Christian, happy to be with you again. Hey Alex. Last episode I had the pleasure to be interviewed by you to share some background about myself and we somehow dropped into the topic of user story mapping at the end of the conversation. But not talking too much about myself, I would like today to hear more from you. Maybe you can introduce yourself to the audience and share a little bit of your background and how you moved into the world of product design. Happy to do that. I was already expecting I have to do a similar introduction after I forced you last week. So where should I start? Even though I'm co-hosting the Product Bakery format with you, I didn't start out as a baker but I also didn't entirely plan on becoming a designer in the first place. So my dream or my plan was pretty much to become an architect. I actually started also in Italy. There's a school called Geometra which would be the preparation for becoming an architect or at least being able to build houses. So I started out there but I soon realized that while I do like the aesthetics of a house, I don't like all the physics and mathematics that are needed to really be able to build a house. After some tries at school, I figured that for me like the creative aspect is really more important. So I was like re-inventing a little bit like what I wanted to do. And since I was usually pretty interested in this whole topic of photography and media, that's how I landed in the whole design sphere. And there I really started in a very kind of traditional way. I went through graphic design school. I worked in some print agencies with some publishers mainly in the tourism kind of space. And purely out of my personal interest, I also taught myself like coding. So I learned really the basics. We're not talking about anything crazier than HTML, CSS, some basic JavaScript, minimal PHP back in the days. And while I'm definitely a poor coder, this at least like landed me my first job in a web agency. And I always focused on the design aspects. Back in the days, responsive web design was still unknown and there was a huge market also in like also focusing on that specific area. The agency I worked with was again more in the tourism area, probably also related to the fact that I'm like from north of Italy where tourism plays a big role. And they also had their own first products, which allowed me like to also get a sense of what does it really mean to go this one step further from designing websites to like really thinking of deeper interactions, thinking about how users use a product on a regular basis, which is more than just navigating through a couple of pages. And from there I then, simply because I also wanted to see the big word, moved to Munich. I started working for Sixt, which is a car rental company here in Europe. Spent some time with them, moved for Sixt to Berlin actually, where they had a startup that was selling cars online. And while I was like on that job, I met Sibylle and she was the former VP marketing from Fintech called SumUp. And so we heard SumUp already in the last session. And that's also where we met. And I have to say that SumUp was really interesting for both my professional development, as well as from a product perspective. Because like when I joined very early, we acquired one of our main competitors. So this meant first of all, combining two existing products into one, having doubled the growth like from one day to the other, having a massive team size. And I think like from that day on, everything just went upwards. And I think from when I joined, we were three, four designers in the whole organization. And I managed to scale the team to more than 40 designers until I then left end of last year to join my current role, which is a banning company where I'm product designer or consulting around product design. Actually on similar topics, I think it's probably my destiny that I ended again on some financial services, financial technology clients. I'm getting deeper and deeper into the banking topics around here. Getting back to the question you asked me yesterday, when you now look at the variety of companies that you are regularly interacting with, what kind of problems or challenges do you see on a regular basis? Or what are the key problems companies are struggling with from a design perspective? I think one problem, and I do feel like it relates a little bit also to what we discussed yesterday when it comes to products specifically, is not entirely about the company itself, but really also about the designers itself and the designers really understanding how they best fit into the company, how do they best communicate with other stakeholders, how they talk business with everyone. And I think there is also what I see and hear from other designers, there's still this need of really advocating for what design really is and what designers beyond coming up with some interesting screens. And I think we are getting in a more and more comfortable place where, especially when it comes to understanding the users and research and so on, this is getting bigger and bigger importance at the different companies. But then again, what are the overlaps between different roles? How do I best integrate into a development cycle? How do I best integrate into the processes that my product managers might run? Yeah, I think there is still a lot of room for improvement, especially in those areas. If we look at all the aspects you mentioned that go beyond just designing a product in terms of research, gathering data and doing the extra miles to re-understand the customers, what do you think is the best ways to get there? Or what really is design then in your definition? For me, I'm a huge advocate of general cross functionality, let's call it like this. I do think that there's this massive importance of really collaborating closely between product managers, designers, engineers, and so on. And to try and really break also the boundaries, to really stop saying, okay, this is go. I'm the designer, so my responsibility is until here because this touches the user and your product manager. Never throw something over the fence just to the other guy and then try that it comes back in a nice way. And I think also here, if I think back, for example, at SumUp specifically, especially because of the massive growth, there was a massive need also to get everyone aligned, especially on the aspects of how do we build interfaces and especially on what are the patterns? How do users interact with our tool? And I think what was really great there, and I think big shout out to my former colleague, Monica back then, is that she was the former front-end engineering manager or she was leading the front-end chapter. And she was really there. She really focused also a lot on these aspects of how can we get everyone aligned? And when you followed the design trends in the last two years, there was definitely this hype around design systems. And I think this was something that together with her help, we managed to really focus on a lot. And I'm saying that design systems are often thought as design exercise, right? It's like designers working in Figma files, Sketch files, coming up with some really nice components and so on, but then everything that comes afterwards is a mess. What was great was that Monica as the engineering lead really was open and we really had this great kind of conversations and alignment to kick this off and to manage to form a proper team around it, right? And you obviously also played a big role because you came in as then the product manager for that team specifically or for that project one-off thing to get everything started. And it really showed the benefit of collaboration. Having a strong collaboration between the product manager, the engineer, and the designers on the team helped us manage the expectations from the stakeholders, helped us push back on the tasks that we couldn't really take in, in order to focus on the task of coming up with a design system and to build a design system that both reflected what we thought as designers are the interactions and patterns that our users need to have it implemented in a way so that we can easily reuse it and build on top of them, to use it then to also constantly improve by having the conversations with the customers and so that every small iteration on the design system is also automatically reflected to all the products. And I think this is something that wouldn't have been possible if we wouldn't have brought down the isolated thinking or the silo thinking. And it was only possible thanks to collaboration. You said that it's very important for a designer to go beyond just your own little world of designing things. If we, if you look now at building such a big design system, and I fully agree with you that the best way to achieve successfully such a project is a strong collaboration. What were the biggest challenges for you that you can share with our audience to manage your and to lead your designers into the right direction, to make sure that they stay close to the customer and also make sure to focus on the key components to be built rather than dying in beautiness? What were your biggest learnings regarding this whole process and the whole time of building up the design system? So I think when it comes to designers, usually making sure that they think about the user is the smallest problem that you have. I think everyone nowadays follows the right approach, has the right mindset when it comes to designing the right products. I think the hardest task is definitely around the stakeholder management and to really get the company buy-in to build a design system because it is an initial investment and you need to know how to communicate it. The way you need to, let's say, sell the design system to the stakeholders is also a little bit where I've seen the biggest challenges for the designers on their day-to-day work within their teams, which is you need to really be able to emphasize with the stakeholders to understand what are their biggest needs, where are they coming from, and make sure that you try and help them along their way. I think in our example, what was important for us was the proving that we can actually deliver faster. I think the more you manage to also do it by having a small proof of concept that allows you to really show the power of a design system, for example, just because we're talking about that one, to then really showcase the needs that the different stakeholders get from it. We, for example, also invested a lot of time in rewriting our whole marketing website as an effort that came out of the design system as well. It was about integrating a new content management system. Also there, marketing usually doesn't, they don't want to completely change their set of tools that they're using. So just coming from the design perspective that, okay, you want to have the consistency with the products and you want to have the latest system running there, won't get you thereby. You really need to work closely with them because otherwise along the way, they will throw you the stick between the legs. I'm not sure if that's even in English. Yeah. So, so I think it's really about understanding, having this empathy with the stakeholders and trying to get close to speaking their language. And I really have to say, I met a couple of designers, their MBA went to business school and so on, and I can really see how that helps them and how that puts them in a different mindset, a little bit away from designers seeing themselves too much as the creatives that are not understood by anyone. And I think this is the biggest mistake or the biggest roadblock that some designers face along the way. Okay. Coming back to the original problem statement, you said back then, SignUp acquired a couple of companies actually, it was when I joined at least already more. How was the decision made to build a design system? What was the process and how did you, or what was your play actually, your role as, as head of design back then? Back then the team was still smaller. I actually had quite a hands-on role also in the whole process of working on the design system, but maybe even one step before why we did it. And I think the different companies that we acquired were one part of the reason. The extreme fast growth of the organization and of the teams was another part of the reason. And we were there and we were looking at a product that over the past grew out of different teams, different people's minds. And it's mentioned even different companies. So there were obviously consistencies everywhere. And we're speaking about internal tools, the official product, the different apps, the web application, the website, especially when you look at the details, it was really hard to maintain. And the growth at the same time also forced us to have more independent small teams to really be able to keep up and to keep the speed up that you usually have when you are a small startup. But in order to enable these different teams and to make sure that you don't spend too much time on aligning again on topics around consistency, you need to find a proper framework. And I think like a design system can really help you with that, set it up properly. Because as I mentioned, ideally it's reflected completely in the design files as well as in the codes. So you have one source of truth of everything that's currently possible and that's not possible. And you can really, by applying these components to your whole product, you make sure that you have a consistent user experience. And as I mentioned earlier, it's also the process then of how to improve your product. You want to make sure that if you improve the way you handle credit card entries, for example, that those improvements are applied everywhere. And this is then relevant for the way you would enter your credit cards when you have to pay for a service on our site, as well as the end client who enters the credit card details on an e-commerce page or on a virtual terminal. And as you have multiple different teams working on all these little experiences, it's important that you also have a single source where you can manage all these interactions and patterns, especially for the growth. This was super important. What were the downsides of having a design system, especially for cross team collaboration? Refactoring. Never heard about that word. Looking back, that was also one of the things we could have done probably in a more efficient or simply in a better way. But to be super honest, I wouldn't know how. The thing is, the second you have a lot of legacy in place and the second you have a product that has grown quite a bit over the past and you want to benefit from the benefits of a design system, you need to also make sure that everything is using the components. And in our case, one decision that we made on the technical side was to also move from AngularJS as a framework to React. And that also meant that we had to rewrite pretty much everything. The bigger issue there was also that we didn't really have full focus to do that. If we would have had the focus to really concentrate on shipping it, it would have been much easier. But the way we also set up the teams was that after an initial kickoff phase, where we planned out the whole design system, where we pretty much laid the foundation, we got back to the normal day-to-day delivery and treated it like a side project. That slowed the process a little bit down and we didn't immediately benefit from the advantages across the board. And we still had some parts of the app in Angular, other parts in React, and it took us quite some time to really roll it out. Definitely there, also one of the key learnings is when you want to push a project like a design system, make sure that you also allocate enough resources for long enough time and to really have focus. And I think I'm actually super happy. I've just recently opened LinkedIn to see that Assemlab is currently hiring more designers that are fully focused on the design system team. And I think that's totally the right way to go about it. And seeing that the company still invests in it makes me actually happy and proud that the whole system keeps on living. You haven't only focused on product design at SumUp, as far as I remember. I would like to know how the implications of the design system were related to the whole branding topic. So just a small side note here, Alex focused also on brand design and was leading and building up the brand design team at SumUp. What are the benefits or downsides of the design team? Maybe you can shed some more light on that. Yeah. Actually, happy that you brought this up. I think this is a very good point and this is something that I also fought for quite a lot. When you think of the way many companies set up their brand, it's something that happens within the marketing team. And it's oftentimes very far from the team that is actually working on the product. And the way I like to look at it is that the brand is just like an integral part of the user experience. It starts when you first interact with maybe the first advertisement that you see somewhere on Facebook, the way you then go through the whole acquisition funnel, all the different touch points. Is it emails? Is it different onboarding flows that need to go through up to then, like really how you use your product, how you interact even with the customer support? So making sure that user experience is considered when working on the branding and vice versa is really key. And I think the good thing also of the design system is that all these small little tweaks that are also being made to the brands are easily applied to the whole system. And the system also allows you to, for example, think wider about, for example, the usage of animations, because like the way you, for example, might define them as part of the branding exercise, the same way you would try to apply animation guidelines or standards across the whole product. From my point of view, the design team always needs to operate as one single organization. And it's very important that product designers and brand designers are collaborating and are combined on a task working on the design system, because you really need to make sure that you include the different perspectives from both teams and that you then also continue to iterate on the system and use it as both teams. I would like to dig a bit deeper into this. Can you maybe make a specific example of how you brought both parts together, product and brand design, to really focus on the common user experience across product and marketing and branding? Yeah, generally one big topic that we did or one big workshop that we did at the beginning of the redesign or the design system project, and I'm saying redesign project because it also came with a little like... You can call it the circuit UI that people know what to google and to check out GitHub. Correct. It's an open source project, so if anyone wants to use it or everyone is in the need of a design system, feel free to check it out and to use it. But yeah, while working on the design system, we also refreshed our branding. We had a bigger workshop where we included both sides of the design, so brand design and product design, as well as different stakeholders from the company to really make sure that we get everyone's input. We obviously had also marketing involved for everything that related to brand values, as well as tone and voice and the communication. Then you have some of the key elements. And again, I think for the bigger picture, you need to collaborate on all the little parts to also make some practical examples. For example, as an integral part of every brand, you have your brand's colors. And I think what was funny here is that we had them pretty well defined from a brand design team, but we then included the product designers as well, just to make sure from an accessibility standpoint that also these areas are covered. And I think without combining the two functions and without collaboratively having them work in that, and that's something that you see often on different products that are also out there, you would really miss out on these things. And then you might have complete different schemes between what someone is using on their advertisement and what someone is using on the products, or you end up having, for example, the schemes that don't work for the product specifically. Obviously, we had some clashes and we had some, let's say, conflicts when it comes to different interests. But at the end, by really having both own the system as well, we managed to get everyone on the same page. We managed to make sure that, for example, that one is really covered. One bigger last question on the whole design system topic. So, we see in product engineering many times cross-team dependencies and cross-team projects. How you deal for a company like SumUp, which is a multi-product company operating in different countries as well as continents, what are the benefits of the design system for such a cross-country collaboration between different marketing teams and branding teams? And how did you manage this to stay on top of things as design lead? Yeah, I think definitely with scale, something like a design system gets more and more important because especially what you just mentioned, having different countries actively working on it, having different teams actively working on it. If you don't have such a system, you completely lose control. And I think like, for example, we did see it also as the company went more and more down the road of like age of transformation. And it happened that here and there, we had some teams popping up that were not entirely aligned with within the organization. And for example, they sometimes started to come up with their own kind of sets of whatever design. Branding assets. Yeah, not only branding assets, but also product-wise, right? And I think what they lost was the whole knowledge that went into the system that we already created because we based it on historical experience, we based it on research and so on, something that you cannot acquire when you completely start from scratch. And I think therefore, the design system is really a great instrument also to onboard such teams, to onboard everyone in the organization, to make sure that everyone gets on the same page. And at the same time, it also forces you to always look more and more on the extremes. We were a Germany-based company working pretty much everywhere. In German, most words are pretty long. You need to consider all these kinds of things. And you better consider it on a system level, right? So that you don't run into problems afterwards. The same topic is also around if we stick to scalability, there are countries that have different reading directions. Take the Arabics, for example. On a system level, like having everything in place that you could easily launch a new country, or that you could easily scale to a different country and accommodate these needs, or for example, new languages is important, but will only help you on the long run. Overall, we see that the design system is definitely made for scale and can help to collaborate across teams. How would you summarize the key points related to a design system? Thinking back, and it's a great opportunity because I think freestyle talking about the experience made me actually remember some of the key aspects and some of the key learnings. So I would say trying to really break it down. First of all, make sure to get the right people involved. You need to have the engineers on top of it. You need to have the product team working with you. And obviously as a designer, you also need to have the full set of design presence and design experience present. So including also brand designers, UX writers, and making sure that you also have, for example, the research team behind you to really push it. Secondly, and I think this comes a little bit with what we just said, design system, even though it has this beautiful part design in the word, it's really not only about the designing and the sooner you get it out of the design tool, the sooner you get it out of Sketch or Figma, the better it is because it's only valuable when it is actually like in code. And if the code is actually published to the whole product, because it doesn't help you when you have the fanciest design system, but it's not being used by all the teams because the benefit that you get from the design system is that you can apply it to the whole product. Learnings are automatically applied to every single part of the product. And in order to also be able to do this successfully, you need to spend a lot of time thinking systematically and making sure that the system also is built for all the different edge cases. And with edge cases, also including things like we shortly touched on it, making sure that it's built for accessibility, making sure that it's built for all sorts of devices, for all sorts of languages, inclusiveness. And I think that's getting more and more important across the globe. Also, if we look at what's currently happening and yeah, when you make sure to think of all these kinds of things, you should have a good system in place. Nice, Alex. Thank you very much for sharing all your insights. Perfect. When I, Alex, met two and a half years ago, I saw a well-dressed Italian guy wearing perfectly ironed shirts, always wearing leather shoes, walking around in Berlin. And I was already back then, oh, this guy seems to know his stuff. About shoes. About shoes, yeah. And obviously building design system and generally building up design teams up to 40 people. But most important is when I met him two and a half years ago, he told me that he's just 23 years old. I think now 25, right? Or already 26. It's really, it's really impressive. I have to admit, I always have to do my math. It's 20, no, it's even 27 at the end of the year. 27 at the end of the year. Okay. Yeah. However, I think it's also a motivation for everyone who's listening that age doesn't matter. And most important is knowing your stuff and passion to what you're doing. I think it's a great way to close the podcast today. I just want to highlight that we are always open for feedback. In case you have some ideas, feedback, or topics you would like to learn more about, feel free to write us an email to hello at product-bakery.com. We would really appreciate your feedback. And other than that, we are also planning now in the next episodes to interview domain experts from different companies to get even deeper insights to particular product topics. So looking forward, sharing with you the next interviews and yeah, Alex, then thank you very much and see you next week.