All articles

How I Do Design as a Backend Developer

HugoHugo
··10 min read

Imagine the place. It's dark, it's only 6pm but winter and cold have arrived.

We are in a classroom, unhygienic and unheated, like all suburban Paris classrooms, because the high priests of 'Macronomics' decided it was more interesting to pay millions of Euros for McKinsey PowerPoints than to actually invest in our future! ... I'm getting off track

Briefly, a circle of people gathers, on small wooden chairs that hurt like hell. I'm present, looking grim. Actually no I wasn't listening to Jean-Michel who just spoke but I'm still trying to understand how the Spurs managed to mess up so badly in the last games of the 2026 NBA Finals.

And then I get up and introduce myself.

"Hello I'm Hugo Lassiège, I'm first and foremost a backend developer and here's my first version of Malt in 2012"

Malt version from 2012 (never shown publicly, and we can understand why)
Malt version from 2012 (never shown publicly, and we can understand why)

Basically, I'm terrible at design.

So how in 2026 do I manage to propose designs like this blog's? That's what I propose to show you in this post.

thumbnail of the eventuallycoding.com blog
thumbnail of the eventuallycoding.com blog

2011, the army of clones

If the somewhat historical part doesn't interest you that much, you can skip directly to the next sections to go to my current workflow which is described further down.

