Как передать макет верстальщику из фигмы
Перейти к содержимому

Как передать макет верстальщику из фигмы

  • автор:

Как передавать макеты в разработку?

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

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

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

Таким образом, я рекомендую использовать для работы приложения хранящие макеты в облаке и поддерживающие возможность кооперативного редактирования макетов в реальном времени. Figma будет отличным выбором.

Для работы в редакторе достаточно создать аккаунт на сайте Фигмы. После регистрации редактор откроется прямо в браузере. Также, для большего удобства можно скачать на сайте десктопную версию приложения.

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

1. Используйте базовую единицу и модульные системы для построения макетов

При построении системы отступов и сеток в макете стоит выбрать значение которому будут кратны настройки сеток и отступов. Если в качестве базовой единицы выбрать значение равное четырем — все отступы и размеры объектов в макете должны делиться без остатка на это значение. Отступы могут быть представлены значениями 4, 8, 12, 16 и т.д., а высота кнопок, к примеру, значениями 32, 40, 44, 48, 52 и т.д.

Значения отступов и размеров элементов кратны четырем. Отступ между колонками сетки кратен четырем.

При построении сеток учитывайте, что бывает как минимум три типа устройств десктоп, планшет и мобилка. При построении сетки отталкивайтесь от минимальных размеров экранов, чтобы все помещалось. Например, для мобилки стоит отталкиваться от экрана 320рх, планшет — 768рх, десктоп — 1024рх. Макет может рисоваться под любой размер экрана, главное чтобы на указанных разрешениях он выглядел также корректно, как и на более крупных.

2. Используйте целые значения размеров элементов и отступов

Благодаря целым значениям макет будет аккуратнее, его рендер на экране также будет более качественным. При условной отрисовке обводки в 1,5px будет возникать размытие этой обводки на экранах с низкой плотностью точек. В случае с разношёрстными отступами да ещё и с дробными значениями разработчикам придется гадать какой отступ должен быть между однотипными элементами 32.7, 32.6 или все же 32px.

На скриншотах одинаковые целые отступы.

Для работы с целыми пикселями необходимо включить функцию Snap to Pixel Grid в меню Preferences.

Чтобы быстро избавиться от дробных значений в размерах, можно нажать на подпись слева от значений.

Стрелки указывают на символы «W» и «H».

Также для пакетного устранения дробных значений отлично подходит плагин Pixel Perfect.

Запустить плагин можно через панель плагинов.

После чего нужно нажать кнопку «Run» и плагин, как по щучьему велению, уберет все дробные значения в выбранных фреймах.

На скриншоте дробные значения устранены, однако стоит учесть, что плагин округляет дробные значения по правилам арифметики — значение до 0,5 в меньшую сторону, значения после 0,5 в большую.

3. Выстраивайте логичную систему отступов

В одинаковых элементах стоит использовать одинаковые отступы, между логическими блоками стоит использовать одинаковые отступы — так проще верстать макеты.

Между единообразными блоками одинаковые отступы.

Для ускорения процесса расстановки одинаковых отступов можно воспользоваться опцией Фигмы — Auto layout. Эта опция группирует объекты в фрейм с равномерными отступами.

Для создания Auto layout необходимо выбрать фреймы, между которыми будут расставляться отступы, после чего следует нажать на клавиатуре комбинацию клавиш «Shift+A» либо нажать соответствующую кнопку на панели настроек.

Необходимая кнопка показана на скрине.

После созданий лейаута можно будет настроить размер отступов введя необходимое значение в соответствующее поле.

На скрине обозначено поле для ввода размера отступов.

Подробнее о том как работать с Авто лейаутами можно прочитать в официальном руководстве Фигмы.

4. Сохраняйте настройки текста, цвета и эффектов в стили

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

Сохраненные стили добавляются в панель стилей, она находится в правой части окна Фигмы.

Подробнее о том, как сохранять стили описано в мануале Фигмы.

5. Подписывайте слои и стили понятными именами

Для организации порядка в макетах подписывайте понятными названиями слои и стили в макетах. Это позволит говорить всем членам команды на одном языке. Также хорошей практикой является расположение стилей и слоев в логичной последовательности.

