Integrating UX And DX

Marko Klemetti at UXDX Community: Helsinki. Video: https://www.youtube.com/watch?v=5BRuTDWIEWs

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.

Eficode and the design system as the basis for culture

[00:00:09] My name is Marko Klemetti. Some of you might already know me; at least I know some of the people in the audience today. I'm from Eficode. Eficode is an IT company which is currently based mostly in... this is our headquarters, just a few blocks away, and then we have offices in Tampere, and then two in Sweden, one in Denmark, one in Amsterdam and one in Germany. We're currently 250 people. What we do is mainly based on DevOps, and then of course development, which we call builders, because we also see development as containing everything that has to do with design as well.

[00:00:58] I'm going to be walking at a good pace today, not only because I'm the last one, but also because there's heaps to show. There are a few things I will first explain to you and then I will show you in real life, so if you see me skipping between browsers and code and the presentation, don't worry about it. It's on purpose. If you're going to pick something from my talk today, that would be: the design system is the basis for the organizational culture and automation. That's pretty much it.

[00:01:38] Everything I'm going to be explaining today has something to do with that idea: how do you bring everything into being part of the design system? I presume everybody knows what a design system is. If you don't, could you raise your hand? Exactly, cool. So then let's move on. Everything I'm going to show you today can be found on GitHub, github.com/eficode/design-system-example. It has really everything. It also has the virtualization environment, all the containers, the hosts, how to run everything that has to do with what I'm showing today. It's there.

Towards zero-day delivery

[00:02:28] Let's start with one of the main things of today. As already mentioned with everything we've been talking about today, design is one of the key points of how to actually get your product planned and done, and then what's the gap between that and having it delivered. What we believe in is what we call towards zero-day delivery. The idea behind that is: you have an idea, or you see your metrics of, say, your customer retention, or you're doing some kind of new version of your site or application or whatever. When you get the idea, or you see that the market is changing, that's the starting point. But however much time it actually takes until you release it or get it out is all spent time, or if you think of it the lean way, it would be waste.

[00:03:30] So what are the ways that you can actually shorten the time from getting the idea, finding something in the market, seeing a metric of something that has to change, to the point where you can actually release it? I've been mostly working my whole career in coding and releasing into production environments, which is the DevOps side, the automation side. But I've always been bothered by the fact that the people who work in the IT part are usually people who are waiting for the design to appear from somewhere, or they're the coders who are waiting for the design to appear from somewhere.

[00:04:20] And seeing that in the modern world, in organizations today already, the design, everything that has to do with it, even if it was paper prototypes, is moving towards electronic formats. We've been talking about InVision, I saw it here a few times, and I'm going to show my presentation using Sketch. It's how you move it towards the electronic vector formats, and then how you bring everything from the automation and release all the way towards design. That's the key. The part of coding, the actual writing of functional code, is becoming more and more insignificant. It was also a part of the Salon Dos [?] presentation and part of the presentation just before that.

[00:05:08] Writing the actual code is getting so much smaller. You already have the components, you have the style sheets, you have the HTML and CSS, you also have templates for the tests, you already have the pipeline for the delivery and automation, how to get your product into your production environment. Writing the code is just trying to pick the exact logic, or then actually picking another product that has already been done in open source or within the organization. That's something I'm going to show.

[00:05:44] The other part I want to say, because I said mostly design: what is happening all the time is of course that cloud environments become more popular. Finnair is also using heaps of cloud currently, and it's become mainstream. But what it's also brought is that it's becoming a self-service environment, which means that the development teams, including the design people, don't have to contact IT to say, "Here's our package, we'd like it delivered." Cloud, and everything that has to do with cloud, has enabled it being self-service, which means that many of the modern teams actually deliver the product themselves, because they have access to that part of the production environments or cloud that is part of the airport [?].

Starting a project from a template

[00:06:43] Cool. So this is how I see that modern software development should go. This is the example; some of you might know that it's from the React app creation. If you pick a Facebook React application, the first line you would write is this. The idea is that when I start a new project, let's say Finnair or Eficode or whichever, it should not start from an empty space or empty folder. What you do is you run a command which brings you the template of that particular product. With the template you naturally have, say, your style files or whichever, in a versioned format.

