Rewriting the rules: How Moldova’s National Design System made UX impossible to ignore in Government Services

Ramona Ziemann at UXDX EMEA. Video: https://youtu.be/OcMUrs_bauI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Welcome to my neighborhood

[00:00:00] Good morning everyone, nice to meet you. It feels really special to be here today, not just because it's the UXDX conference, but because I am speaking for the first time in Berlin. Berlin is not just another random conference city for me. Berlin is actually my hometown. I grew up here, I mean, I'm born here, I grew up here, I worked here, I studied here, I lived half of my life here, and especially not far away from this location. So in a way, welcome to my neighborhood, welcome to Berlin, and thank you for joining my talk.

[00:00:50] Another thing why this speech is special to me is because around 10 years ago I moved from Germany to the Republic of Moldova. Moldova is a small country that is placed between Romania and Ukraine, and I think I would never have imagined that one day I would come back to Germany, to Berlin, to my hometown, and speak about a government design success story from Moldova. So thank you very much for joining, and let's dive into the story.

[00:01:22] We designers know what design systems are supposed to do, right? They should give teams a shared foundation, a single source of truth for components, patterns, rules, alignment, and ideally help teams to move faster and move more consistently. Our design system started with the same goal as well, to bring consistency and alignment to public digital services. But in our case it became something much bigger, it became something much more powerful, because we did not just launch a design system as a helpful design tool. We actually made the design system part of the legal framework, and that legal framework turned the design system into a mandatory national standard for how the government is building digital services. I think that is much more than making sure that you have consistency and alignment, and that is basically the story that I want to share with you.

The Moldovan e-Governance Agency

[00:02:41] Let me give you a bit of context on who's actually behind that cool initiative. I mean, it's of course me, but I'm working at the Moldovan e-Governance Agency, and this is the agency who is behind that cool initiative. We are a public institution that is operating under the government, and our role as the e-Governance Agency is to drive the digital transformation of public services in the whole country. That means we are building basically the technical infrastructure to make the digitalization possible. We are building the platforms, we are building the applications that make it possible for citizens, businesses and institutions to interact with the state online, so that you are not wasting your lifetime commuting somewhere to an institution to get some paperwork done.

[00:03:43] To give you as well a glimpse of what I mean by digital transformation: Moldova has reached a level of public digitalization that I would say many much larger countries are still struggling to achieve, including my very, very bureaucratic, paper-loving country, Germany. And here we are, Moldova is really far ahead of Germany in public digitalization. So today, to give you an example, today in Moldova more than 60 percent of public services are already digitalized, and our goal is to achieve 100 percent public digital services by 2030, and we are on a very good way.

[00:04:35] I want to give you a very personal example. I'm applying right now for Moldovan citizenship, and there is one document which, if you want to immigrate in any country, you always need to present, and that is the criminal record. In Moldova, if you have a digital signature, you can easily access any public digital service and request, either in a couple of seconds, your document, or, in the criminal record example, you can receive it basically next day, in physical format, in digital format, in any language that you want to translate, with all the possible stamps that you need to have.

[00:05:27] In Germany, and it doesn't matter if you are in the country or abroad, it took me almost six months, and I never knew when this document is ready. I didn't even know if my request even arrived at the right person. I had to implicate like four different people, to pay, to go there, to go to another institution to get all these stamps available, and then another person which brought me basically the document then to Moldova, because I had to present that in Moldova. So I think you just understand how non-digitalized Germany is, once you actually leave the country. But in Moldova the case is that citizens rarely need to visit any institution to get some paperwork done, due to the very well connected infrastructure that we have.

The friendliest digital state, and the 50 shades of UI problem

[00:06:26] That brings me basically to the next part, which is, what is actually our mission at the e-Governance Agency? Our mission is basically to build the friendliest digital state. Not the most digital one, but the friendliest one. Because digitalization, or digital transformation, is not just about putting services online, like taking a paper form and putting it into a screen and calling it a day. We are interested in the citizen experience, because for a citizen, governmental services need to be understandable, they need to feel connected when they interact with them, and they need to be as well relevant for them. They should not feel lost when they are using public services.

