Front End Development Cannot Be Separated from the Creative Process
Back around 2000, I was working on a system for logistics. My task was to rewrite the user interface into something compatible with all browsers of that time. I received a Photoshop file with the layout from the design team. A team located elsewhere and with whom I had never communicated previously. The client was obviously of the opinion that such material would be enough for me to understand the intentions behind the creative decisions and the desired outcome.
As one would expect the project went over time and over budget. Because what the client was sold, did not match my implementation. The presentation used at the sales meeting displayed a pristine picture. Using static design and static data, everything looked beautiful and perfectly fitted the example device used for the demonstration.
Alas, a website/webapp is not a static entity. It lives in a filthy world of endless permutations. Thus began the insufferable pain of retroactively refitting the design, to what was technical possible and/or feasible. You have been there yourself — no need for the gory details.
This was in the days where frontend development was ridiculed, before the concept of UX was popularized and IE had a version number of 5. Everything was a hack and all designers came from a background in print.
Some 15 years later, Chrome is driving advancement in web development, Safari is the new IE6 and web production is a smooth ride on a rainbow of well-integrated teams and technology. Well not really.
Frontend has been promoted to a first class citizen but the same problems persist. Collaboration between design and frontend is, more often than not, a discreet operation of handing over visual documentation. With any discreet step comes loss of contextual information, which in turn leads to a separate understanding between the two teams responsible for realizing the visual components of a software project.
The first step, in solving this collaboration problem, is to include the frontend team in the creative process. There are several major benefits to this and no drawbacks.
- Early feasibility checks. With a developer involved, you can have early feedback on whether features are possible and/or feasible. A certain design feature may just need a minor tweak to become easier to implement.
- Those features, which are outright impossible, are caught early and changed or eliminated. Such issues are usually not discovered until well into the development phase. The earlier an issue is known the less costly it will be to correct.
- A common understanding, of the intentions and ideas behind the design, including the business case, is developed. A common understanding leads to fewer misunderstandings. Fewer misunderstandings means fewer issues to correct later.
- Developers are creative people. They have ideas and suggestions. They know what technical features are available. Their input is invaluable to push the boundaries of what can be achieved.
- It is more fun. A point, which should not be underestimated. More fun equals better productivity.
- Last but certainly not least: it is cheaper and faster. The client will save money and get the product faster.
The frontend developer should be part of the creative process from the very ideation phase. It does not make sense to separate these two inter dependent disciplines. Note that you do not have to allocate a developer 100% from the beginning. Your resources are likely better spent increasing the allocation slowly as you approach more final implementation.
The notion of silos in development teams is an antiquated idea that have proven to be a failure time and time again. I realize it may not be realistic to co-locate everyone but if you have to split your team do not split between design and frontend.
The imagination of designers is a wonderful thing and a challenge is always more fun that repetition. However, realism and pragmatism is part of a successful project and developers are rather good at both. Let both parties be inspired by working together and at the same time ensure that the project does not side track from infeasible features.
Start your next project with including the people, who are responsible for implementing your vision, as early as possible.