Пример подписей слоев и стилей.

Слои (фреймы, компоненты) принято располагать в хронологической последовательности, стили текста от более крупного к менее крупному, цвета от менее насыщенных к более насыщенным.

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

6. Создавайте Ui-kit

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

Как работать с компонентами просто и понятно проиллюстрировано в туториале Фигмы.

7. Задавайте корректные размеры текстовых фреймов

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

На скринах показано, что заголовки имеют разную длину.

8. Оставляйте комментарии

Комментируйте свои решения с использованием инструмента Add comment, вызывается кнопкой «С», либо через настройки компонента. Комментирование компонента доступно на панели настроек (находится справа).

Примеры способов комментирования.

Если комментарий к компоненту добавить через правую панель — комментарий будет отображаться в инспекторе кода, в любой части макета.

Комментарий отображается на одной из страниц макета.

9. Показывайте анимацию с помощью прототипов

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

10. Передавайте разработчикам шрифты и иконки

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

11. Проводите презентации и обсуждайте решения

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

Если среди читателей присутствуют разработчики — буду благодарен за комментарии и дополнения к этому гайду.)

Как передать макет из Figma разработчикам

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

Иллюстрация: Merry Mary для Skillbox Media

Редакция «Дизайн» Skillbox Media

Редакция «Дизайн» Skillbox Media

Пишем про дизайн и искусство. Всё, что вы хотели знать о настоящем, прошлом и будущем визуальной культуры.

Создание сайта — трудоёмкий процесс, потому что надо не только продумать его логику и разработать стиль, но ещё сверстать и запрограммировать страницу.

Иногда дизайнер рисует хороший макет, а после вёрстки качество заметно падает:

  • появились лишние отступы,
  • пропали элементы,
  • текст выходит за рамки контентной области.

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

Узнайте у разработчиков о технических возможностях

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

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

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

А ещё стоит сразу предупредить разработчиков, в каком формате вы будете передавать файлы.

Никогда не используйте дробные числа

Разработчики делают сайты на CSS и HTML — они считают все изображения и расстояния в пикселях. Пиксель по умолчанию не может быть дробным, поэтому кегль или отступ с размером 27,789 пикселя внедрить очень трудно.

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

Следите за размерами текстовых блоков и модулей

Кажется, что если текстовый блок гораздо больше, чем нужно, то ничего страшного не произойдёт — там же всё равно нет текста. На самом деле для разработчика это знак — ограничители текста должны быть именно такими, потому что дизайнер что-то там придумал. Из-за этого итоговая вёрстка может превратиться в кашу. Поэтому следите, чтобы у текста всегда была включена настройка автоматического выравнивания по высоте .

Ещё одно свойство текста — он может быть бесконечно длинным. Если вы это не учитываете, то готовьтесь, что итоговая вёрстка будет постоянно ломаться.

Также старайтесь делать модули — если они на одном и том же информационном уровне, то они должны быть одинаковыми. А «почти одинаковых» модулей должно быть как можно меньше, чтобы разработчики быстрее и чище превратили ваши картинки в продукт.

Чтобы не перенагружаться с выравниванием всего со всем, используйте Auto Layout. Он автоматически подстроит все модули внутри себя по заданным значениям.

Поддерживайте порядок в документе

То, что у вас во время работы образуются скрытые группы и хаотичные названия, — это нормально. Но человек со стороны в таком документе никогда не разберётся самостоятельно. Поэтому, прежде чем передавать макет разработчикам, наведите в нём порядок:

  • удалите скрытые слои и лишние стили,
  • разблокируйте все слои,
  • дайте всем объектам осмысленные названия.

Чтобы сэкономить на этом время, пользуйтесь плагинами:

Покажите состояния и сценарии

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

Ещё одна важная вещь — связь экранов друг с другом. Чтобы система работала так, как вы задумали, разработчик должен понимать, что будет, если пользователь нажмёт на одну из кнопок внутри экрана. Эту связь можно показать с помощью стрелок:

Состояния элементов интерфейса лучше всего демонстрировать вариативными компонентами. А для указания связей лучше подойдёт плагин Autoflow.

Оставляйте заметки

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