[00:07:24] And this is where we realized we had a problem. Before the national design system we had a huge, how I call it, 50 shades of UI and UX problem. We didn't have a shared visual language on a state level, and every institution was defining their own design, their own style, their own rules. Every vendor who was building those platforms was building it differently. So we had different navigation, different forms, different tone of voice, different content for the same thing in different places.

[00:08:07] So for a citizen, every interaction with a public service felt like a completely new experience. When you were navigating from one platform to another, the experience feels very fragmented. So yes, the services were online and digital, but they did not feel like belonging to one connected ecosystem. And that is a problem if your mission as the e-Governance Agency is to build the friendliest digital state. We wanted to make sure that citizens should understand where they are, where they need to go, and what should happen next if they are interacting with the service.

[00:08:55] So the question is, how do you make sure that dozens of institutions build services that still feel like one connected state experience? And, surprise surprise, our response was to create a national design system that shares now a visual language, giving basically institutions a tool to make this happen. So we gave them a shared visual language with a component library, with patterns, with behaviors, with rules how to use it, with documentation of how to combine all those components, so that they are not reinventing the wheel.

Making it mandatory

[00:09:53] So yes, the design system brought a solution for consistency. But if the talk was about telling you that, hey, we made just some components, I think I would make this talk under five minutes, right? So the real story is not the design system. The real story is what we actually created around that design system, and the other part is that we made the design system mandatory.

[00:10:23] We realized that if we just put the design system out there as a nice to have, as a recommendation, as a "here we launch the design system and feel free to use it", nothing would be changed, right? Some institutions will use it, some of them will ignore it, and then we are back to our 50 shades of different forms, different buttons and different navigation patterns. So we took another approach. I'm proud of that, that a design system was created by designers and pushed by designers. We made it part of an operational legal framework, and that feels very proud, to have that done.

[00:11:23] Let me explain to you a bit where the design system sits in the legal structure. We have at the bottom the government decision, which basically establishes the national rule, which says that every new public service must follow the design system. Then above that is basically the internal administration order, that is basically relevant for us, it's our kitchen, because we also as an agency have to tell ourselves that, hey, you also need to use that.

[00:11:58] Then above that is the methodology which we created, that I think is the second important part, because that explains the operational playbook, and it explains how institutions should apply that design system, when to apply it, and how to coordinate with us, with the Moldovan e-Governance Agency, how to use that design system, and how to get the work which they are creating, the institution, before it goes into development. But to the methodology I will come a bit later, because that's the most important part of that speech.

[00:12:44] And above that we are having the procurement itself, because now the design system becomes part as well of contracts, technical specification, implementation planning, and collaboration with the vendors who are actually helping those public institutions to build their platforms. And I think this is where design becomes like a governance infrastructure in this case.

[00:13:17] For those who are interested to see what we are building, what we did, how we documented the design system, feel free to scan the QR code and browse around our files. Don't get scared if the website starts in Romanian, but our Figma files in that example are in both languages.

[00:13:40] So, to sum up, we have the government decision which basically forces institutions to use it, we have our internal kitchen, we have the methodology which tells institutions how to use it and how to apply it, and then we have on top the contracts, where institutions and vendors as well must follow the system.

Three outcomes of making it mandatory

[00:14:02] Okay, so we made the design system mandatory. We are telling the people, hey, you have to use it. And basically what's next? What did we achieve now with that? Here I want to present you three, I would say, positive outcomes of what we achieved by making the design system mandatory.

