Designing with Code in Mind

Hello everyone, welcome to Designing with Coding Minds. It's really a pleasure to be here in the react Summit Remote Edition. So my name is Elisabet Oliveira. It's a Portuguese name. I'm actually, I was born in Mozambique and my father was Portuguese and my mother is from Mozambique. So I'm kind of a mix from Portugal and Mozambique, but I grew up in Portugal in Lisbon. Two years ago, I lived in Dublin for about four years. It was a good experience, but I couldn't handle living without a son. And so I decided to go back to Portugal. And since then, I'm working for a distributed team at Elastic. I'm a senior product designer and I really enjoy working in the distributed team. And most of us work like remote. And what I do at Elastic, I work for a project called Elastic UI. It's a design system where we have a lot of components. And the idea of this design system was born for, to provide components for another project called Kibana. But with time, people outside of Elastic started using this design system. And every day we see more and more people using the design system. Also a lot of people contributing with code and it's really amazing to be part of this team. And especially like this design system, we have like the data in mind. So we have a lot of components that helps you a lot if you're going to work with data visualizations. So it's really, you should give it a try. Especially if you have a product with a lot of data, really we have select boxes, color pickers, icons, buttons. There's so many things that table, data grid, a lot of things just that you can think, you can find in this design system. So this is like Kibana. Kibana is the window, let's say, the window of the Elastic stack. It's where you can visualize your data and when you can create data visualizations. And there's different apps inside Kibana. There's the maps, visualize. There's a lot of things there. So my work basically, I work most of the time for the design system, but then sometimes I work for Kibana. And today what I want to talk is about having a designer who codes in your team is a good thing. And the reason I want to talk about this is because right now I start seeing that there's a lot of teams where you have designers and developers and they only collaborate with images. And I think nowadays it's a little bit sad when people just work with static images like you have a Figma where you have a sketch and you work like having comments or sending the link to your Figma and saying, oh, this is what you should implement. Oh, this is the state. This is what you have to change. And then the developer implements that. And then the designer goes there and starts saying, oh, this is not well implemented. And sometimes as a designer, you can sometimes predict all the scenarios and then you have to go back to your Figma or sketch and then you have to fix that. We design and then you have to explain again to the developer what the developer needs to change. So I think that this type of conversation sometimes a little bit difficult or this way of working sometimes it's difficult. And because of that, I want to convince you that it's good thing to have the designer codes in your team. And nowadays, a lot of companies, they have design systems and actually a design system can help you a lot, but it's not 100% perfect. And why is not 100% perfect? Because if you see a case as a very big product like Kibana, okay, you can have components from the design system, but sometimes you don't have yet the component ready or you have to think when you build the components, you have to think how that component is going to work for multiple apps inside Kibana. And sometimes you have to create something that is only going to live inside Kibana and is not going to live inside the design system. So you have to provide designs to the developers, what they need to implement. And sometimes the implementation is not that easy if you think about the design parts. So I believe that having someone that has the skillset to go there and build that structure inside the product can help you a lot. And sometimes just having the design system won't work for these type of scenarios. So what is this thing of designing with code or with code in mind? For me, it's like you design with code. I mean, every day at Elastic, I'll go to the GitHub and I create a bunch of pull requests with things like fixes or fixing parts of the documentation, improving things, add logos. And sometimes I design with code and other times I design with code in mind. And what is this thing of designing with code or with code in mind? So I believe that it works better if you have a design system. So you need to have to design with code. You really need to have the components already done. So you just jump into a project and you fix things with the design system. But sometimes you have, as I said before, complex scenarios like the one in Kibana that you don't have all the components in the design system. And sometimes you need to create components that are going to live just inside that project. And this component is not going to be part of the design system. So I think for those complex scenarios, a good thing is to sketch the idea first. And also when you design with code, you don't need pixel perfect designs. You just need sometimes to, when you start designing, to say, okay, this is the colors I want to use. This is design that I want to create. It doesn't need to be pixel perfect because then you're going to do the pixel perfect, let's say, with code. So you just have the idea and then you fix that with code and you tweak that with code. So advantages of designing with code. First of all, states. You know, when you work with things like Figma or Sketch, it's a little bit difficult to create all the states. Okay, you can have symbols and you can have with Figma components that change states. So let's say a button, you can have different states, a warning button, danger button. But if you create that with code, it's easier because you just need to design a little piece, let's say the button, and define this is the colors that I want. And then with code, you just do the rest. And I believe with a designer who codes in your team, the teams can work faster because you don't need to ask someone to build that and then sometimes go there and say, this is not well implemented. So I believe that having a designer codes, the teams can work really fast. So this is an example of something that I helped. It's part of the Maps Teelastic at Kibana, inside Kibana project. So I was helping to create this new part of the Maps called a Layer Style. And I had a few meetings. I said, okay, this is what we want to build. I created the design and we also have the design system in Figma. So I said, okay, this is what we need to implement. And we have some discussions what we wanted to do. And this was like when the developer implemented. So as a designer, I could see right away a lot of issues, like some of the inputs didn't have like a space in between them. As you can see, like this input, this color picker is not the same size as the other inputs. He used a different size. And I could say to the developer, maybe with this screenshot, put a lot of texts, red text on top and saying, oh, you need space here and arrows saying what you have to fix. And then I had to go there and see if it fixed properly. And imagine that Elastic, we are a lot of people working together. And so what I did is I jumped into the project and I fixed myself with code. So basically I went there and I implemented properly the components that we have from the design system because he was using already the components from the design system, but he was not using properly. Like also this thing, these buttons, it was just appearing on over. He thought it was going to be better because maybe I didn't provide the specs properly. But the reason I didn't provide the specs properly is because I wanted to go there after and fix that because I can code. So this is what I did. I went to the project and I fixed that. I put the inputs with the same size and the final result was this one. I want to show you how it works. So I went to the Kibana project and I created a pull request. This is actually the pull request. In the pull request, I like to explain what I'm doing. I say, okay, this is the design changes. I introduced a gap between the two forms elements. All the forms elements are now compressed. All the roles are now with full width. It was introduced the fix to the left elements when we have two in a row. So I explained what I changed and basically I like to provide the explanations to the developers. So probably in the future, you will know how to implement properly our components from the design system. This is just a basic example of a way you can work when you have like a designer who can code. This is like a different thing. In this one was like the developer implemented first and then I went there and I fixed it. I just gave him some guidances, maybe a few screens, probably not that pixel perfect. I didn't give maybe all the scenarios possible, and I just went there after and I fixed that. With this one, it was a new component that I wanted to introduce in our design system. And I start noticing inside Kibana that a lot of places we start needing color picker components. And so I had this idea because we already were using different color pickers in different parts of Kibana. So I said, okay, this is a pattern that we have to solve. So I decided to create a new component and introduce this component into our design system, the Elastic UI. So for that, I created the component. This is like a screen from the Maps app. And actually this is not pixel perfect. I just did like a screenshot. And then from the screenshot, I just put on top this and what I had in mind. And I shared with the Maps team, I shared with my colleagues, I said, what do you think about this new components? We all agree. I said, okay, this is what I want to build. And when I designed this, as you can see, I just have a few screens. So I probably, if I really wanted to give this to the developer, I would need much more than this. I would have to explain everything like, oh, when you click here, this will happen. And I have to explain and maybe give much more details and much more screens explaining all the different scenarios. So because I was going to code the design of this, and this was just a reference to myself, I just designed this and what it was going to look like, not pixel perfect inside one of the apps. And I also tried in different apps of Kibana. And after that, I decided to, okay, now I'm going to implement this with code and we've used typescript and from the, when we are like defining the types, it actually generates our documentation. So we have to explain everything. So for instance, oh, this is the pallets. The pallets is like an array of objects that can receive a value title. And I explain everything. Some of them I'm a little bit lazy. I just say, handy. And then in the future I'll change. And then this is the most important part is actually the design itself, like the styles and how it's going to look. And then what I do is like, I create a draft in our Elastic UI. So with the draft, it generates automatically our preview page. And then from the preview page, this is the current state of the component. So, and then I can have better discussions with developers and other teams that probably are going to use these components. And I can show them, okay, this is what I have in mind. And we can have discussions. And I just code until just the design aspect of that. Probably for this component, I can maybe create everything, but probably after that, a developer from my team can fix better what I didn't do like properly. So I believe this type of working can solve the bridge between devs and designers. As you can see, it's much better if the designer can jump into the code and solve these small details. So you don't have these never ending conversations that I'll fix this, fix that, oh, I forgot this. And then you go back. It's, I think it's better if you have someone that knows design and goes there and fix that or create something from scratch with design. And in different companies, this designer has different names. At Elastic, it's a product designer. There's now UX developers, some UI developers really have design skills. And you can call this type of person wherever you want. But don't forget that teams should have different type of designers. So don't only hire or don't only try to have one type of designer. I see a lot of companies that only just have designers that create static images and then developers. I think you should have a balance of different type of designers. Ones that are really good with css and they know how to code a little bit of javascript, react, typescript. And then you can have one that are more visual. And you can also have then even developers inside the team. And then all of them together will make all the development be much more faster. And they will work much more properly together. And the teams won't have this gap between designers and developers and no more just static images. So I believe that the future we will have these new design tools. Like nowadays, I know that there's some startups creating tools like Models, Interplay, Figma. And I believe that this is going to be the future. And I hope so that these tools can generate a react code with typescript or not. And then I'm not sure how it's going to happen the PR part when I'm not going to be able to do it. The PR part, how are you going to put that in GitHub? But I believe those tools are going to fix that and think about that. And I hope you like to talk. If you have questions, go ahead and do it. And I just want to say thank you. Let's try to hire and let's try to have designers of code working together with developers. Let's improve our teams. And that's it. So my name once again is Elizabeth. And you can find me on Twitter. This is my website. And I really want to say thank you for all of you to watch this talk. Go ahead and you can have questions. Thank you. All right. Well, thank you. Thanks a lot, Elizabeth. Great talk. From my own personal experience, I know it's really a pain to work with designers that don't speak any code. That's not to say they're bad designers, but yeah, it's really a lot better if you have someone that at least knows a little bit about what you're doing and can understand how to think in components. And yeah, it looks like you really nailed that. So thanks for this information. We're going to jump right into the questions. My first question, or not mine, the first question that we got from the Slack channel is from Rita Castro. How do you handle those cases where the design system does not have what you or the designer wants to achieve, but you are not allowed to change the design system? Yeah, so it happens a lot in Kibana, especially because every time a different app needs something new. And sometimes just because the Maps team needs something new, we won't just create a component for our design system because it's just for one. So it will leave, this component will leave inside the Maps team or the Maps app. And so on and so forth. But then if you see that that component, the pattern is starting to emerge in different apps from Kibana, we start thinking probably we need to create this as a component in the design system. But sometimes just to create something very specific for an app in Kibana, we just start like having meetings with the team. We come up with ideas. So this is what I have in mind. And then sometimes the team itself can do the code or I can help with the code, or I can create some kind of, we start maybe with the prototype. I can create a working prototype. Maybe it's not, the code is not ready or 100% ready for being, to start being used inside Kibana. But at least it shows, okay, this is what we want to do. And we can already start seeing some issues that the component might have. And that's it. Yeah. Yeah, it's a lot more valuable if you can have at least a clickable prototype. And it doesn't need to be production worthy code, but it's easy to convey your ideas to the actual production code writing team if you are able to do this a little bit with a little bit of code. So that's really valuable. Oh, and a follow-up question also from Rita. How did you get into coding as a designer? So, because I'm from Portugal, so in Portugal we end up like doing everything. So years ago, my role was a web designer or web developer, web designer, and at that time, a web designer was someone doing everything. So my first role was mostly doing wordpress teams. So I was just starting buying teams and changing the css. And then one day I had a more complex team that I had to build. So I start building from scratch my own teams. So I had to learn a little bit of PHP, and then wordpress developers and web designers started like moving into front-end roles. So I ended up- You're kind of forced into it. Yeah, so I ended up like being a designer and doing also like UI or more like css. And one day I start doing things like with jQuery. And after jQuery, I started, okay, now I know jQuery. People saying that jQuery is not good. And I said, oh, I have maybe to start learning better javascript. And then from javascript, one day I just end up in a startup and we wanted to create something. And I heard people were using react or angular. So I, okay, let me try. I tried angular too, and it was so complex. So let me try react. And react for me as a designer, I felt it was more intuitive and I just started using. And never left. Yeah. Right, the next question. Do you have any tips how to make it easier as being a developer to bring designers into coding? At least at Elastic, I think one of the things we use GitHub for almost everything. So we communicate inside GitHub, and everything is almost open source, so anyone can see what we're doing. So even the design, when we're trying to fix something, I just put there the Figma link or I put a screenshot. And sometimes you really want to help, so you start seeing the value of GitHub. And as a designer, you want to create your pull requests and to be a contributor. So I see a lot of designers at Elastic that they really want to be a contributor, and they start with small things like fixing an icon or just changing one line of css. So maybe for those teams that want to make designers to code, maybe if they start using GitHub, probably they will start talking in GitHub, and then the designer easily can fix one line of the code there. Yeah, it's because they see what's going on in the code, because they have to communicate to developers in code or in the code environment, GitHub in your case. Then they see what's going on and might be more inclined to say, hey, this looks like I can do this. Yes, even like nowadays on GitHub, you have the suggestions. So you can, when you are reviewing the code, just maybe imagine that someone is using an Xcode instead of a color variable, and you say, hey, you can't use this Xcode, you should use this primary that is the right variable. So maybe you can suggest that on GitHub, or you can start, okay, let me pull this to my computer and let me try to change in VS Code and then do a pull request. Yeah, that's really powerful. We have time for one more question, and then we're gonna go to the next speaker. Do you use any tools to extract your design system components straight into react components? And can you recommend that? Sorry? Can you repeat the question? Yes. Do you use any tools to extract your design system components straight into react components? Actually, we have our design system already implemented in react. And actually, it's really funny because most of the design teams, they have a more advanced version in Figma or Sketch, and Elastic is different. We have all the components online already in react, and sometimes we don't have all the components in design in Figma or in Sketch, because we end up doing a lot of things with code, and everything is live. So sometimes something gets already merged, and we didn't have in Sketch or Figma. That's nice. So that says to me that a lot of the people are, just like you, are kind of a hybrid between design and development at Elastic. Yes, even like one thing that I showed at the talk, the color palette picker. As you've seen, I didn't have the final design. So I did the pull request with my final version, let's say, and then I have to go to Figma and include the design of the color palette picker. But I'm trying to finish first the code, and once it's merged, I can put it on Figma. So it will be first in live, let's say. All right. That's, never heard of doing it that way, but sounds like a good way to do it. Well. Documented how you want it to work. All right, Elizabeth, I'm going to ask you to go to your Zoom room. So there's a few more questions. So people will be asking them in your Zoom room. So thanks for joining us. Oh, that's cool. Okay, thanks. All right, I'll see you in the next one.