Designers, take responsibility for bad implementation
Having shipped products at startups, big companies and design agencies (by nature the most difficult) I realized a huge difference in product quality which depends on the designers mindset (not only developer skills).
Bad implementation is mostly the result of weak communication/collaboration.
Meaning when we (designers) see bad implementation — instead of blaming the developers, we should take/share responsibility! Why? Because bad implementation is mostly the result of weak communication/collaboration. Communication apparently involves more than one party.
While design agencies are superb in creating visions and concepts they very often lack in bringing these concepts to market. Ideas that seemed outstanding become average or even below, once launched.
The main reasons for this are lack of agility (mostly due to clients), long time to market and bad designer — developer collaboration.
I’d like to elucidate the last point, since that’s what we designers have the biggest influence on.
What mindset and skills are needed for designers to effectively collaborate with developers?
Understand code logic
As a designer you don’t have to be good in programming. The bare minimum code knowledge, however, should be a basic understanding of how things are build. Without this understanding, you won’t be able to understand the feasibility of your ideas and the implications of all decisions you make on development time. Furthermore, communicating detail flows and transition will be difficult if you’re not able to describe details in the language of a developer — which brings us to the next point…
Prototype to communicate
The quality of a product is – among other things – defined by the sum of experiences with all detail interactions. Good designers get uncompromising obsessive with details. As a designer, it’s fundamentally your responsibility to make sure that the detail experiences you’re designing for will be implemented in the right way. In software, many of these sometimes unobtrusive experiences are transitions which provide comprehensibility and pleasure while using.
To design transitions, you need to think in motion. Only by trying different variations, you’ll be able to figure out a transition which feels right and makes most sense. Once it comes to describing transitions to developers, it is extremely useful to communicate your specifications with values that can be used in code. If an animation involves easing or even physic behavior — your developers would welcome exact specifications to implement your designs.
There are several tools which can be used to prototype and communicate transitions. For mobile apps, FramerJs and pixate are highly recommendable. If you’re designing for the web, you should get familiar with CSS and JavaScript animation libraries like Animate.css or GreenSock. There are dozens of other libraries which can be used for both design and implementation.
Work as close to your developers as possible
After you have completed your designs — you’re job is not done. In most cases, you’ll need to clarify little details for your developers, make little design changes due to feasibility reasons and give feedback for the newest implementations (quality assurance). You’ll achieve good product quality if you’re working closely to your developers. It might feel uncomfortable to be in a highly flexible and agile team, but the outcome will most likely be better. Don’t get too formal with meetings and structures. The more autonomy and agility — the better. Be flexible, sit side-by-side with your developers and chat whenever needed.
To collaborate effectively, it requires the whole team to have the right mindset. The success of the product comes before the success of the individual. Success only happens in a healthy team environment where everyone is happy to support each other. Your end goal is not to have a good looking concept or to make your client happy — but rather to have a meaningful product which engages users with well designed details.
