As designers, we need to trace how our design will be implemented. We need to collaborate with many teams and especially the team of developers. All these people have their own areas of responsibilities, and we must strive to not get in the way of them. But we need to prepare the ground, so they would not do something unpredictable and wrong with the results of our work. And I don’t speak in terms of arrogance now. No. I just want to say all things (bad or good) which can happen with our design when we have passed it, for instance, to developers depends only on ourselves.
And yes, I want to talk more about the relationships between Designers and Developers. And no, it is not about «designers need to know how to code».
The next list is a few dos and don'ts, so developers can understand us clearly and only in a certain way that we implied.
Speak in details
If we don’t want our implementations would be understood wrong, we need to explain as much as we can about every element of our design. More explanation we give — less money and time we spend. Describe all typical and non-typical behaviors, changes, states. We can do it in many ways: mockups, prototypes, or simply words (why not?). Of course, we can just have a conversation with developers, but make sure that all needed things will be documented somewhere after that.
A small tip is thinking about all with questions: Why?, How? and What If? Why could this button be disabled? How can we reduce the feel of latency before a user see items on the screen? What if an email address will have not been verified by a user? All these questions developers can ask you but better if you think about it in advance.
The problem is that we may create so much design artifacts in this process, so they will mess up our good intentions. In the end, we and developers may have the final design, the prototype, animations, sets of assets, some specifications, user stories, and so on and so forth. We need to be careful with all of this stuff, so it will not expand with changes and corrections.
And always remember that brevity is the soul of wit.
Allows developers to be a part of the product team
It is really important that developers don’t feel like an agency that just get designs from us and give back a code. No. Allow developers to affect products by giving them a voice. Developers are the fundamental part of every team and only they know how to implement things designed by us. That is the reason to go out of the box of our design stuff and listen to other people, who really can know much more than we.
Stop thinking arrogantly and become more open to ideas that other people across the company have.
Understand what the tech stack developers use
We don’t need to understand deeply and how exactly technologies work, but we must think in terms of constraints and possibilities of the tech stack that our company uses. For example, if developers use React Native we can’t easily simplify the design and reduce time on development only by using native elements, just because RN is not really native and has no every component from used OS (even in third-party open-source libraries). If it happens, developers need to elaborate on these native elements from scratch. It takes some time and money.
And it’s the only simple example.
These points here are simple steps which are intended to help us to deliver a design to users with the best implementation.