Sessions is temporarily moving to YouTube, check out all our new videos here.

Designing for the Web

Matteo Pescarin speaking at London CSS in April, 2017
30Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Healthy practices for developers and designers, in other words common mistakes and problems on front end design/development and a bunch of solutions on how to address these problems.


Transcript


Matteo: Hi, everybody. Welcome. So, today, going to talk about designing for the web. Effectively, this talk would be very much has a ... [inaudible 00:00:11] has said is going be very much a very broad understanding of what it means working with the designers for developers. And what it means working with developers from a designer point of view. So my name is Matteo. [00:00:30] I've been working Sainsbury's for two years, and now moved to a new company, just started yesterday. The company's called Build It. I'm the lead engineer, but effectively I've ranged from web design, back end, front end. Mostly front end right now focusing on UX, UI and many of the other problems. We working with style guides for quite a bit now. And there's a lot of that, that comes from my own experience that are going to these lights. [00:01:00] So I hope I can give you quite a good understanding of what's happening, what I think it is, a little bit the situation that the majority I think is currently on right now. But yeah, that's about it. Let's kick it off. So I want to start with a reflection, and perhaps it's a sad note. So I've seen [00:01:30] developers and designers who didn't want to touch a single line of CSS or even HTML. I've seen also HTML markup that browsers shouldn't even be allowed to even pass, in my opinion. I've also seen very beautiful designs that would work perfectly on paper, but that's pretty much about it. So and all [00:02:00] these moments will be lost in time like tears in the rain. So I think the problem is very much, after this parenthesis, the problem is I think, we can see that this problem is actually two-fold. So the designers have actually very little understanding, most of the time I'm talking about of course, old web technologies and the standards. They come from, whatever their field is in, they're coming from. [00:02:30] And while developers are very much focused on, most of the times again, into learning, as we very much know, the ever increasing complexity of front-end interfaces that they are required to build. So at the beginning we can say that if we look at the history of where the web is coming from, and where we are now. When we've seen them in the last almost 20 years [00:03:00] now. We started at the very beginning, we were quite happy if we could do some of the very simple things. We could use a table to display data. And then things got a little more complex. And then all these [inaudible 00:03:15] we were display in this page. It was too much and where we had to many things to display. So we ended up ... We managed to paginate records on different pages and [00:03:30] had millions of records actually paginating. So and the ability to skip from one page to the other was actually quite interesting. But then we ... At a certain point, the complexity got a little bit too much and too late and then we hit somehow UX. And if you've been into that, and if you approached the UX as a newbie, and you might have seen there are certain problems that come with it. And a deep, massive [00:04:00] baggage of understanding that requires you to delve very much deep into it if you really want to get something out of it. So we started looking into ... Once things have got a bit too complex, so we started looking into shifting the domain of investigation towards the content rather than the single pages. Because, of course, that didn't make any sense anymore. So in other words, [00:04:30] we started looking at the understanding, and looking at our target users. So who was coming to our website? What was the segmentation we were looking at? Who are the branches of age? How they were interacting with our website. And effectively we wanted to understand how could a user ... How would a user actually go from point A to point B with the least many amount of clicks to actually reach that point. And, of course, [00:05:00] that came together with a necessity to understand that interactions, and the behaviour. So how the world interacted with the components, and the elements that we were building through the UI of our page or our, whatever it is, website. And this, of course, means usability. And together with it, of course, we also have accessibility, but we also have, of course, device compatibility. And if you have a bit of a look at this, there were actually [00:05:30] many other aspects that I am not talking about here right now. And sometimes I find it a bit too many. So as we can see, there is a lot to take in. So let's make things clear. So you don't know web design, effectively. So can you say what is web design? So in my opinion ... From my personal idea what web design is ... Where you will find [00:06:00] what is the definition, a good, correct definition is very hard to grasp, and many people have got their own interpretation of that. In my opinion, it actually feels like ... It's like a multi-faceted set of practises and doctrines that surround websites effectively. So it feels like like it's kind of everything, perhaps? One good way to define web design I found ... I think it is ... Someone said that actually it's something that is actually much more similar to [00:06:30] product design. So in the real world of physical things, product design is actually very similar to what web design should do. But, again, anyway sometimes it's anyway quite difficult to grasp everything. So for instance, let's see what we have here. So semantic markup. So I don't know if you can [00:07:00] understand any problems in this snippet of code. Apart from the Angular that is there. So I would say ... Almost. Now let's see our question. How many do you know ... How many of you know about this? What is the difference between article and section? Like see, hands up. How many of [00:07:30] you know that? I was expecting many more, yeah? Okay. I mean you don't need to ... I mean, you can fake it, I know. In the real practise I know that. Because section might be a bit a tricky when you actually need to understand and read the documentation. [inaudible 00:07:51] see the documentation. And so how many of you actually know how to vertically align a block element [00:08:00] using only CSS, and not cheating using flexbox? Okay. So how many of you know how many ways there are to actually do that? Okay. So there are ... So I would say that sometimes it's a little bit difficult to be a developer. And I think it can be summarised quite well with this tweet. Yeah. But [00:08:30] let's not discourage ourselves, shall we? So if developers have too much to take in, so what should a designer do? So let's see [inaudible 00:08:42] shall we ask Google? Shall we? So let's see auto completion of Google what gives us. So should designers code? Learn to code, dress Melania, know how to code. Okay, now we've been distracted by Trump again, [00:09:00] let's restrict the search a little bit. So should web designers know how to code, use WordPress, use Bootstrap, use templates. So I think the problem is quite evident. So if Google managed to actually record that, we have a problem and we have a disconnection in somehow. But I think it's important that we need to stop banging our head, and please calm down because we know we can do it. [00:09:30] Because at the end we know that developers know the limit of technology. They know cross compatibility issues, they know browser capabilities, they know performance, supposedly, device limits, semantics, maybe. And supposed features. And on the other end of the spectrum, we know designers have an understanding ... Should have an understanding and very much know why we're using [00:10:00] a particular grid rather than another. They use the understanding of white space, so they use white space within the page. Vertical rhythm, the typography, the colour theory and so on. There are many other things there within that area can be covered. And we shouldn't really, in our daily job try to expect it would be the unicorn. The unicorn I'm referring to is, of course, the person who actually like developers that came from [00:10:30] ... They, at a certain point, became designers. And the designers at the other end that actually got into development. Yes, of course, there are these kind of people, but I think you should be content with what you have at hand and working with it. On the other hand, at the same time you shouldn't even expect that tools should solve your problems. Effectively tools ... We know that since the inception of ... The [00:11:00] creation of the first tools that we had for creating web pages, we know that we had since the beginning, tools that help the designers approach, get close to web development. Even myself, I started using Dreamweaver, Glade, we had FrontPage. And now we having more interesting tools like Sketch, and many other projects that are being now dumped into the internet for public consumption that make [00:11:30] our lives particularly easier, designer's life particularly easier and even developer's lives for that. And effectively developers have tools that help to get closer ... Get us close to design. So we have the ability to create the ... Like formalise the grid system that a developer can understand with their intricated mind. It's not an offence, I mean it's quite a good thing. And they came up with [00:12:00] this [inaudible 00:12:01] methodology of Atomic Design and many others. And these methodologies actually take the design world in this weird cloud, and brings it down to something we can apply in a methodologic way without any problems. And we have libraries and frameworks that we can use for that reason. So there is many things that we have. But at the same time, don't let anybody decide which tools [00:12:30] you should be using. And allow yourself, at the same, t be flexible enough and experiment and try new things. So with this in mind, I think a better world is possible. So we have learned that we can not keep shifting responsibility. At the same time, we can not overload ourselves with the knowledge that we don't have, both designers and developers. We can not expect [00:13:00] the artist to do the job that we should be doing, or the other way around. That doesn't make any sense. And we are risking just like if we want to overload ourselves, we can. And I've have seen that happening. That we can make a fool out of ourselves because we pick up concepts and ideas that we don't ... We only grasp 1% of that whole thing. And so there are also many things that we can do to improve the [00:13:30] current situation without effectively going too mad. So in the following slides I am trying ... I am going to give you a round down of what worked so far, and what could be potentially, hopefully, the key to your success. So I'll start with this, and I wonder how many of you know about the one 10 100 rule. Nobody? Okay, that's good. Help. Yeah, we will understand what it is. It's quite easy, because [00:14:00] what it means is basically that the cost ... So the one 10 100, it can be expressed in dollars, if you want, pounds. So we have the cost of one for if you have to fix the problem at the design time. You have the cost of 10 if you want to fix it in development. And you have the cost of 100 if you want to fix it after delivery. And this is quite a well-known rule if you are a delivery manager or project manager, product manager whatever it is. [00:14:30] This is actually quite important. It is actually very important to keep an understanding of that. And us a developers or designer, whoever you are here, you have to have this very good understanding of that. And along with this part, I think it was Google's analysis actually found out that the 100 is actually more likely over a million. So trying to do something we need to try to do as best as we can at the very beginning. [00:15:00] Of course, we don't need to over engineer, so we that we know there are methodologies to overcome that. And effectively itinerate and validate I think is still valid as a methodology to actually go over and try to find the room, first of all, for improvement. And learn ... This is probably one of the most important things I always repeat. That is learning about ... From your own mistakes. A lot of people that pick up on Agile methodologies. I had just yesterday a very good discussion around that. That is [00:15:30] that majority of people pick up on Agile process, Scrum and say, "Oh yes I know everything about this. Everything is cool, I know how to do it." Et cetera, et cetera. And they keep on doing it, and they keep on failing. And they don't understand. And the company says, "Oh we can not use this one, we have to go back and use waterfall." And it's like, hold on. How this ... Okay, so one of the key things missing is probably is maybe missing retrospecting. And retrospecting is effectively looking [00:16:00] back at what you've done, and trying to learn from those mistakes and improve from there. And on top of that, of course, you want to be able to have the environment where you have the ability to remove obstacles as quickly as possible. So from here, of course, we have to be extremely careful how we are dealing with our design systems, and how we implement things on the development side. Because we have [00:16:30] to keep in mind that both developers and designers are biassed. So you will find tonnes of discussions around this. But you have to gather information. It's quite important that you need to gather information on the user of your product before you start [inaudible 00:16:48] around, trying to do anything around that. There is very much ... Having been into web design like 15 years ago, I remember it was quite easy [00:17:00] to find people that were saying, "Oh I know exactly how the people are using my website are going to use my product, how they should design." This is not the point. Yes, you can do that, but I think you can do even better. So there's always a bit of balance you have to strike, but you have to keep your users into consideration. Any involvement at any stage, at any point, whenever you have the opportunity. So of course, another very good thing that actually worked [00:17:30] very well, and I actually wrote an article around this. You can actually find this on my blog roll. Sorry, self-promoting myself a little bit. But it's quite interesting because rapid prototyping, designing in the browser, rapid prototyping effectively forces you to see the problems that you will discover in implementation time. And we're going back to the idea of actually discovering problems, trying to solve the problems as soon as possible at the very beginning of [00:18:00] your designing sprint and then whatever it is going to be, before you actually deliver. And of course, you need to chose the right level of fidelity, there is a very good article written on Smashing Magazine by Lyndon Cerejo, I guess. But you need to ... The very summary I can give you here is effectively you need understand what is the level of fidelity you want in [00:18:30] your prototypes. You can sketch on paper, or you can get into very high level mocks written with whatever framework. And this is something that I picked up in many occasions had the opportunity to implement myself with the teams I've worked with. And this seems to have cut down first of all, the number of iterations for development of the single elements that we are doing. But also helped us understand what would be the [00:19:00] problems in implementing the whole thing as I was saying before. If you are ... Although, of course, if you are worried that designing in the browser and rapid prototyping could take a lot of the time, one of the things that's been created ... Yes. ... One of the things that's been created by Google is being the design sprints. I find it particularly interesting because it is effectively a very short ... If you don't know about it, it's a very sprint. It's [00:19:30] a five days sprint at most where you can quickly brainstorm ideas, and pick up the best, and try to implement it, and what works best. You can even involve users, stakeholders normally be involved in this. I would totally recommend to look into that, because it helps you if you are working with rapid prototyping, or in designing the browser, or, as we see, style guides in public libraries. That would become particularly useful for actually checking out new [00:20:00] elements, and new styles, new UIs and so on. And of course, as I was saying, using style guides and pattern libraries. I can not recommend that more than that, because it actually provides a very good tool for usability ... That promotes usability, modularity. I think since 2013 where we started seeing the movement towards the [00:20:30] adoption of moderate systems on the web that design style guides. and with I think Brad Frost's being probably one of the most ... The most well recognised. And he fused the systems with Atomic Design that are promoted with pattern library, Pattern Lab as a tool for creating pattern libraries effectively. So I just want to highlight one small thing [00:21:00] here which is actually quite huge. That is pattern largely actually encompass a much more complete and difficult area of design and web design in it's essence. Which you might need to actually understand. I wrote again another article quite recently around this problems of a very particular use case around this which you can find again. But [00:21:30] as a very generic idea, pattern libraries can provide you a set of problems that can be overcome if you have an understanding of what you are trying to achieve, more than anything else. I'm not trying to be very generic here, but if you want to ask anymore questions later on that's perfectly fine. I'll be in the pub for a bit, for a pint. So but I want to ... Last bit, I want to talk about the elephant in the room. So I want to know here how many of you are [00:22:00] working ... Who's developer? How many of you are working with designers? Okay, yeah, that's expected. And how many of you have got a designer sitting there in the same room? Okay. It's like no. Of course. And are many of these that still have their hands up, how many of you are sitting in the same desk as the designers? Okay, fewer but [00:22:30] yeah. And how many of you of those talk on a daily basis with designers? You still? Two? Okay, that's cool. That's cool. So effectively what I'm getting at is that I think this is not a [inaudible 00:22:47] suggestion. Before I was getting to like ... I was very cautious in actually promoting the dialogue. Not just the dialogue, but the thing is also the working together. The [inaudible 00:23:00] [00:23:00] in a very technical terms of developers and designers. So I don't think there is anymore room for having designers living under developer's room ... Developer's door. So UI development effectively ... Or front end design as Brad Foss would put it, takes time and skills. So what I've done effectively in the past I've started ... As I was hinting before, I started helping developers to [00:23:30] emerge in understanding UI development and design to a level where they can take coherent decisions and create a dialogue with the designers. And also pushing to make the concept well clear to company I'm working with as this is not something that's usually understood. So this is cool. I can understand that, but please [00:24:00] don't panic. So first of all you need to work bottom up, for sure. That is have the [inaudible 00:24:08] sitting with the designers. Understand the tools of the trade, and invite the developers to focus on front end design as much as they willing to do that. But in that way you get introduced to the world of design, or how [inaudible 00:24:21] works. And the other way around. And of course, you should also work top down. That is build a use case [00:24:30] with users in mind. Accessibility, usability and device agnosticism and present that to the business. Try to involve them in the process, and make them understand what this means. And to keep it simple, I'd like to end with a quote that should sum it up pretty well. All right. Thank you very much. If you have any questions ... Speaker 2: So you have the developers, the designers [00:25:00] and let's say that you also got back end on the same row. But then you have this very important person in the picture which is business. So how do you pitch to business that you want your solution built like that? Because usually, and I've seen it a lot of times, what you have is this fantastic solution to a problem. And you get everyone agreeing on what you want to do, and then business comes in and says, "Well we kind of need it in two days," or, [00:25:30] "No scrap that, scrape that and do something else. Like I don't care about your fancy designs or whatever." Matteo: Delivery times are always a ... It's a problem regardless of building a style guide, or any other system. So I do agree with what you're saying it- Speaker 2: So my question was, how do you pitch it? Matteo: Okay, so I was getting there. So I think the main point, at least from my experience, has been by building a [00:26:00] like user, like a green field project that actually works very well. That is have a very small project that you can pick up. and you build an MVP with that. That you can you pitch to the business, to the stakeholders, to say, "Oh this is how it is going to work." Whether you have basic ... If you are using a pattern design system, introducing the design system in this way and making this developers and designers working together. You can actually show how much the iteration had been shortening up because you might have already built a [00:26:30] sprint ... A cadence of work in the previous sprint. so know pretty much how long it is going to take for developing a UI piece. And making it ... Working with that you can actually overcome ... You can actually show that. So there are different ways. So I think building use case is probably the best way with a green field project or a small project that you can do with a MVP. I think it is the best way to pitch for that. In other ways, it could be introduced, [00:27:00] but [inaudible 00:27:01] you require a little bit too much of lectures and stuff like that. I'd rather, if it was for me or the situation I've been into, I'd rather work from the, as I was saying, bottom up. In terms of try to see if we can work together, build up the common language we use, the right tools to use and so on. And trying to understand the problems that each other has, and then have the minimum viable product and showcase it to the business. [00:27:30] If that ... Hope that kind of answers that.