Microsoft — мировой лидер в области ПО и ИТ-услуг
185,27
рейтинг
26 февраля 2013 в 10:26

Разработка → Интеграция дизайна. Каждый пиксель имеет значение. Часть 1

Как и обещали, начинаем публиковать статьи по следам Design Camp. Начнем со статьи Евгения Гаврилова из команды интеграции дизайна Windows Phone.

1. Детали и их важность


Сегодня технологии дизайна и разработки современных интерфейсов развиваются стремительно быстро. Ни для кого не секрет, что стандартом де-факто уже является наличие мобильной версии десктопного приложения или его веб-версии для портативного устройства с малым экраном. Сегодняшние пользователи требуют от приложений все больше и больше, и поэтому дизайнеры вкладывают в дизайн приложений и в разработку приложений множество интересных идей и креативных подходов для того, чтобы сделать интерфейс простым, понятным, интуитивным и человечным.



Давайте посмотрим на этот часовой механизм и обратим внимание на самые маленькие детали. Из какого материала они сделаны, какого они цвета, где расположены, какого они размера? Все это, безусловно, играет огромное значение для того, как будет в целом работать часовой механизм. Если какая-то делать будет отсутствовать по непонятной нам причине, или иметь неправильный размер, положение, а возможно и цвет, то часы будут идти неправильно, и конечный пользователь просто не будет ими пользоваться. Этот же принцип применим и к любым программным и интерфейсам. Сегодня можно с уверенностью сказать, что точная реализация всех деталей, цветовых решений, позиций элементов – это самая главная задача при реализации продуктов.


2. Звук – душа мотоцикла


Недавно я прочитал книгу о компании Harley Davidson. Легендарная компания, которая объединила вокруг себя миллионы людей. Мы больше всего знаем их как «байкеров» — людей, которые создали целую философию жизни, культуру, сленг, стиль. Через всю история Harley Davidson проходит один очень интересный момент. Это уникальный звук мотоцикла, который присущ только моделям этой фирмы. Двигатели этих мотоциклов устроены очень интересным образом: только они производят такой звук. В Америке его называют “potato – potato – potato”. Звук поистине необычный и завораживающий. В добавок к вибрации двигателя, все это создает некий шарм и мистический культовый образ мотоциклов Harley.



Звук – это именно та деталь, на которую я хочу обратить внимание. Каждая фабрика Harley Davidson имеет отдел, который занимается тюнингом звука мотоциклов. В нем работают инженеры, которые регулируют определенные зазоры, размеры, отступы, для того чтобы звук у мотоцикла был именно такой, каким его задумали и именно таким, каким его полюбили пользователи.

Когда у владельца Harley Davidson спрашивают: «Что для тебя этот значит звук Harley?», то, наверное, 9 из 10 скажут, что звук мотоцикла – это его душа, или то, без чего мотоцикл не сможет быть настоящим Harley. Эта маленькая деталь для них имеет огромное значение, несмотря на то, что это не какая-то техническая характеристика, не какие-то элементы дизайна. Это звук, который они любят и обожают.

3. Продукт и его реализация


Давайте посмотрим на то, как сегодня создаются продукты с пользовательским интерфейсом.

Все выглядит идеально, замечательно, великолепные формы, нам как дизайнерам это все нравится. Но мы, в определенный момент понимаем, что это только пока что на бумаге. Наступает момент, когда мы начинаем думать о том, как же этот продукт реализовать, что нужно для этого сделать.

В этот момент наступает знакомство с волшебным миром разработчиков. Первый закон, который мы усваиваем, это то, что любой дизайн должен иметь техническое задание и спецификацию. Это не секрет, что процесс создания технических заданий очень трудоемкий и нудный, в нем нет ничего интересного, ничего творческого, дизайнеры его попросту ненавидят. При этом, большинство дизайнеров не понимают, в чем важность этого процесса и насколько этот процесс может помочь в будущем при реализации продукта.

Но мы с вами очень добросовестные дизайнеры. Мы описали все размеры, поставили все спецификации, все радиусы, все цвета. Все определено и все на своем месте.

Даже более того, мы переносим этот дизайн в PhotoShop или любой другой удобный формат, раскладываем все слои по полочкам, нумеруем и именуем их. Другими словами создаем рай для разработчика. Он откроет макет и испытает восторг и радость от того, что дизайнер выполнил качественно свою работу.

