Can Designers and Engineers Use a Single Source of Truth? Part 1.
The recurring nightmare for designers and engineers (Part 1 of 2)
You’re a designer.
Your last project, just like every project before it, ended up in a spiral of chaos.
It started with your neat vector file detailing main screens, but ended up as weeks of back and forth with engineers and stakeholders. Everyone wanted to have a say. Everyone found something missing. So many pieces of UI have plenty of states — no wonder you forgot to draw a whole artboard for every single one of them! Besides — the PM was threatening you with all the deadlines. Oh, and your vector tool started to lag with over 100 artboards detailing the states people have requested to see. Things quickly got hectic! Just when you thought you have some control over this mess, the developers finished the first set of features. You felt the blood rushing to your face — nothing looks the way it’s supposed to. The typography was all messed up. The colors are off.
You wondered, “Why can’t engineers just get things right?” After all, you sent them your vector project accompanied by a CSS spec generated by this trendy new tool. The engineers said they used the spec and that you should stop using vector illustration tools for UI design, but you disagree. Everyone in your design Slack community uses this tool.
You start to raise your voice upon noticing that your date picker looks completely different. They say that they already have a date picker and coding a new one would delay the project, likely lead to more bugs and probably be terrible for users too. You have no idea what they’re talking about. Your vector library of symbols doesn’t have this date picker they mentioned. And to add insult to injury, they didn’t even create this awesome animation that you sent them a GIF for. Apparently it’ll take at least two weeks to recreate.
You feel defeated. You use the tools that seem to be popular and yet you’re never able to deliver the experiences that you planned. The process seems broken.
You’re an engineer.
Your last project, just like every project before it, ended up in a spiral of chaos. Designers, once again, didn’t spec out all the states of components, but raised an alarm when you filled the blanks with hover and active states based on classes that you already had in your CSS files. Your impatience hit the ceiling in a 3-hour meeting all about inconsistencies between vector images and the actual code. You tried your best to explain that static illustrations created in those vector files cannot be accurately recreated in code. Browsers and vector tools live in completely different worlds and things are always going to look different. Designers didn’t want to listen and were constantly attacking your team with the concept of “pixel perfect design”. You wanted to say that it would be pixel perfect if they’d use tools that actually use CSS for styling. However, you stopped yourself. You’ve had this discussion (argument) before. You’re still hoping that designers one day will understand, that users don’t care about their perfect vector files, users only experience what was crafted in code. Unless designers start working closer to code, things are always going to be broken.
You rolled your eyes when they brought the issue of a date picker. Your team made the effort to create a modular library of components that are being reused all across the interfaces. It saves your entire team a lot of time, it definitely improved user experience (all the components are properly tested) and there’s less bugs in the system. It’s not your fault that designers have trouble syncing with this reality. If they’d ask you, you’d say that trying to manually draw all the components that already exist in code is a terrible idea and will always be a source of errors. They don’t listen.
And the final straw — once again they designed some animations in a tool that outputs a GIF. Do they really expect you to code something while looking at a 5-second long GIF? Not only is this a terrible process, but what about the project’s deadline? What about the performance of this fancy animation?
You feel defeated. You’re looking at yet another long night trying to catch up to all the changes to be made. You know the end result is going to be a disappointment and wish things were more unified. This process is completely broken.
Wrong Tools. Wrong Processes.
Sounds familiar? This is the state of digital product development in 2019.
Designers and engineers express their thoughts and ideas with tools lacking compatibility and synchronicity. Developers work with the final, platform-specific production technologies, designers often use vector illustration tools (Sketch, Figma, XD…) to design static representations of interfaces.
Those two could not be more different and less compatible:
- Different rendering engines used, for example, in a browser and a vector illustration tool, cause unresolvable differences in font rendering, colors and gradients.
- Animating static artboards with tools outputting GIFs (e.g. Principle) leads to an often painful and slow process of translating a GIF into performant and reliable code.
- Lack of connection between coded components and vector illustration tools halts adoption of design systems and leads to an inconsistent, buggy and expensive product experience.
The wrong output of a design tool leads to the wrong input provided to the development process. Those combined result in the wrong output experienced by the users. As long as the input remains incorrect, the end result will not be satisfactory.
Let me give you an analogy. Imagine you’re baking a cake. You’re looking at the picture of a great looking lemon cake in a recipe book. The first thing to do is to get a cup of flour. You’re feeling creative though, so instead, you tear out the recipe from the book and shred it to a fine grain. Hmm… Looks like flour and it’s made of the same stuff than the illustration in the book — it must lead to a delicious dessert, right? No. The input is completely incorrect and unless you replace it with the real stuff, that cake is going to make your dear family sick. Not to mention taste awful.
Designers must get back to reality and “bake the cake” with real ingredients, not pictures of ingredients. And design tools have to be able to output the real ingredients… not mere images.
Here’s an idea: Don’t blame designers. Don’t blame engineers. Blame design tools that are stuck in the wrong paradigm and prevent the industry from making progress towards a unified design — engineering process.
Check out part two of this article on how to solve this ongoing nightmare.