Собирайте библиотеку компонентов

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

Не забывайте, что все состояния элементов можно показать интерактивными компонентами. А ещё хорошо, когда на странице со всеми элементами описаны стили: цвета, шрифты и иконки.

Показывайте анимацию вживую

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

Проведите презентацию

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

Лучше, когда вы проведёте презентацию разработчикам раньше, чем клиенту. Иначе может оказаться так, что вам придётся вносить изменения в утверждённый макет — на это обычно тратят очень много ресурсов.

Больше о Figma
  • Как превратить макет из Figma в рабочий сайт
  • Обновление в Figma: новый Auto Layout, вариативные шрифты, тёмная тема
  • 5 лайфхаков в Figma, которые помогут работать быстрее
  • 5 полезных плагинов в Figma: генераторы паттернов и текстур
  • Как делать варианты элементов интерфейса
  • Как создать тёмную тему
  • Готовые решения в Figma: 10 полезных файлов для дизайнеров

Как передать макет верстальщику из фигмы

Но лучше применять специальные программы, например Принцип. Если работаете в Виндоусе, присмотритесь к аналогу — Протопай.

Прикладывайте к макету шрифты и иконки

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

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

Проведите презентацию

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

Созвонитесь с разработчиками, включите презентацию экрана или расшарьте Фигму и проведите разработчиков по всем макетам. Пусть разработчики зададут вопросы и прокомментируют ваши решения в дизайне.

Дальнейшие изменения в макетах уже после начала разработки необязательно презентовать вживую. Их можно донести в переписке.

P. S. Это был вторничный совет о дизайне интерфейсов. Присылайте вопросы.

От дизайна к фронтенду: как передать макет в разработку

Чтобы все изображения и кнопки были на своих местах, анимации корректно работали, а шрифты на макете совпадали со шрифтами в интерфейсе, разработчику нужно больше, чем доступ к проекту в Figma. Мы в Friflex проектируем интерфейсы для миллионов пользователей, и, работая над проектами, очень внимательно следим, чтобы после программирования дизайн сохранял функциональность и внешний вид. В этой статье Светлана Моторкина, Head of Design, Friflex, опираясь на свой опыт, рассказывает, как подружить дизайнера и фронтендера и передать макет в разработку без потерь.

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

Важно понимать, что после передачи макета работа дизайнера не заканчивается. Он как инженер напрямую связан с разработкой и отвечает за весь проект до его реализации.

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

Шаг 1. Старт проекта

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

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

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

Шаг 2. Работа с макетами

Соблюдение структуры

Для простой и удобной навигации в любом проекте должна быть выстроена понятная структура. Называйте страницы и фреймы осмысленно.
Это позволит коллегам понять логику макета и начать быстрее ориентироваться в структуре.

Используйте Changelog (журнал изменений) – фрейм, который содержит поддерживаемый, упорядоченный в хронологическом порядке список изменений для каждой версии проекта. Так разработчик всегда будет в курсе всех изменений.

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

Описание компонента

При описании каждого из компонентов попробуйте поставить себя на место разработчика, которому предстоит взять макет в работу.

Создавайте док-фрейм для каждого компонента, в котором будет:

  • Описание компонента.

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

  • Стейты (состояния).

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

Лайфхак: ознакомиться с примером описания для компонента «Button» можно на сайте Carbon Design System.

Адаптивность и сетки

Адаптивность

Адаптивность – способность макета подстраиваться под разный формат разрешения экрана. Возьмите за правило отрисовывать несколько вариантов макетов под адаптив для разных устройств. Достаточно три – четыре версии (Например для веб: от 1280 – ∞, 1024, 768, 320).

Не забывайте отрисовывать макеты под минимальный размер, либо всегда проверять или закладывать размер на экранах 320px.

Показывайте отзывчивость с помощью Constraints в Figma, т.е. привязки. Если вы рисуете четыре макета, то для каждого из них обязательно нужно прописывать constraints.

Лайфхак: при отрисовке адаптива нужно учитывать Landscape (горизонтальное положение) состояние. Особенно если использование вашего продукта это предусматривает. Актуально для карт, навигаторов, воспроизведения видео.