Затем макет попадает к верстальщику или к фронт-энд разработчику, который создаст ститический код без функциональности, который будет полностью соответствует нашему дизайну. На этом этапе работы, в основном, все дизайнеры остаются счастливыми и удовлетворенными. Они видят верстку макета, и думают: «Ну, все, осталось совсем немного, совсем чуть-чуть». Тем более, руководитель проекта уверяет, что сейчас мы наймем самых лучших разработчиков, они подключат современные фреймворки, добавят сервисы, модули, и все будет работать просто великолепно.

Через несколько недель момент запуска продукта, и мы, мягко сказать, в недоумении, разочарованы: «Как же так? Почему дизайн так выглядит?» На что менеджер проекта вас уверяет: «Вы знаете, функциональность полностью соответствует техническому заданию, все работает. Всего-то мы откроем несколько задач, исправим дизайн, наймем пару программистов, и они все исправят».

Проходит еще какое-то время, наш продукт становится похожим на то, что мы сделали, но не совсем. Возникают вполне логичные вопросы: «Кто в ответе за качество реализации?» или «Почему реализованный продукт, не совпадает с дизайном?», «Какие детали важны при реализации продукта, а какие нет?», «Какие детали можно опустить?»

Кто ставит последнее слово в дизайне, который увидит наш конечный пользователь? Как часто вы задавали этот вопрос себе или кому-то, кто отвечает за разработку. Почему некоторые разработчики не видят разницы? Почему для них некоторые детали не важны, а какие-то детали важны больше, чем другие?

4. Почему реализованный продукт не соответствует дизайну?


Как часто вы слышали в свой адрес вопрос: «Собственно, какая разница, что шрифт на 2 пикселя меньше? Что мы будем сейчас открывать для этого новую задачу и исправлять шрифты и т. д.?» Как часто вы слышали такой вопрос: «Какая разница: серый цвет 30% или 40%? Давайте уже оставим 30%». Или «Анимацию для кнопки подключать? У нас нет на это времени. Давайте отложим до следующей версии».

Чтобы ответить на вопросы:
— Почему одни люди уделяют внимание деталям, а другие люди нет?
— Почему для кого-то важен правильный цвет элемента, а для кого-то нет?
— Почему дизайн важен больше чем его техническая реализация?
я предлагаю посмотреть на устройство нашего сложного мозга.



Не секрет, что левое полушарие мозга отвечает за логику, анализ фактов, числа, алгоритмы. В то время как правое полушарие мозга отвечает за визуальные образы, воспринимает анимацию, музыку, дизайн. Все наши идеи, мечты – исходят из правой части мозга.

И что самое интересное, люди технического склада ума — инженеры, конструкторы, программисты, разработчики − все имеют более развитое левое полушарие. Когда они работают, они в основном используют все свойства левого полушария. В то время как художники, музыканты, дизайнеры, мечтатели и все люди, которые рисуют, пишут стихи, создают креативные используют больше всего именно правое полушарие.

Например, инженер разработчик и дизайнер, работая над одним проектом могут попросту разговаривать на непонятном друг другу языке. И в тот момент, когда для дизайнера совершенно не важно отличие класса от объекта или особенности рекурсивной функции, то для программиста совершенно не важна толщина рамки на кнопке или наличие анимации при наведении на объект.

В этом всем нет ничего личного. Это устройство нашего мозга, видеть и акцентировать внимание на определенных деталях, и совершенно игнорировать, не понимать или не придавать значение чему то другому.

5. Потерянное звено


Что происходит в финальной фазе разработки продукта, так сказать в финальной его стадии, на финишной прямой? Дизайнеры подготовили техническое задание для всего интерфейса и с удовольствием отдают его разработчиками. В то время разработчики, не смыкая глаз, начинают работать над реализацией интерфейса. В большинстве случаем, эти две дисциплины далее никак не пересекаются в процессе разработки.



Как обеспечить постоянную связь между дизайнерами и разработчиками (речь не идет о способах коммуникации между отделами)? Где найти недостающее звено? Мост, который соединяет эти две дисциплины? Переводчика или интерпретатора между разработчиками и дизайнерами?

6. Мыслить как дизайнер, работать как программист


«Мыслить как дизайнер, работать как программист». Эти слова я написал в своем резюме, когда пришел на интервью в компанию Microsoft. Еще я распечатал вот такой плакат.