2012 was quite a long time ago and at the time I was using Bootstrap primarily, which explains that little very characteristic style from the first screenshot (mixed with frankly questionable aesthetic tastes, I'll grant you).

Because yes, in 2011 a framework came out, Bootstrap if you've been following, which offered to make available the official UI kit used at Twitter. Inside we found the guidelines for making buttons, forms, progress bars, all in the spirit of the blue bird. We also found all the tools to more easily build responsive websites with the famous grid system that would last a long time. A very long time.

For backend devs like me, that is to say those with more than modest taste for design, it was an opportunity to start with simple bases to finally make websites that don't look like they came out of a koala's acid trip imagination.

Following Bootstrap several other libraries came out, Foundation, Materializecss, and so on but always with that little syndrome for sites using them of "but damn, what is this army of clones".

From atomic design to design systems

Now it was nice to have a standard grid and buttons, but you still had to assemble them together. If buttons, input fields, text blocks were atoms, you needed to give a structure to assemble them in the form of molecules.

This is exactly this analogy that would be progressively pushed starting in 2013/2014 by Brad Frost, under the name of Atomic Design.

This notion of molecules is really what you might call a component. A component fixes the assembly of our molecules as well as a behavior. And that's exactly what we find in several frameworks released in the same period, React (2013), Vue (2014) and even more generally Web Components (2011).

As an aside, in my previous company (Malt) we grew in the same period, we thought it would be a great idea to mix all of this. We did Bootstrap, then we grouped all of that with an in-house framework (HopModules), we added Vue around 2015, then built Web Components, then used Nuxt a bit later to finally realize around 2023 that actually, that was a lot of everything...

(But it's another story I tell here).

Briefly, we started building "components" that we assembled, standardized to finally arrive at what we call today, a design system, that is to say sorts of Lego bricks that you can assemble together and that guarantee a certain identity, a voice for a site. Design systems that are even often public and that you can find and study on different sites.

Tailwind and design tokens

To build a design system, there was a missing brick. It's nice to say for example that your buttons have a border radius of 4px. 4, not 2, not 6 but 4.

And it's rather simple to express globally:

css
.button { border-radius: 4px; }

But imagine you also want to align this radius on all your cards?

Imagine you want to define a global padding, a "primary" color for your main buttons, the possible font sizes across the entire site.

If the button is the atom, in reality there was a missing element below, how do you create our atoms?

During the 2010s (perhaps via Jina Anne at Salesforce in 2014), someone introduces a new term: the design token.

A design token is the definition of the interface structure by these tokens.

For example:

  • #0055ff becomes the color-brand-primary token
  • 16px becomes the spacing-medium

etc...

And that's exactly the approach of Tailwind in 2017 which arrives with definitions of design tokens via a bunch of utility classes that will become very very used in current websites.

So, Tailwind doesn't get unanimity for many reasons and it was never introduced at Malt. But for my new projects, it became the default solution. And now we can talk about my design workflow :)

My pre-2024 workflow, Tailwind and its component libraries

Pre-2024 (soon we'll talk about the pre-AI agent era...) I launched Hakanai.io. Let's not fool ourselves, it's better than what I was doing in 2012, but it's also as cheerful as an autumn day in Melun.

hakanai.io interface created in 2024
hakanai.io interface created in 2024

Despite this, here we find my 2024 design workflow, the use of Tailwind and component libraries such as preline.io or Flowbite.com. It's an assembly of more or less visually coherent blocks but which have the advantage of having structural coherence through Tailwind's design tokens.

It seems like nothing but it's already good. The spacing and breathing are consistent, the colors give an identity, the fonts are uniform, in short, it's a design system properly used. So yes, even Harry Potter drained of his soul by a Dementor looks better, but it works.

a Dementor expressing its love for Harry
a Dementor expressing its love for Harry

And that's broadly the spirit of most "indie" sites released in that period. Correct. But nothing to write home about.

And then came AI

Starting in 2024 through early 2025, my workflow became less manual. I started building interfaces by asking Claude to do it. It was still copy-paste between the chat in the browser and my IDE. It was only HTML/JS/CSS and then I did the adaptation by hand.

And then Claude came into the IDE, so it could directly create mockups in my code. However Claude reproduces the style it sees in the other pages, so since the site was created pre-2024, well it reproduced my somewhat "meeehhh" style from before.

the broadcast.hakanai.io dashboard
the broadcast.hakanai.io dashboard

So already in 2025, I started changing my workflow for certain pages and especially the first themes available on writizzy.com. I started from a blank slate, giving some constraints but making sure Claude didn't rely on existing work.

forge theme on writizzy
forge theme on writizzy

Sometimes I asked it to draw inspiration from known software, here with Notion:

notion theme on writizzy
notion theme on writizzy

Despite this, Claude has a certain tendency after a while to produce pretty much the same patterns and you can increasingly recognize an interface made by an AI. It's clean, it's better than what I produce alone, but it lacks originality. For admin interface in a SAAS it's not a big deal but to stand out on the internet, you have to make more effort.

I started seeing skills appear to avoid the "slopification": tasteskill and impeccable but which I haven't personally tested. On the other hand, for some time I've been systematically using Claude Design and there, I see a significant improvement in what I produce.

First, what is Claude Design?

Claude Design interface
Claude Design interface

Claude Design is specially optimized for interface creation, whether for its system instructions which are optimized for UI (but not UX!!), and through its tooling.

CD will indeed be able to visualize the result and iterate autonomously via screenshots. You'll be able to have a "tweaks" panel to visualize options, make low fidelity mockups or finished interfaces, comment on areas, etc...

But especially CD can start from a screenshot to get a vibe. So if I take the tux theme we can see in the screenshot above, I started from a site whose graphic vibe I appreciated, I gave it an image and instructions for it to capture the essence: the grids, the particularly bright accents in certain places, the thick and tilted underlines etc... I had to iterate, the first draft had issues but the result is rather interesting.

The big limitation is that CD can't understand animations (except to copy paste the code from the html page), yet that's one of the strengths of the original site and for now it remains a weakness of my workflow.

Another use case is to start from a design system. You can define one directly, or iterate based on the model that seems most relevant to you. Here for example, it's the Writizzy dashboard in its new style. And now each new page starts from this one which serves as a "design system" to build the next ones.

Writizzy design system
Writizzy design system

In short my workflows are as follows:

  • creating a mockup with Claude Design with 3 options:
    • from a brief
    • from a screenshot
    • from a design system
  • implementation in my own code via an "implement-mockup" skill that explains how to transcribe the html code produced by Claude in my technologies (nuxt-ui, tailwind)

And more recently, I'm testing:

  • use of agent-browser or playwright to test the interface, especially in responsive

So don't be mistaken, I much prefer working with a designer and I would when Writizzy gets bigger. But to get started, for an indie site, it remains much better than what I could do before and the level of expectations from users has become so much greater now that anyway, it's no longer really an option to do "like before". Because yes, design gives a voice to a site, an identity. That and of course the text, on the page, the way you address readers. Without identity, a site, an application, doesn't hold your attention.

Of course it's less true on a blog post, you come to read the content, not the container, or on an admin interface of a software. But still, you don't want to be punished visually and give the impression of "meeehhh".

Now let's take a step back, is it perfect? No.

Yes, if you look at the path traveled in 15 years, it's easier to build websites. Since Bootstrap we've sought order, structure, standardization and it works.

But at what cost? We've classified components, documented margins, frozen systems. We've rationalized beauty. The problem is that by wanting to systematize everything, we've created an incredibly clean web, but terribly boring. A web without friction, but without soul. And AI, by its very nature, is the absolute queen for reproducing this kind of lukewarm consensus. If you ask it for "clean", it will give you clean.

Do I sometimes feel a little nostalgic for the ugly web of the early 2000s? Maybe.

Well, not always.... It depends! I don't know!!!

yorkshire breeding site from the 2000s
yorkshire breeding site from the 2000s

But maybe that's exactly it, if AI relieves us of the plumbing, if the technique is automated, it's an opportunity for us to put back intention, identity, emotion (I didn't think I'd write that one day). Maybe that's what the evolution of the coming years looks like, breaking the rules, and making ugly things again, but with a beautiful voice.

Stay in the loop

Get new articles delivered directly to your inbox. No spam, unsubscribe anytime.

0 Comments

No comments yet. Be the first to comment!