The Usual
Designer asks for a "simple feature" that will take a month to build. Developer changes a thought-out UX flow because they think it would be better for users. We've all been there. And it doesn't look like these situations will go away any time soon.
I think we should not avoid those hurdles, but use them as an opportunity to learn new things and build a better relationship with the team and—most importantly—with yourself.
Designer's Pain
You've worked with another team. The developer there was very friendly. They quickly responded to your questions and pushed suggested quick fixes to production. Now come a new project and a new team. You ask your new teammate to change those ugly icons. "We have a prioritized backlog," they reply. "We've created a ticket for your request there."
You check the backlog. Turns out they have chosen a "minor" tag for your task. And there are a lot of "major" tickets in line, so it will take another month or so to roll out the new icon set. All major tasks have time estimates of over a week. On the other hand, they estimated that changing the icons will take just a few hours.
What the hell? Why don't they do it right away? This won't slow down any major tasks. And that's our brand! Don't they know we worked so hard on our brand? The other team would've done that the same day!
...
Obviously, you don't say these things out loud (or more realistically, you don't type them in your team's group chat). You know there is a process for developing a product. But you're still frustrated. Besides, the impostor syndrome kicks in. If your work is rated "minor", then maybe—just maybe—you're not doing something valuable.
Analysis
I've noticed that these thoughts come no matter how the team is organized. You may work remotely or on-site. You may use Scrum, Kanban, or Shape Up. You may work in a team of two or in a large department in a corporation.
Somehow, these destructive thoughts are linked to the core process of creation. Unless you're doing an A/B test to determine what caption to use on a sign-up button, your decisions are pretty much a representation of your way of thinking, your identity. A lot of people tend to be defensive of their identity.
What can we do about that? While becoming less defensive is generally good, it requires a lot of time (as any thought-changing practice would). But there is another way. That is to expand our identity we're trying to protect. Notice that it is not about changing what we are now, but about bringing new things to the table.
New Things
Designer asks for a "simple feature" that will take a month to build. Developer changes a thought-out UX flow because they think it would be better for users. We've all been there. And it doesn't look like these situations will go away any time soon.
I think we should not avoid those hurdles, but use them as an opportunity to learn new things and build a better relationship with the team and—most importantly—with yourself.
Designer's Pain
You've worked with another team. The developer there was very friendly. They quickly responded to your questions and pushed suggested quick fixes to production. Now come a new project and a new team. You ask your new teammate to change those ugly icons. "We have a prioritized backlog," they reply. "We've created a ticket for your request there."
You check the backlog. Turns out they have chosen a "minor" tag for your task. And there are a lot of "major" tickets in line, so it will take another month or so to roll out the new icon set. All major tasks have time estimates of over a week. On the other hand, they estimated that changing the icons will take just a few hours.
What the hell? Why don't they do it right away? This won't slow down any major tasks. And that's our brand! Don't they know we worked so hard on our brand? The other team would've done that the same day!
...
Obviously, you don't say these things out loud (or more realistically, you don't type them in your team's group chat). You know there is a process for developing a product. But you're still frustrated. Besides, the impostor syndrome kicks in. If your work is rated "minor", then maybe—just maybe—you're not doing something valuable.
Analysis
I've noticed that these thoughts come no matter how the team is organized. You may work remotely or on-site. You may use Scrum, Kanban, or Shape Up. You may work in a team of two or in a large department in a corporation.
Somehow, these destructive thoughts are linked to the core process of creation. Unless you're doing an A/B test to determine what caption to use on a sign-up button, your decisions are pretty much a representation of your way of thinking, your identity. A lot of people tend to be defensive of their identity.
What can we do about that? While becoming less defensive is generally good, it requires a lot of time (as any thought-changing practice would). But there is another way. That is to expand our identity we're trying to protect. Notice that it is not about changing what we are now, but about bringing new things to the table.
New Things
Training a part of your brain to be a junior software developer, amateur business analyst or a wannabe manager will lead to less stress at work. It will make you more passionate about the products you're creating and will make you an overall better designer.
Please note: I am not trying to convince designers to become generalists. While there's nothing wrong with generalists, that's not the focus of this article.
What are the first steps? If you design for the web, you can learn HTML/CSS. Build a non-interactive version of one of your designs. Try sending it out to your frontend developer instead of a Figma link. You'll be amazed at what sending an actual website instead of an image does to a designer-developer relationship.
If you're a mobile designer start by creating a simple app layout. Having problems with tools or programming language specifics? Developers from your team will be happy to share their knowledge. Use this opportunity to talk about both coding and design. This will lead to more engagement in design discussions in the future.
What about the business side of things? Hopefully, you have at least some information about how the business you're working at makes (or loses) money. Ask your sales or business managers how they estimate profits from different product features. If you happen to work at an organization with little to no information on finances, I can suggest learning from publications by other designers. When they share stories of user or sales growth, you can look for insider tips about how businesses work.
When it comes to management go to no other than your own pet projects or outside of work activities. How do you plan things? How do you organize an event for a lot of people? (sorry, 2020-2021 is not an ideal time to ask that) Do you have a preferred way of learning new things? Managers have to do that all the time.
New Thoughts
After spending even a little time doing things that other people on your team do for a living you'll start to notice a few things. Notice that you have more empathy towards your teammates. Notice that you are more interested in projects and activities that are not directly connected with design. Remember that icon problem from the start of this article? It is of course a made-up story (is it?). But if it happened, you would notice the importance of those major tickets faster. Or you would be able to argue that introducing new icons is in fact worth a lot of money, and the team should give this ticket a higher priority.
Either way, you'll be more informed, have less stress caused by miscommunication, and be more enthusiastic at work. Regular practice of thinking like a developer/business analyst/manager makes you a better designer.
My Journey
For the last couple of years, my primary activity has been web application design. Besides reading about frontend development, I came up with an idea that would eventually lead me to write this article.
At the time I was thinking about bridging the gap between design and development. Design systems are a common solution to this problem. I've built one with the help of other designers and developers. It has CSS/React/Angular libraries which are open-sourced on GitHub. The key was that I learned HTML and CSS and wrote most of the CSS library myself. As well as a few React components, and even one or two Angular components.
This allowed me to learn at least to some extent the tools our developers use daily. I was able to learn about some of their struggles, and what they're struggling with. It lead to a lot of interesting conversations, which converted brilliantly to better collaboration and empathy inside the team.
Managing a corporate design system is a great way to learn project and people management. If you have a chance to participate in such an activity, I would highly recommend doing so. It is a unique and effective way to meet a lot of people and learn new things.
Conclusion
This article could've been a single sentence: "Designers should learn to code." But I think that at least some of us need to understand why they need to learn that. This is my reasoning, and I think it might help some of you too. Learning how to code, manage a team or count profits doesn't get rid of all your problems. But in some weird way, it makes working as a designer more fun.