В этом выпуске: 5-й выпуск передачи Walking head с участием Евгения Игнашова, статьи о пользе функциональных спецификаций, оформлении таймсерий, использовании плейсхолдеров, продуктовых метриках, вертикальных отступах и написании микротекста.
5-й выпуск Walking head
Разговор с проектировщиком из Redmadrobot и членом «Гильдии вольных проектировщиков» Евгением Игнашовым.
- Реально ли зарабатывать проектированием, вообще не занимаясь дизайном UI;
- Как находить клиентов (напрямую и через студии);
- Как пришёл к профессии проектировщика, а затем UX / UI-дизайнера, как стал арт-директором в красноярской студии «Чипса»;
- О комплексном предложении услуг проектировщика: проектирование, дизайн, написание ТЗ, авторский надзор;
- О типах проектов и ценах.
- О взаимодействии проектировщика с аналитиком;
- Проектной работе в Redmadrobot;
- Жизни на корпоративной квартире роботов;
- Нюансах оформления отношений с заказчиками.
- Что лучше, быть UX / UI-дизайнером или специализироваться;
- Про отличия продуктового менеджера от продуктового дизайнера;
- Про взаимодействие с ПО (product owner);
- Про А/Б-тесты как способ договориться.
- Про фишки при продаже услуг проектировщика;
- На что обратить внимание и чему учиться, чтобы быстрее стать продуктовым дизайнером;
- Как понравиться клиенту за счёт грамотного подхода к проектированию;
- Стоить ли отказываться от Акшуры и переходить на Скетч и Фигму.
Все выпуски вместе в альбоме ВК.
Польза функциональной спецификации
Егор Камелев написал, зачем нужны функциональные спецификации.
Функциональная спецификация подробно описывает текстом спроектированный прототип, дополняя его теми вещами, которые невозможно или затруднительно отобразить в интерфейсе: процедуры и микросценарии, ограничения форм и списков, технические ограничения систем, алгоритмы поисков и прочее.
Зачем нужна:
- Донести до разработчиков информацию, которую невозможно отобразить в интерактивном прототипе;
- Чтобы стать частью договора на разработку;
- Помогает восстановить информацию по «замороженным» на длительное время проектам;
- Во время её написания проектировщик проделывает двойную проверку интерактивного прототипа, находит ошибки и несостыковки и вносит правки.
Подпись для таймсерии
Михаил Озорнин поделился гайдлайном, как делать подписи для таймсерий — графиков, где что-то зависит от времени.
Повышение информативности:
- Дублировать одно и то же — плохо. Не надо писать отметки 01.01.2015, 01.02.2015, 01.03.2015;
- Для дат лучше всего использовать формат 1 мая, 2 июня, 13 ноя. Месяцы сокращаются до 3 букв без точки (кроме июня и июля), ведущий ноль у числа не пишется;
- Если год на отметках повторяется, лучше подписать его только у 1-й отметки этого года. Год стоит продублировать у крайних отметок;
- Секунды у времени не пишутся, если не сказано обратного. Любое время, кроме полуночи лучше писать без ведущих нулей (6:25, но 00:00).
Улучшение оформления:
- Если отметок много и текст подписи переносится на 2 строки, лучше уменьшить количество отметок, чтобы текст не переносился;
- Текст подписи выравнивается по центру, сама подпись — по пеньку;
- Между отметками должен быть минимальный отступ в 16 px, если отступ будет меньше, то отметки слипнутся.
Плейсхолдер
Эрик Бэйли написал, почему не стоит использовать плейсхолдеры.
Если опустить технические проблемы браузеров и особенности режима высокой контрастности, остаются аргументы:
- После того, как пользователь начал ввод текста, плейсхолдер пропадает. Если там была подсказка о формате ввода, она потеряется. Придётся вспоминать подсказку или удалять введённый текст;
- Из-за плейсхолдера неопытные пользователи могут решить, что поле заполнено;
- Длина плейсхолдера ограничена длиной текстового поля. Формат — только текст. Иногда этого мало, чтобы донести послание;
- Плейсхолдер менее контрастен в сравнении с пользовательским текстом, и его труднее читать. Если делать его темнее, пользователи будут путать плейсхолдер и свой текст.
Эрик предлагает размещать текст плейсхолдера между подписью к полю и самим полем. Такое решение:
- Связывает визуальную и структурную иерархию: сначала указано, для чего нужно поле ввода, потом данные, которые нужно знать, чтобы его правильно заполнить, и в конце сама пустая графа;
- Будет переведено вместе со всей страницей;
- Не воспринимается как заранее введённые данные;
- Легко разобрать даже в условиях плохой видимости;
- Не исчезнет, как только пользователь начнёт заполнять графу;
- Может включать в себя семантические теги и быть стилизовано с помощью CSS.
Обсуждение в ВК.
Оценка продуктовых решений
Евгений Лазаренко написал о показателях, с помощью которых можно оценивать продуктовые решения.
Метрики вовлечения пользователей:
- Количество сеансов на пользователя (Sessions per user);
- Продолжительность сессии для когорты (Session duration for a cohort), с течением времени;
- Количество ключевых действий пользователя за сеанс (Key user actions per session). Таким действием может быть лайк.
Бизнес-метрики:
- Пожизненная ценность клиента (Customer Lifetime Value). LTV — чистая прибыль, которую вы получите от клиента, прежде чем он перестанет платить;
- Стоимость привлечения клиента (Customer acquisition cost). Для SaaS-стартапов отношение LTV и CAC должно быть 3 и выше;
- Какую сумму платит вам каждый месяц рядовой клиент (Average revenue per account);
- Ежемесячный повторяющийся доход (Monthly recurring revenue) — доход компании в месяц;
- Отток клиентов (Customer churn) — % от платящих пользователей, который вы теряете каждый месяц (по когортам и общий);
- Отток доходов (Revenue churn) — % дохода, который компания теряет в месяц из-за оттока или возвратов на прошлый тариф. Меньше обращайте внимания на Customer churn и больше следите за Revenue churn. У SaaS-стартапов Customer churn должен быть ниже 2%, а Revenue churn — отрицательным;
- Удержание клиентов (Retention rate).
Служба поддержки:
- Количество входящих тикетов. Если вы выпустили обновление, и количество тикетов подскочило, возможно что-то пошло не так;
- Индекс потребительской лояльности (Net promoter score) — готовность клиента рекомендовать ваш продукт. Не делайте высокий NPS самоцелью. Мета-анализ от Keiningham не нашёл подтверждений, что NPS отражает способность компании к росту. Лучше обратитесь к клиентам и соберите у них обратную связь.
Вертикальные отступы
Егор Горохов написал, как дизайнеры студии Kelnik передают верстальщикам информацию о вертикальных отступах.
Отступы разделены по уровням. 1-й уровень — самый маленький отступ. Например, между заголовком h4 и параграфом или иллюстрацией и подписью. Отступ 2-го уровня отбивает два таких блока. И так далее.
Уровень блока показан цветом.
Дизайнер расставляет в макетах блоки отступов. Для них в Скетче подходят символы. Есть библиотека, в которой уже забит стандартный набор вертикальных отступов.
Расставить отступы по странице — дело не быстрое и муторное. Но преимущества такие:
- Макеты выглядят аккуратнее;
- Проще рисовать после перерыва;
- Новый дизайнер, которого подключают к проекту, рисует в той же системе координат, для фронтендеров не будет сюрприза;
- Поддержка проекта опирается на конкретные цифры при разработке.
По оценке фронтендеров, время на работу с отступами сокращается на 90%. Фронтендер тратит 5−10 минут на заведение настроек в SASS и больше не переживает об отступах. Ему не нужно ничего замерять линейками, он своими глазами видит (цветовое кодирование), какой отступ у блока.
(Самая популярная ссылка в этой подборке, если судить по количеству лайков в ВК.)
Рекомендации по написанию микротекста
Если в вашей команде нет специалиста по написанию микротекста (интерфейсного текста), вам могут пригодиться рекомендации Райана Кордела:
- Микротекст должен помогать пользователям справиться с их задачей. Если он не обучает, поясняет или облегчает процесс — удаляйте;
- Сокращайте формулировки. Избавляйтесь от длинных заумных слов и витиеватых предложений. Избегайте страдательного залога;
- Объясняйте пользователям, что происходит: зачем вы спрашиваете у них какие-либо данные, сколько шагов осталось до завершения процесса и так далее. Давайте ответы на их возможные вопросы;
- Убедитесь, что текст звучит так, будто написан одним человеком для другого. Используйте простые слова, избегайте жаргона. Участвуйте в пользовательских исследованиях, чтобы узнать, как говорят ваши пользователи;
- Начинайте работать с текстом на этапе первых набросков дизайна. Текст, изображения и функции должны работать на достижение общей цели;
- Тестируйте понятность, иерархию и полезность текста: проводите исследования, узнавайте мнения людей, даже если они не совсем ваши целевые пользователи.