Pain

It is not strange, but in the very process of developing the visual part, we in the company are at least 2-3 years behind. First, the classic, isolated, universal model: Design - Design - Layout. Secondly, the same approach remains both for pages of small stocks (caps) and for large-scale services, such as where it is difficult to predict the development scenario. But we are all one size fits all. I personally do not know in our company a character who globally struggles to improve the process and the very system of developing the visual part. Basically, there are skillful phrases about the terms and it seems that all the masters of time management. Many of the harsh phrases like “Percentage of time” completely kill all logic, and naively rely on maintaining productivity at the same level. When you develop a large project, 5-7 global switchings per day to other tasks are completely paralyzed and bring down the entire process of developing the main project. Well, however, this is managerial magic with one-way profit.

The process of developing the visual part is two separate stages of design and layout. The same approach remains both for small pages of the action (caps), and for large-scale services where it is difficult to predict the development scenario.

Now about the resulting "pain" .... The situation, which now looks like this:

Design

Explicit construction errors

Reinforced concrete structure, not at all flexible, well-made compositionally, but not involving change. The design is changing. But if there are no laws and rules (and we do not have them), then the basic errors at the design stage are aggravated with each new element at times.
')

External styling to taste

I agree that purely aesthetically, some things may look very cool. And a lot of likes on Dribble will be collected without difficulty. But if this is their ultimate goal. We have another task at odds.

It is clear that within the framework of a huge company, designers have a customer who will make a decision. But this should not be inconsistent with the general principles of the web, biased attitude, personal "taste".

Layout

I think it has already been understood that at this stage the work is far from “sugar”. We get a dubious frame, not a flexible structure, a layout with aesthetic effects, not involving a resize ... Such a layout is difficult to implement even on a full stack of web tools, and we also take half of them, forcing to support IE8.

Gracefull degradation

Designers are guided by the chips of 2014, and layout designers should solder this in the browser of 2009. I think you understand the temporary gap. If you get closer to the design, then you can experiment by opening even the coolest sites of 2009. Technologically based on IE8, it’s silly to talk about tandem with modern design.

Development bugs

I am kidding: “we write 20% of the code and 80% write crutches and bugs”. Inventing the original, new approach "development by bugs" for lovers of sharp sensation. But starting the 10th project with this approach is close to schizophrenia.

We’ll hit our time management experts again. When they say that there is a gap in time for revision. But this gap is not five times larger, considering 20% ​​of effective work from our side.

Testing. Judgment Day

Our testers are not the guys who write tests for the interface, but the site responses, a kind of MonkeyTesting, only in live performance. After that, a bunch of tickets are put out, that everything is not working well, supplemented by a personal wish. And start local dopily. And we understand that from the very first stage the project was not made for those tasks and the principles on which it is tested were not taken into account. Saw starts on the fly to the hands of developers. We forget about design aesthetics, it just falls out of the game. All this wanders from project to project and with each new hopelessness multiplies.

Treatment

Having defined the diagnosis, obvious solutions emerge. We need to establish the maximum interaction between all the team members responsible for the visual part (design, design, layout), but everyone needs common guidelines and tools.

Based on the best practices, we begin to build our ecosystem, taking into account our features:

Guides

Building basic styles that will start any new project. If necessary, he can be refined and always be up to date and in combat, both externally and under the hood (I mean, the code). The composition is approximately as follows:

Typography (fonts, sizes)

- Headers
- Paragraphs
- Links

Colors

- Basic flowers
- Colors for products (we have several different products within the same company). We want to avoid 10 almost identical colors that are the same visually, but differ in the code in the layouts, so we include possible colors in the guide ...

Buttons

All button states (default, hover, pressed)
Variations (for example with or without an icon) or sizes (small, large), etc.

Inputs (Samsung is not in the best shape)

To designate a reference form of forms is one of my most manic fantasies. You know how any developer has a "bzyk" that does not sleep at night. I have this without a doubt - the form. They literally drove me crazy, unfortunately, not in the best sense. There are details on which it is immediately visible - how much the layout is worked out. And the form is a clear indicator. Even though we had a complete mess with them, even advanced sites like Samsung do much worse. Even in top Awwwards, there are often projects in which the situation with forms is lamentable.
Now in the guides there is a stylization of each of the elements of the form, which we take as a standard. What simply makes life easier for designers and will provide an understanding of opportunities for designers.

Preloaders

We have a critical need for them. Since many actions are performed dynamically, without rebooting, which is not always foreseen by the designers.

Source

The second thing that turned my brain this year was Source . In which finally managed to structure the modular approach and bring it in a convenient form for perception, not only developers, but also designers. Here we focus on the design itself, using basic styles. We deliberately separated the main styles from the basic designs for convenience.

Usage example:

Let's say there is a task to make a block of the registration form .
What elements does it consist of:
- Title
- Text input
- Checkbox
- Button
- Link
- Icon

All of these elements are in the basic whale, you just collect from them the block that we put in the Source . Source is our common base of blocks (in which the markup is visible). In the future that can be reused and modified .

Working in such a process will give us more logic and understanding, will significantly increase the percentage of useful work (which does not need to be redone), the accumulation of the products of our work into a common base and the accumulation of power for new projects.

Frame

Our team has a common understanding of the grid and adaptive. It looks like this:

Full adaptive

Fracture Points (Media):
Smartphones
The width of the window (device) <768px
Container width <768px

Tablets
Width of the window (device)> 768px
Container width = 750px
Desktops
Width of the window (device)> 992px
Container width = 970px
Widescreen
Width of the window (device)> 1200px
Container width = 1170px

Version breakdown

In cases where the content is specific, there is a lot of functionality and it is not possible to use one markup, we make two versions:
- Desktops / Widescreen + Rebuilding for Tablet (12 columns)
- Mobile version (single version) + (its own 6-column grid)

Animation

The inevitable component of the design, which we can not ignore, and which attaches great importance. We need to implement it neatly, without putting a functional part on it. Considering that everything should work in an acceptable form in older browsers. In the future, it will also be documented in the Source . It is possible to redistribute roles in the form of an Interaction Designer. Since here we need a hybrid bundle in the form of technical knowledge + dynamic design (microinteractions).

In my opinion, just a smart system, which at times increase the power and speed. It is a logical evolution of processes for large projects. It does not drive in a rigid framework, but gives guidelines and guarantees that the work will be successfully implemented technically.

PS
Most of these problems I described in the article " Design in the browser ." But the “Old Believers” and conservatives of such a race can be morally traumatic, therefore, if desired, you can comb the process without radical measures and use it as an intermediate preparatory stage for the inevitable “ Design in the browser ”.