Keeping Development in Mind

[00:00:00]
>> This is a bit of a weird catch-all section that I've created at the end of this for what happens after the prototyping stage, right, once you've done the design. Basically, I outlined those stages, didn't I? Discovery phase, prototyping, build, and live, right? Basically, most of the heavy lifting in the design for the designer happens in the discovery phase in the prototyping.

[00:00:27]
Once it gets into build and live, our role changes, right? But that doesn't mean it goes away. And actually, there's important work that needs to be done in the build and the go live, where it's really important to get it right. Because if we don't get it right, the website A won't look like what we agreed it would look like with the clients, which can cause problems, and B will underperform.

[00:00:55]
And C probably never reach its full potential, because a website never reaches its full potential on the day it goes live, right? There will always be things that can improve. So it's that kinda stuff that I wanna get to in this final session. So let's start off by talking about working with developers.

[00:01:14]
Now, by far, the majority of you that are listening to this are either developers or do the development and the design. So you working by yourself makes life a lot easier. But I think it is really important to stress the working relationship between a designer and a developer is incredibly important.

[00:01:36]
And yet these days with the way the industry's gone, it's becoming increasingly abstract from one another. So too often, it's less of a problem in an agency and freelancer environment. Because either the Jack of all trades that are doing both development and design, or, alternatively, they're in relatively small teams where the designer and the developer sit side by side.

[00:02:01]
But in larger organizations, it's like they live in two separate worlds often. I don't know what it's like with you guys. But typically, the developers don't even report into the same department as the designers sometimes. And there's not necessarily a lot of interaction going between the two. But I would say that the fundamental link there between the designer and the developer is probably, it's a three way.

[00:02:30]
That could have been worded better, couldn't it? It's the relationship between the designer and the content specialist and the designer and the developer, are the key relationships in this. And so ideally, you wanna be sitting beside the developer as you do the design, right? I know that doesn't always happen.

[00:02:51]
So the next best thing is you've gotta involve that developer a lot. Show them sketches, show them wireframes, show them everything as you go along. Involve them in the conversation, because they will have all kinds of feedback that they can give on things like performance, on things like security, on things like interactivity.

[00:03:13]
Increasingly these days, I'm going to developers and coming up with some idea about animation or interactivity, and developers are looking at me going, well, that's a bit 2000. [LAUGH] These days, we can do this, and it's amazing and wonderful. So that kind of relationship is really important. I've overwrite the point, but there you go.

[00:03:34]
I will also repeat what I said earlier, don't forget to design with the developer in mind. So create components that the developer can reuse. So when you're working in Figma and you're doing navigation and headers and footers and cards and things like that. Don't just build them individually on each page, but use the component function, so that a developer can easily see that that's a reusable component, it's reused over multiple pages.

[00:04:00]
Design using the auto-layout function I mentioned in Figma. It very closely replicates the CSS box model, which makes life a lot easier, again, for developers. Make use of the color and typography styles to ensure consistency across your designs. Create all those states, think about button states, linked states, form states, all of these things you need to get into with the developer.

[00:04:26]
And error messaging is another really big one to get into when you're working with developers. And then when it comes to breakpoints, consider your responsive breakpoints. We've fallen into this bad habit, I think, at the moment, when it comes to responsive design, where it seems to be the standard rule, you do a desktop version and you do a mobile version.

[00:04:53]
Maybe if you got loads of time and money, you do a tablet version in between. But those are completely arbitrary things, right? There is no mobile size. There is no desktop size. So I would encourage you instead of thinking in terms of just mobile and desktop, actually design your breakpoints around the content, not the device.

[00:05:17]
So that as you're creating your design, again, with Figma and things, you can actually make your design responsive. So the only points where you need a breakpoint and a separate version is where the design kind of falls apart, because the line lights are too small or whatever. So I just break it wherever is the natural place to break rather than at any particular device.

[00:05:44]
And also, make sure your developers are comfortable with these design tools and understand all of their capabilities. I was working with a developer recently, and I just made a throwaway comment. And of course, this is the inspect view for you in Figma. And he was like, [SOUND] I blew his mind, cuz he just hadn't used Figma before, which why should he, he's a developer.

[00:06:08]
And yet, it will give you loads of information, loads of CSS. I'm not saying you use exactly the CSS in there, but it's quick access to all the information that you need as a developer. So yeah, just build and nurture that relationship. Use tools that help each other and support each other, and don't think, that's the developer's problem.

[00:06:31]
I'm speaking to the converted here, but it's worth saying. If for no other reason, you can just edit this bit out and send it to your designers. The other thing I would say when it comes to that working relationship and when you get into the build, is to be flexible.

[00:06:50]
I come across a lot of designers, especially designers that came originally from a print background, that are obsessed with perfect pixel design, which is just not very feasible online. But in particular, I think even with more educated designers, they often make some bad decisions that if there had been a proper conversation with the developer, could have been avoided, especially around the area of performance.

[00:07:17]
So I see a lot of designers, they get carried away with their use of fonts, right? Fonts are a big drain on performance. They get pretty big, unless you're using variable fonts where, which by the way, if you haven't checked out variable fonts as a designer, you really should do.

[00:07:35]
Really, you wanna be avoiding using any more than two fonts. And you wanna limit the number of font variations, weights that you use, because it all build up and really starts having a hit on performance. While I'm going through these, I'm really interested, cuz I know there are developers in the room and there's developers on chat.

[00:07:53]
So if there are any other messages you could send to designers, I'd love to hear it in the chat, right? What other things do they need to know? So fonts is one thing that I often. Images is another when it comes to performance. Designers love to add imagery that has no value, right?