На интервью я рассказал о себе, что я имею два образования: одно в области IT, другое – в области интерактивного дизайна, и последние 6 лет я занимался разработкой интерфейсов и дизайном веб-приложений для мобильных платформ. Так же я с уверенностью говорил, что понимаю нюансы дизайна, вижу детали и могу разговаривать на языке дизайна, но, в то же время, знаю технологии и понимаю, как задуманный дизайн реализовать в коде. Человек, проводивший интервью, был очень удивлен, но в то же время заинтригован, он вышел из комнаты и вернулся через некоторое время со своим коллегой. Это был один из ведущих разработчиков интерфейса Windows Phone. Мы продолжили интервью втроем, после чего мне предложили позицию в совершенно новом отделе интеграции дизайна для Windows Phone (Windows Phone Design Integration).

Интегратор дизайна мыслит как дизайнер, работает как программист. Хочу отметить, что интегратор дизайна не создает дизайн и не пишет функциональный код. Это два основных принципа, которые нужно запомнить.

Так кто же он такой, Интегратор Дизайна? Что он делает? Как работает?

Я постараюсь ответить на эти вопросы, но для начала давайте посмотрим на процесс разработки интерфейса Windows Phone.

7. Дизайн и разработка интерфейса Windows Phone



Все начинается с концептуальной идеи и вайрфрейма. Он может быть создан на доске, листке бумаги, салфетке или в любой графической программе. Затем этот вайрфрейм передается дизайнеру, который прорабатывает все нюансы интерфейса и сценарии пользователя. На этом этапе может использоваться совершенно любой графический пакет, например Adobe, Microsoft Expression и т. д. После тестирования прототипа на фокус группах и утверждения его всеми отделами, создается техническое задание и спецификация для каждого экрана и сценария. В нем четко должны быть указаны все необходимые отступы, размеры, цвета, стили, шрифты и т. д. Вообще техническому заданию для дизайнера в нашей студии отводится очень серьезное внимание, и этому может быть посвящена целая отдельная статья.

Как только техническое задание попадает к разработчику, он приступает к написанию функционального кода, но когда дело доходит до непосредственно программирования визуальной части интерфейса, он только расставляет все необходимые элементы интерфейса на экране без оформления, стилей и точных размеров. Приложение работает, на 100% соответствует техническому заданию, но визуально оно отличается и не соответствует дизайну. То есть, на этом этапе разработчик совершенно не тратит время на то, чтобы полировать интерфейс на то, чтобы расставлять все необходимые стили, отступы и т. д. После этого код попадает в отдел интеграции, где приложение принимает тот вид, который был задуман дизайнером.

8. Бэтмен и Робин — Разработчик и Интегратор



Первое и самое необходимое условие для Интеграции Дизайна – это единая среда разработки и отладки интерфейса. Программисты и интеграторы работают в совершенно одинаковой среде, используют совершенно одинаковые средства разработки и одинаковый репозиторий кода. Давайте посмотрим на аналогию взаимоотношений Бэтмена и Робина. Представим, что Бэтмен отвечает за разработку, а Робин отвечает за оформление, в совершенстве знает и понимает язык дизайна, знает все доступные стили, которые есть в библиотеках, знает все шрифты, которые используются в дизайне и имеет доступ к библиотекам эффектов для анимации. Робин – это человек, который знает все о том, как правильно оформить страницу и при этом он понимает, как устроена архитектура приложения и он великолепно знает и читает маркап язык (XAML, HTML, XML, etc.). Другими словами, он работает, как самый обычный программист, но при этом не пишет функциональный код, но работает в той же функциональной среде, среде разработки.


Если мы посмотрим на функциональные обязанности Бэтмена как разработчика и Робина как интегратора дизайна, то понятно, что за функциональность отвечает Бэтмен. Он пишет модели, сервисы, модули, контролы и т. д., подключает API. Всё, что касается интерфейса: Бэтмен только расставляет сетку, элементы интерфейса без стилей и временные файлы для иконок, так называемые заглушки.

