3 factors that create a gap between web designers and developers, and how to fix them
The workflow between designers and developers may look disgusting: most web projects are created by special interdisciplinary teams that run away immediately after the project is completed. And, in most cases, they never have a serious workflow in terms of product management. Usually, designers and developers are left to go about their business independently.
We need effective ways to narrow the gap between designers and developers so that the design creation process is performed more evenly and efficiently. At a time when web design tools are better than ever, it is very short-sighted to allow design workflows to remain ineffective.
Here is an attempt to enumerate what usually goes wrong between these two disciplines, and how we can permanently eliminate these moments. If you are tired of wasting your time working with developers, this article is for you (developers, you can also learn something new from it).
Most sites can not be created without a certain amount of handmade designers and manual code. In fact, most designers have no idea how the development of their work is done - how exactly the code is used or why different programming languages ​​are needed for different tasks.
')
Why is it so important that designers better understand the work of developers? Because only then will they understand why the developers' code directly affects which of the design decisions will be implemented as a result: developers often have to tell the designers that their requests cannot be fulfilled, which is why designers think that the reason is bad code or laziness of developers. Although in fact most often the reason is practicality; Some design solutions are ideally suited for the infrastructure installed by developers, and many others are really not suitable.
If designers want to stop wasting their time on creating features that will never be implemented, and on disputes in which they will never win, they need to understand the course of thought of developers from the very first day.
Decision
Fortunately (for designers), designers do not need to learn to code to solve this problem. There are two solutions that do not require a lot of time: 1) use a tool like Webflow (we’ll talk more about it later) or 2) make it a habit to ask developers to explain their development approach and the trade-offs they have to resort to in order to implement these solutions . The last tip, obviously, depends on the patience and sociability of the developers (which may be a cat in the bag), so for now let's focus on the first one.
Webflow (and its competitors, Webydo or Froont) is a tool that turns designers into coders. This is a way to create websites by dragging items, designed for professionals, not for beginners. It allows designers to create websites visually in such a way as to use best practices, solutions and trade-offs for web design. For example, in Webflow, you are not dragging the magic grid element onto a page. Instead, you drag a real HTML “div” element into which you add links later. In general, this is drawing HTML code on a page. And it works: the code that this program generates is fully consistent with the W3C, and much cleaner than any code written by developers manually.
With this tool you will learn to fully consider the features of the development in the process of creating a site design. Plus, developers will appreciate that you can provide them with a code that they can immediately start working on (these professional tools allow you to export all the code for later use in the IDE).
Designers are always included in the development discussions of the site at the initial stages, while the developers stay aside until a later time. Why? Because, unfortunately, developers are considered simple machines that turn product and design into code. This point of view, of course, reduces efficiency.
In fact, when developers are removed from the overall picture, the goals of the project are lost as a result of a “damaged phone”, since they are transferred from the client to the product manager, then to the designer, and only then to the developer. Look at it from the following point of view: when the project manager tells the designer to use a special font and style of presentation, while the developers are told that the entire text should be well indexed by search engines, whose goals will be a priority? As a result of the separation, designers and developers cannot synchronize work from the very beginning, and the project becomes not so much focused on performing the most efficient work as on the struggle whose personal goals will prevail.
Decision
Gather designers and developers from the first meeting of the client and the product manager so that both parties can feel the project accurately, understand the message behind the key decisions, and have the opportunity to make intuitive decisions that everyone will appreciate.
Layouts typically use replacement text and images. You probably met the "fish". In the real world, of course, everything is different: as soon as the site is launched with real content, everything changes significantly - usually in a bad way, if the design and code do not take into account changes in image size and the difference in length and positioning of the text. And then, if the client looks and starts making his own micro-changes, you start to move away sharply from the original project.
Ultimately, the developer and designer suddenly get involved in the struggle for how new changes should best fit the goals of both. This is a sudden conflict to which the developer and designer are never ready.
Decision
Discard the concept of layouts. Start from the very first day to develop prototypes with limited functions. The sooner you start working with materials with which you can interact, the sooner you will be able to predict how these materials will need to be changed to better fit the client’s original idea. If you use tools like Webflow or Webydo, you have the double advantage of getting your design to work right away; These tools allow you to create real sites, not just prototypes.
When designers and developers work in isolation, the end result is a site without a soul or essence. Or both. To avoid this, work together from the very beginning of the project.
We need effective ways to narrow the gap between designers and developers so that the design creation process is performed more evenly and efficiently. At a time when web design tools are better than ever, it is very short-sighted to allow design workflows to remain ineffective.
Here is an attempt to enumerate what usually goes wrong between these two disciplines, and how we can permanently eliminate these moments. If you are tired of wasting your time working with developers, this article is for you (developers, you can also learn something new from it).
01. Developers and designers share
Most sites can not be created without a certain amount of handmade designers and manual code. In fact, most designers have no idea how the development of their work is done - how exactly the code is used or why different programming languages ​​are needed for different tasks.
')
Why is it so important that designers better understand the work of developers? Because only then will they understand why the developers' code directly affects which of the design decisions will be implemented as a result: developers often have to tell the designers that their requests cannot be fulfilled, which is why designers think that the reason is bad code or laziness of developers. Although in fact most often the reason is practicality; Some design solutions are ideally suited for the infrastructure installed by developers, and many others are really not suitable.
If designers want to stop wasting their time on creating features that will never be implemented, and on disputes in which they will never win, they need to understand the course of thought of developers from the very first day.
Decision
Fortunately (for designers), designers do not need to learn to code to solve this problem. There are two solutions that do not require a lot of time: 1) use a tool like Webflow (we’ll talk more about it later) or 2) make it a habit to ask developers to explain their development approach and the trade-offs they have to resort to in order to implement these solutions . The last tip, obviously, depends on the patience and sociability of the developers (which may be a cat in the bag), so for now let's focus on the first one.
Webflow (and its competitors, Webydo or Froont) is a tool that turns designers into coders. This is a way to create websites by dragging items, designed for professionals, not for beginners. It allows designers to create websites visually in such a way as to use best practices, solutions and trade-offs for web design. For example, in Webflow, you are not dragging the magic grid element onto a page. Instead, you drag a real HTML “div” element into which you add links later. In general, this is drawing HTML code on a page. And it works: the code that this program generates is fully consistent with the W3C, and much cleaner than any code written by developers manually.
With this tool you will learn to fully consider the features of the development in the process of creating a site design. Plus, developers will appreciate that you can provide them with a code that they can immediately start working on (these professional tools allow you to export all the code for later use in the IDE).
02. Designers and developers are given different instructions.
Designers are always included in the development discussions of the site at the initial stages, while the developers stay aside until a later time. Why? Because, unfortunately, developers are considered simple machines that turn product and design into code. This point of view, of course, reduces efficiency.
In fact, when developers are removed from the overall picture, the goals of the project are lost as a result of a “damaged phone”, since they are transferred from the client to the product manager, then to the designer, and only then to the developer. Look at it from the following point of view: when the project manager tells the designer to use a special font and style of presentation, while the developers are told that the entire text should be well indexed by search engines, whose goals will be a priority? As a result of the separation, designers and developers cannot synchronize work from the very beginning, and the project becomes not so much focused on performing the most efficient work as on the struggle whose personal goals will prevail.
Decision
Gather designers and developers from the first meeting of the client and the product manager so that both parties can feel the project accurately, understand the message behind the key decisions, and have the opportunity to make intuitive decisions that everyone will appreciate.
03. Product content is different from model content.
Layouts typically use replacement text and images. You probably met the "fish". In the real world, of course, everything is different: as soon as the site is launched with real content, everything changes significantly - usually in a bad way, if the design and code do not take into account changes in image size and the difference in length and positioning of the text. And then, if the client looks and starts making his own micro-changes, you start to move away sharply from the original project.
Ultimately, the developer and designer suddenly get involved in the struggle for how new changes should best fit the goals of both. This is a sudden conflict to which the developer and designer are never ready.
Decision
Discard the concept of layouts. Start from the very first day to develop prototypes with limited functions. The sooner you start working with materials with which you can interact, the sooner you will be able to predict how these materials will need to be changed to better fit the client’s original idea. If you use tools like Webflow or Webydo, you have the double advantage of getting your design to work right away; These tools allow you to create real sites, not just prototypes.
Conclusion
When designers and developers work in isolation, the end result is a site without a soul or essence. Or both. To avoid this, work together from the very beginning of the project.
Useful Paysto solutions for Megamind readers:
→ Get paid by credit card right now. Without a site, PI and LLC.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
→ Accept payments from companies via the Internet. Without a site, PI and LLC.
→ Acceptance of payments from companies for your site. With document circulation and exchange of originals.
→ Automation of sales and service transactions with legal entities. Without intermediary in the calculations.
Source: https://habr.com/ru/post/289154/
All Articles