[00:08:13]
It's purely decorative, right? The page is looking a bit boring. Let's put in a stock photograph of two people shaking hands. It's like, why? It's like using bandwidth for no reason, and provides no value whatsoever. So we need to kind of avoid that thing. And understand images better, I think a lot of designers are really poor in understanding the medium in which they operate on the Web.

[00:08:38]
So the fact that some images compress better than others, that kind of thing. As designers, I think we've got a responsibility to understand that kind of thing and not just go [LAUGH]. I think there's this thing that performance is developers' problem. But if you give them a design which has got massive hero images and video backgrounds and fonts and all of this kind of stuff, they can't perform miracles.

[00:09:07]
And JavaScript is the final thing. I mean, there's nothing wrong with JavaScript, don't get me wrong, don't hate me. But as you add interactive elements into a design and add design delighters, so nice animations and that kind of thing, really, really good, but they can cause problems. JavaScript, in my experience, can cause problems, especially on mobile devices, less powerful devices, they don't always run very well.

[00:09:32]
So if you're gonna use JavaScript, use it, in my opinion, at least, to progressively enhance the design rather than as a requirement. But I know that that proves somewhat controversial. So has anybody got any kind of other things designer, developer conflict points? Has anybody posted anything into chat?

[00:09:54]
>> No, one person said, I thought the design process started in Figma. I'm glad I saw this workshop early in my programming career.
>> Yeah.
>> See you.
>> It needs to end in Figma. Well, no, even Figma is only in the middle part of it, because I would ask you, after you finish in Figma, you're then moving into the browser, right?

[00:10:14]
In fact, as somebody who is very old and old school in this, I will actually sometimes just skip Figma entirely and code it in the browser. This gets into the, should designers know how to code debate, right? I believe fundamentally that any designer, any artist, whatever, needs to understand the medium in which they operate.

[00:10:44]
And that doesn't mean they're ever gonna code like a developer can code, and neither should they, they shouldn't be doing production-ready code. But you do need to understand the fundamentals of the medium that you work in. And I think that's why I actually quite like designing in the browser, because I know it works then.

[00:11:02]
I know that that is how the browser behaves. And although Figma and Sketch and these kinds of tools are making leaps and bounds in terms of replicating the browser-based experience, they're still not quite there, it's not quite the same. So there is something to be said from actually, yeah, okay, do Figma to a certain degree, but then take it on and go on to then refine that in the browser and take it to the next level.

[00:11:29]
So don't see your Figma files as written in stone. They are just a step on the design journey. Right, Let's talk about one area in particular, which is called design delighters, cuz this is a tricky one, right? So first of all, let me define what I mean by design delighter, right, cuz it's a bit of a made up term.

[00:11:58]
A design delighter is an interactive or visual element that although not necessary for the site, enhances the experience in some way, right? So a design delighter might be an animation or something along those lines, kind of, yes, you could configure your product through a form with a drop-down menu.

[00:12:20]
But it would be much better if it was an interactive wizard that you kind of played with. So there are things like this. Now, these are really useful components, and there are all kinds of examples of them. So accordions, animation, carousels, interactive guides, wizards, and configuration tools, all of these, I would define as design delighters.

[00:12:49]
And a design delighter is not strictly necessary, but it makes a big difference to a website. And so the way that I tend to approach those as I do design and as I work on design projects is to think of those, I set aside a certain amount of time and a certain amount of budget to do specifically those things, right?

[00:13:08]
So I design the experience as if it's not reliant on those things, and then we add those as an extra layer on top, progressively enhance or improve the application using these kinds of things. And the reason that I take that approach is because I think creating design delighters works best when it's done very much in close collaboration with the developer.

[00:13:33]
A developer is gonna have a much better idea as what is possible and what will fit within the budget, okay? So the design delighters I tend to leave until I'm in the build phase, so that I can do those in close relationship with the developer. So there's a whole load of stuff about working with developers in the build stage.

[00:13:59]
But there is one final message that I did briefly mention before, but I'm now gonna say in very big letters on a bright background. Which is, never ever show a design to a client or a stakeholder that you have not first shown to your developer, right? I see people make this mistake all the time and you get yourself caught in a trap, right?

[00:14:25]
You present and sell an idea to stakeholders and clients that can't be built, right? That isn't gonna fit in the budget, isn't fitting in the timescales. Show it to your developer first, make sure that they get a chance to go, you really wanna do that? If we do that, we're gonna have to change our architecture or whatever it involves.

[00:14:50]
Those conversations need to happen and are really important. And while I'm on ranting, right, one more thing just to throw into the mix, let go of pixel perfect control of design. That's another thing that too many designers seem to be hung up on, and it just isn't relevant.

[00:15:08]
A developer isn't gonna be able to reproduce your design exactly as you envisaged it. The web doesn't work like that, get over it. So basically what I'm saying is this is a collaboration, right? The final design is a collaboration between the developer and the design and the content person and various other people as well.

[00:15:26]
But you don't own the design, right? And I think it's important to recognize that. The final design is really a collaboration between design and development. And that's great. If you're someone that does both the design and the development, that puts you in a uniquely good position, I believe, to produce an outstanding experience, cuz you understand the whole picture.

[00:15:47]
Now, obviously, it's hard to be both an expert in design and development, and I don't think you will be. But there is an advantage in being a generalist as well, so don't regret that. And that means that you need to involve the developer early in the process. And you need to be, as the designer, available to collaborate with the developer during the build.

[00:16:11]
You can't just disappear on to other things.