В то время как Робин, будучи интегратором дизайна, работает над отступами, расставляет координаты, положение объектов, тачтаргеты, стили, цвета и подставляет финальные файлы для фотографий или иконок. Бэтмен ставит заглушки для анимации. Если анимация продумана дизайнером, он просто говорит, что в этом месте будет анимация. В то время как Робин уже поставит правильную задержку, правильные переходы и т. д. Фактически Бэтмен ему оставляет просто заглушку, которую потом изменит Робин. Всё, что касается текста, Бэтмен отвечает за финальный контент, он подключает все стринги, всю локализацию, но совершенно не переживает за стили, за оформление. Этим занимается Робин. Он ставит стили, шрифты, размеры и цвета для всех текстовых элементов в приложении.

9. Разделение кода



Следующая важная деталь для Интеграции Дизайна – это разделение кода. Необходимо построить приложение таким образом, чтобы функциональная часть кода была разделена от маркап интерфейса и стилей. Таким образом мы обеспечиваем возможность людям, работающим в функциональном коде, с минимальным риском делать изменения для того, чтобы не изменился интерфейс. В то же время интеграторы дизайна работают только в коде маркап. Они изменяют стили, они меняют оформление, при этом у них меньше шансов изменить функциональную часть кода.

===
Продолжение следует…

Об авторе


