I recently witnessed an engineer vs designer --well-- fight, with the words, "It's a waste of our time!" heavily expressed by the engineer.
My questions to you are:
- How would you like your designer to approach a concern or problem?
- How can the communication between you and your designer improve?
- What is a good and/or bad experience/collaboration/conversation you had with a designer?
Please add any other insight or advice in the comments!
Top comments (11)
I'll give my perspective as a less-technical team member who frequently collaborates with the technical members of our team. I think it will be relevant to this specific Designer/Dev dispute.
I think that most disagreements are caused by a lack of empathy for the "other side." In this instance, I'll imagine that the designer happens to be non-technical.
The Designer probably thinks: I'm just trying to do my job, and I need the Dev's help to get this coded up.
The Dev probably thinks: I'm buried in work, the specs are constantly shifting, and this won't even matter ("it's a waste of our time.")
I think that having more empathy on both sides is important — and that starts with making a concerted effort to facilitate productive dialogues where both sides can stretch themselves to see the other person's point of view.
The designer has to recognize how frustrating it can be to have requirements change, and to receive time-consuming requests pitched as small adjustments. The dev has to realize that estimating as a non-technical participant can be difficult, and that this person is simply trying to do their job, and needs their help.
In terms of specific tactics, I think that this looks like:
That way, there can be more natural and healthy conversations like this —
Designer: "Hey Dev, I am thinking through some design changes, can I get your feedback on how it will be implemented?"
Dev: "Sure — I like this look, but you should understand that accomplishing this specific effect here will be really technically challenging because of the way the elements are laid out on the page. Is there a way we can capture the spirit of your design without introducing that complexity?"
Instead of:
Designer: "It needs to look like this."
Dev: "Well that's a huge waste of our time!"
Basically...
One of my first meetings at work made me realize the dev-designer dynamic, and it's a shock to me that there isn't as much coordination as I thought there would be.
Beginning the new project, I asked the designer, "How is the process getting your design to production?"
"Well, I just hand them the specs and that's it."
Then after the push the designer is pissed because the result looks nothing like the mock. There was no communication whatsoever between the handing off of the spec until push.
There was maybe one introductory component proposal meeting, but that's it.
Designers and devs live in such different worlds.
It seems like trying to change the current dynamic to a more cohesive and harmonious one poses an ultimately huge overhaul of the system.
Thank you for sharing your experience and insight!
I think having a dedicated project manager can really help in situations like these. Good project managers are really skilled at finding common ground between all participants by getting everyone on the same page with the project's motivations. And sometimes people hear things better from a person they perceive as a neutral party. In my experience many designers are really good at project management also, but since developers sometimes view designers as "the person making things pretty," they don't always feel trusting enough to let them take on the project management role when they feel like the lines of responsibility have changed under their feet.
Well, the designer I work with has a approach, which I think would lend itself better to to a waterfall process than to any iterative approach of software development. In one sentence: Throwing high-fidelity photoshop mocks over the fence to a code monkey.
Having a lot of good ideas, but lacking programming skills, realizing which details cost more than they are worth is hard, especially when one doesn't bother to consult somebody who knows.
I recently contemplated leaving my job, because I'm a bit pissed about the dysfunctional communication, in which I feel to be basically disenfranchised from most meaningful aspects of the project.
Oh my goodness I know what you mean!
I once worked with an incredibly talented designer who I could not communicate with to save my life. Makes me frustrated just thinking about it.
I am so sorry this happens. Why aren't "sit, strategize, and coordinate" sessions normalized? I don't get how apps are successful with all the communication chaos happening behind the veil??
I do design. And I know programming. One would assume, that my communication with developers would be easy.
BUT
The problem is sometimes in completely different perspective. Different priorities. In few examples:
"We are user oriented."
Designer: "User is the persona and we should design thing around them"
Developer: "User is our consumer and will use, what we will ship"
"User has to choose between being reader or writer"
Designer: "Fuuu. Such complex task. When there should be such decision? Will that limited usage? Shouldn't be reader as default with optional opt-in to writer role?..."
Developer: "Writer will have to have access to edit mode. The actions in API should be protected agains tempering from users with insufficient rights. ..."
"Items in the list will be editable."
Designer: "Editable? Inline, dialog or separate screen? Where will user edit it, on mobile or computer? How often? Will need info from the list during editation?"
Developer: "I will add the edit API. All items or only some? What items are enums?"
And with any super duper design process I wasn't able to eliminated all heated arguments. But some pointers for fewer of them from my experience:
As designer:
Ad developer:
I never put it in words (and english is my second language), so ... hopefully it is understandable...
I understand! Designers and developers live in two different worlds. There needs to be a balance of understanding how each other work. Coordination and empathy!
I feel like, sometimes, it's also the companies fault.
Designers can be overworked, especially in companies where there are many software projects and very few designers. Instead of having teams with their own resident designer you have one designer that is responsible for ALL the UX/mockups/wireframing of the web team, the mobile team, the this theam, the that team.
In addition to this you have PMs that sometimes propose features or changes to the development team without consulting with the designer at all.
Another thing is that it can be the management itself considering the work of the designers finished the moment they send the wireframe to the developer.
I'm sure there are bad designers out there and designers with lack of communication skills but my recent experience with designers is more of having empathy for them because they are insanely overworked.
I don't remember where I read this, but I'm pretty certain it was on dev.to... can't seem to remember the title though -- darn! -- maybe it was on Twitter?
Anyway, there was a scenario where a dev and a designer were discussing. The designer was discussing how they often felt disconnected with their engineers, mostly because there expectations were mismatched. And then either the designer had reached out or one of the engineers offered to teach some basics of programming -- the point of the lesson was to help the designer understand some technical requirements essentially.
I think it's important for both sides to understand where each other are coming from. Just like Peter said it's important to offer opportunities for devs to weigh in on creative decisions, I think it can also be useful for designers to see what sort of technical constraints (or possibilities) are in place.
This also reminds of one recent anecdote we had. We as a team had a group session where Ben was demo'ing the article sidebar, and we sat around as he asked for our input. It was a simple "oh I like this," "that looks good," "what if we do that?" back and forth conversation, and I think everyone came out of it feeling pretty solid about the feature and the design going forward. it was great to hear everyone's ideas, and it was an opportunity to include the whole team in the design + development process.
Is the designer embedded in the same team with the developer? If not, it is like someone from your neighborhood homeowner's association dropping by and informing you that you have to move your house away from the road 2 inches due to new HOA rules. It is better to have the other person understand the vision for what you are trying to accomplish. If they understand, but don't see a value in it, then both should cross-train in the other person's field so they understand what the other values. That will lessen the amount of asking for the impossible or not respecting the other's contribution.
When they are on the same team, generally it is understood that they are "in the trenches" together for the good of the user/customer. They see each other's struggles at stand up meetings, ad hoc conversations, etc. So one won't knowingly lobby for something that is obviously intractable for the other. Instead they will try to find a compromise that addresses both their concerns.
If there is still no empathy or working together, then it sounds like a team or employee issue (one or both). And at the end of things, you have to have two people who are both respecting that the other person has a job to do and thinking in terms of goals. Usually two goals ("it should have these effects") can be worked into a cohesive solution. But two specific implementations ("it has to work like this") may be intractable together.