We use cookies to improve your experience and measure our ads. Learn more
We work on the same products and talk most days, and we still surprise each other every sprint. So we wrote down the things we have each been quietly thinking. One list from the designer, one from the developer, both more honest than usual.
Written by Umair Akram (Engineering) and Alfie Willmott (Design) at Cardiff App Developers
We work on the same products and talk most days, and we still surprise each other every sprint. So we wrote down the things we have each been quietly thinking. One list from the designer, one from the developer, both more honest than usual.
If you have ever been on either side of a handoff, you will recognise most of it.
Spacing is doing a job.
That 24px gap is 24 because 16 felt too tight and 32 broke the rhythm on mobile. When it ships as "about 20," the screen stops feeling calm. I know it looks like a small thing. It is the difference between a screen that feels designed and one that feels put together in a hurry.
Component sizes are measurements.
The button is 44 high because that is what a thumb needs and what the input beside it sits at. When it comes back at 40, it stops lining up with the row around it and everything looks slightly off. Sizes in the file relate to each other. Changing one in isolation breaks the two you were not looking at.
You changed something small and did not tell me.
A different font weight, a slightly bigger corner radius, a heavier shadow. On its own, each one is nothing, across forty components, the product stops looking like one product. Changing it is fine. I would rather hear it from you than find it in QA.
When something was missing, you guessed.
Sometimes I forget a state. That is my fault. But when the error state is not in the file, the fix is a two-minute message rather than fifteen minutes of inventing one. The invented one always makes it to production, because nobody reviews a screen they do not know exists.
Mobile got made up as you went.
I gave you 375 and 1440. I know that leaves a lot of guessing in between. But mobile is not the desktop layout with things stacked on top of each other. If you are guessing the breakpoints at 6pm, tell me. I would rather draw the awkward screen than see it later.
October 2026
Explore how sustainable software, efficient AI and informed cloud hosting choices can help businesses measure and reduce their environmental impact.
October 2026
Apple's first foldable iPhone gives apps more screen sizes, more ways to multitask and more chances for old layout assumptions to show. If your business already has an iOS app, this checklist helps you decide what needs fixing, what could be improved and what can wait.
"Just move it" is usually not just.
That card is used on six screens. Moving it on one screen means changing all six, or splitting it into two components that both need looking after from now on. I am not saying no. It takes five seconds in Figma and a decision in code. Tell me what you are trying to fix, not just where to put it, and I can usually do it for free.
Real data is uglier than your data.
Titles wrap onto three lines. Photos come in the wrong shape because a client uploaded them from a phone. Prices have different currency symbols. Half the fields are empty because the user skipped them. If a design only works with the content in the file, we will have to redo it during the build.
Every one-off value costs us later.
Five greys that are almost the same grey are five things that will slowly drift apart over two years. Same with one-off font sizes and spacing. This is not about being lazy. Anything that is not in the design system is something nobody can find later.
That animation will stutter.
It looks great at 60fps on your laptop. It has to run on a three-year-old Android phone on a bus. Blur, big shadows, and anything that moves the layout are the usual problems. Tell me what the movement is meant to say and I will find a cheaper way to say it.
The states you skipped are where users actually are.
Loading, empty, error, offline, no permission. On a slow connection, people see these more than they see the finished screen, so they are most of the real experience rather than edge cases we handle later. When they are not designed, I design them at 6pm, badly.
A custom date picker takes a week.
The framework gives us a lot for free: inputs, dropdowns, native pickers, and accessibility that already works. As soon as a component is custom, we own keyboard support, screen readers, mobile behaviour, and every browser bug. Sometimes that is worth it. It just needs to be a decision we made on purpose, not one we find out about halfway through.
Neither of us fixed this by writing better tickets. Three habits did most of the work, and they are now how design and engineering work at CAD.
Review together before the design is finished, not after. Fifteen minutes halfway through catches the expensive stuff, like a custom component or an animation that will not run well, while it is still cheap to change.
Build the ugly version first. Longest name, no image, empty list, failed request. If it holds up there, the rest is easy.
Ask instead of guessing, both ways. Almost every problem on both lists started as a two-minute question that neither of us asked.
Most handoff problems come from two people making sensible decisions with different information, and then meeting in QA to find out.
We still surprise each other, just less expensively.
Get your design and development teams aligned from the start. A smoother process from idea to launch starts here!