Евгений Гаврилов (Microsoft, Windows Phone Design Team). − Родился и учился в Ростове-на-Дону. Работал программистом в крупных компаниях города. В начале 2000-х переехал на постоянное место жительство в США и продолжил обучение в сфере интерактивного дизайна. Работая в различных компаниях, прошел длинный путь от дизайнера до арт-директора. В начале 2009 года пришел работать в дизайн студию Microsoft Windows Phone. Это было очень интересная и захватывающая работа, потому как именно в то время студия активно разрабатывала Метро интерфейс для будущего телефона. На сегодняшний день, я являюсь ведущим дизайнером отдела интеграции в Windows Phone.
Автор: @kichik
Microsoft
рейтинг 185,27
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (21)

  • +2
    «Летающий асфальтоукладчик» — вот основная проблема дизайна.
  • +2
    захотелось услышать “potato – potato – potato”
    • +2
      Кажется, примерно вот так:
      • 0
        Я когда голодный издаю почти такие же звуки как Харли Девидсон
      • 0
        Топот копыт!
  • 0
    это хорошо работает когда все в одной команде, желательно в одном комнате и под замком, чтоб дизайнер увидев что творит верстальщик надавал ему по черепу

    большинство фирм работает по принципу фриланса, наняли дизайнера он нарисовал, далее отдали верстальщику, который понятия не имеет что задумал первый. вот тут и начинаются разногласия
    • 0
      В этом и состоит ошибка: нельзя подружить дизайнера и программиста. Нужен третий человек, которого в статье назвали «Интегратор».
      • 0
        Технология WPF делает это элементарно. Программист вообще не трогает то, что сделал дизайнер в XAML, он только связывает свой код с ID-именами, присвоенными контролам.
        Я дизайню визуалы WPF-приложений и у меня вообще не бывает конфликтов с программистами. Они понятия не имеют об отступах и координатах, всё закладывается мной в XAML-библиотеки и отражается на экране с точностью до пикселя.

        Этим работа дизайнера в WPF принципиально отличается от работы веб-дизайнера. По статье может сложиться впечатление, что XAML непостижим для дизайнерского ума и требует усилия специального человека. Это не так.
        По-моему, в данном случае просто показана специфика работы в Майкрософт: компания старается унифицировать процесс для разных софтверных платформ.
        Если дизайнить без оглядки на веб-технологии (например, большие приложения), то многое меняется.
        • 0
          Все, что вы говорите, правильно и работает в идеальной среде, когда XAML маркап создает технически граммотный дизайнер, которые знает все об устройстве и архитектуре приложения, и это действительно подходит для небольших проектов (5 разработчиков и 1 дизайнер), но в случае с Windows Phone это было просто невозможно. Маркап создают разработчики, число который измеряется тысячами, и от этого никак не изменить.

          Я надеюсь, вторая часть статьи будет скоро опубликована, потому как там я объясняю одну из основных задач интеграторов — это стандартизация интерфейса и я раскрываю эту тему более глубже.
          • 0
            Это очень интресно! У нас проекты большие, но все равно это — оболочки. Давно хотел почитать, как идет работа над операционными системами и подобными вещами.
  • +1
    Интересно, ваши коллеги дизайнеры знакомы с трудами Эдварда Тафти?
    А то с плотностью информации в плиточном интерфейсе пичалька.
  • 0
    «статистический» код, м? 8)
    • 0
      опечатка. Читать следует — статический код.
      • 0
        Поправил :)
  • 0
    Хорошая статья. В работе столкнулись с похожей проблемой и, возможно, обозначенный в статье подход пригодится для ее решения
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А как связаны Константин Кичинский и Евгений Гаврилов, и про кого именно местоимение «я» в последнем предложении?
    • +2
      Я (Евгений Гаврилов) — автор статьи, на самом деле, это стенография моей презентации, с которой я выступал на DesignCamp, а Константин Кичинский великодушно согласился опубликовать ее на хабре.

      Приношу извинения за опечатки.
      • 0
        Меня, честно говоря, статья слегка шокировала.

        Я — дизайнер визуалов для больших WPF-приложений, (т.е., вся графика — моя, 100% custom, ничего из дефолтных тем).
        — В своей работе не пользуюсь ничем, кроме Expression Blend / VS. Уровень функциональности графических инструментов Expression Blend абсолютно такой же, как и у Expression Design, причем в Blend я сразу применяю нужные панели, и девелоперам в большинстве случаев не нужно ничего придумывать.
        — Иконки тоже все рисую в Blend и конвертирую в ресурсы. Программы Adobe не нужны вообще, за ислючением редких случаев, вроде рисования шестеренки (использую векторы, импортированные из Fireworks).
        — Все стандартные контролы делаю сам.
        — Структуру библиотек с XAML-ресурсами создаю сам, конвенции нейминга ресурсов тоже мои. Иначе просто невозможно держать в голове «что, где и как» и следить, чтобы от спринта к спринту не разваливалась айдентика.
        — Да, интегратор есть. Он занимается кастомными контролами со сложными дата-темплейтами, пишет расширения, сделал reference application, частично заменяющую Style- и UX Guides.
        — О том, чтобы кодеры, кроме логики, вставляли C# элементы визуализации, и речи не идет. Им вообще запрещено это делать, если я не прошу.

        Мне казалось, что мы работаем по той схеме, которая была задумана MS. Возможно, для мобильных приложений, которые мы еще не делали, лучше другие методики. Буду, как говорится, следить за рекламой…
        • 0
          Таких специалистов, как вы — очень мало.
          Я тоже делаю 100% кастомные интерфейсы WPF/Metro, но со мной в паре работают дизайнеры, тк мы делаем интерфейсы на заказ, невозможно пропустить этап создания дизайна в PSD т.к. если сразу делать XAML — дорого на итерациях.
          Да и в своих проектах — сначала рисуем — потом XAML, тк картинку править всегда проще, да и потом код красивее.
          А еще у нас есть программисты, которые вообще не вникают в то, что я делаю с дизайнерами.
          Т.е. я как раз интегратор дизайна в своей команде.

          Я пробовал подружить дизайнеров своих с Expression Blend — это не возможно, дизайнеры думают одним полушарием, а как верно указано в статье — нужно двумя. Программистов, кстати — тоже пробовал, и тоже — невозможно, тк тут другая беда, но с противоположным полушарием — они просто перерисовывают с картинки дизайнера, не задумываясь о том как этот интерфейс будет работать, а зачастую очень часто требуется внести изменения для стандартизации интерфейса упрощения XAML кода, или просто потому что дизайнер не предусмотрел какой-то модели поведения.

          То, что нам с вами кажется элементарным (и вы и я можем работать в бленде что-то придумывать сразу там даже, видим XAML код стилей и компоновки, лишь взглянув на дизайн окна, видим сходу косяки вида: 'это прокрутка нарисована неверно, ScrollBar так работать не может" и можем сами же эти косяки поправить) для всех остальных — непостижимая магия, дизайнеры не понимают структуру и логику приложения, программисты не видят разницы в скруглении угла 4 или 5px

          Те все же схема работы описанная в статье, на мой взгляд, самая верная.
          • 0
            По-моему, хороший интегратор — зверь еще более редкий.
            Мой, к сожалению, оказался слишком хорошим — его перевели в архитекторы, а мне в помощь отрядили бакэндера, которому еще только предстоит разобраться в XAML.

            Я думаю, что каждый веб-дизайнер, владеющий HTML и CSS, может так же нормально работать с XAML. Просто в WPF выше порог вхождения, это нужно знать изначально.
            Думаю, это — потенциальная тема для дискуссии. Хорошо, хоть есть с кем обсудить :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка