Full Stack Devs Suck at Design. I Can Save Them

Hello. It's still very bright, by the way, that light, still really, really bright. Hello. I'm Tantacool and full-stack devs back at design. I'm just going to try and find this button here.

It's the green button. I can save them. I have saved them in the past and I can save them again. So, the problem is that I can't see my slides down there because I don't have my glasses on. So, sometimes devs make design decisions just because they can or because they have to.

That can mean that your app is going to go completely off-brand, looking at you, Lawrence, with your squashed logo, one like that. You can get weird UX patterns. When I worked with developers before, I heard this term bike-shitting a lot. I didn't really know what it means, but now I do. So, you can go off-brand when you have this many colors to choose from.

It gets confusing. You have to remember them all. This is a recent incident we had, actually, at work. Don't put form inputs below the submit button just because you can or because someone else did it. I tried to get Jack GPT to draw this up for me and he refused.

So, actually, sometimes the AI is right at UX and your full stack devs aren't. He was trying to draw the form bit below the submit button but refused to put it on the screen because it should never go below the submit button. Here's a good story I heard yesterday as well. UX to the developer. Here's my design, dev.

No, I think we need to move that icon, UX. Well, this is the logical placement. Here's the design system that's in place and here's the reasoning behind it. And the dev was like, well, let's get AI to make the final decision, not the designer. Why are they there?

How do I know this? So, in a previous life, I used to work in enterprise software and my job was to clean up devs, basically. I removed a lot of bootstrap and I put in semantic HTML and hand-rolled CSS, basically. And so what that did was we were taking away all the design choices away from the developers so that they didn't have that cognitive overload. Also, so they didn't fuck it up, basically.

As a result, people stick to their jobs, designers do design, developers do the development. And why does this happen? Well, just because you can, you control the code base, you're the developers, doesn't mean you should. If this piece of graphic design here doesn't make any sense to you, then you're not a designer, basically. Then don't do design.

So how did we get here? Well, how did we get here? We have the tools, we just forgot how to use them. Because HTML is only for junior devs, and real devs just use lots of devs, which is why God invented JavaScript. And you can see here, actually, the HTML person is just the HTML guy, and to be a developer you have to be full stack or better.

Otherwise you're just the guy. So, click, here we go. But where we're going, we do not need three UI libraries to build our apps. That sheds the end to do an accordion. Or, actually, you can make one with semantic markups, and then you can put your styling in your global CSS, and it makes your code a lot easier to read.

Cognitive overload for developers is massively reduced. You can see what you're doing, you don't have to scroll all over the bloody place. But also, CSS is also just for juniors, so God had to invent style components to make CSS difficult as well. And things like CSS and JS, because otherwise you're just the CSS guy, not the full stack developer, who is more important. Right, yes, and this is, I have seen so many code bases where you have your TypeScript files, oh, sorry, I thought that was seconds.

You know, you've got all your TypeScript files nicely arranged in your big directories, and in all of that, you've got your index.tsx, lovely, all very nice and organized. And in those, you have the style.tsx file, and in each of those files, you have every piece of UI in there, so you could have one button in every single file. I've seen this happen, because there's one on one page, and they're like, well, we'll have 12 instances of our button style components, and then you start getting drift.

And that's when your design starts cocking up, basically. And so, I'm here basically to make life easier for developers. You make things less complicated, your design is going to look great, and you don't actually have to design anything. We also have a new entry in our full stack developer portfolio here, should we say, of devs. We have Claude, who loves to add lots and lots of markup to your code.

So I have now trained Claude to, it's illegal for Claude to add a font color, padding, or anything like that. It's just pure semantic markup, or jsx. I get a load less crush to my code, and it looks way better. I'm like, look, mate, look at the CSS, don't touch it. We don't end up with lots of different designs.

So it's a global CSS, or get out of here, basically. The design just happens. If you want fancy stuff, you can do your magic sparkles and your beautiful 3JS, that can all come later. The way I design is I basically get wireframe into my app, get people to test it. So a little primer here.

If you're a developer, you don't have a designer sometimes, this is just a good little checkpoint to look at. As little design as possible is the main one, and everything else basically falls out of the back of that. Excuse me, just going to have a sip of water. And shake like a leaf. Anyway, I'm fine.

Yes, so, great little checklist here if you're particularly a developer with no designer. But here's our CSS guy. Now, it's amazing what he can actually do. So as I've said, I work purely with semantic markup and CSS. Global CSS means that the designers can take ownership of that, or somebody who's in charge of design.

The instant design comes out of the box, basically. Oh, what's that? Let the developers go fast. You don't have to wonder about overload of design choices, what's our brand color, I've forgotten which pale and blue it is. And then also on the design system that I'm building, I've put in minimal utility and layout classes so that we don't need Tailwind.

Tailwind has got very weird lately. I can't operate it anymore. It's very complicated and lots of different bits of code I have to add just to create my own classes. And then variables for app customization. So if you have a suite of apps, for example, you can change it pretty easily.

So we're going to go through this list of what is good design and how does CSS and HTML assist that. One moment to call off the drink. Right, that's better. So, being innovative, well, what you want to do with your products is get PMF basically, the mythical crypto PMF. So in order to get that, you want to test early.

And in order to test early, you want to get your app out fast instead of languishing over it and going, oh, it's not perfect. This is what CSS can do for you. I actually built these basic tabs out. Sorry, I can't see that. My eyes are not very good.

