Design integration. Each pixel matters. Part 1

Published on February 26, 2013

Design integration. Each pixel matters. Part 1

    As promised, we are starting to publish articles in the wake of Design Camp . Let's start with an article by Evgeny Gavrilov from the Windows Phone Design Integration Team.

    1. Details and their importance


    Today, design and development technologies for modern interfaces are developing rapidly. It's no secret that the de facto standard is 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 demand more and more from applications, and therefore, designers are investing a lot of interesting ideas and creative approaches in application design and application development to make the interface simple, intuitive, 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 in how the clockwork as a whole will work. If something to do will be absent for an incomprehensible reason, or have the wrong size, position, and possibly color, then the clock will go wrong and the end user will simply not use it. The same principle applies to any software and interfaces. Today we can say with confidence that the exact implementation of all the details, color schemes, positions of elements 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. The legendary company that brought together millions of people around itself. Most of all we know them as “bikers” - people who have created a whole philosophy of life, culture, slang, style. Throughout the history of Harley Davidson, one very interesting moment passes. This is a unique motorcycle sound, which is inherent only to the 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 bewitching. In addition to engine vibration, all this creates a certain charm and mystical cult image of Harley motorcycles.



    Sound is exactly the part that I want to pay attention to. Each Harley Davidson factory has a department that tunes motorcycle sounds. It employs engineers who regulate certain gaps, sizes, indents, so that the motorcycle sound is exactly the way it was conceived and exactly the way users like it.

    When the owner of Harley Davidson is asked: “What does 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 a motorcycle cannot be a real Harley. This small detail is of great importance to them, despite the fact that this is not some technical characteristic, not some design elements. This is the sound they love and adore.

    3. Product and its implementation


    Let's look at how products with a user interface are created today.

    Everything looks perfect, wonderful, great forms, as designers we all like it. But we, at some point, understand that this is only so far on paper. There comes a time when we begin to think about how to implement this product, what needs to be done for this.

    At this moment, you get acquainted with the magical world of developers. The first law that we adopt is that any design must have a technical specification and specification. It is no secret that the process of creating technical specifications is very laborious and tedious, there is nothing interesting, nothing creative, designers simply hate it. However, most designers do not understand what is the importance of this process and how much this process can help in the future when implementing the product.

    But we are very conscientious designers. We described all sizes, set all specifications, all radii, all colors. Everything is defined and everything is in place.

    Even more, we transfer this design to PhotoShop or any other convenient format, lay out all the layers on shelves, number them and name them. In other words, we create a paradise for the developer. He will open the layout and experience the delight and joy of the fact that the designer performed his work qualitatively.

    Then the layout gets to the layout designer or front-end developer who will create a static code without functionality that will be fully consistent with our design. At this stage of the work, basically, all designers remain happy and satisfied. They see the layout of the layout, and they think: "Well, that's all, there is very little left, 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 the product was launched, and we, to put it mildly, at a loss, are disappointed: “How so? Why does the design look like this? ”To which the project manager assures you:“ You know, the functionality is fully consistent with the technical task, everything works. All in all, we will open several tasks, fix the design, hire a couple of programmers, and they will fix everything. ”

    Some more 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 the implementation?” Or “Why does the implemented product not match the design?”, “What details are important when implementing the product, and which are not?”, “What details can be omitted?”

    Who puts the last word in the design that our end user will see? How often did you ask this question to yourself or to someone who is responsible for the development. Why don't some developers see the difference? Why for them some details are not important, and some details are more important than others?

    4. Why does the product sold not match the design?


    How often have you heard the question in your address: “Actually, what's the difference that the font is 2 pixels smaller? What are we going to open a new task for this and correct fonts, etc.? ”How often have you heard this question:“ What is the difference: gray color 30% or 40%? Let's leave 30%. ” Or "Connect button animation? We don’t have time for this. Let's put it off until the next version. "

    To answer the questions:
    - Why do some people pay attention to details, while others do not?
    - Why is the correct color of an element important for someone, but not for someone?
    - Why is design more important than its technical implementation?
    I suggest looking at the structure of our complex brain.



    It is no secret that the left hemisphere of the brain is responsible for logic, analysis of facts, numbers, algorithms. While the right hemisphere of the brain is responsible for visual images, it perceives animation, music, design. All our ideas, dreams - come from the right side of the brain.

    And most interestingly, people of a technical mindset - engineers, designers, programmers, developers - all have a more developed left hemisphere. When they work, they mainly use all the properties of the left hemisphere. While artists, musicians, designers, dreamers and all the people who draw, write poetry, create creative, they use the right hemisphere most of all.

    For example, a developer engineer and designer, working on the same project, can simply speak a language incomprehensible to each other. And at that moment, when the designer does not care about the difference between the class and the object or the features of the recursive function, the thickness of the frame on the button or the presence of animation when hovering over the object is completely not important for the programmer.

    There is nothing personal to everyone. It is the device of our brain to see and focus on certain details, and completely ignore, do not understand or attach importance to something else.

    5. The Lost Link


    What happens in the final phase of product development, so to speak in its final stage, on the finish line? Designers have prepared the terms of reference for the entire interface and are happy to give it to the developers. At that time, developers, not closing their eyes, begin to work on the implementation of the interface. In most cases, these two disciplines do not further intersect in the development process.



    How to ensure a constant connection between designers and developers (we are not talking about ways of communication between departments)? Where to find the missing link? The bridge that connects the two disciplines? Translator or interpreter between developers and designers?

    6. Thinking as a designer, working as a programmer


    “Thinking as a designer, working as a programmer.” I wrote these words in my resume when I came to an interview with Microsoft. I also printed such a poster.



    In an interview, I told about myself that I have two degrees: one in the field of IT, the other in the field of interactive design, and for the last 6 years I have been developing interfaces and designing web applications for mobile platforms. I also said with confidence that I understand the nuances of design, I see the details and can speak the design language, but, at the same time, I know the technology and understand how to implement the design in code. The person conducting the interview was very surprised, but at the same time intrigued, he left the room and returned after a while with his colleague. This was one of the leading developers of the Windows Phone interface. The three of us continued the interview, after which I was offered a position in a completely new design integration department for Windows Phone (Windows Phone Design Integration).

    A 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 functional code. These are two basic principles to remember.

    So who is he, Integrator of Design? 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 Windows Phone interface.

    7. Design and development of the interface of Windows Phone



    It all starts with a conceptual idea and a wireframe. It can be created on a blackboard, piece of paper, napkin, or in any graphics program. Then this wireframe is passed 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 scenario are created. It should clearly indicate all the necessary indents, sizes, colors, styles, fonts, etc. In general, the technical task for the designer in our studio is given very serious attention, and this can be devoted to a whole separate article.

    As soon as the technical task reaches the developer, he starts writing 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 sizes. The application works, 100% meets the technical specifications, but visually it is different and does not match the design. That is, at this stage, the developer does not waste time polishing the interface to arrange all the necessary styles, indents, etc. After that, the code gets into the integration department, where the application takes on the look that was conceived by the designer .

    8. Batman and Robin - Developer and Integrator



    The first and most necessary condition for Design Integration is a unified interface development and debugging environment. Programmers and integrators work in exactly the same environment, using exactly the same development tools and the same code repository. Let's look at the Batman-Robin relationship analogy. Imagine that Batman is responsible for the development, and Robin is responsible for the design, knows and understands the design language, knows all the styles available in the libraries, knows all the fonts that are used in the design and has access to the effect libraries for 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 is arranged and he knows and reads markup language perfectly (XAML, HTML, XML, etc.). In other words, it works,


    If we look at the functional responsibilities of Batman as a developer and Robin as a design integrator, then it is clear that Batman is responsible for the functionality. He writes models, services, modules, controls, etc., connects the API. Everything about the interface: Batman only arranges the grid, interface elements without styles and temporary files for icons, the so-called stubs.

    While Robin, as an integrator of design, works on indentation, arranges coordinates, position of objects, touch targets, styles, colors and substitutes final files for photos or icons. Batman puts stubs for the animation. If the animation is thought out by the designer, he simply says that there will be animation in this place. While Robin will already set the correct delay, the correct transitions, etc. In fact, Batman leaves him just a stub, which Robin will then change. Everything regarding the text, Batman is responsible for the final content, he connects all the thongs, all the localization, but does not worry at all about the styles, the design. This is what Robin does. It puts 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 markup interface and styles. Thus, we provide an opportunity for people working in functional code with minimal risk to make changes so that the interface does not change. At the same time, design integrators work only in markup code. They change styles, they change appearance, and 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 of the city. In the early 2000s he moved to a permanent residence in the United States and continued his studies in the field of interactive design. Working in various companies, he has 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 it was at that time that the studio was actively developing the Metro interface for the future phone. Today, I am a leading designer of the integration department in Windows Phone.