How Codelitt Teaches Me to Be a Better Designer - Part 1
This is the first part of a two-part article dedicated to the design work principles I found to improve my work and ease collaboration with developer teams. I am by no means someone to preach and spread wisdom, I am still reading and informing myself, trying to find what works best, and make decisions to form better habits. Most of the ideas written here are on my to-do list. They are ideas to incorporate in future designs to make them better: easier to understand and to implement.
Good Cop, Bad Cop
One of the saddest misconceptions in the digital creation world is that it can be divided into good guys and bad guys. “Designers are the bad guys, developers are the good guys” - or vice-versa depending on who you ask.
We designers are often called out not being thorough. We hear that the behavior of our designs is unclear, that we do not look at problems from all angles, even that we’re lazy. And we, designers, are often annoyed with developers and their carelessness, the so obvious misalignment of elements, the shocking "shortcuts" they take. They turn our designs into Frankensteins while claiming it looks exactly the same, or even worse - that it doesn’t matter.
But calling names and throwing guilt is not the way we do things at Codelitt. We give each other constructive critique. We’re constantly looking for ways to improve and facilitate collaboration between teams. We know that it is on us to change and improve ourselves and not just preach to others.
With that in mind, I wrote myself a list of principles and best practices to follow and implement in my work to make my designs better and easier for developers to work with.
THE BASICS: MAKE PEACE
We’re lucky here at Codelitt, because we all try to play nice together. Also there are a ton of tools that make getting our jobs done and understanding of each other easier (big shout out to Figma)! But still, I think it’s sad how the industry tends to put designers and devs at two sides of the battle ring instead of preparing us to help each other.
At the end of the day, we are all digital creators! We just use different tools and approach a problem from different angles. I shouldn’t call out the dev team for not thinking the way my team does! Instead, I should be grateful that there is another valuable group in my corner that holds a different perspective and also cares greatly about the final product. We should be friends, not enemies. We should channel our energy into making our work easier and smoother instead of trying to battle over who does a better job.
PRINCIPLE 1: NAMING CONVENTIONS
Yes, it’s true: to designers, most of the time it really doesn’t matter if what we see on screen has a name. But in software world names are everywhere. Hey, we’re not designing flyers in Photoshop over here, we’re making digital products. We must have a naming system and stick by it.
I read somewhere that in the programming world a name should answer 3 questions:
- Why it exists
- What it does
- How it is used
In essence this name is a full, complete piece of information that transcends cultural backgrounds and possible misconceptions. I believe that answering all three of those questions while designing will help me think of ways a certain component will be used, define its default value or current state, and determine what other possible states and variations should be included in the design.
By following this principle, I force myself to think of multiple possibilities and ensure my designs are more robust and thorough, making it possible to answer questions a programmer might have upfront. This thought process also makes the design more usable, and of course, more organized.
PRINCIPLE 2: FOLLOW A METHOD
Having a grid, a system, or any logical, structured approach that I follow in my work is key. For my developer friends, having a method and explaining it upfront not only makes both of our lives easier, but also significantly reduces the margin of error. Because let’s face it - unless we are doing some crazy artsy-designer-breakthrough website, we need a system. Having a system for sizing, placing, and arranging the elements makes our work consistent, systematic, and easier to implement.
Codelitt’s Design Team uses an 8 pt grid with a soft approach and since introducing it, it made collaboration between designers and developers noticeably easier. However, I am aware that dev teams would appreciate it more if I followed this principle better so there would be fewer question marks. Which brings me to my next point:
PRINCIPLE 3: WRITE DOCUMENTATION
Yup, we all hate it. Well, at least I do. It’s that thing that feels like it’s always standing in the way of work (or is the reason you have to do more work once you’re done with the main job, designing). Well, we need to shift the paradigm. We need to teach ourselves that documentation is a part of our job like everything else.
Good documentation is like having access to our thought process anytime. But it’s even better than that because it’s not exclusively my thoughts alone. We all know what it’s like to come back to a design we created a couple of months ago and try to answer a question a dev has today. If we, the ones who designed the darn thing have no idea, how can we expect that someone else does?
Documenting our designs helps developers find answers and understand designs without needing us. This principle also helps us go back to a project (or pass it off to another designer) without having to question the intentions of why we chose to do it the way we did.
PRINCIPLE 4: BUILD A SYSTEM
This principle is the one we are all always working on. No matter how much work we put in, there is always room for improvement. Like cleaning your bathroom, no matter how much you do it there are always some spots that need attention or can be improved.
We should constantly be improving our design system skills and working on finding better solutions and ways to group and organize elements. We should approach designing those elements so they are as versatile as possible during the actual design process.
We should never be lazy and skip adding that one icon to the design system before using it in the designs…
All of that counts. Having a system that is usable, scalable, and easily maintained is the Holy Grail for every designer. I believe none of us has achieved it yet - but not for lack of trying.
Codelitt’s Design Team is currently working on creating such design systems for Desktop and Mobile platforms. We aim to improve and speed up our workflow, improve consistency throughout the company, and create design tokens that developers can easily change when implementing our work to various platforms.
It is a constant work in progress, but one well worth doing.
If you liked the first part of this blog post, stay tuned for part 2 that will cover pacing design work, being accountable for implementation results, and managing user feedback.
If you liked this article, check out: