Design or code: how to work out in one evening which suits you
August 28, 2026 · 8 minutes · Vladimir Motipan
A procedure instead of guesswork: build the same product card two ways and compare. Below is the exact task you can do this evening, for free.
Why «what should you be» quizzes do not work
A career quiz asks whether you like logic and whether you consider yourself a creative person. The trouble is that both professions require both, and you are answering not for your real self but for your image of yourself. Someone who has never opened an editor answers about an imaginary job — and gets an imaginary result.
The second source of error is a picture assembled from other people's stories. «The designer draws pretty things and the developer repeats them» is the most widespread and the most wrong picture there is. In reality both roles make decisions, just about different things, and the choice is not between «creativity» and «logic» but between two kinds of tiredness.
The advice given in almost every article on the subject sounds right: try tasks from each direction and compare. It is just rarely explained which tasks to take so that the comparison is honest. Below is a concrete procedure: the same object, the same amount of work, one evening.
The same screen two ways: the point of the experiment
Take a product card — the most common interface element, simple enough to build in an hour and alive enough to run into real decisions. First build it in Figma, then write it in the browser. The order matters: the design first, the code second, because that is how the work goes in life.
Fix what the card contains in advance, or there will be nothing to compare the two experiences against: a photograph 280 by 200, a category badge «Ceramics», the heading «Olma mug, 350 ml», the description «Matte glaze, handmade. Dishwasher safe», the price «€24» and the button «Add to cart».
Set the sizes with numbers too, not by eye: card width 320, inner padding 20 on all sides, 16 between the large blocks, 8 between lines of text inside one block, card corner radius 16, photo corner radius 12. All the numbers are multiples of four — when every distance comes from one short set, a rhythm appears between the elements and you no longer have to choose between 13 and 15 pixels every time.
Nothing paid is needed. Figma runs in a browser and the free plan is enough for this task. For the second part you need any text editor — the free Visual Studio Code or even Notepad — and the browser you already have.
- 20 minutes — take someone else's card in an online shop apart and write down what it is made of.
- 40 minutes — build your own card in Figma using the numbers above.
- 20 minutes — write the markup of the same card in
index.html. - 30 minutes — style it in
style.cssand adjust a couple of values right in the browser. - 10 minutes — break four things one at a time and put them back.
- 10 minutes — answer the six questions from the section below, in writing.
What you do in the designer's role: taking a screen apart into grid, text and elements
The first action is not drawing but analysis. Open any online shop, find the product list and split one card into four layers: the canvas (background and width), the containers (invisible rectangular areas that hold the construction together), the content (text, images, buttons) and the emptiness (the distances between all of it). The emptiness is not on that list to make up the numbers: it is set with numbers just like a font size, and it is precisely random distances that make a screen look untidy even when every element on its own is fine.
Then build your own card. In Figma press F and make a frame 400 by 640 — that will be the screen. Inside it assemble three text layers, select them and press Shift + A: you get a container with auto layout that arranges the content itself. Give it a downward direction, a distance of 8 and inner padding of 20 — with numbers in the right-hand panel, not by dragging with the mouse.
Build from the bottom up: individual elements first, then blocks, then the whole card. The photo — a rectangle 280 by 200 with a corner radius of 12. The text block — a badge at 12 points in the colour 8A8378, a heading at 20 semibold in 1A1A1A, a description at 14 in 6B6B6B. The bottom row — the price and the button in a horizontal container with space between them. And all of that inside an outer vertical container with a distance of 16 and padding of 20.
At the end, test the work for strength: replace the heading with «Olma mug of warm clay, handmade, 350 millilitres». The card should become taller, the width should stay 320 and the distances should stay the same. If something has shifted, look for the layer with the wrong sizing behaviour. That is what an interface designer's work is: not «making it pretty» but describing the rules by which a screen lives with any content.
What you do in the developer's role: the same card in HTML and CSS
Create a folder and two empty files in it: index.html and style.css. In the first one, describe what each piece of content is. The card — <article>, because it is a self-contained piece of content. The heading — <h2>. The badge, the description and the price — <p>. The button — <button>, not a coloured-in <div>: a real button takes focus on Tab and fires on Enter, and none of that has to be programmed. The grouping blocks — <div>: exactly the same role as a frame with auto layout in the design.
Open the file in the browser and you will see black text in a column. That is normal: without styles the browser stacks blocks one under another, and that order is called the flow.
Now the styling. The key discovery of this part is that auto layout and flex are the same thing in different languages. A direction down or to the right is flex-direction: column or row. The distance between elements is gap. A frame's inner padding is padding. Centring is align-items: center. Pushing to the edges is justify-content: space-between. So exactly the numbers you already decided on in the design will appear in the CSS: gap: 16px between blocks, gap: 8px inside the text, padding: 20px around the edges, border-radius: 16px on the card.
And the obligatory part of the experiment — breaking things. Make one change, look at the result, put it back. Delete the line box-sizing: border-box — the card becomes 40 pixels wider, because the padding is no longer included in the width you set. Change column to row — the blocks line up and squeeze together. Set gap: 0 — everything sticks together, and you see the same rule of proximity as in the design, only in another language. Remove justify-content — the button presses up against the price.
Which feelings to judge by: what should appeal, and what it is fine to dislike
After the two builds, answer in writing and briefly, with the first thing that comes to mind. Where did the time pass unnoticed and where were you glancing at the clock? What annoyed you more: that there is no single right answer, or that there is a right answer but it does not work? When something did not come out, did you want to try variants or to find the cause? Which of the two cards do you want to finish right now? What have you already looked up of your own accord, in passing?
How to read the answers. Design, more likely — if you enjoyed trying variants and comparing them, if a spoiled card made you want to rearrange rather than debug, and if you are comfortable with there being no right answer. Code, more likely — if it was the breakage that gripped you: not «it got ugly» but «interesting, why did it do that», if you wanted precision and repeatability, and if the pleasure came not from the beauty of the result but from the fact that it came together correctly.
It is fine to dislike: in design — the endless comparison of nearly identical variants and other people's changes with no reason given; in code — that a mistake in one character stops everything and half an hour goes on hunting for a typo. If that annoys you, it does not mean you «are not suited»: it is part of the job in both cases.
«Neither» is an honest result too, and it cost you one evening instead of a year. Two hours are not enough to measure ability, but they are enough to measure interest. Ability is built by practice; interest is not — it either appears or it does not.
Check yourself separately on the honesty of your wording. «I liked design because it is beautiful there» is not an observation but a retelling of expectations. An observation sounds like this: «I spent twenty minutes choosing between two shades of grey and did not notice the time», or «I spent half an hour finding why a block had moved by four pixels, and that was more interesting than the card itself». The second is more useful than the first, because it describes the work rather than the picture.
If you would rather not do this step by step yourself, the same experiment is assembled whole in the «Where to start» course for €3: two hours, eight short lessons, a starter file in Figma, a starter project for code and a walkthrough of the finished solution to compare with your own. The course does not teach a profession — it exists precisely so that you can choose a direction from experience rather than from stories.
Where the designer's work ends and code begins
By this point the border is visible with your hands, but it is worth stating. The designer decides what is primary on the screen and what is secondary, and by what means that is shown; how much emptiness there is between blocks and why exactly that much; what words are on the button; which states an element has — normal, hover, pressed, disabled; what a person sees when the list is empty, and what they see when everything is broken. Half of that list is not about beauty but about behaviour.
The developer decides which tags describe the content so that the browser and the screen reader know where the heading is and where the button is; how the blocks will behave if there is twice as much text or the window is half as wide; where the data will come from — the title, the price and the image come from a server, they are not typed in by hand; what to show while the answer has not arrived; and how not to write the same thing six times. A design is static; code has to work for an endless number of cases.
And there is the seam, where the most interesting things happen: in the design the heading takes two lines, in life you meet one that takes five — truncate or wrap? In the design there is one button, in code it needs at least four states. The design is drawn for one width and has to work at all of them. A good specialist in either role is the one who asks the questions about the seam before the work is done, not after. Incidentally, it is precisely because of such questions that a separate handover procedure exists: what goes into it is covered in the article how to hand a design to a developer.
Where to go next depending on the result
If the design turned out to be closer, the next step is components, variants, states and responsiveness — that is, «Interfaces in Figma». You can start from zero, and it ends with a design that gets accepted into work.
If the code turned out to be closer — «Markup without magic»: flow, the box model, flex and grid down to causes rather than recipes. Also from zero. Later, once your markup is confident, React opens up — but only after that, and by the list of requirements rather than straight away.
If both options felt boring but the very idea of «making a thing that works» did not, try a direction with no screen at all: a program that processes data rather than drawing an interface.
And the last rule of choosing, the most reliable one. If you are torn between design and markup, take the direction where you wanted to finish the card. That is a more accurate sign than reasoning about the market and salaries: you will be doing this for many hours in a row, and interest is the only thing that holds you over a long distance. Set yourself a first step for the week — small and checkable: build a cart screen out of three such cards, or write a second card next to the first and make them line up in a row. And put a date on it.
Where to start
3 modules · 2 hours · From scratch