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:
start feature together. Make planning meetings together with both white-frames design and architecture design. => both sides will knew what is intended and will be on the same boat.
make meeting notes. And review notes together at the end of meeting. The same meeting will different people remember differently.
make developers watch user testing. That is best eye-opener what is important for users.
respect technical/design limitations. Yeah, is nice to have idiot-proof design. BUT not on hight cost from developers. And vice versa, to have heavy feature no-one will understand. Compromise. Both sides.
go over the feature periodically. There will be changes. Plan and design is only until first line of code. Then there is many changes on both sides (error states, limited configuration, etc.)
As designer:
be mindful of different perspectives. As you know, users are different from you. So are developers, they are thinking more in DB schema than in result user interface.
don't bother developers with your decisions. Yea "radio buttons" or "select box" is for designer heavy decision, for developers not so much. It is your work (and your product manager).
Ad developer:
your computer usage isn't middle class usage.
you know about the features and the code behind. User doesn't. Nor does designer. It is your job to know that stuff.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!