April 1, 2015 at 13:453 factors that create a gap between web designers and developers, and how to eliminate them
- Transfer
The workflow between designers and developers may look disgusting: most web projects are created by special multidisciplinary teams that run right 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 on their own.
We need effective ways to bridge the gap between designers and developers so that the design process is more even and efficient. At a time when web design tools are better than ever, it is very shortsighted to let design workflows remain ineffective.
Here is an attempt to list what usually goes wrong between the two disciplines, and how we can permanently eliminate these points. 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 cannot be created without a certain amount of handmade designers and manual code. In fact, most designers have no idea how to develop part of their work - 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 code of developers directly affects which of the design decisions will be implemented as a result: developers often have to tell 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 to the infrastructure installed by the developers, and many others really do not fit.
If designers want to stop wasting their time creating functions that will never be implemented, and arguing that they will never win, they need to understand the train of thought of developers from day one.
Solution
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 decisions . The last tip, obviously, depends on the patience and sociability of the developers (which may turn out to be a cat in a poke), so for now, let's concentrate on the first.
Webflow (and its competitors, Webydo or Froont) is a tool that turns designers into coders. This is a way to create sites by dragging and dropping items designed for professionals, not beginners. It allows designers to create sites visually in such a way as to use the best practices, solutions and trade-offs of web design. For example, in Webflow, you don’t drag the magic grid element onto the page. Instead, you drag the real HTML div element into which you then add links. In general, this is drawing HTML code on a page. And it works: the code that this program generates is completely W3C-compliant, and much cleaner than any code written by developers manually.
With this tool you will learn to fully take into account the features of development in the process of creating a website design. Plus, developers will appreciate that you can provide them with 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 discussion of site development in the initial stages, while developers remain on the sidelines until a later time. Why? Because, unfortunately, developers are considered simple machines that turn a product and design into code. This point of view, of course, reduces efficiency.
In fact, when developers are removed from the big picture, the project’s goals are lost as a result of a “damaged phone,” because they are transferred from the client to the product manager, then to the designer, and only then to the developer. Look at this 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 all the 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 effective work as on the struggle, whose personal goals will prevail.
Decision
Gather designers and developers, starting with the first meeting of the client and the product manager, so that both parties can accurately experience the project, understand the message behind the key decisions, and have the ability to intuitively make 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 starts with real content, everything changes significantly - usually for the worse, if the design and code do not take into account image resizing and the difference in the length and positioning of the text. And then, if the client looks and begins to make his micro-changes, you begin to move sharply away from the original project.
In the end, the developer and designer suddenly get involved in the struggle for how new changes should better meet the goals of both. This is a sudden conflict for which the developer and designer are never ready.
Decision
Give up the concept of layouts. Start developing prototypes with limited features from day one. The sooner you start working with materials that you can interact with, the sooner you will be able to predict how these materials will need to be changed so that they better match the original idea of the client. If you use tools like Webflow or Webydo, you have the double advantage of making the design 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 bridge the gap between designers and developers so that the design process is more even and efficient. At a time when web design tools are better than ever, it is very shortsighted to let design workflows remain ineffective.
Here is an attempt to list what usually goes wrong between the two disciplines, and how we can permanently eliminate these points. 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 cannot be created without a certain amount of handmade designers and manual code. In fact, most designers have no idea how to develop part of their work - 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 code of developers directly affects which of the design decisions will be implemented as a result: developers often have to tell 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 to the infrastructure installed by the developers, and many others really do not fit.
If designers want to stop wasting their time creating functions that will never be implemented, and arguing that they will never win, they need to understand the train of thought of developers from day one.
Solution
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 decisions . The last tip, obviously, depends on the patience and sociability of the developers (which may turn out to be a cat in a poke), so for now, let's concentrate on the first.
Webflow (and its competitors, Webydo or Froont) is a tool that turns designers into coders. This is a way to create sites by dragging and dropping items designed for professionals, not beginners. It allows designers to create sites visually in such a way as to use the best practices, solutions and trade-offs of web design. For example, in Webflow, you don’t drag the magic grid element onto the page. Instead, you drag the real HTML div element into which you then add links. In general, this is drawing HTML code on a page. And it works: the code that this program generates is completely W3C-compliant, and much cleaner than any code written by developers manually.
With this tool you will learn to fully take into account the features of development in the process of creating a website design. Plus, developers will appreciate that you can provide them with 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 discussion of site development in the initial stages, while developers remain on the sidelines until a later time. Why? Because, unfortunately, developers are considered simple machines that turn a product and design into code. This point of view, of course, reduces efficiency.
In fact, when developers are removed from the big picture, the project’s goals are lost as a result of a “damaged phone,” because they are transferred from the client to the product manager, then to the designer, and only then to the developer. Look at this 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 all the 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 effective work as on the struggle, whose personal goals will prevail.
Decision
Gather designers and developers, starting with the first meeting of the client and the product manager, so that both parties can accurately experience the project, understand the message behind the key decisions, and have the ability to intuitively make 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 starts with real content, everything changes significantly - usually for the worse, if the design and code do not take into account image resizing and the difference in the length and positioning of the text. And then, if the client looks and begins to make his micro-changes, you begin to move sharply away from the original project.
In the end, the developer and designer suddenly get involved in the struggle for how new changes should better meet the goals of both. This is a sudden conflict for which the developer and designer are never ready.
Decision
Give up the concept of layouts. Start developing prototypes with limited features from day one. The sooner you start working with materials that you can interact with, the sooner you will be able to predict how these materials will need to be changed so that they better match the original idea of the client. If you use tools like Webflow or Webydo, you have the double advantage of making the design 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, IP and LLC.
→ Accept payment from companies online. Without a site, IP and LLC.
→ Accepting payments from companies for your site. With document management and exchange of originals.
→ Automation of sales and servicing transactions with legal entities. Without an intermediary in the calculations.
→ Accept payment from companies online. Without a site, IP and LLC.
→ Accepting payments from companies for your site. With document management and exchange of originals.
→ Automation of sales and servicing transactions with legal entities. Without an intermediary in the calculations.