Как же так?

Вы посмотрите только, какую прощальную гифку запилили в Ситимобиле 😭

You’ll always be my brother

Выделять фичи блеском — нямням

pipe.com

На Dribbble появился новый вариант публикации – Case Study

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

Вижу, что многие его просто включают, и у них получается просто описание после первого шока.

Cofix

Быстрый доступ к личной карте гостя со штрихкодом. Достаточно протянуть телефон бариста и немного наклонить для сканирования.

А так вот для чего в Figma появились иконки 🤔

Для Figma вышло обновление, которое позволяет делать свои фавиконы с помощью эмодзи в названии проекта

Можно, например, поставить 🚜, если ваш проект связан с переездом, или 💩, если вам он не очень нравится. Прикольно

В iOS 16 добавили кастомизацию главного экрана: шрифты, цвета, виджеты и объекты поверх них, как на WatchOS

Мечтал о таком переходе при разблокировке

Мем ☝️

Internet Explorer окончательно перестают поддерживать, в Южной Корее даже буквально похоронили браузер. Надпись на плите гласит: «Он был хорошим инструментом для загрузки других браузеров»

В Figma виджеты добавили. Теперь не только в Figjam, и не в отдельном окне как плагины.

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

Интерактивно только для эдиторов, у вьюеров ничего не нажимается 🫠

Мне написал один артдиректор дизайн-студии с вопросом про ТЗ (техническое задание), а именно такие вопросы. Сразу для удобства под вопросами напишу свои ответы.

1. На каком этапе начинают и заканчивают писать ТЗ? Дизайнер работает уже с готовым или оно пишется в процессе проектирования/дизайна?

Как гласит пословица «Без ТЗ результат ХЗ». Я согласен, но это не значит что ТЗ должен писать сам клиент. Если он не хочет, пусть не пишет, дизайнер сам может посмотреть конкурентов, прикинуть список того, что может понадобиться, определить список платформ, размеров экрана и т.д. Составить список вопросов, и уже со всем этим вернуться к клиенту, чтобы откалибровать видение. В общем, получается, что ТЗ пишется сообща.

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

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

3. Насколько детально ТЗ описывается. Нужно ли писать в нём «слайдер с цикличной прокруткой внутри которого 8 фотографий с возможностью загружать новые из админ панели»?

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

4. Как в процессе фигурирует ТЗ, когда клиент только пришёл.

• Бриф обязательно. Без вводных никак.

• ТЗ пишем сами, если клиент не предоставил. Формируем список вопросов клиенту. Можно схему проекта сразу делать, так будет понятно какие экраны нужны, что упускаете из виду. Можно несколько экранов для определения стиля или вообще ограничиться референсами.

• Отправляем ему на утверждение и список вопросов.

• Снова калибруем ТЗ. Снова отправляем.

Не делаем макеты, пока не утвердите список.

Что об этом всём думаете, и согласны ли с тем, что клиент не обязан писать ТЗ, а может только участвовать в его написании вместе с вами?

Не хватает краски печатать на упаковках. Выглядит вот так стыдно

Отличие подходов Android и iOS к интерфейсу на глобальном уровне кратко в этом видео