About this talk
This talk explores the concept of design logic and its importance for developers in creating cohesive, user-centered websites. The speaker challenges traditional perceptions of the full stack developer's role, emphasizing that understanding design principles can enhance coding practices. With over ten years in front-end development, the speaker shares insights drawn from personal experiences working with various content management systems like WordPress, Drupal, and Umbraco. Through practical examples, they illustrate how developers can go beyond merely copying design tokens from Figma, advocating for an interrogation of design to uncover underlying logic. By bridging the gap between designers and developers, the talk encourages a collaborative approach to web development, aiming to create more intuitive and flexible user interfaces.
Full transcript
Alrighty. Should we get started? So, welcome to my presentation uh design logic unearthed and thank you all for being here. Um, so today I'll be trying to teach you how to code rockolid sites via the lost art of design interrogation. And I'll just start the recording. So, what do I mean by design and what's going on with this weird prehistoric kind of theme I've got going on
here? So, I'm going to get into that in a second. But first, I want to challenge you a little bit. I want to challenge your preconceived ideas um about what being a full stack developer is because often we think about it as encompassing all of the programming stuff, right? So everything from backend development through the front end and we consider this to be uh what web development
is. But is there a missing end here? Right? Design we often think of as being in its separate silo like it's completely separate from what we do as engineers and programmers. But really is it that different? I mean, there's a lot of logic, algorithms, um, hidden processes in what designers do that actually mimic and mirror what we do as developers. So, I'm going to try and actually
test you a little bit here and try and challenge you to maybe expand your skill set in the design direction of the stack. So, a little bit about me. Um, I'm originally from New Zealand, hence the weird accent that hopefully you'll get used to by the end of it. Um, I've been working in frontend development for 10 years. So, I originally started in WordPress and then moved
to Umbraco for a while, uh, which is another, uh, open source CMS. Um, I've dabbled in Craft as well and just since the last two years I've been working in Drupal and I'm working for Evolving Web right now in Montreal, Canada. And I always wanted to be an archaeologist. Like when I was a kid, it was my main passion when I was like 7 years old. Uh
so I hope you will indulge me a little bit in this sort of prehistoric theme we've got going on. So let's start with a little story. Okay, imagine you're coming into an ancient cave and you discover some dead sea scrolls or dead CSS scrolls. Hope you like that pun. and you discover a story unfolding. So imagine this is you, a developer. You're coming to the end of
a project. You've finished building a website, maybe for a university. It could be for a business. Could be for anything. And you're really proud of yourself. You've been copying all of the design work from Figma into code and you think you've done a pretty good job. Okay. But then you want a second opinion. So, you ask a fellow developer and they spot a bunch of little bugs
and most of them are pretty trivial. But there's one really, really tricky front-end bug, okay? And you can't find any sort of elegant solution to solve it. So, what do you do? You have a think and the only thing you can think of is a really hacky CSS parent selector override. So, I think we all know that kind of thing, right? where maybe the lists look completely
different in the sidebar and the only thing you can think of is to target all the lists inside the sidebars and you change the bullet points or something like that. And so we push that live and we don't do any code review, you know, we just keep it quiet. It's just one little commit, right? And then your manager has a look and he finds two tricky frontend
bugs. Most of them are pretty simple, but there's two and you're you're scratching your head trying to figure out how to solve them. And so what do you do? Well, you do another hack key CSS parents like to override. And you use the tried andrue important flag, which just seems to fix everything until it doesn't, right? So, we'll just slip that in there. And we know it's
not really good practice, but it's fine just for this one-off case. the design team, okay, they're the pickiest of all, you know, because they want to guarantee the integrity of what they've designed and they find three really tricky front-end bugs. And so what do you do? Another CSS parent selector overwrite, another important flag, and a really weird utility class. So, you know the ones the things that
are like no borders when empty or rounded corners bottom left and you do this kind of thing and it's not really part of your system but you just kind of bang it in there and it kind of does the job and the QA team I mean we said the design team was worst of all the QA team it's their job to find bugs so of course they
found more we do another parent override we do another important flag somewhere we do another utility class somewhere and we duplicate a big chunk of code because we're panicking, you know. So maybe we duplicate the entire menu code. So in the header, you just copy all that HTML and CSS and you just paste it into the footer of the website and you just change a color. And
that's the easiest thing you can think of. And then just when it couldn't get any worse, the real test comes when you hand it over to the client. And the client's quite enamored with what they've been sold. you know, they love the design. They love all the little bits and pieces. And so what do they find? Well, they find more and more and more bugs. And so
this goes on and on and on and you can never ever get it quite right. And there tends to be like a tugofwar that happens where you kind of pull one end of the string, you try and fix one bug, and somewhere else in the code, it slips up somewhere else, which forces you to do these hacks over and over and over again. So, how did we
get into this mess? Well, it all started out at the very beginning. What we were doing quite quite rightfully and quite faithfully is copying across all the design tokens, all the values from Figma, and we were just putting them in our front-end code. So, all of the colors, all of the measurements, all the font sizes, the topography, we're just copying those straight across into our code. And
it's kind of working for us, but obviously we get tripped up in the end. And so this is the big thing I want to try and sell you on today, which is this idea of design logic. And really, it's not something that is totally new to you guys. I'm sure you're all aware that there's like logic living in all the Figma files that you uh review. But
I want to try and introduce this idea as a way of like bridging the gap between designers and developers. So what is design logic? It's the underlying patterns, the logic, the uh that govern design. Really, it is the big picture thinking. So instead of copying and pasting just the tokens, just the values, uh that's really only half the story. Um, and by fully interrogating the design, by
fully actually delving in there, uh, we can come to an actual more accurate big picture understanding of what's going on and how it is supposed to work by actually looking at the meaning of things. So, here's a really, really trivial example, okay? And we've all done this before where you look at a design, you see the font size is 24 pixels, the line height is like 32
pixels, and you just copy it into your code, you know, which is totally fine, but is there an underlying logic or an underlying underlying algorithm uh that's going on here? Is there something more that we can um extract from this? And already you might see that actually it's about 1 and a3 times the font size. So maybe that's the pattern, right? Maybe it's as simple as that.
And there might be other uh headings that you have to style on a website. For example, if you're dealing with like rich text, you might be responsible for styling the H1's, twos, threes, fours, fives, and sixes. And so you need to fill in the blanks as a developer. So we could use that. But have you ever noticed that, and this is true on almost all websites you've
ever worked on, as the font size increases, the line height becomes a lot tighter? And this is just a general rule across almost every website. Whereas you go up the font sizes, um the the actual line height value needs to get smaller. And that's just because visually we don't need such a big gap with those large font sizes. So this is the underlying logic that the designers
are thinking of. they're they're thinking this when they actually do the Figma designs. Um, but it's kind of an unspoken thing most of the time and it's up to us as developers to really extract So that's just a really small example. Uh, let's get into some bigger kind of more real world sort of things. So there's a design logic behind color. So even colors, you think of
them as being fixed values, that is really only half the story. So, here's a little screenshot I made of just some different design elements. You've got a heading. You've got some paragraph text in here. You've got some icons. I don't know if it shows super well up on the screen, but they're slightly different colors. So, you got a dark red heading, dark green icons. Uh, but what
if you wanted to do a reverse version of that? You know, for all sorts of reasons. You could be maybe wanting to do like a dark mode or maybe it's sitting inside of a block that needs to be toggled. So maybe the designer can actually or rather the content editor can actually go in in Drupal and toggle the color of this particular block. But have you ever
noticed that with mostly this is true on most websites when you toggle dark colors they almost always flip to full white. Okay. So this is the logic of the way that the colors is working. So when you have dark colors, they almost always flip to full white. And for some reason, full black, like, you know, as a hex code 00, that's pretty rare. You don't really see
that so much on websites. Full white super common. Almost never will these be actual like light versions of the So let's look at this example. So this is taking it a little bit further. We have this piece of text here. This might be rich text coming from CK editor or something. There could be anything in there and as a developer you forget that oh actually this can
be toggled as well. So let's look at the logic. Let's try and flip that to white. And again you'll need to go into your Figma design and actually try and extract the logic of what's going on. But in most designs you'll see that to go white. We can then go into the Figma design and say okay is that the full story? Is there another secondary color that
comes in? Because if you go back, you'll see there was this secondary yellow color. Maybe there was another color like this teal color that we can bring in. So, this is just a a small example of how it works with So, yeah, some takeaways here for you. Dark text colors, um, they're often just full white when they're reversed. I'm not sure why. Um, I don't want to
make this too much about coding and programming, but we can use things like current color to easily flip the foreground elements. So, this is really going to change the entire way that you build websites. It's less about making all paragraphs a dark gray color and more about actually inheriting something maybe from the block that they're within. So, actually, there's big consequences for the way the logic of
colors work. There's also the design logic of layouts. So here you have a carousel, pretty simple thing that you see on most websites. Um, usually there's an image in the background and you normally have like floated elements on top, arrows and a navigation down the bottom. So we want to ensure that nothing everlaps. And so it's our job as a developer to go into the design and
actually see what that logic is. So here we might see that okay we need to have safe spaces on the left and the right. So instead of making that text just purely centered um maybe we do some sort of um calculation like this. And it's less about the formula here and more about actually just seeing what that logic is how the the algorithm of the layout is
supposed to work and how things relate to each other. Same thing with that little navigation thing at the bottom. So, some takeaways here. We need to study the relationship between these elements, how they relate to each other. So, in a design, you might see that something is 400 pixels wide, but that's not often the full story. Maybe you need to have some flex properties on it that
actually allow it to grow or shrink. There could be a push and pull happening. Um, it's about identifying the logic and driving our own measurements. So again, if you see something that's going to be 100% wide, you might even think that's the full story, but often there's more going on. This is about forcing us to write in a defensive way because with that example we saw before,
the text could change. The text could be much longer than that. It could be like a full sentence. How is it supposed to react? What was the designer's original intention when they were building that? And we have one last example here with spacing. If you take anything out of this presentation, this should be it. This is probably the most important part. Again, this is true on almost
every website you've ever worked on, but especially on homepages of websites. You often have these stacked sections, right, which can be reorganized using, you know, layout builder or maybe you're using paragraphs. And normally the user can come in and they can reorganize these. They can drag and drop them into any order. Um, and maybe they can change the color of these blocks as well. And you might
think, what's the spacing in these blocks? And hopefully the design has made it easy for us. Hopefully, it's just 100 pixels, right? And so, it's just a simple thing like that. But is that really the full story? Well, as you can probably suspect, it's not. So, what if we change one of those blocks and we change the color? So by changing the color of the block, now
the space visually to our eye looks twice as big as it should be. And suddenly the paragraphs look way too far apart. And that's going to be flagged by a designer or someone in the QA team. And again, if you go back to the Figma design and you see the way the designer has done it, you'll find the spacing is a lot smaller Maybe it's just one
times or one and a half times the original value, but we need to put this logic into our websites when we're building them. It's not as simple as just outputting every single block on a page. So, some takeaways here, the spacing between stacked blocks is determined by the color. Um, and this is true on almost all websites. Um, how do we do that? We could take advantage
of the CSS has selector. So you can check what siblings are coming before and after and you can update them uh and check if the color is going to be the same. And really this is about getting us out of that habit of let's ask the designer. I think as developers or certainly um certainly for me I have this tendency to always ask the designer, you know,
when there's some sort of discrepancy that comes up or some sort of thing that I'm not quite sure of. But instead of let's ask the designer, maybe we should just be trying to find that logic that they've already put in there and given to us. So to sum it all up, as developers, we are more in kind with designers than we think. Um, this is a key
one. So design is a profession rooted in logic, especially in 2026. It's become more about um userdriven goals rather than pure artistry, which is what I think we have the tendency to think of it as. But why do we find this so unintuitive? Why do we think about our profession in these very separate ways where designers are living in their own sort of artistic, artsy, creative world
and us programmers are somehow different. There's this tendency to think there's a hard line between us. So I want to take you back in time a little bit. Okay, this is probably a term you haven't really used to describe yourself in a very long time. Um certainly I know when I was in high school I knew I always wanted to grow up and be a web designer.
Like that was the end goal for me. Um and I think this is really like the root of like where we all come from. You know back in the day everyone would have described themselves um using web designer at least part of the time but it's not something you really hear of anymore. So let's go way way back right early 2000s. Um, so it comes from this
time when people were basically just doing stuff um, however they wanted. They they were kind of doing it in a really ad hoc way. They were tinkering around. The people that were doing the coding were the ones that were doing the designing. It was all about experimentation and there were no hard there was no hard breakdown between the camps because it was all very experimental. And you
can even see the Space Jam website, which is still online today, by the way. But again, even in professional context, people were mostly just winging it. I mean, this was made in the late '9s. Um, so people were making it up as they go. And as such, like there was not a big gap between the different people on the team. Yes, people had different roles. um but
it was a a much closer sort of environment rather than the really fractured kind of um industry we live in these days. So this is the way I like to think about it, right? Web designer, that's our home base. That's where we come from. That's like our origin story. But eventually that became too that became too useless of a term and we needed to specialize as as
we as an industry became more professionalized. we needed um ever more fractured terms. So eventually developer was different to designer. Backend dev than front-end dev. These days I would describe myself as a UI developer may sometimes called like front of front end. Um but as we go on like these um categorizations become more and more fractured. And when I was doing some research for this article, I
discovered this really amazing article from the very very early 2000s um 25 years ago in fact. So even in the early 2000s, people were starting to identify these rifts that were going on in our industry. So this CIS admin guy Robert Miller says, "How can we work together if we don't understand each other?" S systems administrator Robert Miller describes the view from his side of the cubicle
and attempts to break down the barriers between creative and system professionals. In this article, which is still online today, by the way, he says, "I've made a point of working as closely as I can with my developers and designers, and I'm a much better CIS admin for the effort." And you might look at this and think, "Oh, well, doesn't it look like there were different roles already,
even, you know, 25 years ago?" He then goes on, "I've been able to show the designers how servers work so they can reduce the amount of time they spend trying to put stuff where they think it should be and focus on making pretty and functional UIs." So, you know, sounds about right. That sounds like what a designer should be. But then at the very end of this
article, there's this really fascinating uh list of definitions that he gives to us. So to him, a developer is someone who creates serverside code that translates objects into HTML. And to him, a designer is someone who creates HTML images and client side scripting, which is really weird, right? Like these days, you would never describe a designer as doing all of that. So this gets back to my
original point where back in those days we were much closer as an industry and the reason for that is that the real designers really weren't even in the room with us at that point. So back then where were the real designers? Well I mean the people who had actually trained in design people who had gone to art schools they were mostly still in the printing world or
they were doing other arts related professions. And that's because back then web design techniques were extremely limited. I mean, you could barely even control the fonts on a page. You couldn't really control the typography. There was even this idea of like web safe colors, which was like this very limited gamut of colors. And so, you couldn't really do anything. And so, naturally, designers weren't even interested at
that point. And so the art of designing websites back then was just the realm of web geeks, you know, myself included, the people who were really just passionate about this new technology and they were experimenting and trying new things. So what happened when designers did finally come to the table? Well, I mean in the early days there was a lot of experimentation going on. Um I remember
when I first started there were a lot more images in general. So for example on your website you would have background images for everything. You know your buttons would have background images and things were a lot more crazy and you know generally more artsy and artistic. These days things are more restrained. They're still creative but we've um matured into an industry that is much more UX driven
user focused. Um it's more science-based in general. So, we actually have more in common with designers these days as developers than what we did. So, I've talked a little bit about design logic up until this point. Um, but I want to see if we can find some for ourselves or at least try and find some where it's missing because it's not always the case that the designer
will actually um put the necessary clues and tools in their work for us to find. So can we find where that logic is missing? So this is going to be our mission. Let's root out where the design logic is needed. So we're wanting to build a particular part of the UI. Um where do we actually need some logic where we can't find it? We're going to interrogate
the design to find it. And we're create going to create our own design logic where there is none. But of course we have to negotiate with the designer through this whole process. So, let's take this example. This is a really simple one, right? So, you've got a mobile nav. You click the burger icon to open the menu and there's a bunch of items in here. And at
first glance, everything looks totally fine. You know, no issue. But the more you think about it, the more you realize actually each item has two separate functions. So, on one hand, it's going to go to the about page, that first item, but it's also going to expand the menu. So, there's two things going on, but it looks like one clickable area. So, the designer hasn't put a
clue in there for us on where those clickable areas should uh should change from one to the other. So, let's just recap that. So, each row in the menu has two functions. Click to go to the page and click to open the menu. There's no visual separation for us in the design. Um, and there's no clues in the design that can help us try and figure that
out. So, we go back to the designer and we negotiate a solution. And maybe it's as simple as actually adding in a divider. It doesn't look that great to be honest. It looks much cleaner the way it did before. But in this case, we need something like that to actually make the design come to life and work. Or this is another classic example. So, this is your
typical hero block that you have on a website. Um, you have some text overlaid on the top and you have this person in the background. And this is so so hard to get right, especially when it needs to be full width and height of the screen. There's all sorts of things that can go wrong. And sometimes the logic isn't in the design for us to solve these
problems. So the requirements here is the image needs to span the full width and height of the screen, which could be any size. The focal point of the image should always be in view. So we don't want to crop away that person's face. and content editors will need to be confident that when they upload an image in Drupal that it's actually going to work and they're not
going to have to play a guessing game of trying to get an image that really works. So you can see even on a really wide screen the top of her head her brain's sort of gone. On a tablet screen part of her face is gone as well. And the story changes completely. Even on a mobile phone we've got something else going on. So, it's clear that the
cropping is not really working. We can help with things like Drupal focal points. Um, that module can really help to try and alleviate these problems, but we're probably going to have to change something else. And that could be a bunch of things. You know, there's no one magic bullet here. We could snap that image to a fixed ratio. So, maybe we just say, hey, it's always going
to be 2x3. And in that case, we're not going to do the full width and height thing. uh maybe we change the way that that text box behaves. So in the design you might see yes the text box is always 400 pixels wide but maybe we need to reinterpret that maybe the text box actually can shrink a little bit you know maybe it's more like a min
width of 300 pixels or something like that. Um or we just add a hard requirement that actually you can't put a person in there, you know, no people allowed. You can only put something like landscape which can be cropped, you know, anyway. And of course, we've got to talk about AI. It wouldn't be a presentation without AI. So, can I get a show of hands in the
room who has heard of AI or has a decent understanding of AI? Can I just get a show of hands? Put your hands high in the room. Yeah, any kind of understanding will do. >> Cool. I think that was most of people. Um, so Amy Irving, it's really surprising. So, basically, she hasn't done a lot of recent work, but she was fairly active in the early 80s
and I think she was nominated for maybe two Golden Globes, I think, and one Oscar, but pretty obscure. So, it's amazing that most of you seem to know who she So, let's wrap this up. So, my challenge to you, so my challenge comes in two parts. The first part is I want you to level up your dev game. So, we're very competent as developers and we're very
proactive in trying to expand our skill set in the programming realm, but I want to challenge you. Think about the other end of the stack. the other part of the spectrum which is design. Um trying to un expand your understanding of things like uh color theory for example or Figma or any of those design kind of things that we usually don't think of as being our responsibility.
Um I want you to take a step back as well. So when you're implementing a front end instead of copying across design tokens try and question yourself as to what they actually mean. Is it just the the story that yes, you can just copy it straight across or is there something deeper going on? Um, and question your tech choices. So again, this can change everything. You know,
is Tailwind the right technology for the job. Maybe when you look at the Figma design and you see that logic, you realize actually no or maybe we do use it. So you want to question what you're doing completely based on how the design is supposed to work. Yeah. And the bigger challenge is exploring that other end of the stack and bridging that gap between designers and developers.
Um connecting with your roots. You know, I don't want to get too sappy here, but I do believe that we all eventually come from that original um that original birthplace of web design and that's all who we are at our roots. Um so try and relearn what it means to Um, and try to expand your working knowledge of things like design systems, storybook. You might just focus
on the technology side of things, how to set up a storybook instance, but try and understand how design systems themselves are supposed to work. Cool. And that is the end of my presentation. Um, yep. Thank you. Nice. There's a feedback code there if you want to submit some feedback. Um, so yeah, if anyone's got any questions or comments or anything, I'd love to hear. Yep. Oh, we
got one over here. >> Um, I've been kind of getting more into front end back for most of my career and so been kind of naturally thinking about like sort of design from an engineering standpoint. I think it's kind of what you're suggesting here. >> Yeah, exactly. I think the logic in designs can completely change the way you might even choose a technology. So you might completely
move away from you know one particular way of doing CSS or even one particular way of doing templating based on the way that your designers are setting things up. >> I also sort of see it as like ownership of the design rather something that's like handed to you. like the thing that you're creating, you are actually responsible for decisions around that. And once you take ownership of
it and you get into things like design or color theory and other things that are normally in designers hands, it's extremely empowering because you can we're designing for content management systems where we expect our clients to be slapping layouts and components and content together and it's supposed to just work. But to create components that actually do that is super hard. Exactly. Yeah. And quite often I notice
we find these little discrepancies in a design and we think if only they could have made our lives easier, you know, by changing one thing in the design. But actually by Yeah. By taking that on board, I think it's really empowering because then we suddenly it clicks for us and we realize that they're not trying to make our lives difficult. They just have a completely different mental
model sometimes of how the design is >> Cool. Yeah. One over here. I would just love to say something as a designer on design. Um, don't be afraid to ask questions, please. Um, like definitely look through your Figma file, actually open up the prototype. For me, like I always build in interactions to my components and I want to be able to use that as like this is
what I'm expecting. So like look at that stuff, look at the documentation. But if you do run into the situation where it's like, "Oh, there's these two things that are just slightly different. This is going to make my life miserable." Just ask like, "Is that actually important?" It might not be. Um, so yeah, I would love to have that open communication that I think there's sometimes this
artificial barrier that comes up once the handoff is complete. >> Yeah. Exactly. Yeah. So, it's about bridging that gap between Yeah. designers and developers and like Yeah. the more dialogue you have, I think that can be the start of that awareness shift >> I think you can kind of create the space for that because when developers are working on product for clients, they're just like got to
get the deadline. I got to get this done and so we're kind of reluctant to reach out because we feel like it might slow it down even though it does lead to better quality. I've been thinking that like the middle ground is like design systems and like building out a storybook instance. And when a developer is tasked with doing that, they're not trying to hit a deadline
and trying to bring something that everyone can share that is of high quality. I feel like the conversations among um design system teams is like where this design logic really comes into play. Nice. Any other questions? >> Nice. I've been told to also remind you that at evolving web we also have um our own conferences as well which you're almost welcome to to join if you're interested
in this kind of thing if you're interested in um agency sort of work then we have some awesome conferences coming up uh later this year.
