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

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

#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 лет уже прошли огонь, воду и медные трубы, за них часто сами работодатели конкурируют, соревнуясь между несколькими офферами, а всё равно вопрос про вызов почти не звучит. А если звучит — это праздник, сразу узнаёшь единомышленника. Уже думаю: может, микро-статью написать об этом — почему не стыдно спрашивать на собеседовании про вызов.

Якоб Нильсен написал о новой (третьей) парадигме пользовательского интерфейса.

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

In English. #ai