Никита Семёнов написал о презентации дизайн-решений. Некоторые пункты:

— Отличное решение может сгореть из-за плохой презентации, а дизайнер — утонуть в доработках;
— Клиент — не противник, а партнёр. У вас знания и опыт в дизайне, у него — знания о бизнесе, продукте и целевой аудитории;
— Будьте благодарны людям, участвующим в презентации и дающим обратную связь, — они тратят своё время и энергию;
— Презентуйте своё решение лично (офлайн или онлайн). Его вы знаете лучше всех, плюс сможете видеть эмоции заказчика и сразу ответить на вопросы и обсудить замечания;
— Убедитесь, что на презентации есть человек, который будет принимать финальное решение. Если его нет, встречу лучше перенести;
— Объясните регламент встречи. Когда задавать вопросы: в конце или по ходу рассказа?
— Напомните о целях и задачах, особенностях аудитории и её болях, юридических, технических, временных и прочих ограничениях;
— Покажите весь пользовательский путь с помощью интерактивного прототипа;
— Расскажите, как ваше решение изменит показатели. Например, раньше сотрудники тратили на задачу 20 кликов и 5 минут, а будут 7 кликов и 2 минуты;
— Приводите аргументы из мира тех, кто вас слушает (узнайте, кто перед вами). Продактам важны сроки и KPI, юристам соблюдение законов и так далее.

#presentation

Юрий Марьенко написал об основных типах навигации на сайтах.

— Статичное меню в начале страницы. Если на странице содержимого много, пригодится кнопка возврата наверх, чтобы удобно было возвращаться к меню;
— Фиксированное меню — всегда остаётся на виду при скроле страницы. С ним в любой момент можно перейти в другой раздел сайта, но оно может мешать изучать содержимое страницы;
— Сочетание большого статичного и небольшого фиксированного меню — фиксированный вариант отображается при скроле, не занимает много места по вертикали и даёт быстрый доступ к самым важным разделам;
— Бургерное меню (статичное или фиксированное) — по нажатию на иконку бургера отображает список разделов. Хорошо работает на мобильных сайтах за счёт компактности. Часто используется на популярных сайтах (с большими каталогами), так что паттерн должен быть хорошо знаком пользователям;
— Многоуровневое меню — отображает основные разделы (4–7 пунктов), по нажатию на которые можно увидеть подменю с большим количеством подразделов. Подходит компаниям с несколькими направлениями бизнеса, узкоспециализированным интернет-магазинам;
— Меню помогает посетителям быстро понять, о чём сайт.

#navigation #menu

Станислав Хрусталёв написал о сторис.

— Коллекцию сторис люди привыкли видеть в верхней части экрана;
— Коллекция может реагировать даже на небольшие жесты, прокручиваясь на одну историю;
— При прокрутке выравнивайте сторис по сетке, чтобы их положение было более предсказуемым;
— В Инстаграме и Телеграме привычная форма для сторис — круги;
— Форма квадрата или вертикального прямоугольника позволяет разместить на них текст. Горизонтальных карточек лучше избегать — их на экране помещается слишком мало;
— Выделяйте непросмотренные истории, просмотренные отображайте в конце списка. Тинькофф Банк позволяет настроить, что делать с просмотренными историями;
— Не используйте разный шрифт для заголовков в сторис;
— Если миниатюры избирательно анимировать, они привлекут больше внимания;
— Телеграм показывает количество слайдов в истории;
— Анимация: а) увеличение, б) появление поверх основного контента снизу или сбоку;
— Показывайте сторис на весь экран;
— Полностью или частично затемняйте фон, чтобы легче было прочитать текст (но в меру);
— По умолчанию — без звука. Если в сторис есть видео, добавьте субтитры;
— Переключайте слайды и стории автоматически, а также при нажатии на правую (вперёд) и левую (назад) сторону экрана и свайпе влево и вправо;
— Показывайте, когда произойдёт переключение на следующий слайд;
— Останавливайте переключение слайдов нажатием;
— Контекстные кнопки должны быть достаточно большими;
— Переход к целевому контенту можно реализовать через свайп вверх;
— Дайте возможность сохранять истории и делиться ими;
— При переключении между слайдами и историями — разная анимация;
— Закрывайте истории свайпом вниз, нажатием на крестик, автоматически после просмотра последней истории.

