Collaboration between a front-end developer and a designer is key to a successful project and will probably DEFINITELY save time and money.
As a front-end developer, one of the major pain points I encounter is being handed a set of web designs that has been signed off on and finalized before I even roll onto a project. The designer delivered the mockups and has moved on to the next project. It is a common assumption that the designer is no longer needed.
However, as I’ve seen in over 15 years of working on web development projects, the role of a designer is one that should be included throughout the entire project lifecycle. By retaining the designer, it allows for collaboration among the team to find the right solution vs. having the design mock-up be an inflexible blueprint. That collaboration can influence how development hours are spent and budgets are managed.
Opportunities crop up all the time to save development time with design adjustments, such as “Hey, I noticed in the mockup that this element should look like this but it’s already inheriting these styles. Does this meet branding guidelines and the intended functionality so we don’t have to write additional one-off styles?” And it adds up.
But if the designer has rolled off, or there are no more design hours left in the budget, this conversation does not happen and the result is more development time spent on a custom feature.
Let’s take a look at the process from a front-end standpoint:
The first thing I do when I begin working on a complex feature is to look at native behaviors in whatever framework I’m working in or researching well-adopted and -maintained third-party libraries to get from point A to point B as quickly as possible. Less development time means less cost passed on to the client or more development time for additional features.
The beauty of working in the open-source space is that often someone else has needed to solve the same problem you are trying to solve, and has contributed their work back to the community. I won’t opine about the benefits of open source, there are plenty of posts out in the ether of the internet about it, suffice to say it saves time or money or both.
So, now, picture this scenario, the native functionality or a module or library I’ve found, solves the problem the designer is trying to solve in a similar but different way. Now I get to pick my own adventure. This functionality doesn’t exactly fit the functionality the designer created so:
- I will custom build it from scratch, taking more development time.
- I will propose working with the designer to adapt the existing functionality.
Option A is always going to take longer.
Option B may delay starting work on a feature but probably won’t delay overall progress in an agile process. From my experience, this option provides a better overall solution and often a more familiar interface for users if your site is using a native feature or a common third-party library.
There’s the long-held stereotype that designers and front-end developers don’t get along and I have to pause to chuckle. Half of the front-end developers I know come from a design background and every designer I’ve worked with has been constructive and helpful trying to streamline development efforts.
Maybe I’ve just been lucky, but I really and truly think the perceived animosity stems from that finalized design hand-off, where front-end developers can’t go back to the designer, explain the challenges and collaborate to build something better together.
Design is a critical aspect of a healthy DevOps cycle, and front end developers need ongoing access to designers to deliver the best solution at the lowest cost.
