(electronic percussive music) (audience applauds) - Alright, I know it's post-lunch, pre-coffee, so let's get you to move slightly.
Little show of hands, who considers themself primarily a designer? Quite a few of you.
Who's primarily a developer? Awesome, and who's both? Cool, okay, well it means I can't hack on either group, but we'll work with it.
(audience laughs) For what it's worth, I've tussled with this question for the entire time I tried to make this talk. And I realised I think the best thing is to say that I'm a developer who loves design. I've been on design teams for a long time now, starting with the design team in Atlassian that worked on the first design language for that company. And it's gone on from there, and I realise that design teams are a great place for developers to be, and that's where this talk's coming from.
But it wasn't always like that.
Like many people, in the early stages of my career, design and dev were just two tribes, never the twain shall meet, lovely big wall. And we just threw things over the wall at each other, and bitched in our beer about how the other side, God, they should know some more about what we do. What are those idiots doing? And it only changed for me when I started learning more about design, and understanding what designers were trying to do in the first place. And I've been really lucky to work with a whole bunch of fantastic designers who had the time and the patience and the generosity to teach me, to actually put up with my dumb questions.
Even more scary for me right now, is a bunch of them are here, including Amanda, who is the first designer I truly worked well with. She's probably bright red and angry at me right now for saying that. (woman laughs) But I've also seen the reverse, of developers helping designers learn code, or at least to understand what the code was doing. And I think that this made everyone involved better. It certainly made me a better developer, and I've seen designers grow, and grow their toolkit, by learning more about the code.
The more I understood, the more I realised that a lot of design and dev conversations go a bit like this.
Really strongly held opinions, and why? Because, well, realistically they're both right. And because developers like to be right and to win arguments, this can go on for quite a long time. (audience laughs) And I also realised that design and development really have a lot in common, they're both highly creative pursuits, they're both about solving problems for humans. We have similar group critiques and reviews, and I think we even share the same sort of frustrations, like we've all got the nephew. (audience laughs) Sorry, throats a bit dry today.
And I've learned that there's a really big difference when you're talking about things developers and designers should know, it's really about each other.
That's really the bit that's missing from the end of the title.
And there's a big difference there between knowing something to understand it, which is about empathy and building respect, and knowing to be able to do it, which is doing the actual job, to whatever level you do that.
And I think that we should all embrace Shoshin, beginner's mind, no matter how good we are in one sphere, to be open to the fact we may be new in another, or to learn new things about our own craft. And I propose basically a golden rule of collaborative knowledge, learn about others as you'd have them learn about you.
If you expect that other role to understand what you do, go and learn what they do.
Learn the basics of their craft and it tends to flow. And there's an obvious corollary here, be a guide for others to find the joy you found. Because you've got to a stage where you're passionate enough to have come to a conference. You obviously enjoy what you do.
Somewhere along the line, people helped you find that. They showed you things that you thought were amazing. And what can really be more satisfying than being that person for somebody else? Or to put it differently, geek out together. Like just get excited at each other, it's really fun. And this leads to the inevitable question that has to be raised at every conference, or you're not allowed to have one.
Should designers code? Look, it puzzles me and kind of ticks me off that this is not habitually asked in a pair. Should developers design? Because asking this out of balance is really, really silly. It belittles whichever side you say should go learn the other, but it also puts design on this weird pedestal, out of reach of these pleb developers, oh, they won't understand that. No, we'd better do it, I mean they'd use Comic Sans. No, we wouldn't use Comic Sans, we'd use Roboto, that's developers' Helvetica. (audience laughs) In any case, it's nonsense.
You can't do design, or development, without impacting the other one.
They're not separated, design choices, from the very beginning, will have impacts all the way down through the UI layer, down all the way to the data layer.
If you design a screen that requires monstrous amounts of data, you'll melt the server.
If you find that out too late in the process, that's when really bad problems happen.
You've got to go back to your absolute conceptual level. You do want back-enders in your sketching sessions. And the same thing is when design goes to devs, they find the gaps, they find the bits that don't work, they help the design evolve, so you just can't separate them.
So all this hand-wringing, like would we really ask should we be good at our jobs, or should we build empathy with people? I don't think we'd question that.
So I think we need to move to a different question, to what level should people design and code? None at all I think we can rule out.
Like I said, if you don't know some of your counterpart, you're just not really very good at what you're doing. You will be limited all the time and you won't even know it. I didn't know that until I learned some design. But I do think we should knock off the top one, which is doing something all the way to production level. That's not really collaboration, that's a career choice, that's a career change. I don't think we should require that.
Now I'm saying I think I whole bunch, right? Now opinions, opinions are lovely, but we all know opinion-driven design is pretty awful. So I decided to try and get some data, so I naively ran a survey.
Now, having had my survey retweeted to literally over a million people, 176 responses doesn't seem like a lot, but that's actually enough, my analyst friends have assured me, (audience laughter) this is enough to rule out the variations so we can use this data. But it's okay, 'cause it kind of confirmed what I expected anyway.
How much code should designers know? Massive spike, 52% said they should know how code works, but not do any, and 42% said be able to do it, but not to production, right in that sweet spot. And same thing for developers, it was really much the same thing, slight variation, but that's probably just because of the number of people up there.
Now, I'm not gonna go through all of the data in this, I will release it later on.
I asked other questions as well, which I'm not gonna get into today.
So we can come back to this, but hey, now we've got data for extra shine.
And I think that the exact level you choose inside this range really comes down to how does your team work, who've you got, who do you have and what do they do? Because if you think about a collaborative session of developers being in a sketching, or ideation session, and the designers taking it through to the final, that's an example of this where the two sides needed to work together. And similarly, a designer might come in with some hacky code, and they'll hand over that concept, but the developers will make the real one for product.
These are examples of what I'm talking about. So, what then should you learn? We'll get past the if, and I'll say what.
So I figured roles, process, basics, history, and schools of the craft.
And in the data, this is the shape of all of the answers, so apart from what I'll show you in a moment, pretty much 70 plus percent thought that roles, process, principles, were all important or critical. So that's pretty good.
The free text talked about respect an awful lot, and wishing the other side would just come from a position where you assume your counterpart has a good reason for what they're saying.
I am really sad about this result, though, where most people felt the history and the schools of the craft weren't important. And I don't think you can really push forward in your industry without knowing how you got there. And as Mark pointed out this morning, art began at least 40,000 years ago, and art being the root of design, that makes our contribution a little bit more in context. Mathematics, established around 3,000 BC, root of programming, but if we want to come more forward to programming in GUI design, that gets us first programme, 1842, Ada Lovelace. And then the first GUI's were really radar displays, and these inspired Douglas Engelbart.
And you probably know about the mother of all demos. I think that's just, we need to look at that, because it's technology forcing design to evolve. Everything we use, from waking to sleep, has been intentionally designed by somebody. But everyone who did that was standing on the shoulder of those giants, as we all do every day.
Plus, there's a commonality I think it's a pity to miss. Just as these are design movements, there are programming paradigms.
Long running, heavily debated topics, that some people will say you can be right or wrong about. But you really can't, they just are.
And this is, to really push it, there are papers suggesting that programming in its current state is post-modern.
I think it's a pretty good theory.
Let's get back to the crowd pleasers.
Roles and process, now, I thought this was a great thing to ask, until I realised that trying to tell people what roles and process is like is like defining normal, okay? 'Cause job titles are so unreliable I can't really do much there, and every team works differently. So I'll give you some quick shapes, but what you should do, is go and sit down with your team, find out how you role.
Someone's gonna disagree with everything I say now, but research to me is basically figuring out are we solving the right problem? UX is how we're gonna do that, how is the flow, what is the specifics of our solution? Interaction, how do the things behave? And visual design, how things look.
Now, for developers, we tend to think of design as visual design, we tend to get very hung up on the literal, the bits that we can see and we understand a little bit more easily. And there's this lovely illustration by Jasper Stevenson showing how most designers tend to have a spectrum of skills, and that determines the job title. And I think that's a really good way of putting it, because you have the same thing on the development side. And the more we realise the things that bring us together, the better.
Dev roles, I get why these are hard to follow. Frontend or UI code, that's code for rendering things into browsers, they're the people you will work with the most, but not the only ones that designers should work with. Backend's about applying business rules, data is code to supply content.
DevOps, code to deploy the other code.
And then QA, which is code to make sure the other code is still working. (audience laughs) Crystal clear, yeah? Now, you might be really shocked, but there aren't any really lovely graphics about development roles. I had a crack at one, and every single line was just marked full stack, that didn't help. Process is the same, while every team does differ, there are common shapes.
For developers trying to get into what's going on in design, the double diamond's a really good one to start with. It explains why sometimes designer feels like it's gone backwards if you don't understand this process. Because you diverge in the problem space, and then you converge back to the problem you're gonna solve, and then you diverge again to look at solutions, and come back to the actual one you're gonna build.
But if you miss that double diamond, it feels like you've suddenly gone backwards, didn't we have one yesterday, you know? I think this is the best one, though.
Everyone should see this, I'm sure everyone's seen this at some point, the design squiggle.
I think this is the best way, this is what design feels like to me.
Lots of doubling back, lots of craziness, and then really certain, really good clarity. And that's when you know you're ready to hand something over to be built.
Development, there are two big processes.
There's Waterfall, where you do everything in one massive hit, and there's Agile, where you do the same thing, but you write circles. (audience laughs) But seriously, most teams do use agile these days, or some variation of it, and the thing that's most relevant to design and dev collaboration is this, the concept of MVP. And while the bottom one is meant to be the ideal, where you're usable all the way through, both of these happen.
The top one requires a lot more trust between design and dev, so that's why you want to be able to talk to your team, and know how this is gonna play out for your project. Because you might have to design a component in isolation, and then you're probably gonna have to adjust that component when you get it all together at the end. But it's still the better way to go than waiting 'til the end to do everything. So the basics, the basics is where things get more interesting, I suspect.
That for designers, I think the basics you want to actually know about code, they're really about knowing the medium.
There's things that you need to know, like I said before, that design will break code. It'll make problems in those design choices that can't be resolved in the code.
And then there's working together.
Yes, you need to understand HTML, but I'm gonna try and tell you the why behind these things, not just the what.
Why do you need to understand HTML? You need to understand why a menu, and a select, and a form behave differently, and why you can put an icon into one, but you can't put it into the other. These are things you need to know, because it changes how hard and long the dev time will be. And CSS I think, we all know by now, we're the only people that do this, the drag back-and-forth thing.
(audience laughs) But if you don't sort of get into the browser and know how it feels, and how the break points are gonna work, all that kind of stuff, and how grid and flex box actually work and what they can do, it's gonna be a real struggle to design with them. So, on the upside, there are lots of lovely, sort of visual tutorials you can do. Now JavaScript, I direct you to the idea, Chris Coyier published a screencast titled something like this is the one trick designers need to know about JavaScript, something along those lines.
There are links in my slides for later.
But if you can learn how to click something, and put a class in something else, you can probably build every concept you've ever tried to mark out.
You can probably do whole websites with that. Accessibility is kind of a call to arms, we need you, we need allies, we need designs to not come through with pale grey small text. Not because we disagree with the aesthetics, but it breaks accessibility, it simply cannot be read by too many people.
And just like colour theory isn't random, accessibility requirements aren't random.
Performance budgets, there are whole articles about this, but you should be talking to your devs about performance budgets, it's why you can't have 10 typefaces and a fast site.
So this one, okay. (audience laughs) Designers, I am strictly talking to you for a moment here. This is an intervention.
(audience laughs) Now I know you're all modern designers, you don't do this anymore, so I'll just fix this slide. Just a second there, there we go, right.
(audience laughs) (audience applauds) You need to find a way to transfer files, and keep them in order, and understand that somebody else could have to look at this directory and figure out what's going on. Beginning dates, just put the year, month, date, it's an easy, easy way to change what you've always done to something that someone else can figure out. But if you really want to impress your developer friends, (audience laughs) learn semantic versioning, and if you really want to know how much I geek out about this, just search my name in SemVer, and watch the entire talk I've already done about this. And I swear I am fun at parties. (audience laughs) But don't think you can't do it.
This is a screenshot of what my current head of design Miranda in Figma.
By the way, Figma, awesome, like Sketch but everyone can use it. (audience laughs) Figma iterations in our design system are versioned, and they're released like this, so that the symbols go out in lockstep with other things. So it can be done.
After those basics, there are lots of things you can do. And I think the obvious one is to keep learning more code. If you are willing to look a bit, and learn a bit about terminal, it's a bit like learning to click something in JavaScript.
One little thing that sounds scary will unlock the ability for you to do things like run up the app yourself.
The tools you want to use with CSS are all on CLI, it's an unlock skill.
Data structures and AI concepts, high level. Just understanding what they are, because they will affect your design.
Developers, alright, developers in the room. Design is not random. (audience laughs) If you take nothing else away, design is not random. The biggest thing that you want to do as a dev is learn enough that you can understand what your company's design language is all about. And that will tend to lead you first through visual design basics, so I know that I said that that's not all of it, but it is where you're probably gonna start. But when you can answer questions like why do we pick those colours, that typeface, why do we animate things a certain way, that's when you start getting the real value. These things that are not too hard to learn that demystify design.
Colour theory, so many devs get into it this way. Because colour theory's basically maths, right? The idea that designers go and meditate on a mountain and come back with a palette (audience laughs) look, it's good myth, but they're plugging stuff into these same tools that you can get online that'll tell you, oh, this is my brand colour, bang, ooh, there you go.
Now it's not slavish, you don't literally follow it. But it's the way that you understand how palettes come together.
I think this one's more interesting, though. And I did this literally a week ago.
I gave this one to a developer at work who was like nah, nah, I don't care, don't care, don't care. Five minutes later, and I mean literally, this is fascinating, I got this message on Slack. And this is also why every news website out there is either black, blue, or red.
Because black is balance, blue is trust, and red is we're trying to position ourselves against the ones that picked black and blue. (audience laughs) Typography is another kind of, it's catnip to geeks 'cause it's got lots of cool little bits to learn, right? But if you need to code anything serious, anything like vertical rhythm, you've got to understand the anatomy of type to understand how to measure it, and how to talk to the designers about it.
And typeface also has really strong psychology. You can definitely get type wrong.
They're a massive part of your band, and so that ticket you got to fix the typeface that you thought wasn't important was really, you should think about that ticket like a red build, like you genuinely broke things.
If you put the wrong typeface up, it's important. I promise this is not a joke, C.R.A.P. design. Google it, it's a really good way to level up your understanding of layout, but it's a whole talk to itself.
Animation, okay, here's the cheat code, developers. Look up Disney's 12 principles of animation, done. Five minutes on YouTube, you will know so much more about animation than you could believe you could get in that time.
You will probably read a lot more after that. Voice and tone, this is how your product speaks. And it's like lolcats, when you try to write one, and it's wrong, and it grates.
Because there is a right and wrong way to write lolcat. There really is, try it. There is a right and wrong way
for your product to speak to your users.
And developers will often be the ones that break this, unintentionally, because they're building a form, and they had to put a label in it, and instead of saying something like you need to log in again, they say you must authenticate, you need to re-authenticate, your session has logged out. (audience laughs) Robot. After that, you've got to get into the harder stuff. User research, rather than trying to learn this all at once, go to your researchers and say, can I come along to the next session. Just go and do it, it's scary for devs, we don't like talking to people. (audience laughs) But you're gonna have to meet some humans, I'm sorry. Start sketching things, figure out how quickly you can sketch something instead of code it, it's pretty amazing.
And then the big one, design thinking.
Because design thinking, while it's a buzz word, it's also a really good way of understanding that design is not just putting things on a screen and tidying them up, that kind of thing.
Design thinking is a transformative aspect of design. It's the way that design can impact an entire business, from the very top to the very bottom.
It's really exciting stuff, it's well worth a bit of time to look at, there are courses on it. So that's kind of your homework, right? So, I'll close by returning to these golden rules. Learn about others and be a guide, because if you've ever wished that someone would learn about your job, learn about theirs.
It's the best way to open that up.
And if you wish that people would teach you, teach people things you know, make that the environment that they're operating in. In other words, lead by understanding, and lead by doing. Because what designers and developers should know most of all is how much we have in common, and how awesome it is to work together.
So think about the guides you had to get to where you are now, and go and try and be that person for someone else.
Thank you. (audience applause) (electronic percussive music)