#stories

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

— Виртуальные помощники постоянно переключаются между сценариями общения, которые можно разделить на три типа;
— 1. Фактовый вопрос-ответ — фактически верный ответ на вопрос пользователя, например, «Какой орех самый крепкий»;
— 2. Продуманный разработчиками диалог — получение определённых данных в заданной последовательности, чтобы сыграть в угадывание персонажа или заказать такси;
— 3. Свободный диалог — имитация естественного диалога при ответе на вопросы вроде «Как у тебя дела»;
— Сначала определите целевую аудиторию сценария, почему пользователь выберет голосовое взаимодействие вместо привычной альтернативы, в чём выгода бизнеса (деньги, лояльность, пиар);
— Вторым шагом опишите основную идею сценария, цель взаимодействия, контекст (дома, за рулём, на прогулке), изучите прямых конкурентов (голосовые технологии) и косвенных (альтернативные технологии и методы вроде «спросить соседа»);
— Затем создайте каркас сценария. На диаграмме покажите все возможные развилки. Проверьте, чтобы их не было слишком много, избавьтесь от тупиков, добавьте способы вернуться назад;
— Детализировать сценарий удобнее уже в таблице;
— Можно заранее синтезировать аудио фраз голосового помощника и запускать их при проверке сценария — погружение будет полнее, чем при зачитывании ответов своим голосом;
— Четвёртым шагом проверьте сценарий на коллегах;
— Диалог записывайте, потому что по ходу общения не будет времени для заметок;
— Ищите ситуации, когда: а) пользователю непонятно, чего от него ожидают, б) слишком разнообразные ответы пользователей не уложить в сценарий, в) возникают тупики, г) собеседник забывает инструкции;
— Если такие проблемы не возникают, переходите к тестированию с потенциальными пользователями.

#voice

Срочных задач не существует

Заказчик: Доброе утро! У нас срочная задача, очень надо, сделай пожалуйста!

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

Срочная — это когда? Через час, сегодня к вечеру или к концу недели? Особенно если я прочитал сообщение не сразу, а через пару часов, то вопросов ещё больше. Я уже опоздал? Мы в жопе? Ааа!!!

Срочность относительна. Для задачи, которую делать 10 минут дедлайн через 2 часа — это не срочно, но клиент может не знать, что её делать 10 минут. Поэтому он наводит панику, чтобы показать всю важность задачи и то, что она ему очень нужна. Но для меня ценной информации в такой формулировке — 0.

Лучше не использовать такие слова как «срочно» или «ASAP», а в постановке задачи описать проблему и указать дедлайн. Дизайнер посмотрит задачу, оценит её и скажет, успевает ли он сделать к указанному времени.

Плохо:
У нас супер срочная задача!1 Выручай! Нам надо срочно отдать макет в печать.

Ничего не понятно про задачу, кроме того заказчик в панике.

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

Тут всё понятно: исправление минорное, за пару минут можно всё обновить. Нет повода для паники.

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

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

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

#совет

Кира Калимулина написала о тексте для пустых состояний и ошибок.

— Пустое состояние отображается, когда на экране нет содержимого: 1) Пользователь не добавил или нужные данные ещё не накопились, 2) Он всё удалил, 3) Нулевые результаты поиска или фильтрации;
— Общие рекомендации: определите контекст появления такого состояния; в заголовке расскажите, что произошло; в подзаголовке подскажите, что делать дальше (иногда имеет смысл успокоить пользователя); в тексте кнопки направьте его к целевому действию;
— В статье Кинерет Ифры — более подробная классификация пустых состояний и отдельные рекомендации под каждое;
— Вместо пустого состояния можно показать видеоподсказку или инструкцию;
— Если поиск не нашёл то, что искал пользователь, можно показать что-то похожее. Но важно сообщить об этом;
— Можно показать демоверсию содержимого, например, если эту функциональность открывает премиальный тариф;
— Не стоит: рассказывать о других фичах (может запутать); шутить, когда появление такого состояния может разочаровать пользователя; драматизировать («Мы очень старались, но так ничего и не нашли! Простите нас, пожалуйста, мы обещаем исправиться!»);
— В сообщениях об ошибках превращайте негатив в позитив, если это не искажает смысл. Например: «Эти товары недоступны для юридических лиц» → «Эти товары доступны только для физических лиц»;
— Если есть возможность, к сообщениям об ошибке добавляйте полезные ссылки. Например, на чат с поддержкой;
— Не пишите «Упс» или «Ой» — становится похоже, будто вы не контролируете, что происходит с вашим сервисом;
— Единственная ошибка, в тексте которой можно шутить, — 404.

