Hello! Welcome to my talk, today I’m gonna talk about „Building Web Development Ecosystems using Design Systems“. My name is Fabian Hippmann and I’m the CTO of Moonshiner.
So, what is a design system and why do you need one? From our experience working with a lot client projects, building a lot of customer’s platforms, what we found is that before using or establishing a design system, the workflow is pretty similar. It was all the same. You started from the ground up, you got some designs from an agency that maybe did the design and you had to build everything from ground up. That means you had to do all the buttons from scratch, you had to think of how many different variations there are, you had to invest – from our experience – more than, I would say, 20% to 30% of your time of the projects just for setting up these base components and getting something to a stage where it can really be used, where you can build a platform as a whole – where you can take the components, you take the buttons, you can build the select, and then use it in an application.
What we found is that – still by starting this from scratch every time and having companies that just had a design and maybe some color variables – this was really tedious! Not only for us, but also for our customers. What we found and what we tried to do – or what we didn’t want to do as developers, is doing this every time. The effort is too high, the reward is… you can work, you can develop features and we found that building up or establishing a design system – meaning a common language, meaning some base commonalities between the design and the development – really helps, working on your project and then also scaling this to multiple projects.
When you’re working on one project, this may be fine – you’re doing your WordPress site and you need some Bootstrap application, that’s absolutely fine, or you use Tailwind CSS. But for us it was: we go to a customer, we had one project and we needed to build the ecosystem around it. So we had a progressive web app that we needed to build and we also had to build the dealer space – for example – in the background. It wasn’t an option to just do this every time and maybe when there is a small adaption, copy it and then maintain two systems – for us it really needed to be established rules. And it needed to be: okay, we develop it once, we maintain it, but we can scale and focus on the features.
Also when establishing – or really starting from scratch for companies that we work for – there’s often an internal design team. And this design team, they really have a strong UX focus, most of the time there’s also marketing and brand experience managers in the background that really care about their brand. For us it is also super important that we kind of merge these worlds together. They’re completely different, designers don’t have to know about development – developers, the other way around. And also marketing and brand is just a completely different world, where development most of the time is a product of investing your budget, investing time and effort into the whole program.
What we found is that we needed a way to connect those together – as I said before, we want to focus on the features, not on the pixels. When you don’t have the same kind of language as a designer, when you’re always talking about „okay, I need this button“ – the designer says „take a look at this file and just copy the properties.“ That’s not a working mode where you say you go to work and it’s really fun. As a front end developer – at least for myself it was like this – it’s okay, you can do projects like this. But really establishing and building an ecosystem, you need more „Fingerspitzengefühl“, you need to be more precise and there needs to be a mode established, that can be upheld for years to come and can be really put into the organization.
Like I said, consistent brand – it’s not only that brand managers say: hey, I want to have the logo the exact same way every time. It’s more about for the users. Imagine you have 10 applications or you have in the company your insurance provider, your bank, you have 10-15 teams working on projects behind it. A lot of times – from our experience – there is no common layer behind it. For the user there are no rules established, because it’s more „okay, we build something now and we care about this stuff, designs and that sort of stuff, later.“
This leads massively to super different UX and UI. There are cases where you maybe have a stepper component, where you see „okay, I’m one step from five“ and they look absolutely different from the design perspective. And they’re also independently developed for every projects – meaning n-times the effort for developing it. This, when you come from a customer side and when you company is really customer-focused, it’s just a no-go. You go to a homepage, go to your insurance calculator and you have to rethink completely. It’s like when you go from Google to Bing – you have to really stop and think „where do I start now again.“
This is something that we found hugely important to the people in the companies, that do the UX. It’s also important to the customers. Also important as the brand. Because when you go to a page, it’s not only that you buy insurance, you get insurance, it’s also about the feeling that this whole experience gives you as a customer. When you’re a bank or an energy provider, this is just hugely important! An energy provider is such a vital part of your life – you don’t think about it, but when you need it, or when energy is not there anymore, you really think about it. To keep customers happy, I think this whole experience from start to end has to be coherent – when you had a bad experience of going onto the system, getting your energy, or it was super complex and you had to get it from other providers. I think that’s a whole image that you build. And I think design and keeping this common is a huge challenge.
How – how do you do it? Or what were learnings that we gathered throughout the years? What we found – or the mode that we are doing – is that most of the time we really check the complete ecosystem of a customer. We try to think „okay, what technologies are they using, who are the key players that we work with, what will the collaboration look like, how easy should it be to customize it, are the guidelines really narrow and strict, or is it loose so that we can build the application however we want?“ After that, we establish most of the time a central repository for UI components, token, styleguide and CLI consumable through npm. So you can start up new projects, you can start developing a new project and you also have a styleguide where you see components and code one side – left side, right side. That really helps when working together with design people and development people long term. It also is a good way to constrict the design and components to one space, so you can test them and you can really develop them further.
How does it look like, what are the components that we most of the time try to offer when building something up for companies? What we do, we try not to just bring React – doing one technology most of the time is just not viable. When you come to an established system where many developers work, there’s just preferences, there’s good practices that you have to adhere to and that makes sense. I think it’s a luxury to really pick a technology. When the chance is there, I think it should be done. So when you can go to a company, evaluate everything and then stick to one technology – I think it makes it massively easier long term to build it up and to really get more developers working on it. But for cases where this is not possible, we try to not only offer technology-specific parts, we try to decouple it. So we have a multi-layered approach, that’s what we do usually. We have – for example – when you say, okay, you just want to do a landingpage HTML, some marketing manager wants to send the CSS to an agency and they’re not integrating into a techstack at all, the design system needs to be flexible. It needs to somehow accomodate it and at least for a small part needs to be consumed from the design system. What we are doing is that we’re offering the compiled CSS and we’re offering a blueprint on the design system, on the styleguide, where all the components are shown – so that you can copy the HTML-structure, import the CSS and then it will still look like it’s a fully blown React, Angular, or whatever application.
We’re also offering design tokens, meaning when you have a design system, you have the small building blocks. The small building blocks that we identified to make absolute sense is that to extract – for example – the colour, sizes, spacings and so on into their own packages, so that they can be consumed completely independent of the technology stack. They could be consumed in applications built on React, they could be built using Angular, but they also could be completely native, or they could just be a desktop application where you consume it. That is kind of the smallest building block in our design system architecture. So when you’re in a position, you say: okay I just want to have the colour, I don’t want to think about the spacing all the time, you implement the design tokens. When you say "okay, maybe I want to use the CSS, but I’m not feeling comfortable using any technology below it", you use the compiled CSS ready-to-go. But when you say, okay, you’re now maybe working on a long term application, you have an established techstack – what we’re building, or what we’re offering is most of the time two parts: we have UI components – this is the simple stuff, the stuff that just needs to work, the buttons, dropdowns, everything that you can think of that’s really super basic. Then what we’re doing is when you’re building a page and you want to have some kind of CMS content, meaning maybe a data privacy page, on one page it uses WordPress – WordPress is super fine for this case – you can still consume the library, show it in the WordPress context. But when you say you want to do a Gatsby-, Next.js- or Nuxt-Application, you can still use these bare components, you don’t have to think about „okay, how should the general page layout look like, how should it feel, how do we want to present ourselves to the customer?“ These two parts – UI components and CMS components – are something that we found super powerful. UI components is a thing, very basic, used widely – material design is something really built up from a provider. But also CMS components where you really have an added value after you build one page and you want to keep it all technology-agnostic, you don’t want to be hooked into using maybe WordPress, you don’t want to be hooked into using Sitecore CMS, you don’t want to be hooked into using Adobe Experience Manager and adhere to the syntax, but you can use it in any context that you like as a programmer. And we found that really powerful.
Something that we usually also try to deliver – I’ll come to that I think in the next two slides – is that we try to, also when a new project starts you say „okay, I now want to build up my website using the design system“ – meaning the components or the tokens overall. What we found important is that when you say you have a company with 10, 15, or maybe you have 30, 40 applications, it’s very important to keep track of them. Not just from a design- and marketing- and brand-experience, but what we als found is that when you need to upkeep an application, as a company you should be in control or you should have a view of everything that’s out there in the ecosystem at once. What we add is a project schema to every project that we develop or that is developed by other people – describing what APIs are done, how does the front end look like, how is it built, who’s responsible for it, this will then be shown in a developer dashboard. That’s usually our recommendation and that’s also how we handle front end applications at Moonshiner. We build applications for our customers and keep track of them using the logs, alerting and so on, using one central developer portal.
That’s for the „package“.
The next part is what we found – I described it before – you need to be able to communicate with a designer really efficiently. You can’t talk about „okay, this pixel, one pixel more at the top, okay I need a button“ – „but which one?“ – „the red one“ – „okay the red one with the outline, or do you need the one that’s just basic“ – „no, I need the one with outline“ – „do you need it rounded? What kind of shape do you need“ – this is maybe pretty obvious. Everyone says „okay, we communicate now in english“, when I speak to a german speaker that doesn’t know it – or knows it a bit – you get a lot of conflicts. It’s a very natural concept. This is something that we really found when that is not established, developing gets super hard. The developers really get irate, they don’t know, or they get super frustrated – same with designers. There’s more like a silo that you build up, you build not confidence in the system, but you build a wall in between. What we found that completely is enough to split this up is the ubiquitous language – meaning you establish a language where when you build a design, when a designer in his day-to-day life in the company works with a webpage, they use the same language in their components, in their structure as the developers do. For example, Figma is a really great tool for designers, but also they have a really strong developer-focus. Meaning that everything that they do and how they think and how their approach is, is connecting the designers closer to the developers. That’s why Figma introduced variants and components, so you can think in the design like you will be doing in the development. This is an example from – it’s not a customer project, but it’s – a stratum UI design kit. You see in the left side the designers – not like maybe some years ago, they just clicked together everytime, copy-paste it – but they really have the same interface as a developer. Here they have a type-dropdown, it says „okay, what is the outline, what is the base-shape.“ It says „okay, this field.“ And for the developers it’s then the same – in this example it’s in this case not the same, because I’m using different projects, but for the language or how it is done, the workflow and the mindset can be really much, much closer together. Then, what is achieved when the developers don’t have to think about five times what they need to build, is for us a hugely, hugely, hugely improved development-time and also the fun in developing it is there again – at least from our experience, there’s pages that were built up on a day with a design system, it was checked by a designer – I think the review took half an hour – then it was done. It was not five iterations to get it perfect, it was half an hour, taking a look at it, maybe giving some feedback, then adapting and deploying it. We think that is how development should really be and how front end developers just have the most fun with it.
I mentioned Figma – Figma is a great tool, what we’re trying to do is, you could just create also in Adobe XD a page, have some components, then name them similarly. The interface is not that nice, but you could do that. You could just write a text or the naming in on the left side, but what Figma offers is a component based approach – you build the interface using dropdowns, you really describe what you see. It also offers a really world-class Rest API, so you can all the content that you see on the screen in this tool through a Rest API and what we are using it for, is that we synchronize the basic design tokens, so the building blocks of building a design system from Figma directly into the code, version controlled, but this helps us also to abstract away a layer where you don’t have to think about it. So I know a lot situations, designers improve the whole design. Then they say okay, developer, please take a look, take a look at what values you need to change. Then it’s a process. When you have this maybe once it’s fine – when you have it every week, it just gets super tedious and it’s a task that I think nobody likes to do, the review process is very hard, for the designers as well, developers as well and for the whole brand experience. What we found: abstraction is a way, automating it makes it much more reliable, takes away the work from developers and also really tries to incentivize the designers to think about their whole structure properly. When they know they have an impact to that code and that the developers really know what they changed, they get insights into that „thinking way“ by checking these schemas.
Yeah, I wrote it: Figma is really a great tool, even though I’m more from a technical side really found it out to be a really great partner. We did a lot of different design tools – Adobe Vision, XD, Envision, whatever – Figma is really just, I think, for us the future for design systems.
So, what’s the next part? I kind of want to tell you about some showcases that we did and where we established design systems – or re-established – together with the internal technical team and the companies.
The one case is Wien Energie – we built up the Wien Energie website last year. When the whole lockdown started – I think there was a day when Sebastian Kurz announced „hey, you all have to stay at home.“ We went into home office, started the project up and we built it. We were super enthusiastic to build it up and what we did there is, we built like the website that you see when you go to wienenergie.at, using a design system that we built ourselves. And I think now there’s – in maybe half a year – there were four or five different applications built, also by other people. It adapts to WordPress, it adapts to schema oriented CMS as a back end, we have it available in Gatsby, we have it just with React, I think we also have it available using Create React App. It’s really a good use and the feedback from the users was really that it’s a good way and I was really surprised that it just works so well and application could be done in under a day. Before it just had to be brought up, there had to be much more iterations.
XXXLutz – we helped out to build up the XXXLutz Group digital architecture. For the e-commerce shop, we built this up with the internal team. What we found – very important – was that a design system needed to be established, because XXXLutz is multiple brands – they don’t only have XXXLutz, they have Möbelix, Mömax, POCO, all under their brand. They all have to be maintained. And they’re maintained – that’s the luxury I talked about – by one techstack, it’s React based and it can all be maintained by the same team.
Signal Iduna – for Signal Iduna the challenge is that many different people use it, different techstacks. So we opted there for a Web-Component based design system, on the front end rendering part still offering the CSS design tokens, but using from our preferred stack web components. There, a really large focus is on „okay, how do the developers and designer communicate, how will they build future applications lasting for years and how can teams be built up, using this as a base?“ All of these three – I think we have some more – usecases were really interesting projects. Starting completely from a green field, where you can really think about what will be important in two, three, four years for the company. You can really – like I said, XXXLutz, they went from having one shop, trying it out, building it, into having four brands, twenty different ecommerce shops and other applications and a growing number of developers – hugely– and improving a lot, learning a lot as a company. And also for us Moonshiner – really growing together with the customer.
Yeah, so these three usecases I think were super positive and we as Moonshiner always try to improve on it, this is now a quick overview, it’s not perfect, but I think we found a good mix.
The tools that we’re using, they’re not secret. I mean this is not super in detail, but what we love using, we do design systems using Vue.js, Web Components and so on – but we found React and Preact to be a super powerful view-layer that you can build up on. You can still integrate into Angular applications – with a bit of twisting. But using React, the structure, the whole system, it’s really so well thought out and for us it’s a technology that will be there in many, many years. Also seeing what the brains and the community does in React is just really satisfying for us and gives us a lot of confidence in the system to use it. Also there could be many other technical frameworks – Svelte and so on – but for us, when we go to a customer we need to make sure that what we establish there is really proof. And we know in five years, we will find developers maintaining it and we will find many people still loving and understanding what it does.
Reakit – I have togive huge props to the Wien Energie – is an accessibility library where we build our design system on top of. It allowed us to not worry about accessibility all the time. We had to keep in the back of our minds, but we know Reakit offers us a really solid base that does the accessibility part on a really good base. We used it – used the forms. I have to say the form integration is really excellent! Managing forms, form state and the whole accessibility and compasability is really great. Also learned a lot from that!
Yarn – we really love to work with Yarn. We have experience using learner and using npm, but we found that Yarn is just the speediest – crazy good compared to learner or npm! What we use all the time is the workspace send and the monorepository approach, meaning that you have the most important parts that belong together in one repository, it’s not 100 different cases or libraries, it’s most of the time what I described before.
Like I said before, when you have a huge ecosystem, it’s not an ecosystem when you have one application. It’s an ecosystem when you really build this stuff up in a company and for that we integrated or we monitored backstage.io really closely. When we started 2007 at building up the XXXLutz platform, we already thought about „okay, we need a developer platform, developers need to be able to see what we work on, what we’re responsible for.“ Last year, backstage.io – powered by Spotify – they open-sourced the internal developer platform solution and we found there’s a lot of adapters already. We think backstage.io makes it really easy to get an overview of your whole digital ecosystem, not only front end, not only back end – which is usually the problem, you have either monitoring on the back end service or the front end. In this case you can put everything into the platform. Developers can build their plugins, you see logs that you may have, you see the documentation, you can build up your onboarding, it’s really your developer landscape for the company. We as Moonshiner – as an agency – found this to be a really powerful tool and also saw it in the companies that we work with that it’s already becoming a part of their developer experience. It’s really fast!
Yeah – I think it’s always good to close out with a lot of love! So these tools, they may be easy in this name and with their logos here, but we proofed these tools over and over again. We just found that we will stick to it – why do we stick to it – should we change it – we thought about that a lot. But they really proved to be super worthy and we’re happy to work in a community or work with tools that have such a strong community and will last companies that we work with. We establish this for a long, long time.
That’s my talk about design systems, or building up web development ecosystems using design systems. If you have any questions, I think there will be a Youtube link somewhere, so leave a comment! Subscribe as well to the devjobs.at channel. Or contact me at email@example.com if you have any questions that you need to know or – while we’re here – you want to work with us and you want to be part of this whole design system journey.