I’m a designer, you’re a developer let’s make it work.

Inês Pais
REWRITE TECH by diconium

--

Designers are often moved to create not only a beautiful design, but also provide a great user experience. With that in mind, the work between designers and developers should be based on collaboration for the outcome to be the best possible.

However, often the communication is not that effective since the two areas are so different and both parties may not feel comfortable talking about something they don’t know that much.
Good communication will guarantee the success of a good product and a more efficient project from start to finish.

Let’s talk

Daily communication is key. Both designers and developers should meet early on the project and as regularly as needed.

Photo by Annie Spratt on Unsplash

Think of the project as an incremental process: design and development is being done all the time, every time, so the communication also has to happen all the time, every time!

We should try to avoid a handoff only communication, we will miss opportunities and questions about design that could lead to assumptions, resulting in unnecessary and time-consuming changes.

Let’s discuss

We may not always see eye to eye, and we often do not know the extent of your work. Having discussions is totally fine, we might not know what it takes to code a proposed design. Be curious — try to learn something about the other side.

Make it possible for designers to attend some more technical rounds and make room for questions, we do want to understand more and be more accurate when estimating development times, building designs that are doable and introducing new ideas.

Photo by Carl Heyerdahl on Unsplash

You also might not always know what we do, so we should take the time to present the context and reasoning of a certain design or a feature.

Talking about design is highly subjective and therefore can be challenging. Everyone’s input is welcome and valuable. We should take constructive feedback — based on data instead of personal preferences as part of the design process.

Let’s be mindful

Every project has time and budget constraints and even the more well-planned project can have a step back (it can be a good thing — time to reevaluate the progress).
A change in the requirements can also delay the project, if that occurs, check if this change brings value to the project.

A change that could seem minor to us as designers could mean a lot of work for a developer — remember that most of us don’t know how to code, so changes should be well thought out and analysed.
Check frequently about the feasibility of new requirements and changes and estimate as a team.

Let’s build

Photo by Marvin Meyer on Unsplash

Consistency and specs are like air, we need it as clear as possible.

We know you need them, and we are the ones to blame by not providing explicit specs or by assuming you’ll understand what we designed. But, when we do, just try your best to follow them so the reviews run smoothly. Also, everything should be up to date and ideally have a version control, so we’re all speaking the same language.

Let’s compromise

As every other person, working on a project you don’t like or understand can build tension and we might not get what we want, sometimes things just don’t have a place on the product, either on the design or on the code. Don’t take things the hard way and focus on the bigger picture.

Let’s do epic things!

So, the question is, how do we make it work?
We should all provide a collaborative, creative and non-judgmental place to work, so everyone feels entitled to raise doubts, questions and feels their opinion is valid and relevant.

We are all striving together to create the best product for our company, the stakeholders and ultimately — the user.

Photo by Ian Schneider on Unsplash

--

--