At Audry, we are lucky that our engineer Anastasiia is not only incredibly good at coding, she also really enjoys writing. Why would we waste this talent? That’s why from now on, you can read her views on her work now and then on our blog.
She takes us into her world as an engineer. The problems, the happy moments, and her way of working. Or as she likes to say it: I’m Keeping It Simple, Stupid.
It so happened at the beginning of my career that I used to be my own designer. I learned the basics of UX/UI; I used to export assets and implement the design right away. (I believe a lot of Frontend Developers were like this). And I made a bunch of mistakes — wrong dimensions, quality not good, quality too good, wrong fonts, usability level is 10 Donalds Normanses of 10, etc. But somehow, I learned how to manage it quickly, so until I work alone, it is okay.
But when I moved to a different position, I wasn’t my own designer anymore. I used to be a boring developer who opened sketch or photoshop(Figma nowadays) 2 times a season, periodically asking to prolong or borrow the license from the Head of Design to open and edit something.
And this is where the issues start. The first time, you probably don’t realize yet that the designer cannot read your thoughts, so you pretty much think that all should work, and you wait for the mockup. But when it’s time to implement it, you find out that nothing works properly, and you cry.
This article is not to point out any issues, not blame developers or designers; the article is about keeping such different worlds aligned, so everyone is happy, calm, and healthy. And productive.
Throughout my career in development, I only once wanted to show off. It was at the start. But then, working in the rapidly extending industry, if you desire to produce a helpful product, there is no longer time to feed up your egocentrism. We have to invest time and power into adding and improving efficiency.
There is no good or evil side; there are possibly different ways of thinking and doing. And it doesn’t make sense to accuse parties when in the end, you have a lousy product or overwhelmed colleagues. There is always a problem of both — the designer didn’t tell, the developer didn’t ask, or vice versa:
- Wrong estimations of the implementation.
- Working overtime on tricky design solutions.
- Reworking some parts off app due to performance.
- Inconsistent UX and UI across the app
- Losing simplicity of the code.
- Lowering the productivity.
But what to ask, what to say?
We will consider 3 crucial components of a healthy and efficient working process:
- Working together on the design from the beginning (from the creation of the idea).
- Focus on valuable points for a particular project.
- Keep the dialogue with the designer going through the mockup creation.
1. Working together on the design from the beginning
But what do I mean by “from the beginning”? The new feature of the existing app or the beginning of the app?
Ideally — first, but sometimes people replace each other, and sometimes you need to start working on the halfway ready product. More often nowadays, developers come to the project which is already producing value, and your goal is to make the process better. The second case requires more time and patience, but I can say that it’s possible.
No, it doesn’t mean that you, a developer, have to invent the visual design. Your role in this game lets the designer know which restrictions are due to the implementation tools. If some features are essential from a usability perspective, maybe you have to consider another tool?
2. Focus on valuable points for a particular project
Your target is always customer value.
If, for some reason, you don’t feel like the customer value plays a significant role for you at this job, you have to reconsider the field to work in. Of course, life is not that simple; there are always complexities and reasons we took the A or B decision.
If that is so for you and you have some obstacles, it probably doesn’t make sense to read this article.
You have to participate in the brainstorming stage — your role there is listening to the ideas coming from your team and evaluating what can be challenging to achieve. It could be different cases — e.g., because of compliance, security, or not enough resources, etc.
You don’t cross their ideas out — you help people realize what pitfalls could be and save your engineering team time and energy.
This is where your soft skills are essential.
You have to be: clear, coherent, considerate, transparent, friendly, encouraging.
If you have already adopted design brainstorming together with the team, but it fails anyway, you need to think if you understand your field? Do you communicate effectively?
Now, when the discussion is done — you already know what you can wait for from the designer and prepare the tools to implement it.
3. Keep the dialogue with the designer going through the mockup creation
You, the developer, probably know that layers on mockup never work the same as in HTML. And the exported CSS from the visual design tools is not precise, especially from the perspective of readability, layout structure clarity, and performance.
And this is fine. However, there’s a lot of sadness when you cannot fit something in the layout cause it’s not followed the previously made one.
In the worst case, a developer stays quiet and builds a fort on top, which causes UX inconsistency, losing simplicity and code clarity.
Dear developer, the designer probably doesn’t know perfectly how the CSS and HTML work, even if they say they completed the course, even 3 courses, even if they developed a website.
The developer probably doesn’t know how to build smooth and juicy visual design mockups as well.
An average person probably has to spend years just doing the same thing to master it(which, let’s be honest, never accurate) and understand all of the tricky parts no matter how good the courses were.
Will you trust a dentist who did 3 video courses on teeth surgery?
So unless the designer has years of experience in frontend coding, you have to support them.
It is never an extra step to talk to a designer about how your specific code works and the restrictions. It’s nearly impossible to have a conversation only once and forget about it. There will always be points to discuss, and the initiator of the talks should be you, the developer, because you and your team will implement the given design. And telling just a framework and libraries names is not enough.
Some things you can potentially discuss with your designer:
- How do you want to handle images? If it’s a blog, it could be one way to handle them if it’s business data — another.
- Do you foresee significant visual changes in the resizing? Apart from those done with CSS (and ideally explain why here could be a problem).
- If this is a catalog, how exactly do you imagine UX is done? Should we lazy load, or is there a paginator? How could it be done on mobile sizes? Pick the one who plays good cards for both sides.
- What is colors schema? How are we going to extend it?
- Whats are the breakpoints, and how the UI elements should look in the most used ones.
- What’s the key UI elements look like — buttons, inputs, loaders, tooltips, popups. Let’s build a library and plan the possible scalability.
- What are the gaps? Pick the system you would like to work with and use only those gaps across the entire app (exceptions a small details in the particular child components)
- Should we define the ubiquitous language and its scalability?
- What pattern do we want for layer names and exported assets?
- Should we keep components naming the same in code and a design?
But if you already adopted the discussion with the designer but it fails anyway — you probably have to ask yourself if you understand the problem you are trying to solve.
You can say that the point about a component library is clear as a summer sky, which could be skipped for sure. Obviously, the designer will create a set of components and going to reuse them.
I will reply — you should discuss it, because:
- You will reach a point when the component should be extended, and the way of its realization should be discussed.
- You don’t yet know if the designer has a habit of creating a library or just repeating the shapes and colors that create different views of the application. This point is important as sometimes, an extra 2px on the button could significantly change the UI consistency. What are you going to do if you have dozens of mockups with the approximately same-sized same-sized buttons?
- I bet developers can find more reasons.
We need to keep the dialogue with the designer throughout the creation of visual design — but never think that you know better how to do it. You know how to speed up the implementation and keep the app’s performance, but don’t tell the designer how to do their job.
Your target is customer value.
Be always friendly and encouraging because this is the only way to keep healthy relationships.
I know that this article is not enough for such a broad topic, and there is much room for exploration. However, I won’t make it any longer 🙂
Oh yes, I nearly forgot. I was supposed to put an image to make it more interesting.
Here you go. Sarra, the designer, and I —haven’t killed each other, stayed productive.
Subscribe to Anastasiia’s Medium to read more about engineering practices.