#empty_state #error #writing

Почему важно проводить 1 на 1 с дизайнерами

У нас в студии была важная проблема, которая только недавно начала решаться.

Ощущение брошенности.

В Райте есть разные форматы работы с клиентом. От проектной до полного аутстафа. Чаще всего у дизайнера есть арт-директор и менеджер, но бывает так, что клиент полностью забирает дизайнера к себе в команду. У меня так было с несколькими клиентами. Я работал в продукте с командой клиента, а через Райт получал денежку, корпораты и дизайнерский движ в офисе.

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

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

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

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

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

Люди работают с людьми. Людям надо давать говорить, людей надо слушать и возвращаться с тем, что обсуждалось. Разговаривайте 💛

#рабочийкейс #процессы #менторство

Алексей Нибо написал об интерфейсах для промышленных устройств.

— От таких интерфейсов зависит эффективность работы специалистов;
— При его создании надо помнить, что это не мобильное приложение, получающее много полезного от операционной системы. Экран блокировки, панель уведомлений, строка состояния, клавиатура и прочее — всё это надо разработать;
— Ссылка на стартовый экран на всех экранах позволит быстро перейти в любой раздел приложения (и просто если пользователь заблудился);
— Одна из задач — показать пользователю, работает устройство или нет (панель уведомлений, строка состояния);
— Стандартные дизайн-решения могут быть неприменимы. Экран может плохо отзываться на прикосновения, тогда свайпы использовать нельзя. Или быть утопленным в корпус, тогда рамка будет мешать нажимать на небольшие элементы по краям экрана;
— В промышленных устройствах могут быть не самые хорошие экраны и графические карты. Учитывайте ограничения железа. Хватит ли мощности для анимации? Стоит проработать состояние ожидания между вводом информации и реакцией системы?
— Эти интерфейсы специфичны. При разработке клавиатуры, возможно, не надо копировать популярные аналоги, так как пользователям нужен лишь ограниченный набор символов (изучайте свою аудиторию);
— Со специфического устройства интерфейс проще перенести в веб или мобильное приложение, чем наоборот. Поэтому лучше начать с него.

#industrial_device

Станислав Хрусталёв написал, как сообщать об использовании кукисов.

— Обычно такие сообщения находятся в нижней части экрана;
— Зафиксируйте его на странице и не перекрывайте другими всплывающими сообщениями;
— Оно должно быть компактным, без длинного текста и лишнего пустого пространства, но при этом выделяться на странице и соответствовать стилю;
— Не должно блокировать взаимодействие с остальным интерфейсом (не модальное);
— Можно добавить иллюстрацию, чтобы вдохнуть в формальное сообщение немного жизни;
— Можно пояснить, зачем вы используете кукисы, какая от них польза клиентам, как можно запретить их сохранение;
— Рассказывать, что это вообще такое, лучше на отдельной странице с деталями;
— Там же можно рассказать о причине сбора (почему это важно и как отразится на клиенте), типах кукисов, способе отказаться от использования и настроить;
— Ссылку на неё разместите в сообщении и сделайте заметной в тексте. Открывать её лучше в новой вкладке;
— На кнопке согласия пишите гендерно-нейтральный текст;
— Кнопки может и не быть, если согласие — это дальнейший просмотр сайта. Тогда будет крестик для закрытия сообщения;
— Тогда всплывающее сообщение после перехода на страницу с деталями можно уже не показывать;
— И вообще его можно автоматически скрывать через некоторое время.

#legal

Маргарита Романова написала о проектировании внутренних CRM.