Сетка

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

Для мобильных устройств обычно используется 4px или 8px сетка.

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

Для веба используется известная сетка Boostrap.

Существует два вида сетки:

  • Фиксированая сетка – сетка, в которой колонки зафиксированы по ширине.
  • Резиновая сетка – сетка, в которой колонки меняют свою ширину в зависимости от размера устройства.

Лайфхак: добавляйте в стиль созданные колонки/сетки. Чтобы применить колонки к монтажной области, достаточно ее выделить и выбрать на панели «Design» в разделе «Layout Grid» соответствующий разрешению макета стиль. Включить/выключить отображение колонок и сетки: Ctrl + G (для Mac),
Ctrl + Shift + 4» (для Windows).

Карты экранов

Карта экранов показывает весь User Flow, не давая разработчику запутаться в архитектуре продукта. С картой экранов будет понятна логика переходов и взаимодействие с интерфейсом для конкретных кейсов.

Лайфхак: не обязательно рисовать пути вручную, для этого есть множество плагинов. Я использую AutoFlow, ArrowAuto.

Заметки разработчику

Оставляйте заметки разработчику. Такие, как описание действия компонента при нажатии на него. Выберите Master Component, нажмите на иконку настройки и в появившемся окне Documentation (документация) введите текст в поле «How to use this component». Текст отобразится в виде комментария в CCS.

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

Автоматически упорядочивайте и очищайте документ Figma с помощью плагина Clean Document. Он позволяет удалять скрытые слои, разгруппировывать однослойные группы и т.д.

Шаг 3 Передача в разработку

Статус готовности и версионность

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

  • Делить на отдельные пейджи. Разбивайте макеты на вкладки по готовности: готово для разработки / в процессе.
  • Указывать статус в самом макете. Маркируем статусы на каждой группе или на каждом макете.

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

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

Прототипирование

Разработчик не всегда понимает, какой элемент с чем и как должен взаимодействовать в интерфейсе. Для этого нужно прототипирование. Переходы и простые прототипы можно собирать в Figma. Для более сложной анимации вам потребуются дополнительные инструменты: Principle, After Effects и т.д.

Лайфхак: если у вас не хватает навыков сложной анимации, прикрепляйте референсы анимации в виде скринов и ссылок.

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

Графические ассеты и шрифты

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

При использовании нестандартных шрифтов в макете, не забывайте прикладывать архив или давать ссылку на скачивание.

Анализ объема работ и общение с разработчиком

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

Если вы не работайте в Figma, а используете Sketch, можно передавать макеты в Zeplin.

Шаг 4 Дизайн-ревью

На стадии дизайн-ревью задача дизайнера состоит в том, чтобы сверять дизайн- макеты и логику работы.

Фидбек от разработчиков

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

Лайфхак: используете комментарии в Figma как дополнительный инструмент для коммуникации. Участники могут читать, добавлять упоминания и оставлять комментарии к файлу без ограничений.

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

Лайфхак: возьмите скриншот сборки экрана и приложите рядом со своим макетом. Зафиксируете рядом с экранами правки и отправьте на доработку.

После того, как разработчик внес все правки, задача переходит на QA.

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

48 показов
15K открытий
5 репостов
51 комментарий
Написать комментарий.

Ох уж эти идеальные дизайнеры, которые где-то существуют )
Вообще интересно было бы про стандартизацию всех элементов )

Развернуть ветку

Достойно оплачивайте услуги и вы удивитесь, сколько толковых дизайнеров, разработчиков, строителей, сантехников.

Развернуть ветку
4 комментария

Добавлю пару советов:

— Разберитесь как работают средства лейаутинга в выбранной технологии. Как происходит компоновка, как отрабатывается ресайзинг визуально. Хорошие разработчики не откажут ни в экскурсе, ни в наброске мини прототипа на поиграться. Зато вы будете с разрабами в одних системах координат, и не будет вопроса, почему нельзя 13.58 пикселя тут и 45.42 пикселя здесь.

— Излишняя кастомизация — зло. Старайтесь стандартизировать размерности/отступы и прочие паддинги. Анимации должны быть переиспользованы либо действительно необходимы.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *