How working with a designer helps you grow as a front-end developer
If you’re a developer and wonder whether you should go full-stack or focus on front-end, this article will give you some hints from my personal experience.
How it all began
I’ve been a frontend engineer for the last 5 years, but in order to understand what I do now, you need to know about my journey.
I have a technical background. I went to an engineering school and fell in love with algorithms there. I liked the fact that by only writing logical instructions, you would always have a predictable result. In code, there’s no place for emotions or interpretation - just cold, implacable logic.
It’s funny to think that during my studies, I learned design patterns when it comes to code. but I never learned design tricks on how to make sure that someone would actually use what we were coding.
All these years of studies were theoretical, and I quickly realized that I had no clue how to apply them to real-life examples. How to make sure your users will get the most from your app is something that you learn through practice (and sometimes, mistakes!).
Then, I came to front end a little by accident: I was onboarded at my first job on a front-end task, and I loved it so much that I quickly decided I was a front-end engineer and no longer full-stack.
My first task was to implement an autocomplete displaying a list of users into their components’ library. It had to be easy for the devs to use it in the products, easy for the users to understand, and still have those magic moments that make the experience more memorable.
A specific trick was to add an option to display the logged-in user first. For example, if you’re a manager and you’re part of a large team, you may have to scroll through the list to find your name. But in a Calendar app, most of the time you’ll want to see your own schedule first, rather than your team’s. By adding this shortcut, we made sure that the most useful action was easily accessible and always visible.
Focusing on these details is what makes your product stand out. But more on that later!
Of course, I liked front end because of the code: it’s an ever-evolving ecosystem.There are so many JS frameworks to play with, and there hasn’t been a week in 5 years where I didn’t learn something.
But this story is more than just about code: you become a front-end developer because you want to delight customers through your product.
Why design matters
All of my work experiences shared one aspect: the products were designed for a large range of diverse users with different backgrounds.
They need to work for Kevin - born and raised with fast Internet, checking Snapchat far more often than he’s checking his mailbox. But also for Susan, who writes on a keyboard with only two fingers and who has no clue when asked ‘what’s your browser?’
When you’re facing these challenges, you can have the fastest engineer, the most organized product manager, but your team also needs a creative designer.
I’ve always been interested in design but never took any courses. This is why I design the same way I cook: I follow recipes that are proven to work. I’m not good enough to improvise, so if I have to create an interface, I’ll find inspiration by looking at industry standards.
How I realized design was part of my equation
The first company I worked for sold different products, each with a dedicated team of developers and at least one product owner. The design team was on their own, and designers were not directly part of product teams.
The design team was composed of UX and UI designers and integrators. Designers only got involved at the beginning of a project to provide high-fidelity prototypes, whereas CSS integrators joined to give the interfaces their final glow. As front-end engineers, we had to keep our hands off CSS, and I had little interactions with the design team.
But I soon realized that design was kind of a black box to me. How can the choice between two shades of green for a success button matter that much? How can interfaces anticipate solutions when the users themselves have trouble evaluating their needs? And how can we bring joy and excitement with only grids and shadows?
I’m a curious person and every time there’s something I don’t understand, I’m intrigued and want to solve the puzzle. It was the exact same thing with design: I wanted to sit down with designers, look how they worked and ask questions until I could figure out their secrets.
This had me frustrated because since we worked in separate teams, I found it difficult to interact.
I also realized that as a down-to-earth person, I needed to be around creative people because they provide me with the right balance: they bring me outside my comfort zone and reassess what I was taking for granted. I was missing this synergy between logic and emotion; between data and intuition.
I knew that I still had so much to learn, but one piece of the puzzle was missing.
How I found my balance
When I was looking for my next professional adventure, I sat down and thought about what was important for me. I realized that design was one of these things, and that I wanted to be inspired by designers.
I looked for companies where designers would inherently be part of my future team; companies with a strong culture of design.
Since I joined Spendesk a year and a half ago, I’ve worked with four different designers and I’ve started the implementation of a design system with one of them. (If you want to know more about design systems and why they are important for your product, I recommend this article).
By working more closely with a design team, I realized that it was easy to create an interface that doesn’t look bad, but it takes expertise to do an outstanding design.
Designers are able to take the hardest issues customers might face and make the solution look easy and intuitive. Every time I think I’m about to break their code, they surpass themselves even more and never cease to amaze me.
A year ago, we refactored our export interface. We used to have an over-crowded interface, with a lot of information that had already been reviewed by users.
The most visible action (the purple button) was to cancel the latest action (it wasn’t the most used). While the main action of the interface (to export expenses) was accessible through a small button at the top right side of the interface.
That’s not intuitive. We replaced it with a lighter interface with a summary of what the export will include. (They can still access the details of the export via a dedicated button).
The main action is now easily identifiable and unambiguous:
Dev and design have some common principles. One of them: don’t repeat yourself. When I joined Spendesk, we had duplicate components, unclear design rules, and mismatched interfaces. This wasn’t scalable from a tech point of view, but it also impacted our customers’ experience.
Providing consistent interfaces and experiences has been one of our priorities since then.
Consistency comes with clear naming and conventions. And since these are tasks developers are used to do in their jobs, creating a dev-design squad can be a good solution.
But the design challenges the dev the same way the dev challenges the design. I‘ve lost track of the number of times where I looked at a design and said “that’s really beautiful, but it’s three days’ work.”
But we always find trade-offs. And by pushing the limits of my CSS knowledge, I ended up mastering flexbox, animations and Sass mixins.
Always aim for simplicity
My main takeaway would be to always aim to answer a complicated need in the simplest possible way. When a user doesn’t have to ask how to use a feature, that’s the most rewarding part of my job.
That’s the proof that the work of the whole team has been done successfully. From the problem discovery to the launch, without excluding solution definition, implementation and testing: everything has been smoothly orchestrated.
Now that I’ve done my part, it’s your turn to share your front-end tips and experiences! I’m curious to learn how your team is organized and what you like the most about being a front-end engineer. Please, feel free to reach out!