— Клиент внутреннего продукта — компания, которой продукт помогает преследовать свои цели. Пользователи — сотрудники этой компании;
— Приоритет отдавайте потребностям компании, но помните, что состояние сотрудника влияет на эффективность его работы (а это в интересах компании). Внедрение более спокойной цветовой гаммы → люди меньше устают и делают перерывов → выполнение и перевыполнение нормы;
— Интерфейс должен помогать сотруднику принимать решения. Если решений принимать не надо, то операцию можно автоматизировать, и человек (и этот интерфейс) не нужны. Узнавайте, какая информация о клиентах полезна сотрудникам;
— Используйте термины, но дайте возможность их изучить с помощью подсказок, онбординга или гайдов;
— Не бойтесь подсвечивать пользователю отклонения от нормативов, так как это может приводить к штрафам и премиям;
— Искореняйте хитрости, позволяющие обходить надзор за качеством и количеством выполняемой работы. Вроде возможности сделать неучтённый перерыв, выключив интернет. Из-за них компания теряет деньги;
— Обращайте внимание на пользовательские лайфхаки, помогающие ускорить работу. Это главный источник идей. Смотрите, что они делают вне интерфейса: бумажки, распечатки, заметки. Если они нужны для работы, с интерфейсом не всё хорошо;
— Не злоупотребляйте, обозначая важную информацию. Особенно с помощью красного цвета. Когда всё важно, ничего не важно.

#crm

Илья Бирман написал об онбординге.

— Он появляется не вовремя, мешает воспользоваться приложением, а когда информация из него нужна — её уже не найти;
— Нахваливать в нём приложение и его фичи нет смысла, человек его уже установил и запустил;
— Обучать работе с приложением — тоже, так как надо сначала внимательно всё прочитать и запомнить, а уже потом — применить эти знания в реальном интерфейсе;
— Если интерфейс действительно требует обучения (и его нельзя сделать понятнее), лучше добавить подсказки, кнопки-вопросики с подробным пояснением в сложных местах, ссылки на гайды и видеоинструкции;
— Рассказывать в нём о новых фичах тоже не стоит, так как человек обычно запускает приложение с какой-то целью, и онбординг только помешает;
— Телеграм сообщает об обновлениях в отдельном канале. Если фича понравилась, сообщение о ней легко можно переслать;
— Онбординг действительно может повысить метрики. Но это не значит, что его обязательно надо добавлять. Рассказать о чём-то пользователям можно иначе;
— Если нет никаких других вариантов рассказать о продукте, лучше сделать это онбордингом, чем не сделать вовсе;
— Онбординг проще добавить: он не взаимодействует с другими частями приложения, не добавляет новых связей, поставить его может отдельная команда.

#onboarding

Егор Грохотов написал о быстрой проверке гипотез.

— В Авито разработку и развитие продуктов делят на стадии. Каждая завершается гейтом — встречей, где команда презентует и защищает свой прогресс перед руководителями направлений;
— Проверяют гипотезы на стадиях New Opportunities Discovery (этап исследования) и Product Discovery (этапы проверки спроса и ручной проверки). Цель — попытаться убить продукт на самой ранней стадии;
— Быстрее и эффективнее всего проверять самые рискованные гипотезы;
— Изучайте рынок в том числе через экспертов. Пара интервью с экспертами поможет быстро разобраться, как устроена интересующая вас сфера;
— Если этап исследования подтверждает потенциал идеи, при проверке спроса можно оценить продукт по верхнеуровневой воронке и нащупать каналы продвижения. Например, можно посчитать конверсию лендинга;
— Ручная проверка — сопровождение нескольких клиентов по всем этапам взаимодействия от заявки до целевого действия, чтобы выявить проблемы. Продукт при этом может быть собран на коленке;
— Подключайте юристов и бухгалтеров пораньше, чтобы собрать соответствующие ограничения и не тратить время на правки продукта потом;
— Скорость сборки прототипов новых услуг увеличивает заранее подготовленная инфраструктура: CRM, телефония, чаты, отдельный счёт в банке.

#product #research #process

Максим Десятых написал, как выбрать наставника в дизайне.