[00:14:20] One big change is that we kind of changed the ways of working. By making the design system mandatory it kind of influenced how public institutions are building their services, because previously many institutions were approaching their projects in a very technical mindset. So they have an idea, let's find some developers and let's build the platform, right? But now, since we have that methodology, institutions need to think about a design concept, let's call it like a prototype, before it goes into development, and coordinate those concepts which they created with us. So we are basically playing this role like a gatekeeper, of making sure that they are building something real for citizens.

[00:15:28] And so the shift what is happening here is that we gave them the UI, let's call it like that. We gave them the foundation, and they have the navigation patterns, they have the rules, they have do's and don'ts, best practices, patterns and so on. So now they don't have to have 50,000 meetings of talking about UI and how all this platform should look like, because that's already resolved. Now they have basically the time to talk about the UX. So that means, what we wanted to achieve with that, as the e-Governance Agency, we wanted to be the gatekeeper, and we wanted to achieve that those institutions are thinking earlier about flows, about structure, about the content, about the real user experience, and this is where designers are basically playing an important role.

[00:16:32] The next shift was, we kind of, I would say, indirectly created a demand for designers, because many public institutions do not have the in-house capacity to have designers, and so they rely heavily on external IT companies that are helping them to build the product. But because now institutions need to coordinate the design concepts which they created before it goes into development, that means that those IT companies need to have a designer in their team, and they need to implicate as well designers much earlier into the process. So it's not anymore that some front-end engineers are creating something and then...

[00:17:00] [Roughly three and a half minutes of the recording, from here to 00:20:26, carry no audible speech; the automatic transcription produced only repeated filler, so this passage could not be recovered.]

Design QA, and what ignoring design costs

[00:20:26] ...and so on. So for them that was a huge help. As well, we kind of reduced the rework which they previously had, and made it basically part of that delivery process.

[00:20:45] Maybe for those ones who are in a similar situation, maybe you don't have the legislation on your side, but what you could do in your organization or in your company is introducing quality checks, we are calling it design QA, before something goes into development, to always verify what happened before somebody started to code.

[00:21:06] Because every time when you basically ignore design, organizations, institutions, companies, the state, will pay anyway later for it. Because the bad outcome is that you will have more rework, you will have an increase in support requests because people cannot find where's the button to apply, right? Or they simply don't understand the content because it's so complicated written. And at the end it's just bad user experience. And because the goal is not only to create better libraries, the goal is actually to create a better way of how to build digital services. So thank you very much.

Q&A: how do you make sure it is used?

[00:22:05] Host: Thank you. That was great. It's kind of, I guess, seeing the different levels of complexity in something like government services. I know I live in Spain, I'm struggling to navigate some of the services, so it sounds amazing. And we've got some great questions already in, so we'll jump in. How do you make sure the design system is being used, and how does the design QA look at this scale?

[00:22:37] Ramona: So, how do we make sure the design system is used? They have to use it, right? We have in Moldova a system where we know which institutions are planning which services to digitalize, so we are a bit aware of, let's say in 2026 this amount of institutions will come up with something new. We are also right now, we are really doing this, sending institutions an official letter of, hey guys, you mentioned that you will have those platforms somehow, you are working on them, so don't forget to send us something for review, and reminding them one more time that, hey, there is a government decision, there is a methodology which you have to follow. How the QA... what was the question with the QA?

[00:23:29] Host: So I guess they're legally supposed to do it, yes, but how do you validate that they are doing it?

[00:23:35] Ramona: Well, they just simply have to follow that, right? Because we had a case where an institution was aware of that decision and they were not following it. They were just publicly launching it. And then, yeah, we have to send like an official letter: guys, why didn't you do that?

[00:24:00] Host: Okay, so it's because everybody is published, you're aware of what's happening.

[00:24:04] Ramona: Yeah, yeah, yeah.

Q&A: accessibility, code, and design principles

[00:24:05] Host: Great. What about accessibility? What part is guaranteed by the design system and what part by the different apps? So where does accessibility lie?

