Designers & Developers

Designers & Developers,not Designers vs. Developers.

Designers and Developers, a tale as old as time in the IT world. Our brains are wired differently. I knew this beforehand, but working firsthand with developers made this very clear. Sometimes, just referring to one thing with a certain designation that the other half is not used to can make a 1-minute conversation go on a tangent that makes it last half an hour! For this reason (and some others), it’s important that developers and designers are at least on the same wavelength when working in the same team, and this – for me – just means that they should work in close proximity from the get-go.

When researching other people’s experiences with this, I came across a post from Kumar that compared the relationship between designers and developers to an arranged marriage. One of the points in his comparison was how people from very different backgrounds and lifestyles have to come together in both contexts, and I honestly think that having the opportunity to work with all of the different people that make up a team is what makes it all worth it! Understanding their limitations and how they get around those to get their work done will help you further grow in both your professional and personal life.

A lot of articles mentioned that you should have meetings before handing off the designs from the design team to the developer team, but one thing that is good about working in a small startup like Cloudoki is that there are other options, such as having both teams – or at least one person from each – working together. This way, it might take a little bit longer the first few times, but it allows both the designers and the developers to understand each other, get into one another’s thought process, and the workflow that others navigate through. This will make the long term process easier, designers will be more aware of what is possible and what isn’t , and discussions with the developers will provide information on what can be done now, later or never. All of this with the added bonus of getting to understand why or why not and keeping that in mind for future projects.

Back when I was studying to become a designer, I always had this burning desire to work in close proximity with a development team, and this was something that I’ve always felt to be lacking in some of the courses I took.

Fortunately, ever since I’ve started working at Cloudoki, I’ve had the chance to work closely with the development team, and this experience made me realise that there are certain things that I, as a designer, can take into account from the start to make my fellow developer colleagues’ work easier and more fluid. I believe that working together has had that impact both ways.

Communication is KeyEstablishing a healthy dialog from the get-go seems to be the most important thing. Don’t just hand-off the designs, especially without having a conversation with the developers. Create a bidirectional line of communication that can be used to ask questions and express concerns regarding features, their implementation, among other things. If this line of communication is always open, even before hand-offs, it’ll be easier for everyone to be comfortable asking questions, expressing concerns, making suggestions and discussing them.

Put your pride aside and keep an open mindWhen either side wants to make changes – either because it’s easier to code, or because it looks better some other way – don’t get defensive, and instead try to understand why developers think it might be easier to code, why they think it might look better in the suggested way, or ultimately, why they believe it might make more sense for users to look like that.

Take time to learn the basics from the other side (this goes both ways)Take some time to learn the technical jargon employed by the other half. Again, communication is key, and you can’t properly communicate with each other if both halves don’t know the basics behind each other’s work! So definitely do take the time to understand these basics I’m referring to by asking questions and making an effort to understand, as this alone will save you from useless arguments and frustrations that might come up.

Now, you’re probably wondering what “basics” might be all about – well, in the designer’s case, I mean that designers should know the basics about coding, and in the case of developers, I mean that they should learn the basics about interacting with whatever tool the designers come to use to do their work. Why? Because this will do wonders towards realising where the aforementioned technical jargon comes from! Again, we don’t want to be talking about oranges, and have someone understand those oranges as apples – get everyone on the same level, otherwise things will get lost in translation.

An argument towards the need for designersWhen writing this article, I decided to ask some of Cloudoki’s developers – ranging from front-end ones (who I get to work the most with) to testers – if it made sense for them to have designers in the team, and if it was a positive or a negative experience for them, and here’s some of the pointers they had to say:

“Designers have a lot more background in what comes to the usability of the product, and it’s important for us testers to understand that. It also helps to have designers onboard to answer the questions I have about the design.”

• Junior Tester

“The only negative side is the kickoff to a project being slower. The positive sides are that handoff is smoother, less time consuming, and less stressful for both sides. Also, having an internal design team means they’re more easily accessible to answer questions, which makes it easier to work.”

• Senior Full-Stack Developer

“It’s more fun to work on a good design than a simply functional one. Even just having a more consistent design throughout, makes me prouder of my work/code and more eager to share it. Having a more consistent design also allows for a better workflow when coding. Overall, designers make my work easier.”

• Front-End Developer

“As a developer working with a designer side by side can be great for your team and here are some points on that:- it allows us to mitigate issues sooner than later- it makes development faster as we know right away what the designer is thinking for said design- it improves the communication between devs and designers- it gives developers a better view on design work- the disadvantage will be the time spent going through things but it’s something that will be gained since there’s little back and forth trades.”

• Senior Full-Stack Developer

Finally, if there’s one thing I can say that I’ve learnt working with the developers, is that everything can be solved with a <box />.