— Выгорание и профессиональные кризисы актуальны для творческих людей;
— Новичкам наставник поможет с конкретными инструментами и техниками, зрелым специалистам — определиться с направлением развития, какие хард- и софтскилы улучшить, с мотивацией (в том числе оформить портфолио), построением карьерного трека, повышением стоимости услуг;
— У многих успешных людей есть желание делиться знаниями. Ментором может стать коллега, руководитель с прошлой работы, восхищающий вас фрилансер;
— При выборе наставника не стоит смотреть только на конкретный набор скилов, которые можно перенять;
— Важно, чтобы человек работал в схожей области дизайна (UX, веб, 3D, брендинг) и схожем формате (продукт, фриланс, собственная студия);
— Квалификация важнее опыта. Ментор с небольшим (по времени) опытом может многому научить;
— Опционально: опыт наставничества, умение не давать советы, а направлять мышление;
— Важны личные качества: увлечённость профессией (не выгорел и продолжает развиваться в индустрии), приятность в общении, отвечает на сообщения не через неделю, общительность и дружелюбность (большой нетворк), о нём нет плохих слухов (умеет работать этично, с соблюдением отраслевых стандартов);
— Подобрать хорошего наставника можно только методом проб и ошибок, как и психотерапевта;
— Наставник должен сохранять профессиональную дистанцию и пресекать попытки стать близкими друзьями или любовниками.

#career

Тарас Бакусевич написал об индикаторах загрузки.

— Видимость состояния системы — одна из эвристик Якоба Нильсена;
— Наличие информации о загрузке увеличивает допустимое время ожидания (в эксперименте: 23 секунды против 9);
— Неопределённые индикаторы, в отличие от определённых, не показывают прогресс и сколько времени осталось до окончания;
— Если ждать меньше секунды, индикатор загрузки показывать не надо, чтобы не сбивать пользователя с толку;
— Если больше 3 секунд, нужны определённые индикаторы;
— Не используйте сложные анимации, так как для их корректного завершения может не хватить времени. И не стоит искусственно увеличивать время загрузки ради завершения анимации;
— Не отображайте несколько одинаковых индикаторов для отдельных элементов экрана;
— Показывайте скелет экрана, чтобы повысить воспринимаемую скорость загрузки. А лучше постепенно отображайте готовый контент (прогрессивная загрузка);
— Во время долгой загрузки дайте пользователям возможность продолжить работу с интерфейсом и при необходимости прервать процесс, чтобы у них было чувство контроля за ситуацией;
— Встраивайте индикаторы прогресса в другие элементы интерфейса, например, в кнопки, чтобы показать связь между действием пользователя и реакцией системы;
— Если процесс долгий, рассказывайте об этапах загрузки или выполняемых фоновых процессах;
— Можно показывать подсказки, советы, интересные факты или просто забавные надписи.

In English. #loader

Антон Стен написал, что вайрфреймы устарели.

— Это уже не наброски, но и не дизайн высокой точности;
— Они фокусируют внимание на структуре и сценарии, а не эстетике и деталях, прорабатывать которые ещё рано (вроде цвета кнопок);
— Но люди в последнее время научились давать обратную связь, а если нет, хорошие дизайнеры умеют сместить акцент на актуальные вопросы;
— Их легче создавать, поэтому проще отказываться от не сработавших идей;
— Но с дизайн-системой создавать дизайн высокой точности так же легко;
— Описать взаимодействие (переходы с экрана на экран) можно и с помощью прототипа в Фигме;
— Кто-нибудь работал с вайрфреймами, которые становились дизайн-макетами без перемещения или хотя бы небольшой реорганизации элементов? А если всё равно дорабатывать структуру и иерархию, то какой смысл в вайрфрейме?

In English. #wireframe

В KISLOROD написали о триггерах.

