{"id":246,"date":"2019-02-28T11:43:52","date_gmt":"2019-02-28T10:43:52","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/the-eternal-struggle-between-designers-and-developers\/"},"modified":"2020-01-10T16:33:29","modified_gmt":"2020-01-10T15:33:29","slug":"the-eternal-struggle-between-designers-and-developers","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/frontend\/design-ux\/the-eternal-struggle-between-designers-and-developers\/","title":{"rendered":"The eternal struggle between designers and developers"},"content":{"rendered":"

W<\/span>hen a discussion between a designer<\/span> and a developer<\/span> reaches a dead-end, it happens that both of them start talking mumbo jumbo, using big words just to close the thread in their favour, leveraging the different skills of each other. This was the baseline idea for Davide Di Pumpo<\/a>, front-end<\/span> developer<\/span> with UX<\/span>\/UI<\/span> design skills, when thinking about a title for his talk at Codemotion Milan 2018<\/a>. While the talk (and thus the title) was taken in Italian, its title can be translated as \u201cLike Gestalt, with Redux on the right\u201d. It sounded interesting, but all the attendees discovered that even the title was just mumbo jumbo (a \u201csupercazzola\u201d, as he said referring to a popular Italian movie): there was nothing about Gestalt, nothing about Redux. It was about the eternal struggle between designers<\/span> and developers<\/span>.<\/p>\n

When designers<\/span> think about a project, like for instance<\/span> a new layout for a website or a mobile application<\/span>, they usually put it on paper with mockups and sketches<\/strong>, and then developers<\/span> will implement their idea using the most appropriate technologies. However, many designers<\/span> agree that often the output of this process<\/span> is not exactly what they had in mind, as if something got lost in the implementation process<\/span><\/strong>. How to solve this problem? Is this due to developers<\/span>\u2019 oversights? Or did the designer<\/span> do something wrong?<\/p>\n

Davide proposed an interesting approach to fill the gap in the communication process<\/span> between developers<\/span> and designers<\/span>. Instead of using only the traditional design tools, like Adobe Sketches or similar software<\/span>, he proposes to use a single JSON<\/span> file<\/span>, where all the information about design details can be summed up. JSON<\/span><\/strong> is commonly used to allow communication among computers, and it has the advantage of avoiding any kind of ambiguity. But instead of asking developers<\/span> to work on such data<\/span>, why not ask designers<\/span> to use JSON<\/span> files<\/span> as a unique \u201csource<\/span> of truth\u201d, where all the information about design is stored? This approach was used by Davide\u2019s company, Credimi, where designers<\/span> were able to re-design the layout of their website in just eight hours.<\/p>\n

While JSON<\/span> allows us to specify some information, there is another tool that can help designers in describing a UI<\/span> component<\/span>. Web components<\/span><\/strong> can be implemented using HTML<\/span> and Javascript<\/span>, but they can be described by means of GraphQL<\/strong>, which uses a very similar language compared with JSON<\/span>. You can thus define GraphQL types and the information that composes a type. By means of JSON<\/span> and GraphQL types<\/strong>, designers can define a common language<\/strong> for communicating with developers<\/span>, thus easing the communication process<\/span> between them.<\/p>\n

Of course, learning JSON<\/span> and GraphQL is not enough. Designers still want to have tools to see what they are doing with their design ideas. For these reasons, Davide also proposed a set of useful tools for designers, which can actually also be used by developers<\/span> in some situations:<\/p>\n