[00:07:46] I just returned from Australia yesterday, and they've been taking it really far there. It's a governmental example, and I like to show it because the Australian government has created a design system which has of course the components, the HTML, everything. They've decided also to expand it to React. And what they've also done, as part of the design system, is it's versioned, so you can go to GitHub, and if you find a problem in their design system, you would just post a pull request, and it would be merged by the team behind the design system. That's an example.

[00:08:47] So when you start a new project, you'd pick your style guides or whatever as part of the project, but in addition to that you would also pick everything that's included as part of it, which could be, say, the backend example, it could be the front end having the React components in place, it could be the provisioning, it could be the acceptance tests or whatever. Here's an example of a Sketch file. It's currently using a style package called UIkit. Some of you might have been working with it too. Don't worry too much about the components here, but you'll see that this is a basic style guide for UIkit components.

[00:09:44] What the designer would do is create a page. I'm just going to show you a simple login page here, which has the title, then two text boxes, a select box and login. What happens when you write in the version number and pick the package is you would also have the components ready-made for you, which means that building this page in code would be just writing text field, text field, checkbox, button. It would also have, for example, the provisioning on your own computer, which means that you run one command and it starts the project for you.

[00:10:43] And since you've written the text fields, checkbox and button, you can go to your browser and see: okay, here it is, my localhost shows me this page, which looks exactly the same as in the design. The reason for that is simple: this one line of code, basically. And the good part of course with that is, when you're maintaining a design system containing not only the components here but also the infrastructure, you could, for example, change the button styles and they would be reloaded immediately in the browser. Probably you are all more or less familiar with this stuff, but as I said, it could be taken so much further.

Why design systems, and what they usually lack

[00:11:38] Just quickly, why design systems are popular today. As I said, they are the uniform voice, identity and styles of the organization. Usually the style book is something that is divided within the organization. The Elisa style book, for example, is openly available to everybody from style.elisa.fi, as an example. So you don't just want to have the style book work in your organization, you also want to share it with everybody.

[00:12:14] They kick-start new innovations. You start a new project, you have a team working on a product, and someone starts a similar product. They are sharing the information in between; 99% of the initial product phase is exactly the same for the two projects, which means that through the design system you can share it all with the other team. Also, when you make an update in team two, let's say you create a new kind of date picker or some component that's pretty difficult to do but is inevitable as part of the product, when you've finished it you just promote it back to the design system, the same way as is happening currently in the Australian design system. Someone posts a pull request with the new component, someone who's the owner of the design system reviews it and merges it, and by changing the version number you get the new component.

[00:13:19] What design systems are usually lacking, and why I'm also speaking here today, is that developing and implementing them at organization level is usually pretty difficult. Let's say you have created your design system, which includes the HTML and CSS, and then you decide, "Let's expand this to React," which is currently the most popular JavaScript-based user interface design system, sorry, framework. And then you'd like to expand it to iOS or Android, or you want to have AngularJS as part of it. How do you get the team that starts the project in, say, AngularJS to actually contribute and build on the existing design system? So that if you later decide to continue on the Angular side, you'd already have it as part of the design system, and not just something that team extended for themselves and didn't share with the whole organization.

Tested components and acceptance tests

[00:14:29] Then the tested code components. To my surprise, which I'm very happy about, to be honest, the Australian design system already has the components tested. But it's actually not so difficult. In the example I have on GitHub, when you run npm test, it actually runs tests on the components, and it's something that also guides the component development. If we take the text field here and we just add a new span, just as an example, we've made a change, unknowingly, to our original design system coming from the version number. We see that okay, there is one failure in our tests, and the reason is that we went and changed our original design system. So we have two options: either we of course make a pull request to the original design system, or we try to find some way around that component. So testing, as I said, is a very essential part of the whole equation.