— В психологии это сигналы, приводящие к срабатыванию автоматических поведенческих реакций человека;
— Изначально термин применяли к людям с ПТСР, которые не могли контролировать свои эмоции и поведение. В их случае триггером мог стать любой раздражитель: звук, запах, набор слов;
— В дизайне таких триггеров не бывает, хоть термин и используют. Обычно пользователи — здоровые люди с запасом воли, самостоятельно принимающие решения;
— К общепринятым «триггерам» стоит относиться как к гипотезам (и проверять их). Они могут не сработать или поднять только промежуточные конверсии;
— Чтобы покупка состоялась, у клиента должна быть мотивация (желание) и возможность (наличие достаточного количества денег и готовность преодолеть прочие барьеры на пути к покупке). Когда их достаточно, триггер (подсказка) поможет решиться на покупку;
— Чем больше желание и чем меньше барьеров, тем вероятнее сработает триггер;
— Повысить желание могут мотиваторы: удовольствие и неудовольствие (или их ожидание), сопричастность к группе;
— Барьеры на пути к покупке: цена, время, физические и интеллектуальные усилия, социальная приемлемость, непривычность (отклонение от шаблонов);
— Типы триггеров: сигнал (просто сообщение о возможности, когда мотивация и возможности высоки), инструкция (упрощает путь, когда много мотивации, а возможностей мало), искра (подаёт идею, когда мотивации мало);
— Триггер должен быть своевременным, чтобы не раздражать. Для этого надо изучать свою целевую аудиторию;
— И важно не скатиться в тёмные паттерны, чтобы не потерять доверия клиентов.

Конспект книги Нира Эяля «Покупатель на крючке». Сокращённый перевод статьи об учёных, которые сделали большой вклад в создание приложений, вызывающих привыкание. #psychology

В DesignHub написали, как давать обратную связь.

— Фидбек нужен всем. Даже опытному специалисту можно помочь свежим взглядом со стороны;
— Говорите не только, что не понравилось, но и как можно сделать лучше: предложите решения, приведите примеры, объясните, почему;
— Если не хватает экспертизы для конструктивного фидбэка, всё равно сообщайте, когда чувствуете, что что-то не так;
— Все люди разные, выбирайте форму обратной связи для конкретного человека: кого-то мотивируют позитивные комментарии, кому-то достаточно сухих фактов;
— Обсуждайте фидбэк лично: так комфортнее его получателю, и другие люди не скучают от специфической информации;
— Здорово, когда есть регулярные встречи между дизайнерами, на которых можно посмотреть и покритиковать работу друг друга;
— Не забывайте хвалить. Психологически тяжело, когда в ответ на хорошую работу поступает только список того, что нужно исправить;
— «Всё фигня, надо переделывать» — в целом хороший фидбэк. Можно сформулировать мягче, но главное не потерять смысл, чтобы специалист не услышал «Всё хорошо, но есть что улучшить»;
— Не надо выдавливать из себя комментарий, просто потому что подключили к задаче и спросили мнения. Если добавить нечего, так и говорите;
— Формулируйте комментарии как предложения для улучшения («Можно сделать это», «Тут хочется сделать так», «Думаю, будет лучше попробовать»). Вы можете оказаться неправым. Получатель фидбэка может не согласиться с комментариями;
— Фидбэк для кандидатов должен быть таким же, чтобы на ранних этапах взаимодействия заложить правильные принципы коммуникации.

#process

Таннер Колер и Эми Чжан написали, как пользователи воспринимают тёмную тему и о связанных с этим нюансах.

— Считается, что она снижает нагрузку на глаза и экономит заряд батареи (в телефонах с OLED-экранами). Но исследования показали, что для краткосрочных сессий эффект незначителен;
— Вкладываться в тёмную тему есть смысл, если пользователь долго смотрит в приложение в течение одной сессии (чтение электронных книг), часто к нему возвращается (мессенджер) или приложение в основном используется при низкой освещённости;
— Аргументами за могут быть: 1. Эстетическая привлекательность (у проектов вроде Нетфликса вообще нет светлой темы); 2. Повышение доступности для людей с заболеваниями прозрачных сред вроде катаракты;
— По умолчанию тема приложения должна соответствовать теме операционной системы;
— Люди спокойно реагируют, если отдельные веб-страницы (например, открываемые тёмным приложением через вебвью) не имеют тёмной темы. Но всё равно не забывайте о таких страницах, если можете контролировать их дизайн;
— Используйте картинки с прозрачным фоном, чтобы в тёмной теме они не превращались в белые прямоугольники;
— В светлой теме показать, что один объект находится ближе другого, можно тенью. Но тень не работает в тёмной теме, поэтому обычно более близкие объекты делают светлее;
— Тёмный фон легко поглощает слишком тонкие шрифты, а жирное начертание кажется жирнее, чем такое же на светлом фоне;
— Чтобы графика, которую нельзя заменить для тёмной темы (например, логотип партнёра), сохраняла контраст, можно добавить обводку, свечение, тень и градиент, незаметные в светлой теме;
— То же самое, если графика может стать частью имейла;
— Тёмный фон поглощает тонкие серые разделители. Если в светлой теме достаточно обводки, в тёмной теме может потребоваться изменение фона карточки;
— QR-коды лучше не инвертировать. Многие сканеры настроены обнаруживать тёмные элементы на светлом фоне.

