Integration design. Every pixel matters. Part 1
As promised, we begin to publish articles in the footsteps of Design Camp . Let's start with the article by Eugene Gavrilov from the Windows Phone design integration team.
Today technologies of design and development of modern interfaces are developing rapidly rapidly. It's no secret that the de facto standard is already the availability of a mobile version of the desktop application or its web version for a portable device with a small screen. Today's users are demanding more and more from applications, and therefore designers are investing in application design and application development a lot of interesting ideas and creative approaches in order to make the interface simple, understandable, intuitive and humane.
')
Let's look at this clockwork and pay attention to the smallest details. What material are they made of, what color are they, where are they located, what size are they? All this, of course, plays a huge role for how the clock mechanism will work as a whole. If some do not exist for an incomprehensible reason, or have the wrong size, position, and possibly color, the clock will go wrong and the end user will simply not use them. The same principle applies to any software and interfaces. Today we can say with certainty that the accurate implementation of all the details, colors, element positions is the most important task in the implementation of products.
I recently read a book about Harley Davidson. Legendary company that has united millions of people around itself. We most know them as “bikers” - people who created a whole philosophy of life, culture, slang, style. One very interesting moment passes through the whole history of Harley Davidson. This is a unique sound of a motorcycle, which is inherent only to models of this company. The engines of these motorcycles are arranged in a very interesting way: only they produce such a sound. In America, it is called “potato - potato - potato”. The sound is truly unusual and fascinating. In addition to engine vibration, all this creates a certain charm and mystical cult image of Harley motorcycles.
The sound is exactly the part that I want to pay attention to. Each factory Harley Davidson has a department that is engaged in tuning the sound of motorcycles. It employs engineers who regulate certain gaps, sizes, indents, so that the sound of a motorcycle is exactly the way it was conceived and exactly the way the users liked it.
When the owner of Harley Davidson is asked: “What does this Harley sound mean to you?”, Then probably 9 out of 10 will say that the sound of a motorcycle is his soul, or without which the motorcycle cannot be a real Harley. This small detail is of great importance for them, despite the fact that this is not some technical characteristic, not some design elements. This is a sound that they love and adore.
Let's look at how products are created with a user interface today.
Everything looks perfect, great, great shapes, as designers we like it all. But we, at a certain moment, understand that this is only for the time being on paper. The moment comes when we begin to think about how to implement this product, what needs to be done for this.
At this point, comes acquaintance with the magical world of developers. The first law that we assimilate is that any design must have technical specifications and specifications. It is not a secret that the process of creating technical tasks is very laborious and tedious, there is nothing interesting in it, nothing creative, the designers simply hate it. At the same time, most designers do not understand the importance of this process and how much this process can help in the future with the implementation of the product.
But we are very conscientious designers. We described all sizes, set all specifications, all radii, all colors. Everything is determined and everything is in its place.
Even more than that, we transfer this design to PhotoShop or any other convenient format, put all the layers on the shelves, number them and name them. In other words, create a paradise for the developer. He will open the model and will experience the delight and joy that the designer has done his work qualitatively.
Then the layout goes to the layout designer or to the front-end developer, who will create a static code without functionality that will fully comply with our design. At this stage of work, basically, all designers remain happy and satisfied. They see the layout of the layout, and think: "Well, that's it, just a little bit, very little." Moreover, the project manager assures that now we will hire the best developers, they will connect modern frameworks, add services, modules, and everything will work just fine.
After a few weeks, the moment of launch of the product, and we, to put it mildly, at a loss, are disappointed: “How so? Why does the design look like this? ”What the project manager assures you is:“ You know, the functionality fully corresponds to the technical task, everything works. All in all, we will open several tasks, correct the design, hire a couple of programmers, and they will fix everything. ”
Some time passes, our product becomes similar to what we have done, but not quite. Quite logical questions arise: “Who is responsible for the quality of implementation?” Or “Why does a realized product not coincide with the design?”, “What details are important in the implementation of the product, and which are not?”, “What details can be omitted?”
Who puts the last word in the design that our end user sees? How often did you ask this question to yourself or someone who is responsible for the development. Why some developers do not see the difference? Why for them some details are not important, and some details are more important than others?
How often have you heard the question: “Actually, what's the difference that the font is 2 pixels smaller? What are we going to now open for this new task and correct fonts, etc.? ”How often have you heard this question:“ What is the difference: gray is 30% or 40%? Let's leave 30% already. ” Or "Animation for the button to connect? We have no time for this. Let's defer to the next version. ”
To answer the questions:
“Why do some people pay attention to details while others don’t?”
- Why is the correct color of the element important for someone, but not for someone?
- Why is design more important than its technical implementation?
I suggest to look at the device of our complex brain.
It is no secret that the left brain is responsible for logic, analysis of facts, numbers, algorithms. While the right brain is responsible for visual images, it perceives animation, music, design. All our ideas, dreams - come from the right side of the brain.
And what is most interesting, the people of a technical mindset - engineers, designers, programmers, developers - all have a more developed left hemisphere. When they work, they basically use all the properties of the left hemisphere. While artists, musicians, designers, dreamers and all the people who draw, write poetry, create creative use the right hemisphere most of all.
For example, a design engineer and a designer, working on one project, can simply speak in a language that they don’t understand. And at that moment, when the difference between a class and an object or a feature of a recursive function is completely unimportant for a designer, then the thickness of the frame on the button or the presence of animation when aiming at the object is absolutely not important for the programmer.
This is all nothing personal. This is a device of our brain, to see and focus attention on certain details, and completely ignore, not understand or attach importance to something else.
What happens in the final phase of product development, so to speak in its final stage, at the finish line? Designers have prepared a technical task for the entire interface and are happy to give it to the developers. At that time, developers, without closing their eyes, begin to work on the implementation of the interface. In most cases, these two disciplines do not overlap further in the development process.
How to ensure constant communication between designers and developers (this is not about ways of communication between departments)? Where to find the missing link? The bridge that connects these two disciplines? Translator or interpreter between developers and designers?
"Think like a designer, work like a programmer." I wrote these words in my resume when I came to an interview with Microsoft. I also printed this poster.
During the interview, I told about myself that I have two educations: one in the field of IT, another in the field of interactive design, and for the last 6 years I have been developing interfaces and web application design for mobile platforms. I also said with confidence that I understand the nuances of the design, I see the details and can speak the design language, but at the same time, I know the technology and I understand how to implement the intended design in the code. The interviewer was very surprised, but at the same time intrigued, he left the room and returned some time later with his colleague. It was one of the leading developers of the Windows Phone interface. We continued the interview in three of them, after which I was offered a position in a completely new department of design integration for Windows Phone (Windows Phone Design Integration).
The design integrator thinks like a designer, works like a programmer. I want to note that the design integrator does not create a design and does not write a functional code. These are two basic principles that need to be remembered.
So who is he, Design Integrator? What is he doing? How does it work?
I will try to answer these questions, but first let's look at the process of developing the interface of Windows Phone.
It all starts with a conceptual idea and a wireframe. It can be created on a blackboard, a piece of paper, a napkin or in any graphic program. Then this wireless frame is transferred to the designer, who works out all the nuances of the interface and user scripts. At this stage, absolutely any graphic package can be used, for example, Adobe, Microsoft Expression, etc. After testing the prototype for focus groups and approving it by all departments, a technical task and specification for each screen and script is created. It should clearly indicate all the necessary indents, sizes, colors, styles, fonts, etc. In general, very serious attention is given to the technical task for the designer in our studio, and a whole separate article can be devoted to this.
As soon as the technical task gets to the developer, he starts writing the functional code, but when it comes to directly programming the visual part of the interface, he only arranges all the necessary interface elements on the screen without design, styles and exact dimensions. The application works, is 100% compliant with the technical specification, but visually it is different and does not match the design. That is, at this stage, the developer does not spend time at all to polish the interface to arrange all the necessary styles, indents, etc. After that, the code goes to the integration department, where the application takes on the look that was intended by the designer .
The first and most necessary condition for the Integration of Design is a unified development environment and debugging interface. Programmers and integrators work in exactly the same environment, use exactly the same development tools and the same code repository. Let's look at the analogy of the relationship between Batman and Robin. Imagine that Batman is responsible for the design, and Robin is responsible for the design, he perfectly knows and understands the design language, knows all the available styles that are in the libraries, knows all the fonts that are used in the design and has access to the effects libraries for the animation. Robin is a person who knows everything about how to properly design a page and at the same time he understands how the architecture of the application works and he perfectly knows and reads the markup language (XAML, HTML, XML, etc.). In other words, it works like the most ordinary programmer, but it does not write functional code, but it works in the same functional environment, the development environment.
If we look at the functional responsibilities of Batman as a developer and Robin as an integrator of design, it is clear that Batman is responsible for the functionality. He writes models, services, modules, controls, etc., connects the API. Everything related to the interface: Batman only arranges the grid, interface elements without styles, and temporary files for icons, so-called stubs.
While Robin, being an integrator of design, works on indents, he sets the coordinates, the position of objects, touch charts, styles, colors and substitutes the final files for photos or icons. Batman puts stubs for animation. If the animation is thought out by the designer, he simply says that there will be animation in this place. While Robin has put the right delay, the right transitions, etc. In fact, Batman leaves him just a stub, which then will change Robin. Everything related to the text, Batman is responsible for the final content, he connects all the strings, all the localization, but is not at all worried about the styles, the design. This is what Robin does. It sets styles, fonts, sizes and colors for all text elements in the application.
The next important detail for Design Integration is code separation. It is necessary to build the application in such a way that the functional part of the code is separated from the interface markup and styles. In this way, we provide the opportunity for people working in functional code to make changes with minimal risk so that the interface does not change. At the same time, design integrators work only in the markup code. They change styles, they change the design, while they are less likely to change the functional part of the code.
===
To be continued…
Evgeny Gavrilov (Microsoft, Windows Phone Design Team). - Born and studied in Rostov-on-Don. He worked as a programmer in large companies in the city. In the early 2000s, he moved to permanent residence in the United States and continued his studies in the field of interactive design. Working in various companies, I have come a long way from a designer to an art director. In early 2009, he came to work in the design studio Microsoft Windows Phone. It was a very interesting and exciting work, because at that time the studio was actively developing the Metro interface for the future of the phone. To date, I am the leading designer of the integration department in Windows Phone.
1. Details and their importance
Today technologies of design and development of modern interfaces are developing rapidly rapidly. It's no secret that the de facto standard is already the availability of a mobile version of the desktop application or its web version for a portable device with a small screen. Today's users are demanding more and more from applications, and therefore designers are investing in application design and application development a lot of interesting ideas and creative approaches in order to make the interface simple, understandable, intuitive and humane.
')
Let's look at this clockwork and pay attention to the smallest details. What material are they made of, what color are they, where are they located, what size are they? All this, of course, plays a huge role for how the clock mechanism will work as a whole. If some do not exist for an incomprehensible reason, or have the wrong size, position, and possibly color, the clock will go wrong and the end user will simply not use them. The same principle applies to any software and interfaces. Today we can say with certainty that the accurate implementation of all the details, colors, element positions is the most important task in the implementation of products.
2. Sound - the soul of a motorcycle
I recently read a book about Harley Davidson. Legendary company that has united millions of people around itself. We most know them as “bikers” - people who created a whole philosophy of life, culture, slang, style. One very interesting moment passes through the whole history of Harley Davidson. This is a unique sound of a motorcycle, which is inherent only to models of this company. The engines of these motorcycles are arranged in a very interesting way: only they produce such a sound. In America, it is called “potato - potato - potato”. The sound is truly unusual and fascinating. In addition to engine vibration, all this creates a certain charm and mystical cult image of Harley motorcycles.
The sound is exactly the part that I want to pay attention to. Each factory Harley Davidson has a department that is engaged in tuning the sound of motorcycles. It employs engineers who regulate certain gaps, sizes, indents, so that the sound of a motorcycle is exactly the way it was conceived and exactly the way the users liked it.
When the owner of Harley Davidson is asked: “What does this Harley sound mean to you?”, Then probably 9 out of 10 will say that the sound of a motorcycle is his soul, or without which the motorcycle cannot be a real Harley. This small detail is of great importance for them, despite the fact that this is not some technical characteristic, not some design elements. This is a sound that they love and adore.
3. Product and its implementation
Let's look at how products are created with a user interface today.
Everything looks perfect, great, great shapes, as designers we like it all. But we, at a certain moment, understand that this is only for the time being on paper. The moment comes when we begin to think about how to implement this product, what needs to be done for this.
At this point, comes acquaintance with the magical world of developers. The first law that we assimilate is that any design must have technical specifications and specifications. It is not a secret that the process of creating technical tasks is very laborious and tedious, there is nothing interesting in it, nothing creative, the designers simply hate it. At the same time, most designers do not understand the importance of this process and how much this process can help in the future with the implementation of the product.
But we are very conscientious designers. We described all sizes, set all specifications, all radii, all colors. Everything is determined and everything is in its place.
Even more than that, we transfer this design to PhotoShop or any other convenient format, put all the layers on the shelves, number them and name them. In other words, create a paradise for the developer. He will open the model and will experience the delight and joy that the designer has done his work qualitatively.
Then the layout goes to the layout designer or to the front-end developer, who will create a static code without functionality that will fully comply with our design. At this stage of work, basically, all designers remain happy and satisfied. They see the layout of the layout, and think: "Well, that's it, just a little bit, very little." Moreover, the project manager assures that now we will hire the best developers, they will connect modern frameworks, add services, modules, and everything will work just fine.
After a few weeks, the moment of launch of the product, and we, to put it mildly, at a loss, are disappointed: “How so? Why does the design look like this? ”What the project manager assures you is:“ You know, the functionality fully corresponds to the technical task, everything works. All in all, we will open several tasks, correct the design, hire a couple of programmers, and they will fix everything. ”
Some time passes, our product becomes similar to what we have done, but not quite. Quite logical questions arise: “Who is responsible for the quality of implementation?” Or “Why does a realized product not coincide with the design?”, “What details are important in the implementation of the product, and which are not?”, “What details can be omitted?”
Who puts the last word in the design that our end user sees? How often did you ask this question to yourself or someone who is responsible for the development. Why some developers do not see the difference? Why for them some details are not important, and some details are more important than others?
4. Why the implemented product does not match the design?
How often have you heard the question: “Actually, what's the difference that the font is 2 pixels smaller? What are we going to now open for this new task and correct fonts, etc.? ”How often have you heard this question:“ What is the difference: gray is 30% or 40%? Let's leave 30% already. ” Or "Animation for the button to connect? We have no time for this. Let's defer to the next version. ”
To answer the questions:
“Why do some people pay attention to details while others don’t?”
- Why is the correct color of the element important for someone, but not for someone?
- Why is design more important than its technical implementation?
I suggest to look at the device of our complex brain.
It is no secret that the left brain is responsible for logic, analysis of facts, numbers, algorithms. While the right brain is responsible for visual images, it perceives animation, music, design. All our ideas, dreams - come from the right side of the brain.
And what is most interesting, the people of a technical mindset - engineers, designers, programmers, developers - all have a more developed left hemisphere. When they work, they basically use all the properties of the left hemisphere. While artists, musicians, designers, dreamers and all the people who draw, write poetry, create creative use the right hemisphere most of all.
For example, a design engineer and a designer, working on one project, can simply speak in a language that they don’t understand. And at that moment, when the difference between a class and an object or a feature of a recursive function is completely unimportant for a designer, then the thickness of the frame on the button or the presence of animation when aiming at the object is absolutely not important for the programmer.
This is all nothing personal. This is a device of our brain, to see and focus attention on certain details, and completely ignore, not understand or attach importance to something else.
5. Lost Link
What happens in the final phase of product development, so to speak in its final stage, at the finish line? Designers have prepared a technical task for the entire interface and are happy to give it to the developers. At that time, developers, without closing their eyes, begin to work on the implementation of the interface. In most cases, these two disciplines do not overlap further in the development process.
How to ensure constant communication between designers and developers (this is not about ways of communication between departments)? Where to find the missing link? The bridge that connects these two disciplines? Translator or interpreter between developers and designers?
6. Think like a designer, work like a programmer
"Think like a designer, work like a programmer." I wrote these words in my resume when I came to an interview with Microsoft. I also printed this poster.
During the interview, I told about myself that I have two educations: one in the field of IT, another in the field of interactive design, and for the last 6 years I have been developing interfaces and web application design for mobile platforms. I also said with confidence that I understand the nuances of the design, I see the details and can speak the design language, but at the same time, I know the technology and I understand how to implement the intended design in the code. The interviewer was very surprised, but at the same time intrigued, he left the room and returned some time later with his colleague. It was one of the leading developers of the Windows Phone interface. We continued the interview in three of them, after which I was offered a position in a completely new department of design integration for Windows Phone (Windows Phone Design Integration).
The design integrator thinks like a designer, works like a programmer. I want to note that the design integrator does not create a design and does not write a functional code. These are two basic principles that need to be remembered.
So who is he, Design Integrator? What is he doing? How does it work?
I will try to answer these questions, but first let's look at the process of developing the interface of Windows Phone.
7. Design and development of the Windows Phone interface
It all starts with a conceptual idea and a wireframe. It can be created on a blackboard, a piece of paper, a napkin or in any graphic program. Then this wireless frame is transferred to the designer, who works out all the nuances of the interface and user scripts. At this stage, absolutely any graphic package can be used, for example, Adobe, Microsoft Expression, etc. After testing the prototype for focus groups and approving it by all departments, a technical task and specification for each screen and script is created. It should clearly indicate all the necessary indents, sizes, colors, styles, fonts, etc. In general, very serious attention is given to the technical task for the designer in our studio, and a whole separate article can be devoted to this.
As soon as the technical task gets to the developer, he starts writing the functional code, but when it comes to directly programming the visual part of the interface, he only arranges all the necessary interface elements on the screen without design, styles and exact dimensions. The application works, is 100% compliant with the technical specification, but visually it is different and does not match the design. That is, at this stage, the developer does not spend time at all to polish the interface to arrange all the necessary styles, indents, etc. After that, the code goes to the integration department, where the application takes on the look that was intended by the designer .
8. Batman and Robin - Developer and Integrator
The first and most necessary condition for the Integration of Design is a unified development environment and debugging interface. Programmers and integrators work in exactly the same environment, use exactly the same development tools and the same code repository. Let's look at the analogy of the relationship between Batman and Robin. Imagine that Batman is responsible for the design, and Robin is responsible for the design, he perfectly knows and understands the design language, knows all the available styles that are in the libraries, knows all the fonts that are used in the design and has access to the effects libraries for the animation. Robin is a person who knows everything about how to properly design a page and at the same time he understands how the architecture of the application works and he perfectly knows and reads the markup language (XAML, HTML, XML, etc.). In other words, it works like the most ordinary programmer, but it does not write functional code, but it works in the same functional environment, the development environment.
If we look at the functional responsibilities of Batman as a developer and Robin as an integrator of design, it is clear that Batman is responsible for the functionality. He writes models, services, modules, controls, etc., connects the API. Everything related to the interface: Batman only arranges the grid, interface elements without styles, and temporary files for icons, so-called stubs.
While Robin, being an integrator of design, works on indents, he sets the coordinates, the position of objects, touch charts, styles, colors and substitutes the final files for photos or icons. Batman puts stubs for animation. If the animation is thought out by the designer, he simply says that there will be animation in this place. While Robin has put the right delay, the right transitions, etc. In fact, Batman leaves him just a stub, which then will change Robin. Everything related to the text, Batman is responsible for the final content, he connects all the strings, all the localization, but is not at all worried about the styles, the design. This is what Robin does. It sets styles, fonts, sizes and colors for all text elements in the application.
9. Code separation
The next important detail for Design Integration is code separation. It is necessary to build the application in such a way that the functional part of the code is separated from the interface markup and styles. In this way, we provide the opportunity for people working in functional code to make changes with minimal risk so that the interface does not change. At the same time, design integrators work only in the markup code. They change styles, they change the design, while they are less likely to change the functional part of the code.
===
To be continued…
about the author
Evgeny Gavrilov (Microsoft, Windows Phone Design Team). - Born and studied in Rostov-on-Don. He worked as a programmer in large companies in the city. In the early 2000s, he moved to permanent residence in the United States and continued his studies in the field of interactive design. Working in various companies, I have come a long way from a designer to an art director. In early 2009, he came to work in the design studio Microsoft Windows Phone. It was a very interesting and exciting work, because at that time the studio was actively developing the Metro interface for the future of the phone. To date, I am the leading designer of the integration department in Windows Phone.
Source: https://habr.com/ru/post/170719/
All Articles