But I built these tabs out just using CSS. They're actually radio buttons. It's a bit weird. But it's super lightweight code. And you can see here the markup.

It's not full of crust. It's not like a million Tailwind colors and shadows and dropdowns and all that kind of thing. You can see what you're coding. It makes you fast. You get up to test early.

And you can embarrass yourself in front of your users. So this is what I'm working on at the moment. The old Pentacle project has become virtual. If anybody knows of Pentacle, not just me, a project named too. So we have one minified CSS that rules them all.

I haven't actually put it in here, but the CSS is broken down into element names. Then it all gets bundled into one. And then each app has theme variables, so that we don't kill everybody with boredom having the same design for every single app. We can change things at this global level. Sorry.

And then at the local level, basically. And also just really easy to do dark and light work, which is normally really hard and complicated. But CSS, if you're minimalistic with your CSS, you can do it very quickly. Sorry. Anyway, quick tip for developers.

Functions first. Bring your code to the surface. I also do quite a bit of back-end work as well with data. And I just like to think about how that interfaces with my front-end and how much front-end I can actually get rid of to let the back-end come through. Because that's actually what people are interacting with.

It doesn't have to be all that design personality. Your brand can be very simple. Don't design it. Let it design itself. Here's an example of that.

I mean, it didn't really. But it's about taking things away. Get your product working and then see what it's telling you. And take away as much design as you possibly can. So good design makes product useful.

Yes. So this is kind of referring to the product in the product. So I think about my CSS library as a product. So inside the product, it empowers devs. It gives them more time.

It's less confusing. You don't have to think about design. You don't have to think about centering divs. Horizontal and vertically. It gives designers control over things like color palettes.

Make it super simple. You can control, like, global border aliases, global padding, all in one place. Which then, in turn, tidies up your design. And it's self-explanatory because even the junior developers know HTML. So this is just a quick drive-through slide.

Don't let your users get away. So make your product useful. Put your information within your interface. Don't let this guy here go off to your marketing website or your get book. He'll get distracted because something's just happened in the group chat and he's gone.

Bye. Aesthetics talks about this. So that is basically how I control light and dark mode. Super minimal amount of colors. Your design will look way better.

Make things minimal by default here. That's the card. That's used across multiple apps. And it's, you know, a few lines of code, basically. Then you can add some chaos.

Once you've got your wireframe and grid stuff in, then you can kind of add some swishy animations and make it weird and interesting and a bit overloaded, that one. Right, so this is an example of very simple designs that had a bit of chaos added later. This actually took two weeks to build. And it's really simple. It's three pages.

It's in Helveska. But all the work went in and this was going to be animated, but that was too dangerous. But this is a piece of 3JS. It's quite a long animation and it's got a very specific film grain effect over it. So that's where the energy went into after we really nailed the design down to literally nothing.

All right, yep, so making your product understandable. Again, kind of product in the product with your code base being part of that. Make it understandable. It's a lot faster to be able to code semantic HTML. It means you don't have to make up styles, components, and invent new taxonomy that may not line up with what the business thinks.

And then everyone has to learn a new language. You know, with all millions of divs as well, things just get confusing. So semantic HTML actually gives you so much just out of the box. That's my continuation of the He-Man theme about brand colors. I got cropped off there.

And also with semantic HTML, you know, you just get accessibility out of the box as well. And also for people who are using keyboards to navigate or a sighting tag, again, their screen readers can read semantic markup. They're not reading the divs. Yep, quick tip also, follow human patterns, eye tracking, things like reading books. It's kind of a well-known design pattern.

Start up there, read down, finish the page, press the submit button at the end. Don't put the input after the submit button. Good design is unobtrusive. This is Viper that we did last year. And it's this very simple grid.

It's got a simple animation in it, super old school, UL, LI for the footer navigation. And to give it that elegance, we just put a simple scroll behavior, smooth, no JavaScript required, good old HTML, and it looks very, very nice. Keep your design honest. Be upfront. Tell your people that you've all unsubscribed them basically.

Oh, shit, I'm running out of time. So be upfront. Don't hide information. Don't do dark UX patterns. Never pre-select a radio button.

That's the worst UX crime. Good design is long-lasting. This is from 1923. And HTML also is never going to go out of fashion, as Tim has proved in his motherfucking websites. There's no dependencies.

It's just going to run basically, and it works. There's no buttons, though. So good design is thorough down to the last detail. Again, just create a simple grid. Don't have millions of different paddings and alignments that Claude has given you.

Just strip it all out, basically. Literally have nothing, and it will look better. Here are some examples of that. You can see where the H1s are. You can be a bit weird with design.

Grid system is a good example here of just design and aligning up. Right. Be environmentally friendly. You can have a small amount of code. Less is more.

There's a tiny amount of elements on that design, but an element of being handmade makes it interesting. So this means that you can be consistent. And as backend developers, or whoever you are, you can just get away with a handful of colors, and it looks frickin' awesome, really. And you can use your code to inspire your front end. But I have ideas.

No, don't. Just remember, as little design as possible. But also, as John Maeda says, great design makes things clear. But simplicity and complexity also need each other. So again, that's back to that principle.

Start with something really simple, and then add some beautiful design elements. This is something I did for Joseph. Neat preview. You can see just H2s and paragraphs in here. A bit of fiddly CSS for the borders so that it works in responses, so you don't get double borders.

And again, this is all completely stripped back to absolutely nothing, and a handful of CSS, basically. So, that's it. I finished early. I erased the last slide. Yes, remember, you can just not design things.