[00:15:53] And then of course the same goes for the back end. What we could have, for example, is a users test. Sorry, a bit more code, but it's really easy to read: should log in with a right email and password, something that most of the services use. What we do is we post to the server login, sending an email and password, and make sure that the response is accepted and it includes the user information. The good parts are that you already had your login system as part of the template you started with, and you also have the examples of how to write easy test cases for the functionalities that you start creating. In exactly the same way, if you made a change, one of the tests would fail.

[00:16:53] And then even more interestingly, as you already have your Sketch or any other design system tool in use, you have the components there. I already mentioned the date picker as one of the more difficult components. They're also usually really difficult to acceptance test. So what you would add into your acceptance tests, of course, is a way to write your test cases against the designed application. Here's just an example of six test cases with various usernames and passwords which are wrong, and then we're verifying that login fails with this particular information. What our acceptance test templates would naturally do is start a browser for us and run the test cases in that particular browser, or if you used a mobile application, you'd see them run on the mobile application, like so. And they also came as part of the original version number.

The delivery pipeline, live

[00:18:16] Then the delivery pipeline. As I said, it's actually not a big addition after this. I'm using simply Jenkins as one of the examples here, but you could use whatever suits best. You'd have the pipeline, which means that you'd have the building of the components, the tests I just showed you, the acceptance testing, and in addition you probably do some kind of security audit on your product, and linting, making sure that the code quality is similar in all of the components you're building. And then of course the deploy, which deploys the new version. While I'm talking, what I'm doing here is I'm going to try to deploy us the one with danger [?], like so. And our design system is currently working in the design system, hopefully that works, and once the pipeline is finished it should hopefully change the color to red. It will start in a minute, so we can continue.

[00:19:36] The key point behind everything I've shown you is that once you have this kind of way of working, with the designers, developers, DevOps, the whole production environment, what's happening here is that you don't only have that one version number with the one package, but you are also adding a way of enhancing better practices and enhancing automation. Which means that if one of the teams comes up with a solution for, say, security auditing, you want to know that the packages are secure, through that design system or the package behind it you would also share that practice with all of the projects. Let's see how we're doing here.

[00:20:25] As I said, the only things you'd actually need are the build and deploy phases. You build your application, you deploy to the production environment, and that's it. But how are you sure that it actually works, and how do you make sure that it keeps its quality in the future? You need something else as well. And as I said, as part of the whole thing, building an environment around automation, supported by the organization, would of course be the way of doing it. So here are the Robot tests, and then the last part would be deployment.

[00:21:22] We're having a good silent moment, waiting to see what happens. Let's see: the tests did pass. We have a tool called Kubernetes up and running here in the background; actually it's running Kube [?], hopefully that works. And once the deployment starts, what it does is just update the packages here. First it builds, of course, the production images. Perfect. So, this being the last slide, this was a quick glance into how the whole design system and styles can be taken so much further in organizations, to also enforce better communication within different units or within the organization. Cool, it's deployed. So once I reload, it should have turned red, which it does. And that concludes my presentation. Thank you.

Q&A

[00:22:38] Host: Thank you so much for the super insightful talk. Are there any questions regarding the design system from any of you? I have a question for you. Are you scared? Okay. Is this a project-based system, or are you using it company-wide? Because there might be different needs and different ways of how you do something.

[00:23:03] Marko: To be honest, in organizations, like I said, we are a consultancy company ourselves, and we are working with our customers to make their design systems better. Usually this starts from a team level. Someone like a propellerhead comes up with the idea of starting to expand. In companies that already have a design system in place, the HTML, the CSS, they would start expanding it to, say, React components. And then in Slack, or some other way of communicating, like at lunch, they would tell people, "I've actually created React components," and someone else says, "Wow, actually we could use that as well," and it starts expanding organically. And then someone picks it up and decides that this is something that we could actually do.

[00:24:01] Or then in organizations like Finnair or Telia or Elisa, just to name a few, what they would do is build a design system team that usually consists of people in the development teams, but they are the brains and the acceptance body behind what we are going to include in our design system, and, once it's expanding, what we are accepting into it.