Валерий Щучкин

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

Вот несколько правил, которыми я руководствуюсь:

Никаких абстракций в макетах

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

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

Никакого рыбного текста

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

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

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

Разберитесь с единицами измерения

Это правило характерно для мобильных интерфейсов. Давным-давно большинство экранов имели примерно одинаковую плотность пикселей. А в 2010 году появился iPhone 4 с невероятно чётким по тем временам экраном. В нём было в четыре раза больше пикселей, чем в его предшественнике. Дизайнеры сразу же отреагировали, и вместо того, чтобы продолжить рисовать макеты в разрешении 320 × 480 px они начали использовать 640 × 960 px. Такие макеты лучше выглядели, если смотреть на них на экране смартфона, но работать с ними гораздо сложнее, и вот почему: в коде размеры указываются не в физических пикселях, а в логических. Особенно это показательно на примере операционной системы Android, где экран с логическим разрешением 360 × 640 dp может на скриншоте иметь разрешения 360 × 640 px, 720 × 1280 px, 1080 × 1920 px и 1440 × 2560 px. При этом если приложить к экрану линейку, то при каждом из этих разрешений физическая высота элементов будет примерно одинаковой.

Когда разработчик получает макет в разрешении скриншота вместо логического разрешения, ему нужно все отступы и размеры разделить на коэффициент плотности экрана. Даже если взять любимый дизайнерами размер 720 × 1280 px, останутся вопросы. Разделить на два можно, но какой отступ указать в коде, если на макете он составляет 35 px? Если пиктограмма была нарисована в большом разрешении, при уменьшении она линии могут не попасть в пиксели, иконка будет выглядеть замыленной. Если же увеличивать изначально маленькую иконку, проблем не будет.

Сейчас, когда большинство интерфейсов создаётся в векторных редакторах нет никакой необходимости использовать увеличенные до размера скриншота макеты, и Figma и Sketch делают это автоматически в своих приложениях для просмотра макетов на экране смартфона, поэтому проще всего при создании макетов руководствоваться двум я размерами: 375 × 667 для iPhone и 360 × 640 для Android — эти разрешения являются самыми популярными на данный момент.

Старайтесь держать макеты в порядке

Каждый из нас представляет идеальный макет по-своему: у кого-то все элементы разложены по папкам и артбордам с ювелирной точностью, у других в списке элементов бардак и анархия. Если на выходе нужна растровая картинка, нет никакой разницы, что в слоях в исходном документе. Но если вы отдаёте гайды в Zeplin или Figma, огромное количество слоёв заставит разработчика потратить дополнительное время на то, чтобы разобраться в структуре макета. Если с вашими макетами работают другие дизайнеры, вы можете здорово упростить им жизнь, поддерживая порядок в макетах.

Делайте больше прототипов

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


Эти рекомендации наверняка нельзя назвать полными или универсальными, в каждой команде складывается свой подход. Однако главную мысль можно сформулировать так: у ваших дизайн-макетов тоже есть дизайн, и в ваших силах его улучшить.

Вася Сергеев

Иногда для прототипирования хватает и прототипа на экране компьютера или на планшете. Но иногда все это бесполезно, если не учитывается эргономика и среда обитания будущего интерфейса. Так в лаборатории автомобильных решений год назад появилась половина автомобиля Lada XRAY.

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

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

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

Александр Моисеев

Хочу рассказать, как удалось с помощью анимации улучшить показатели сервиса.

Есть такая фича в приложении Яндекса — Поиск по картинке. Позволяет найти похожие картинки и определить объект по фотографии

Раньше это выглядело так

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

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

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

Мне кажется, выглядит магически 😉

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

Результат был отличным. Мы сократили отказы в момент загрузки до 15%. А ещё увеличилось количество запросов картинкой в день на 60%.

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

Быстрое переключение вкладок в Яндекс.Браузере для Android