[00:24:17] Ramona: Well, we are testing. I will make a disclaimer that we were, for example, not testing very much the accessibility in the sense of different user needs, because it was simply not the time for that. The design system, what you will see right now in Figma, for example, that's the status quo, and now we are kind of giving it out to people to get more feedback on where we can improve and so on.

[00:24:58] Host: So kind of at this point in time it's still with the apps, but you're hoping in future to incorporate more of that into the design system?

[00:25:03] Ramona: Yeah, yeah.

[00:25:06] Host: Great. Does the design system live only in Figma, or do you have a shared implementation in code, for example Storybook, and who owns and maintains it?

[00:25:17] Ramona: We are maintaining it. Right now it's in Figma. We are working right now on the coded version. Just before the speech I was asking my colleague who was in the audience, I was like, well, what is the status of it? Maybe they ask this question, I don't know. So it's like 80% done. We are really also reviewing what those engineers are coding, so it's also a QA here. But right now it lives in Figma, we are working right now on the coded version. And yeah, we are basically, the Moldovan e-Governance Agency is the owner of the product.

[00:26:01] Host: Brilliant. Your talk focused mostly on design systems. How would you weigh that against design principles, like not asking users for data that you already have? I know with government it feels repetitive, you're like, you already know all this about me.

[00:26:14] Ramona: So the tricky part is, and we are experiencing this right now, because a lot of institutions are now, so Moldova has a mandate of digital transformation, we have that goal by 2030 to get fully digitalized, that means all those institutions are in a, not in a rush, but urging to kind of launch something or to build something. And now we see that the ideas which they have sometimes don't match with our, let's say, components which we have available, or patterns or rules.

[00:27:02] Host: Yeah, I worked on a single view of the customer project in a bank and it is a nightmare. There is 300 systems.

[00:27:08] Ramona: Yeah. So you cannot be aware of all the possible scenarios and use cases. And we have, for example, a designer in our team which is working on a platform, and we are just seeing right now that, oh my God, this pattern we didn't cover, this doesn't work. But that's good, you know, we just launched something where we can work on, and then step by step we need to give it to people to get feedback.

[00:27:37] Host: I mean, rather than just working in the black box. Launch and iterate.

[00:27:41] Ramona: Yeah, exactly. It's really like this.

Q&A: red tape, and requests for new components

[00:27:43] Host: Brilliant. This being a government project, did you run into red tape, and how did you handle bureaucratic blockers? So you got this mandated into law, I'm assuming that was a bit of red tape.

[00:27:53] Ramona: Wait, what is the question again?

[00:27:57] Host: So when you were trying to get this adopted, the bureaucracy, the slowness, the difficulty, what were your challenges and how did you overcome them?

[00:28:07] Ramona: The challenge, I think, is to explain what is a design system, and what does it mean for institutions. Because you are talking as a designer to some bureaucrats, right? They have no idea what that is, and they don't understand how it helps them, actually. And that was a bit, not a challenge, but you have to explain, explain and explain. And I think once institutions are coming to the point to talk to us, because we're reviewing as well what they are doing, and giving them as well feedback, there is a learning curve. But yeah, so the blockers are more like, first of all, understanding.

[00:28:58] Host: Yes, I can empathize. Okay, I think we have time for one final question. How do you handle external requests for new components to fill unresolved gaps, and what is the response time that you have for those types of requests?

[00:29:16] Ramona: So if there is an institution who are sending something for review, we have like 10 business days to answer to them. Sometimes it can take longer, because sometimes I have to reassure something with our legal department. But usually 10 days is enough. And we are appreciating actually if institutions are telling us, or those IT companies are telling us, that hey, this component doesn't work, can you create something else? So we are basically then later defining if it's worth to make it globally available for everyone, or to just leave it as a local component on their side.

[00:30:05] Host: Brilliant. So it's never going to be finished, it's a continuously evolving piece. Well, that brings us to time. So thank you once again, Ramona. Thank you very much.

[00:30:15] Ramona: Thank you.