The infamous ‘Unicorn’ is rare and highly sought after these days. If you aren’t aware of what this is, it is commonly defined as a designer who also develops (or vice versa). This sounds wonderful and all, except in most cases, these unicorns either don’t exist, or have been taken as they are in such high demand.
If you can’t have every designer knowledgable about html/css, or train every developer to have a visual eye, the next best option is to have a very short gap between design and development. The quicker you are able to get feedback on designs in terms of what’s possible (technically), and what is feasible (time-permitting), is incredibly important in an agile workflow where iterations and designs must be spec’ed out in weeks.
I’ve worked on projects where development isn’t a part of the initial conversation. Designers often have a tendency to brainstorm in a vacuum. There are plenty of benefits to this. Mainly, in order to generate as many possible ideas as possible, technical constraints shouldn’t be considered (in the earliest stage). But once the idea has been formed, understanding the technical implications of implementing a specific design is crucial to pushing that idea down the design funnel and moving onto medium-fidelity mockups, prototypes, gathering feedback, etc..
Often that answer isn’t as clear we we’d like (yes this is possible, or no it isn’t). In these common scenarios where design is in flux and developmental costs need to be researched, ensuring that communication is open allows for as organic decisions as possible. Close proximity is paramount in the flow of this communication.
Ever since agile and the lean development workflows became widely adopted, design and development being done in parallel has become widely accepted. In some cases, startups and agencies will have a designer sit side by side with the developer walking them through how things should work (I’d like to call this ‘real-time unicorning’). This has been incredibly efficient at times as it allows designers to get immediate feedback from the device, and see in real-time how things will look for the shipped product.
One of the perks of being here at Ratio, is that I’m seated side by side with the developers. If I have a question regarding the feasibility of a feature, or I want to make slight adjustments to the animation of a button, I can quickly understand what that will entail. Communication is left open, and ideation can flourish.