Do the mechanisms of developers clash with the vision of designers?
Over the last few blog articles, many things were written about communication, knowledge sharing, and current trends. This time, we pretend to know how front-developers and designers are supposed to coexist. Do the mechanisms of developers clash with the vision of designers? It was what we discussed with Luis Mirandela, a front – end developer with more than 10 years of experience.
Q: Luis, you’ve been working in front-end development for more than 10 years, and many things have changed since that, including the way we moved from the archaic process of producing static designs in Photoshop to embracing a much more expansive toolset. Is it fair to say the modern Web design process requires intense collaboration between designers and front-end developers, or in your opinion, companies can succeed in having separate departments for web design and front-end development?
A: Nowadays having separate departments should not affect the end product. Obviously, communication is key on the course of all the projects but current technologies and methodologies make it possible to share designs and their interactions with the end-user in a way that it’s very clear what the result should be, examples of that are Adobe XD, Figma and Sketch. Also, one thing to notice is that now UX is being taken very seriously and that brings to the table very clear guidelines leaving front-end developers and web-designers be usually in sync.
Q: You’ve mentioned a broad array of tools, however, a question that emerges is how to choose those tools? Should a developer choose a technology that fits his taste or should he opt for a specific technology based on the project?
A: This question usually causes a lot of discussion. As a personal opinion, each framework has its own pros and cons, so I normally choose depending on project requirements, when I’m working on a small solo project or up to a team of 2 maximum, React is my way to go. The minimal amount of boilerplate needed and getting results from the get-go is a huge plus. If I’m rather working on a large-scale app with a bigger team, I’d normally (if the decision of the tech is on the dev team side) go with Angular, the opinionated design makes it that team changes would not affect productivity in a mid to long term and also makes it easier to clean, refactor and maintain the code which is a nice thing when you have a large project.
Q: Finally, there is another world we haven’t explored…the back-end. After all this composition of design and front-end, how does the articulation with back-end work? I mean, does a front-end developer usually work with what the back-end provides, or is there any kind of communication to reach a middle ground?
A: There is a lot of communication, obviously documentation helps mitigate this a bit, but there are always many other things to discuss. For example, the back-end provides an endpoint for a certain feature but the way the app was designed requires another type of request, getting this information in two steps, or another data structure as normally front-end should have the minimum amount of business logic as possible. Those two sides of the coin can also improve a lot of an app by profiling bottlenecks and find new ways to improve communication and data handling, making the app quicker and safer.
For more content on technology, programming, and business development follow our YouTube Channel where we provide Talks and Podcasts on these topics.