Chris Strahl:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code, and how it relates to the world around us.
As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at TheDSPod. We'd love to hear from you.
Hey everybody. Welcome to the Design Systems podcast. I'm here with Morgane Peng. She's a managing director at Societe Generale.
Morgane, welcome back.
Morgane Peng:
No worries, I'm super excited to be back. Thanks for having me back.
Chris Strahl:
Yeah, so we were jamming just a little bit around a huge variety of topics before the program, but I think one of the ones that was interesting to me, that I'd love to start out around, is this idea of how your design system has changed as you've gone to scale.
Last time we chatted, you were talking about how the design system was becoming a lot more of just the way that the organization was thinking about the creation of product. That was going from this thing that was sort of... I mean, I don't know off to the side is not really the right thing to say, but not front and center in the product process to something that is now very much a core way of building.
Can you talk to me a little bit about that transition and what that meant for you in the team?
Morgane Peng:
Yes. I guess obviously at the beginning, and I think we were trying to have this design system thing before that name actually existed. I remember the first time I went on the podcast, we were joking about the fact that design system are very badly named for what they are.
We were having a design key code library that we wanted to reuse, and then we started adopting the name design system and then just realized that everyone was confused because now they call the design team, the design system team because for other people they see design system as basically designers. Yeah, that went for a while, but I feel like now especially design system is such a commonly used term now that is been better.
But I thought for us really as we scaled, so at the beginning we were using it on a few projects and then adoption happened and we started using more and more. All the usual benefits of design systems, such as going faster, not having to redevelop buttons, the wheel and everything, that goes along with helping adaption.
I do remember there was a tipping point where we at some point no longer had to fight for the design system to be used. Because it came became that thing that the same way that you have to use branding, the same way you have to use your company tech stack. That became something that was normal. Moving from something that was new and people were a bit suspicious and why would they have a dependency on another team to okay, no, that's something I need to use, and that's just how we work.
I feel like the same happen design wise where I know that it can be sometimes difficult to convince designers to use the design system at the beginning. But I think we always realized that this is a common knowledge. This is a common brand, really. Everything that we feed back to the system can be reused and improved for other services that I think everyone started to nurture this mindset.
And I guess that's why I was discussing a pattern. Something very strange happened because when you start to think systemically, when do you stop? Is it just for patterns and cards? Can you go beyond would you think? For example of obviously I work on financial interfaces. For example, the trade letter, how many trade letter can you design? How many trade ticket can you design? How many four eye check, which is basically a security process, can you design?
After trying to align on buttons and cards and [inaudible 00:03:48] bars and all this, more and more the team decide to ask around, oh, has anyone worked on this type of use cases? This kind of patterns. This kind of technique, way of thinking, spread around the team to the point where we are now also defining business patterns.
Chris Strahl:
Interesting. So you went from this idea of we have to build these very simple things, these basic componentry, those low level bits of UI that construct the majority of experiences that we're familiar with, to thinking about more feature driven experiences. What is this thing that represents a feature or represents a complete bit of UI that has a real distinct set of user value or piece of user value?
And then now you're starting to take that to the point that you're actually thinking about what are the business problems that are associated with these things? And this viral spread of systems has had this infectious nature at the organization that has helped not just think about patterns in the context of basics, but as really complex systems of things.
Morgane Peng:
Yeah. Just to give you one example that I like to reuse because we have written about it on a Medium blog. One example is what I like to call the four eye check, which is sometimes when you need to perform a very sensitive action, you actually need someone else validation. So under the pair of eyes, so this is why it is called four eye check.
But the four eye check is not just the UI part, it's basically the whole flow. Who validates when? What do you show? What action can I do? Where do you place the information when there's an alert for example, and this is what we are trying to document.
It can also be some business rules. So what constitutes as a validation? Is it someone from your team? Is it your manager? Is it someone external? So all this again, I think before where we used to do is for every new services and new project, we just try to design it bespoke.
But then after a while, and then especially with the team asking, "Hey, has anyone done this? My project needs four eye check." We start to realize there's patterns, so one name, right, that then we also try to document. And this has been quite a struggle because honestly it's already hard to document the smaller elements such as the button and thing. Obviously going beyond that and documenting whole flows and business rules, it's really difficult.
Chris Strahl:
So this is actually something that, the four eye check, represents not just a bunch of UI but actually a workflow in the business and a set of actions that result from that workflow.
Morgane Peng:
Yeah.
Chris Strahl:
I mean, how do you guys characterize this? Do you think about it as is this a micro front end? Is this a feature pattern? What is it that you think about in terms of labeling this or putting a name behind it, or understanding more about how do you think about this independently from just another button?
Morgane Peng:
Oh, good question. I think we're struggling with naming honestly. For now, we just call it business pattern. But then I realize that business patterns can be also business cases pattern. I don't know, it's all getting very confusing.
I mean, at the end of the day, what we're trying to say is, okay, there's a similar use case that some actions or needs are done on the screen. Instead of trying to just improvise locally on one service, we try to tap into what has been done before, what's been tested before, and try to leverage on this instead of doing the whole thing from scratch.
Usually actually, because we've done this exercise on a service where we actually listed everything that we could reuse from somewhere else, and obviously, and I need to be very clear about this, this has to be analyzed and processed by a designer or by someone.
You can't just copy paste stuff around and just hope that it works. That doesn't work like that. But if you do this exercise, especially on the one we are talking about in the article, I think 80% of what we had as use cases in the interface was already done somewhere else that we could leverage on.
And of course if you sell that to the designer, the idea is to be able to leverage on it and go faster. If you tell that to your stakeholder, that also will hopefully interest them because that means we can spend more time doing other things. The custom one or the 20% are not things that we've done over and over again.
Chris Strahl:
Yeah, and I think that this is interesting because it speaks to the cultural aspects of design systems at SocGen with the idea that you fostered this as a way of working. And so it's not just about let's go use this design system.
One of the things that was really striking in our conversations over the summer is, for example, you don't have a name for your design system. Because you don't want people to think about this as something outside of their normal workflow, or to get too attached to where does budget come from or how do people think about the construct of the design system? You just want it to be the way that people work.
I think that by fostering that... I mean it's no secret to the people that I chat with that I'm a huge fan of what you all are doing because I do really fundamentally think you're living in the future. What I mean by that is you have a culture that is set up around this idea of systems. That is starting to branch out into a lot of things that people would not immediately think about being in the design system. That's largely based on this cultural value that systems are the right way of constructing product.
Morgane Peng:
That's a lot of praise here. I don't know if we are living in the future, I think we were just very pragmatic. Because when we decided to scale design, something we decided is not to have huge design teams, huge numbers of people in the design team, partly for this budget constraint.
And also I feel like the difference is working in an established industry, I know that when you scale you have to optimize. You cannot work the same way that you know work when you're a smaller structure. Finding ways to systematize our work or knowledge was definitely something that was needed to do first to be able to scale to the entire corporate investment and banking division. I feel like that was much more being pragmatic than anything.
But yeah, I'm very proud that today the team we think system and it's also willing to contribute, pitch in the knowledge. I guess we're still struggling to redefine how we going to save all this knowledge. We've currently exploring different options. There's no such thing as, oh, this is my design, I'm not sharing it. Oh sorry, you can't use this. This doesn't exist and hopefully it will never exist.
But yeah, I guess having just this realization that this is a common project or platform really helps when it comes to reusing and developing the system.
Chris Strahl:
Is it viewed differently by the business as a result? And so what I mean by that is the decision makers that are deciding to fund or expand, the pragmatic approach tends to be the one that, in my experience, drives real value.
I see all sorts of companies that go out there that say, "We're going to go build a design system." And what they end up doing is they end up using what is essentially a CMS to build some sort of reference site. But that's not actually helping them really ship product. It might be something that people can point at to be like, yes, we have a design system, or yes, we have this reference site.
That is what we should be doing. But it doesn't really bake into the workflow, how that gets done, how that shows up in product. The two things are somewhat divorced, and I think that's what I mean by you living in the future is you've been able to very pragmatically connect that. The stuff that is in your design system is stuff that actually ships every single day into your product.
And literally every change that somebody is making is something that improves that product stack across that organization. And that's things from the very, very small to basic componentry, to things that have a tremendous amount of value. If you're going and building an app and you're saying like we're going to have an authentication workflow, or we're going to have a four eye check workflow, or we're going to have any number of other pieces that you can just adopt from the design system.
Yes, sometimes you have to extend them or modify them, but on the whole, everything is practical because everything exists in production. I think that that's the biggest difference that I see between design systems that see this huge rise in adoption and are fundamentally seen as drivers of business value and strategic value, instead of things that just are ultimately reference sites on the internet for what should be.
Morgane Peng:
Oh, okay. Fair point here.
That reminds me. I saw actually several times Dan Mall's conference on your next component. He's arguing exactly this, saying that you should be focusing on what the community is excited about at that specific moment. You should be focusing on what brings the most value to your organization. The only way to do that is actually to talk to people and do a bit of research.
I definitely can feel this because I remember, so I use this example that when we introduce our adaptive color, so this is a color system that actually adapts to so color adapt to depending on what level they are, and also what kind of elements they are so we can guarantee construct ratios and everything.
But when we implemented this, that was not because we wanted to implement adaptive color itself. Or I don't think we even mentioned accessibility issues, which was one of the key reason we wanted to have this system. We did it because at some point in one of our training application, a client were complaining that they couldn't see the price properly. We piggybacked on this saying, "Okay, we need to solve this systematically because we can't just fix it for that specific trading application because it's going to happen again in another application."
Let us work on something that at the end of the day became a adaptive color system, and this is how we got funding. It's not by going around and saying, "Hey, we need to do that because I've seen people do this and the competitor are doing that, so can we do this, please?" It's really trying to recapture those moments and nuggets of interest and making sure this is embedded into your roadmap.
Chris Strahl:
Exactly. One of the things that is great about that story is it's very specifically tied to customer value.
I think that there's lots of people who get caught up in this idea of we want to have things that are on brand. Of course you want on brand experiences. We want to have things that are consistent. Of course you want consistent experiences.
But ultimately if you're able to serve user value in a systematic way across your entire app ecosystem, that's making better quality software. We talk all the time in design systems about the idea that this is about making you faster, less maintenance, and more consistent.
But really to me, design systems' true promise is the ability to build better software. And that is because of two things. First, it lets you take innovations adaptive color and make that just something that's generally available for anybody to use inside the organization. And the second side of it is it gives us back our attention and our focus on those harder, more interesting 20% UX problems that you were talking about, that oftentimes fall off the to-do list because there's so many other things that we could ship that are much smaller, much more bite sized, but ultimately don't matter as much.
Morgane Peng:
Yeah, and earlier you were talking about business values. I mean, how do business stakeholders react to that? That's very interesting. We actually had a presentation to someone quite high up in the organization. Obviously you wouldn't pitch the same way design system to this person than anyone actually anywhere else.
I think I didn't realize back then, but the way of introduced design system is obviously customizing to the audience, so to that person. I also introduced design system. I think the first thing I mentioned is design system for us, really, is a way to earn a voice online. Because for so many years, and anyone who worked in a big organization would understand that, if you don't have a clear strategy to do that, people will just do whatever they can. Because at the end of the day, they want to release their products and they want to release their own map. That will create a lot of entropy and when you start to have entropy, it is so hard to go back and to fix the things.
I feel for me, articulating design system more like owning a voice online. Because we invest a lot in our sales force and on our sales people. But having the same ability to eat online and also reducing entropy is a key argument for us.
It might not be obviously everywhere, but again, doing research and knowing what people care about in your organization is key, and suddenly he wouldn't care about design tokens and everything else that is currently happening now. I mean, if it solves a business issue, for example, we've done it differently with adaptive color, then yes, sure. But just saying, "Hey, Christa, forget what everyone's doing. Let's do design tokens." I'm not sure that's something that would have convinced him anyway.
Chris Strahl:
Yeah, I think that there's a lot of hangup in the implementation details, and I think that those hangups in those details are largely because this has been something that has traditionally, if we can even have traditions yet for a concept that's maybe a decade old, been the realm of individual designers and engineers that have driven a lot of these initiatives.
And maybe at the group or the team level, you've started to see a lot of adoption, but when you actually elevate to that strategic level and you start to think about how does my design system relate to business value and strategic value for the organization, framing it in terms of it gives us a voice online is much more interesting than saying, "Well, we can change a token value and watch that token propagate through our applications," what you're going to care about at that upper level.
And ultimately, I think this is where this is headed, at least that's what my opinion, is that we're going to start to see a lot of the decision making around design systems be viewed as more strategic and be viewed as things that ultimately are represented as executive initiatives. I want to have a better voice online. I want to be able to have a brand that connects with customers. I want to be able to exponentially grow my product through solving difficult UX problems.
Those are the types of statements that make that appeal in the place that I think really spreads design systems to be much wider inside of big organizations.
Morgane Peng:
That's exactly what we're trying to do. Even with this kind of extension of the design system mindset that we have on a business patterns, the idea is, again, sure does this thing that exist, you can leverage on it if it makes sense. If not, it's fine. But at least you're aware of what exists elsewhere and you don't have to restart from scratch.
I mean, I've been following those projects for long enough that sometimes I feel that we are always repeating the mistakes of the past, just to give non-sensitive comments such as asking when people are going on holiday in your planning to make sure that you are going to be able to deliver. Suddenly, everyone's gone and you have no one to give feedback on your product. This kind of things, it's like documenting those things. Or for designers having this tendency, especially when you're junior, to jump training to the high fidelity prototypes, but you haven't understand the full flow and then you realize, oh, you've designed everything and it doesn't fit the flow of whatever you're doing.
I feel like there's some common mistakes that we really want to avoid, and being able to document patterns is a way for us to trying to avoid history repeating itself.
But yeah, it's not easy. It's definitely an exercise, that it does take a lot of time to do properly.
Chris Strahl:
Yeah, and there is a dichotomy. It is important to talk about the low level stuff.
I think that the point that I was thinking about is that low level stuff is things that we've been talking about for a little while now. I mean, not a long while, but a little while.
What I'm excited about is this new conversation that is happening that is around that strategic value and around thinking about what does this mean for the future of digital at my organization or the future of product at my organization? I think that that's the conversation that's just getting started.
Morgane Peng:
Yeah. Obviously if you stay at the low level of buttons and colors, typography, you're going to be treated like this. That's very interesting because we had this discussion. Is the design system, is it a technical asset, or is it a business asset?
Chris Strahl:
That's a wonderful question by the way. I love I framing it that way about where does the asset live.
Morgane Peng:
Yeah, and what do you want to do with it? Is just to provide buttons and cards to services so they can develop faster then? Okay. I mean, that's valuable. A lot of design system are fully pitching themselves as a technical asset.
But again, for us, and also maybe because we are extending the notion to business patterns, we really wanted to place a design system as something that has business values, that actually has an IP. Again, because there's so much that we cover with the design team and so much that we have these days on all the use cases that these has values. And that's something definitely that we want to be understood.
This is why we actually ended up doing this exercise where we realized that 80% of the use case on the service were designed elsewhere. That was something we could reuse is really to show that this knowledge has values because obviously then allows us to go faster. But we had to do this exercise for people to really understand what that can bring, obviously.
Chris Strahl:
Yeah. What was the driver and what was the reaction to that sort of exercise? Were people surprised? Were people engaged and excited about it?
I understand you were trying to do this to prove a point that there is a lot of value in this that is beyond just building apps, but actually in how we leverage the work that we've done as an organization and how that relates to a lot of the things that you can take on.
But what was the reaction to that and how do people feel during and then after?
Morgane Peng:
I'm going to quote my CO because... I can't remember in a slide. I said it's something very the design system way, which is design systems allow us to build on our collective knowledge. I can't remember how I phrased that, but he looked at the slide and he was like, "Yeah, so I understand it's good for design. Is good for the money?" I was like, "Oh, yeah."
Another way to frame it. Yeah, okay. I could just go. Yeah. Again, it's the same thing said in a different way, right?
Chris Strahl:
It's like hey, there's a return on investment. I mean, business speaks in dollars, or euros in your case. But I think that there's this funny idea of when you're working with people on design teams and engineering teams every day, you tend to think about how it impacts their lives very specifically. It's better for designers, it's better for engineers, it's better for product people, it's better for content people. What better means takes on this context of it's easier or it's faster, or it makes people happier or lets them do better work.
Then you bring it up to that business level and it's like, all right, how much money are you saving me? It's a little reductive in how it views that, but ROI has lots of different forms. I think that when you think about how to express those forms of ROI at that business stakeholder level, that's where you start to make the connection of, hey, this is better for designers and that allows us to do X. It's that thing that allows us to do X that I think you have those lots of higher level, C level stakeholders and organizations.
They really want to understand that as it relates to design systems, because again, this conversation is just starting to happen. There's still a lot of gaps in understanding of why this has business value or strategic value versus why it has practical value for an engineer or designer.
Morgane Peng:
I mean, I could totally understand if we were having a discussion and they would ask me, "But why don't we just use anything that exists? Why don't we use Google material?" Yeah. I could understand that this could be also a strategy, but if we use that, that means we don't build anything. We have no knowledge around. We will choose follow all the patterns of Google, but is it even adapted to building training application? I'm not sure. Is it adapted to do very condensed, high data density data visualization?
Even Google adapts have seen some of the font sizes and design patterns in some of the more condensed applications they have. Yeah, do we want to outsource all this knowledge? In a sense in the past, that's what we used to do. We used to work primarily with agencies, external agencies, and then depending on connection, they would go different piece of the business and not necessarily talk to each other. Because obviously at the end of the day, they're in competition.
Do we want to just let this run wild, or do we want to do something? I feel like this is maybe some conversation we need to have. Yeah, sometimes it's an investment. Sometimes there's all right, sometimes it's good for the wallet the image my CO had. It's even better. Damn, I forgot it.
Chris Strahl:
[inaudible 00:25:11] that was, yeah.
Well, so that's an interesting sort of framing. You used to have this idea that you have these competitors, cooperators, inside of the organization that were building out all these systems. Putting that outside your organization for the way that we were building it made sense at the time. Everything is pretty bespoke. And so having some agency do some bespoke thing that isn't the core competency of the business makes sense.
But as you're able to centralize and work within these systems, the ownership of that system does make sense. And this is why Knapsack doesn't have an opinion about the content you put inside of Knapsack is because that content is where that value is in the design system. The things that you try to put in it, have you figured out how to string together, get how Pages and 17 other different apps to make a cohesive design system?
That's the problem that we want to solve, but we want to empower people to be able to build better content inside of their systems. I think that thinking about that content as a strategic asset and that content basically being the patterns that you're building, that gives you a lot more control and also a lot more insight into how those digital experiences are working with customers.
I also think it's fascinating to think about this as a legacy brand. I mean, the internet didn't exist when your organization got started.
Morgane Peng:
Yep.
Chris Strahl:
And so when you think about that transition, I mean that sounds almost like a change in just general mentality of what's valuable in terms of product.
Morgane Peng:
And obviously that really depends on the industry, but especially in my area, we are still pretty much... So again, I work in the corporate and investment banking area. Our clients come primarily because they have a financial need, whether it's to finance a bridge, issue some stocks buy another company. They don't come to us because they saw some kind of ads online and they're like, oh yeah, that looks cool. Let me just go and finance 10 planes.
That doesn't work like that, so primary human connection is. The financial need goes first, but we're still starting to see that now, not having digital tools that go along with this service that starts to be really bad for the business. And obviously when this happened, that's when we started to see a change in consideration. Because honestly, pretty much what people were thinking before was just like, oh, yeah, this is some kind of nerdy thing. We don't need that. This is for the internet, right?
No, no. We have services that we keep clients, and that involves depending on which industry you are and where you are in that process. I mean, we started to see some services where they would be the primary driver of a business relationship. But I have to say, this is still not the main driver. But being aware of all this really helps as well.
Because just to give you an example, the way we do usability testing is very different than how you would do that in retail. We really rely on a commercial force because they're the one who connect with clients depending on the client needs and the interest. Because, again to use the same example, we not going to ask a client to do a test to finance bridge if they're not even in that business. We do need a good partnership with business, and for them also to understand why we need the involvement in the design process.
But all this has been a long journey. Obviously depending on people, sometimes I feel like we like, ooh, going backwards, sometimes forwards. But yeah, I mean, that's why it's been interesting for me as well to just see how this evolves throughout time.
Chris Strahl:
Yeah, I mean, like I said, I think you're living in the future.
Morgane Peng:
I'm going to send this to the people who are still unsure, but thank you.
Chris Strahl:
But the idea of engagement with business stakeholders and people that are effectively selling commercial banking products and having their input into what you're building and ultimately the ability to affect the system of how you build, it's maybe not totally unique. But it's definitely something that's really advanced relative to where most people are, where I think, like you said, there's still this idea that design systems is some geeky thing that a few people are experimenting or messing around with.
And seeing that systems' viewpoint not just exists within designer technology, but actually make it out into the realm of how the business operates, it's really cool.
Morgane Peng:
Oh, again, that's why we don't have a name. Because if we have a name, that productify the design system.
I feel these days it's so easy to be against each other in organization. Oh, they just don't understand design system. They don't understand my craft. Yeah, something we've been very, very mindful of is really try to go beyond. And it's hard, obviously, because especially in big organization. If you don't have the same acronym, people suddenly become very suspicious of you. We've been really trying to explain.
But okay, the good thing, again, being in-house is if you start working, people will know. And then as I said, at some point, there's a tipping point where people who don't want to use the system but don't want to work with you have to justify themselves and not the reverse anymore.
But that takes time, relationships, and grind. Yeah, it's not something easy. It's not like a five magical tips to get everyone to listen to you.
Chris Strahl:
Yeah, that it's a little click baby for this podcast. But no, I think that what you said though is meaningful. The idea that you go from this point eventually where you've made enough culture change and enough change to the way that the business thinks about digital products, that people start having to justify why they're not using your system instead of you justifying to them why they should use it.
I think that it's actually valuable. We've glossed over it a couple of times, but I think that saying, why didn't you name your design system? I'd love to just let the listeners know why that is. Because I think it's a really interesting reason.
Morgane Peng:
Yeah. I was very convinced, but obviously I had to explain that to the team. And honestly, if they really wanted to go with Hadron, which is what they wanted at the beginning, I guess I probably will have give in. But I was saying, first you choose a name that honestly is so hard to say in French, people are going to be" Hadron, Hadron?" Everyone's going to be so confused, so you are not making your life easy by choosing a name that is hard to understand and pronounce already with some of the user base.
Also, if you have a name like this, then you have to start explaining what is Hadron and what is a design system? And people are like, hold on, but are you explaining design system? Are you explaining Hadron? Oh, wait is Hadron... Ah, Hadron is a design system. Sometimes what we want to do is not to remember what is the name of that thing. It's just to use it.
I use this analogy. It's a bit like, do you need to rebrand your HR team? I'm not sure. You just need to have HR. So we really wanted more to focus on the usage of the system. And of course that means we can't have shiny swags and we can't have shiny merch and everything. But I still also, especially for big organization like us, and I haven't mentioned that, but the design system is now used beyond our entity.
It's used by other entities as well. Not having a specific name make it also easier for adoption because... Let's phrase this way. If it has been named Morgane's design system, it would be difficult to sell it, right? Because people would be like, "I'm not Morgane, I'm not using it." But if you name your company design system-
Chris Strahl:
Or, who's Morgane?
Morgane Peng:
Yeah, who's Morgane, right? And then yeah, yeah. I'm going to send you to a marketing page where I explain what is Morgane. This is just creating a lot of disruptions, friction, on the path of getting adoption of your design system.
Yeah, we just decided to not have a name and just say, "Hey, there's the design system. You got to use it." If somehow they want to Google what is design system, there's definition out there. We don't have to maintain some kind of external marketing page as well.
Yeah, I guess that was just pragmatic as well, and just trying to make our life easier.
Chris Strahl:
Well, I love the pragmatism, and I love what you're doing. Thanks so much for being back on the program. It's always a pleasure to talk to you. I always learned so much from these conversations, so thank you. Thank you again for being here.
Morgane Peng:
Oh well, thank you for having me again. Again, I'm so excited to always chat design system stuff.
Chris Strahl:
Well, I look forward to seeing again soon.
Morgane Peng:
Thank you.
Chris Strahl:
Have a great day everybody. Thanks so much.
That's all for today. This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter at TheDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comments.
As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
