 My current job title is Lead Interaction Designer. I say that because I don't actually program a lot in my everyday life. Well, actually not at all currently. I have, however, been working very close with C and C++ developers and various flavors of web developers for almost 10 years now. The reason I'm telling you this is because I have actually proof that you can learn stuff by just listening to people talk about what they're doing and googling. I'm really good at googling. I have googled, I don't know, deep pointers, memory leaks, all sorts of things. And I'm going to conferences like this one. So I'm here today because I, as a designer, have been told for a very long time that I need to know how to program. I need to know the technology so I understand the medium I'm working in. And I think this is correct because it's really hard to do my job without knowing what actually is going on below what I'm drawing up in my wire frames. We do understand that. We as designers, and I think there's a lot of agreement also in this room that this is how it works or should work. And I know that you, like you, the developers, are excellent teammates and partners in crime when it comes to discussing functionality and my designs. So my wish, personally, is that you just knew a bit more about design. And we heard this morning, like borrowing UX principles for API design actually helps your work. And I would love everybody to come out from this presentation with a feeling that knowing the discipline of design, which is very much what you're working with, maybe side work with, would make our discussions that we should be having much more valuable and it would lead to much better outcomes. So I would like to tell you a story. Meet Marcek, or this is like a blurry version of Marcek. He's sitting on a fish in the middle of Oslo. We work together at CF Engine, which is a Norwegian startup building configuration management software. Very complicated, very complex beast. And Marcek was our database engineer. He was working in C and at the time we were working together, he was tasked with rewriting the whole database. This is a sketch, one of the many, many, many sketches I made. Illustrating one of our shared problems. So we were trying to make filtering on tens of thousands of hosts work for various people in various use cases. I was working on the UI. I don't need to go into the details here. But the database had to be working, or it had to serve multiple purposes for multiple users. So we couldn't just say like, oh, you make the database, so it works for me. It had to work for APIs. It had to work all over the place. So we had a lot of discussions. We had a lot of discussions on whiteboards. We had a lot of discussions over paper. We were banging our heads against the wall, solving really, really difficult problems. And one day Marcek came back to me and said, you know what? I found it. So he had been digging for, I don't know how long, and finally found a way that made it possible for me to design a sensible solution to this very difficult filtering problem. So effectively, he had been co-designing parts of the user interface. So how did that happen? Mainly, of course, because we talked to each other, why we were both working on it. But also because I explained what the problems were that I was trying to solve. So I took design a bit down to Earth by discussing my thoughts, asking for opinions, trying to make him understand what I was trying to do, showing very, very early sketches, like even earlier than this one, because this one is already pretty clean. I've been drawing boxes and arrows and things all over the place. And I demonstrated to the whole team of C developers that I was solving concrete problems and I was working at solving concrete problems. So discussion by discussion, everyone picked up bits and pieces of design principles and constraints and learned more about how and why I made those decisions. As a side effect, I was also exposed to a lot less bike shedding. So I wish I had that planned. I hadn't. I would like to start now with some myth-busting because I see a lot of misconceptions about what the designer is, what the designer does, what the designer, how a designer works. Because that is important to understand in a way because we're not in this box. I feel this kind of a mysterious animal to some people. So myth number one, one is born a designer. So the genius designer doesn't exist. I am totally not a genius designer. I suspect that that genius designer person exists just doesn't exist anymore than the genius developer. There are no unicorns. And all of the things I know, I have learned. I didn't even study design. I just studied opera singing. So it's perfectly possible to build knowledge just by sitting down and practicing and reading. So I spent many, many hours on learning, practicing, improving my skills, reading, asking other people about what they were doing, how they were doing it, looking at solutions that other people came up with. So design can totally be learned. There's plenty of resources available. I put some up. There's books, there's online resources. So there's actually no excuse to not look at them unless you think it's important, not important. So you probably don't want to become a designer anyway. So the basics will do, just like the basics will do for me. I don't want to become a programmer. Another misconception is design is this creative chaos. We disappear into a magic bubble and reappear with a solution or something visionary. So a lot of times I am met with the statement, oh, but you're a designer. As if no one could expect any kind of structured thoughts or works from me, it would just appear. So first, if you're not able to work in some sort of structured way, you will not get anything done. And design is work, just like any other kind of work. And I would also say that programming is equally creative because problem solving is a very creative process. You start looking at the problem, you explore options, and eventually you land on a solution. So this is my process. I have talked to a lot of people and they all have the same process. So the kind of design I do is probably closer to what your work is than any kind of digital or graphical design. So what I do is I drill into the details, I kill some darlings, I explore different options, I Google a lot still, I fledge out all the tiny details, I change some, I streamline the designs. I usually start from a very high level, I work my way down into the details and I rinse and repeat. From what I know about working, what developers or what you guys, the kind of work you do, this is very similar. And we iterate over it all the time. So if you're refactoring your classes, I'm probably refactoring my sketches. And for all I know, this is probably very similar for any kind of person who is solving problems. Another one, this is just plain wrong. Design is full of rules and principles and theories. And there are smart people who have written books about this, like Alan Cooper, the about phase that I showed before. He's like the father of interaction design, who's one of the, who wrote this about Facebook. And I don't think you should read that because they stick and it covers everything, but I did. But there's stuff out there that is more appropriate maybe for developers. So this is a very quick and easy read, it's very entertaining and it's very practical and it's just enough so that you understand the principles and that you can put to work right where you are right now. He also has a fabulous cheat sheet that is called the five fonts you'll ever need. If you stick to those, you'll be safe. Or you could take a look at the material design spec that Google has published. It's excellent, even if you don't do anything that is related to material design or Android applications or whatever. The way they explain the decisions they have made and how they came to this design spec is really, really useful. So you'd learn how animations lead a user through a process, why you can't make stuff fly in from the right after the user has clicked some place on the left, which should be sort of obvious. But the moment you start thinking about this, you see the world in a slightly different way. So why am I talking about all this? It's because I want us to be better at collaborating with each other. I believe we can all agree that designers should know more about technology, as I said before, to understand the medium. And there's a lot that still has to happen, but that's a different talk. But to be truly able to work together, all of us have to expand our skills on both sides of the spectrum so we can actually really meet in the middle and create an environment of mutual respect and understanding of our specific skills and trades. The first reason is obviously shared understanding. So if you think back to the sketch I showed you earlier, the sole purpose of this was to discuss a potential solution that I was working towards to solve our filter problem. And I didn't expect that to be implemented that way. I wanted Marcek to understand what I was trying to do. So he could actually solve parts of my problem or of the actual problem we were solving in the application because he understood what I was trying to do and how I was thinking the UI could behave. So that wouldn't have been possible if Marcek had never been actively involved in this whole process because then he would have been done with his database, had kind of handed it over to the rest of the team and then I would have worked my way. I mean, in reality, I look at the database and then I have to work in these constraints and sometimes it's really hard to solve the problems that a user has that is not looking directly at the database but who wants to interact with the data. So, with us working in parallel, we could inform our decisions based on what the other person was doing. Katie Kowalschen, I hope I pronounced that correctly, has had published a very interesting, a very thoughtful article on a list of parts where she states that involving engineers in all of their design reviews improve the team's overall understanding of the system, which obviously then led to much better results. So, she writes, the developers began to understand the thought process behind our design decisions and everyone could holistically understand the systems we were all building together. So, it's this kind of shared understanding that really puts value in our discussions and then leads to much, much better results because we know what we're thinking on both sides. Another one is shared vocabulary. While we're building this shared understanding of the system we're working in, we also build the shared vocabulary. So, an example from a recent conversation I had just some weeks ago, there was a developer saying to me, oh, but this doesn't work because I need a click event to run the query and update the UI. I suspect everybody in this room understands what that means. If I was standing at a design conference, I wouldn't be as certain. But how about we need to improve the glanceability of our navigation to increase the conversion rates for this particular scenario? Who understood what that was supposed to mean? I saw one hand, you win. So, just take a moment to imagine what those discussions and the decisions we're making could look like if you had some working knowledge of design while I have a working knowledge of engineering. Another reason is that we come to solutions much faster. So, we will achieve much better quality because we understand what we're working on in significantly less time because we work in a much smarter way. And that's Jeff Gotthoff. He is the author of Lean UX, which is a really interesting book. He argues for cutting deliverables and focusing on quick iterations. That's what he calls get out of the deliverables business. Let me just give a quick definition of what deliverables means here. It's like me working on wireframes, for example, that in addition to me sitting there and solving the problem, I have to document meticulously what are the different elements on the page, how are they supposed to behave, what are the ways from one screen to the next, how do I envision the functionality to come together so that the interface works as expected. This takes a lot of time. And it still is no guarantee for no misunderstandings or wrong conceptions or just different mental models on both sides. So, but to understand what this actually means, we need to look at how many of us, how many of us work today. So, we need to talk about process. Show of hands. Who is using some kind of agile process at work? A lot. Who of you who had your hands up in the air right now are working on large enterprise projects? Some. Keep your hands up. How many of you are working with designers as part of that team? Yes, hands go down. So, voilà, this still exists. This is a classic model which a lot of big companies still use today, especially if design agencies are involved. So it looks something like this. Analysis happens on the business side. Someone figures out what needs to be built for whom. Then the concept and design phase is taken by the design team. Or an agency. In a worst case scenario, the concept comes from an agency and then the internal design team has to make it work. And then there's the implementation phase which is obviously the engineering team's responsibility. We have handovers at every single side of this. Everybody focuses on the work of deliverables and the documentation which as I said before takes a lot of time to produce, a lot of time to read and digest. So, luckily a lot of people understand that this is not the ideal way of working. So more and more designers get better at understanding programming, engineering, and weasel their way towards the implementation phase. Some create functional prototypes or static websites as their deliverables rather than Photoshop files, which is already a good step forward. And we do that because we have understood that the classic model of handovers don't really cut it. There's a lot of misunderstandings and we're not happy of how it worked out because we care about what the end result is going to be just as much as I believe you care about your work. So, how about you weasel your way into the design phase? And I call that weaseling because you can't just say from today on I will be designing. You have to learn and then you have to make a change in the way, in the process you're currently working with. And I believe the weaseling way will make your life easier. So, I hear you. You're a busy people. You have a lot of things you have to do. Technology is constantly changing. It's a never-ending stream of things you could learn and improve them. Take new technology showing up that you should probably learn. So, do you really need to add yet another thing to the list? Well, you already are designing. I am convinced that every single one of you who's sitting in this room is already making hundreds of design decisions in your everyday work. You define button states, transitions between streams, database schemas, APIs, JSON schemas, graceful degradation, all these kind of things that falls into the engineering bucket of the work have direct impact on how the functionality is and therefore is design work in a sense. And this is what Paul Boagra writes in an article on Smashing Magazine. The truth is that as a developer delves into a building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest falls to the developer. So, the more you know about what we are trying to achieve, why we made certain design decisions in even the deliverables that you get, and more you know about the design process in general and the tools and constraints we are using to get to our results, the better all those design decisions are going to be. And this is not new, it's your reality. You are making all these decisions today. So, what about you start thinking about these details that you are deciding every day while you're implementing what someone else potentially has come up with? So, I would just like to leave you with this. Go forth, learn about design. You can learn on the job because you could ask to be included in design reviews and usability tests. You can read online magazines, such as A List Apart and Smashing Magazine. There's tons of books out there. I really recommend, for example, Steve Krug's Don't Make Me Think. He's like the usability guru. It's really nice to read and it's really entertaining. And there's so much in there that you probably do from a gut feeling that is now set on some sort of principle or framework so that you start understanding and seeing how these things work together. You could also start thinking about those decisions and be aware of them that you're already making and the effects they have. Talk to designers that you have on the team and ask them about this. And if you feel like really diving into the subject and get some more comfortable with how other people's work, take a close look at interfaces you like and figure out why they work and how someone potentially made them to work. A good exercise is to copy and interface and just try to find out how the elements fit together. And I'm saying copying not in the sense of make it look the same but make it work the same. So I hope we will know all leave this conference and start breaking down the silos. Thank you.