Большая часть статьи отвечает на вопрос как должен выглядеть макет, как к нему оставлять комментарии и согласовывать его с разработчиками. Вступительная часть статьи «Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.» отвечает на вопрос «Как передать макет?», – это самая простая часть не требующая развернутых комментарии.
Для вас прокомментирую.) Макет передается разработчиками в виде ссылки. Если передавать макеты не в Фигме, он может пересылаться в виде файла.
Ссылке или файлы вы можете передать внутри CRM системы, с помощью мессенджеров или других способов передачи информации, коих сейчас довольно много, в каждой команде они свои.))
Макет стоит сопроводить комментариями, китом и презентацией. Все это написано в статье. Мне больше нечего вам добавить. Статья подписана так как нужно.
Думаю, пользователи которым адресована эта статья разберутся с тем в каком виде и как передавать файлы. Спасибо за ваши замечания.)
Возможно, в будущем я напишу статью о том как построить комфортную коммуникацию между разработчиками и дизайнерами. Этот вопрос не относится к теме статьи.
В промежутке между 360рх и 1024рх, стоит добавить размер 768рх, например. Могут быть любые приемлимые значения.
Касаемо десктопных макетов также могут быть разные макеты для небольшого экрана и для крупных экранов. Все зависит от сложности проекта.
Кроме того, бывают разные подходы к подготовке адаптивных макетов, может быть респонсив, может быть адаптивный дизайн, может быть вообще отдельная версия сайта для мобилки и планшета.
Вижу, что тема с подготовкой размеров экранов довольно интересна и работа с адаптивным в целом. Думаю, есть смысл подготовить отдельные публикации на эти темы. ?
Вы заблуждаетесь о передачи файлов в статье написано:
«Редактор дает возможность получать доступ к макету всем участникам команды в режиме онлайн, все изменения в проекте происходят в реальном времени, их сразу же видят все члены команды. Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.»
«Таким образом, я рекомендую использовать для работы приложения хранящие макеты в облаке и поддерживающие возможность кооперативного редактирования макетов в реальном времени. Figma будет отличным выбором.»
Касаемо комментариев для разработчиков также написано в пункте №5 и №8, а также в пункте №11.
Статья о том, как должен выглядеть макет, а не о том как составить ТЗ на сайт.
Вы подняли интересную тему взаимодействия дизайнеров и разработчиков. На эту тему можно написать отдельную статью. Возможно, этим займусь чуть позже. ?
Для передачи макетов в разработку нужно подготовить макеты в необходимых разрешениях. В сформулированном тезисе речь идет о «...как минимум три типа устройств десктоп, планшет и мобилка.»
На практике бывают различные агрегатные состояния даже десктопной верстки: отображение в окне, отображение при открытом боковом сайдбаре, без него, с разными размерами перемещаемых виджетов, отображение на небольшом дисплее в режиме разделенного экрана и т.д.
В идеале стоит просить дизайнера подготовить макет для каждой подобной непонятной или сложной ситуации, это его работа.))
Проекты бывают разными, соответсвенно количество макетов может быть разным. В статье написано что стоит учитывать наиболее маленькие разрешения ибо порой дизайнеры этого не учитывают. В итоге макет попросту не помещается в экран.
Касаемо пограничных состояний можно готовить отдельные версии макетов, что сделает и дизайн верстку более качественными.
У меня нет рецепта для всех сайтов, ведь они бывают разными. Где-то достаточно трех состояний, где-то нужно более глубокая проработка. Если есть вопросы по конкретным ситуациям – можете написать мне в Директ, обсудим что можно придумать.))
Начет движка Фигмы не совсем понял. В Фигме можно использовать различные инструменты для подготовки адаптивных макетов. Если компоненты завернуть в автолейауты, правильно выставить параметры позиционирования элементов и отступов внутри фреймов – можно с легкостью подготовить адаптивные макеты под любое разрешение.
Очень важно, что бы на поддерживаемых продуктом разрешениях контент отображался корректно. Если продукту не интересно поддерживать старые смартфоны или компьютеры – он может этого не делать, но в моей публикации указаны размеры вполне актуальные. Не все пользователи просматривают десктопные макеты на весь экран, например. Не все планшеты имеют высокое разрешение, равно как и смартфоны, некоторые планшеты поддерживают режим раздельного экрана и.т.д.
«Если дизайнер нарисует, что на планшетниках какой-то набор элементов должен становиться сладйером, то он имеет в виду именно ширину экрана или все устройства с сенсорным управлением?» – для этого существуют комментарии дизайнера и он может описать в каких случаях должен показываться этот элемент и как он должен работать.)
При проектировании экранов важно учитывать с каких девайсов его просматривают пользователи. Это с лёгкостью можно проверить через сервисы метрик.
При разработке адаптивной верстки могут учитываться не только размеры экранов, а и платформы с которых пользователи просматривают верстку.
В пограничных случаях, когда экран не относится ни к планшету ни к десктопу, могут подготавливаться отдельные макеты, все напрямую зависит от продукта, а они бывают разными.
То как выглядят макеты напрямую зависит от обозначенных разработчиками или дизайнерами брекпоинтов. Можно нарисовать только три ширины экрана, а можно больше: под маленькие смартфоны, под обычные, под разные размеры планшетов и десктопов. Все зависит от бюджетов компании, сроков и сложности задачи.
Да, пока сетки не могут учесть всех нюансов, местами результат получается топорный. Чтобы получилось что-то вменяемое нужно отправлять разные запросы и корректировать результаты работы. В целом работа дизайнера в этом и заключается – итеративного дорабатывать разные концепции.
По запросу «Не знаю чего, сделайте чего нибудь», дизайнер также ничего не сможет сделать. Сначала нужно составить бриф и уточнить все детали у клиента, что бы потом не рисовать бесконечное количество вариантов.)
Касаемо вкусовых предпочтений – тут также сначала нужно составить бриф и после показать клиенту референсы, что бы убедиться что дизайнер и клиент говорят об одном и тоже. Только после этого дизайнер приступает к работе. В случае с сеткой дизайнеру потребуется максимально подробно описать запрос исходя из данных зафиксированных в брифе.
Говорить о сетях как о серьёзном инструменте пока сложно, но возможно, в будущем они таковыми станут и это было бы круто.)
Планирую этим заняться.)
Большая часть статьи отвечает на вопрос как должен выглядеть макет, как к нему оставлять комментарии и согласовывать его с разработчиками. Вступительная часть статьи «Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.» отвечает на вопрос «Как передать макет?», – это самая простая часть не требующая развернутых комментарии.
Для вас прокомментирую.) Макет передается разработчиками в виде ссылки. Если передавать макеты не в Фигме, он может пересылаться в виде файла.
Ссылке или файлы вы можете передать внутри CRM системы, с помощью мессенджеров или других способов передачи информации, коих сейчас довольно много, в каждой команде они свои.))
Макет стоит сопроводить комментариями, китом и презентацией. Все это написано в статье. Мне больше нечего вам добавить. Статья подписана так как нужно.
Думаю, пользователи которым адресована эта статья разберутся с тем в каком виде и как передавать файлы. Спасибо за ваши замечания.)
Возможно, в будущем я напишу статью о том как построить комфортную коммуникацию между разработчиками и дизайнерами. Этот вопрос не относится к теме статьи.
В промежутке между 360рх и 1024рх, стоит добавить размер 768рх, например. Могут быть любые приемлимые значения.
Касаемо десктопных макетов также могут быть разные макеты для небольшого экрана и для крупных экранов. Все зависит от сложности проекта.
Кроме того, бывают разные подходы к подготовке адаптивных макетов, может быть респонсив, может быть адаптивный дизайн, может быть вообще отдельная версия сайта для мобилки и планшета.
Вижу, что тема с подготовкой размеров экранов довольно интересна и работа с адаптивным в целом. Думаю, есть смысл подготовить отдельные публикации на эти темы. ?
Все верно. Под мобильные устройства макеты разрабатываются в логических пикселях, а при выводе отображаются физический размер.
Макет нарисованный под 375px будет иметь размер на выходе в разы больше, в зависимости от коэффициента масштабирования экрана.
Например, для десятого айфона макет рисуется под 375рх, а на выходе рендерится картинка с разрешением 1125px по ширине. ?
Вы заблуждаетесь о передачи файлов в статье написано:
«Редактор дает возможность получать доступ к макету всем участникам команды в режиме онлайн, все изменения в проекте происходят в реальном времени, их сразу же видят все члены команды. Для передачи файлов Фигмы коллегам достаточно скопировать и переслать ссылку на макет хранящийся в облаке.»
«Таким образом, я рекомендую использовать для работы приложения хранящие макеты в облаке и поддерживающие возможность кооперативного редактирования макетов в реальном времени. Figma будет отличным выбором.»
Касаемо комментариев для разработчиков также написано в пункте №5 и №8, а также в пункте №11.
Статья о том, как должен выглядеть макет, а не о том как составить ТЗ на сайт.
Вы подняли интересную тему взаимодействия дизайнеров и разработчиков. На эту тему можно написать отдельную статью. Возможно, этим займусь чуть позже. ?
Помимо рекомендаций касаемо размеров экрана, в статье идет речь и о других важных моментах. Поэтому статья отвечает на вопрос из заголовка.
Касаемо размеров макетов я дал комментарий. Если вам не ясны другие тезисы – пишите, постараюсь вам помочь разобраться.)
Для передачи макетов в разработку нужно подготовить макеты в необходимых разрешениях. В сформулированном тезисе речь идет о «...как минимум три типа устройств десктоп, планшет и мобилка.»
На практике бывают различные агрегатные состояния даже десктопной верстки: отображение в окне, отображение при открытом боковом сайдбаре, без него, с разными размерами перемещаемых виджетов, отображение на небольшом дисплее в режиме разделенного экрана и т.д.
В идеале стоит просить дизайнера подготовить макет для каждой подобной непонятной или сложной ситуации, это его работа.))
Проекты бывают разными, соответсвенно количество макетов может быть разным. В статье написано что стоит учитывать наиболее маленькие разрешения ибо порой дизайнеры этого не учитывают. В итоге макет попросту не помещается в экран.
Касаемо пограничных состояний можно готовить отдельные версии макетов, что сделает и дизайн верстку более качественными.
У меня нет рецепта для всех сайтов, ведь они бывают разными. Где-то достаточно трех состояний, где-то нужно более глубокая проработка. Если есть вопросы по конкретным ситуациям – можете написать мне в Директ, обсудим что можно придумать.))
Начет движка Фигмы не совсем понял. В Фигме можно использовать различные инструменты для подготовки адаптивных макетов. Если компоненты завернуть в автолейауты, правильно выставить параметры позиционирования элементов и отступов внутри фреймов – можно с легкостью подготовить адаптивные макеты под любое разрешение.
Хороший комментарий, стоит подготавливать макеты для таких состояний.)
Очень важно, что бы на поддерживаемых продуктом разрешениях контент отображался корректно. Если продукту не интересно поддерживать старые смартфоны или компьютеры – он может этого не делать, но в моей публикации указаны размеры вполне актуальные. Не все пользователи просматривают десктопные макеты на весь экран, например. Не все планшеты имеют высокое разрешение, равно как и смартфоны, некоторые планшеты поддерживают режим раздельного экрана и.т.д.
«Если дизайнер нарисует, что на планшетниках какой-то набор элементов должен становиться сладйером, то он имеет в виду именно ширину экрана или все устройства с сенсорным управлением?» – для этого существуют комментарии дизайнера и он может описать в каких случаях должен показываться этот элемент и как он должен работать.)
При проектировании экранов важно учитывать с каких девайсов его просматривают пользователи. Это с лёгкостью можно проверить через сервисы метрик.
При разработке адаптивной верстки могут учитываться не только размеры экранов, а и платформы с которых пользователи просматривают верстку.
В пограничных случаях, когда экран не относится ни к планшету ни к десктопу, могут подготавливаться отдельные макеты, все напрямую зависит от продукта, а они бывают разными.
То как выглядят макеты напрямую зависит от обозначенных разработчиками или дизайнерами брекпоинтов. Можно нарисовать только три ширины экрана, а можно больше: под маленькие смартфоны, под обычные, под разные размеры планшетов и десктопов. Все зависит от бюджетов компании, сроков и сложности задачи.
Тоже это заметил.
Да, сетка рисует что угодно главное максимально подробно составить запрос.
Да, пока сетки не могут учесть всех нюансов, местами результат получается топорный. Чтобы получилось что-то вменяемое нужно отправлять разные запросы и корректировать результаты работы. В целом работа дизайнера в этом и заключается – итеративного дорабатывать разные концепции.
По запросу «Не знаю чего, сделайте чего нибудь», дизайнер также ничего не сможет сделать. Сначала нужно составить бриф и уточнить все детали у клиента, что бы потом не рисовать бесконечное количество вариантов.)
Касаемо вкусовых предпочтений – тут также сначала нужно составить бриф и после показать клиенту референсы, что бы убедиться что дизайнер и клиент говорят об одном и тоже. Только после этого дизайнер приступает к работе. В случае с сеткой дизайнеру потребуется максимально подробно описать запрос исходя из данных зафиксированных в брифе.
Говорить о сетях как о серьёзном инструменте пока сложно, но возможно, в будущем они таковыми станут и это было бы круто.)