On compromise between design and engineering
This is what I send (and talk through) with any new engineering teams I’m working with. My goal is to make it clear that designs are a living document and there’s space for compromise throughout the engineering process.
🤠 Executive summary/TLDR
Consistency and reusability are the goal! — There is usually a different design that will get to the same goal if something is ever a major pain to build
Make calls and use your design intuition, but also please ask me to double check 😺 a note on the story is best
I will try to always explain the why of any design calls in that context, so we all grow in design skills
Personally as a designer, I would consider screens in zeplin to be a good map to what we are aiming for, but definitely a living document with space for compromise and conversation.
And I know that in the process of building a design, engineers make a lot of design decisions, in one way or another.
eg:
How exactly is it responsive?
How and when is the data loaded?
How does this one thing stack at tablet-width which laid out in the designs?
etc
So when it comes to making design calls in the engineering process there are some principles to know:
The big goal is consistency and reusability of components.
Yay for any decisions that help us to maintain consistency / reuse existing components!
Overall, it’s good for the user experience if the product feels super consistent, and I am always open to any suggestions you have on how to do that regarding reusability of components.
Anything that feels like an inconsistency or missed detail
If you spot an inconsistency in the design which feels like a mistake or a missed detail — ie.
One thing looks visually like the same colour but is actually a slightly different colour
there is a difference in spacing than what we usually use
there’s one thing with slightly different data or info that seems like it’s not intentional,
then usually it is in fact a design mistake/missed detail and I will appreciate your help if you spot it :)
80/20 rule moments
In my experience at least, occasionally when building front end you hit the 80/20 rule, where you have a thing built to 80–90% pixel-perfect in 20% of the time, and then can spend the rest of the time f*cking around trying to get the final pieces to get in place to look pixel perfect….
I would suggest if you hit that point, reach out and have a conversation about it, as there’s a good potential there is some design compromise that can happen to hit the end goal of the user experience in some slightly different way that isn’t a major pain to build.
Generally immutable design philosophies: things to keep in mind when making design calls
Alignment (left, top, right) is SUPER IMPORTANT!!
If the left or top or right edges of things are aligned, they generally need to be. Bottom alignment is usually not as important, unless it’s something like a grid or a table.
Why?
A very core design principle is basically — if things are aligned to a grid they will just look better, which makes it look more professional, which makes the product look more trustworthy and feel more well-designed, which is good for a business. If the alignment is off the whole thing starts to look just… wonky and unprofessional
If in the build it looks different in a way that impacts the way the whole page or whole section looks.
ie. Changing the spacing within table rows from 4px to 8px would obviously change the feeling of the whole page as the whole table will be way taller.
vs. Changing the spacing between two unique elements from 9px to 12px = probably fine, but ask me to double check
Information hierarchy and visual rhythm
If changing something changes the information hierarchy or visual rhythm of the page. ie. If in the design, a heading is clearly “the first thing that catches your eye”, and in the built version it is no longer that, then it’s likely the core message of the design might have changed.
Ask: Does the visual element contain meaning?
ie. Sometimes a drop shadow can have no meaning and just look pretty. In other situations it can mean this element can be scrolled to the right or this is a modal on top of other stuff so you can close it. A keyline can have no meaning and just look nice, or it can mean this is a new section. If the design element contains meaning but is a PITA to build, then it’s probably still possible to find a compromise but will mean we have to find a compromise that could look different but communicate the same meaning.
Process: How to do design decisions in the eng process
I would appreciate a quick shortcut message + screenshots to double check — if you ever think it’s annoying, I promise it is not (this already happens and i love it)
question: if it would be picked up by QA, then does the design in zeplin need to be changed too? Or is recording the decision in shortcut enough?
Dev-design pairing about every 4 weeks?