In English. #dark_theme

Станислав Дайнеко написал о трёх поколениях интерфейсов.

— 1. Статичные интерфейсы. Физическая кнопка не перемещается по устройству и связана с конкретной функцией;
— 2. Зависимые от контекста. Появляются физические кнопки, которые не перемещаются по устройству, но в разном контексте могут отвечать за разные действия. Например: а) физические кнопки в банкоматах, подписи к которым отображаются на экране, б) софт-кнопки в мобильных телефонах;
— 3. Динамические. Кнопки переехали на экран, их положение на экране и функции меняются динамически;
— Концепция динамических интерфейсов появилась уже в персональных компьютерах, но не была распространена широко. Навык «уверенного использования ПК» вполне себе был преимуществом;
— Пожилым людям может быть сложно разобраться в современных массовых интерфейсах, так как прошло уже два концептуальных перехода.

#olds

Юля Гранкина написала о виджетах.

— Виджет может поднять DAU приложения. Он привлекает внимание на домашнем экране. Упрощённое взаимодействие повышает лояльность продукту;
— Создавая виджет, надо определить основную функцию приложения;
— Виджеты включают 1) важную информацию, которую можно узнать, не открывая приложения, вроде погоды, 2) элементы управления основным приложением вроде музыкального проигрывателя, 3) коллекции потенциально интересного контента вроде фильмов в онлайн-кинотеатре;
— Данные о пользовательских финансах лучше не выносить в виджет;
— В виджетах разных форматов стоит использовать одни и те же размеры шрифтов и менять только объём информации;
— Актуальные размеры для iOS можно посмотреть в Human Interface Guidelines. В Андроиде размеры виджетов завязаны на размер ячейки, в которую вписывается иконка и название приложения;
— Можно предлагать пользователям варианты виджета с разной функциональностью;
— Стоит проработать пустое состояние, чтобы оно мотивировало сделать то, что приведёт к заполнению виджета. Можно и просто показывать коллекции контента или связанную с приложением статистику;
— Увеличение шрифта в системе на виджеты тоже влияет. Проверяйте, какой максимум текста может поместиться;
— Практика показывает, что минимальное время для смены контента на виджете — от 5 минут на iOS до 15 на Андроиде;
— В iOS нажатие на виджет открывает приложение. Если его размер превышает Small, можно добавить разные области нажатия. В Андроиде возможно более сложное взаимодействие с виджетом.

#widget #mobile

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

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

Есть один вопрос, который я даже у сеньоров слышу нечасто и удивляюсь, почему. Спрашивают про процессы, про вакансии, про специфику продукта, но почти никто не задаётся вопросом: а в чём здесь вызов?

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

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

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

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

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

Но не спросишь — не узнаешь. И поразительно, как мало людей спрашивает. Сначала я списывала это на стеснение: людям на собеседовании сложно поменяться ролями, сложно перестать продавать себя и потребовать от работодателя продать им вакансию. Это понятно в отношении неопытных ребят — я и сама на ранних этапах карьеры куда угодно бы пошла и ничего такого бы не спросила, чтобы не показаться наглой. Но ведь ребята с опытом 5, 7, 10 лет уже прошли огонь, воду и медные трубы, за них часто сами работодатели конкурируют, соревнуясь между несколькими офферами, а всё равно вопрос про вызов почти не звучит. А если звучит — это праздник, сразу узнаёшь единомышленника. Уже думаю: может, микро-статью написать об этом — почему не стыдно спрашивать на собеседовании про вызов.