CWDN series: DevEx – Penpot: For good front-ends, build bridges with design
This is a guest post for the Computer Weekly Developer Network written by Alonso Torres in his role as a software engineer at Kaleidos working on Penpot.
Penpot is an open source design-to-code platform helping developers and designers work better together.
A self-confessed geek, black-belt debugger and also a father, Torres says what he loves most about programming is being able to always have a new challenge that needs to be solved and look for the best possible solution, which insists is always a fun process.
Torres writes in full as follows…
Front-end UI and UX – and the design elements that support them – are a critical part of creating good software. But cross-functional collaboration between developers and designers is one of the most fraught relationships in software development.
The best simile is designers and developers working separately on either side of a wall.
When the designer finishes, he or she “throws” the design to the other side of the wall. The developer on their side will try to code the design but usually it’s a process frustrating for both parties: on the design side the code usually won’t reflect the design exactly; on the developer side the design won’t respect standards and good practices (for example: using standardised spacing or coherent colors).
There is a better way and to get there we need to stop thinking of design and code as separate entities and instead as part of the same workflow.
Different worlds
Developers don’t want design-centered tools with developers as an after-thought, yet that is the environment where they are most often forced to operate. Static designs usually won’t reflect the behaviours the code needs or are open to interpretation by the developer, forcing them to make choices that aren’t that important to them, but are extremely important to the designer. For example, even if the designer creates the desktop and mobile layouts, it’s the developer who has to decide the intermediate states (and if there will even be intermediate states!).
It’s a frustrating experience where the designers and developers are consistently at each other’s throats. They start thinking not of the product as a whole or the best experience for the users but on “defending” their side.
Developers will fight for the code to be the source of truth and – logically, crucially – the designers will do the same.
Also, the product quality could be diminished on both the design side and the code side. The screen could either have differences with the design or not use good practices or temporary “hacks” to adapt to the designer’s vision.
Torres: Hey, don’t throw it over the wall – designers & developers have to speak the same language, let’s work together better.
Furthermore, it’s harder to maintain and expand. If a future feature request requires a big change in the designs, it can have dramatic consequences on the code and in the worst case scenario developers might need to rewrite the whole front-end to incorporate the new functionality.
Building unity
Designers and developers have one thing in common: everyone has their own workflow so it’s really important that the tools can adapt to these workflows while maintaining their productivity.
Also, for developers it is really frustrating when the design is beautiful but it’s not really the best way to represent information. On the other hand designers get frustrated if the development team restricts their creativity.
Where can we find a middle ground? The tooling is crucial and it has to take into account both sides. Language is key in communication. We cannot have designers and developers talking of the same things in different terms because so much can get lost in translation.
Firstly, developers and designers both need to feel safe with the other “entering” their design. Collaboration has to be bi-directional and both roles have to incorporate input necessary from the other role. Also every day we start seeing more intermediate roles of designers that code and coders that design, making it even more important for bi-directional information pathways and common translation across ecosystems.
On that note, designers and developers have to speak the same language. That includes web standards and names but also here design tokens (similar to programming variables) take special importance. You don’t want to talk about a “black text” but more specifically reference the default-text-heading-color.
Design tools need to incorporate ways to inspect design changes, as well as tools to inspect and measure the design in order to incorporate that information properly into code.
We are starting to see a new wave of developers and designers working side by side, with shared ownership of design and code.
This makes designers and programmers happy and improves the long-term sustainability of front-end development.
