Проектировщик интерфейсов

Здесь описан портрет проектировщика интерфейсов из продуктовой команды СКБ Контур.

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

Каждый блок — это список знаний, практик и навыков. Проектировщик должен освоить их все. Дополнительные штуки обозначены знаком — тут можно выбирать что по душе, и копать вглубь там, где интереснее.

Соль

Главный приоритет работы проектировщика в Контуре — продукт, а не макеты. Если в макетах всё хорошо, а в продукте всё плохо, работа проектировщика не выполнена. Хороший проектировщик часто заходит в сервис, смотрит, как работают старые и новые функции, следит за порядком и заводит баги.

Проектировщик интерфейсов и его прототипы являются важным коммуникационным инструментом для команды. Команде должно быть комфортно общаться с проектировщиком и удобно работать с его прототипами.

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

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

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

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

Для настоящего проектировщика не существует неинтересных задач, то есть таких, над которыми он работает спустя рукава, невнимательно и без старания.

Использует сценарный подход: за каждой кнопкой, экраном, разделом в системе проектировщик видит сценарии работы реальных пользователей. Вопрос «Какой сценарий?» должен предшествовать любым изменениям в продукте.

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

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

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

Работа над задачей

Правильный процесс повышает шансы получить качественный результат. Не каждая задача требует прохождения всех этапов.

  1. Обсудить задачу с командой:
    • Установить всех «заказчиков».
    • Понять критерии успешного решения задачи, какими метриками их можно установить.
  2. Сделать бумажные наброски, обсудить их с командой.
  3. Создать концептуальный прототип в Sketch, обсудить с командой и техподдержкой.
  4. Совместно с юзабилистом подготовить прототип к юзабилити-тестированию: Sketch + Invision.
  5. Провести юзабилити-тестирование, обсудить результаты с командой. Исправить недочеты. При необходимости провести тестирование еще раз.
  6. Подготовить детализированный прототип с информацией для верстальщика (Measure или Marketch, Invision).
  7. Презентовать прототип разработчикам: проговорить голосом все основные моменты, пройтись по всем экранам.
  8. Поддерживать прототип во время разработки:
    • Отвечать на поступающие вопросы.
    • Если в процессе разработки решение поменялось — незамедлительно вносить правки в прототип.
  9. Протестировать до выхода: последовательно прокликать все основные сценарии, если есть форма: заполнить форму, проверить валидацию, написать баги, проверить их исправления. Если в задаче есть печатные формы — напечатать их.
  10. Добавить метрики.
  11. Проверить задачу еще раз после релиза.
  12. Проанализировать статистику использования по метрикам, отзывам пользователей и техподдержки.
  13. Провести ретроспективу.

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

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

Если не понятно, что делать дальше, это повод встретиться и поговорить, а не сидеть и думать одному.

Проектировщик не занимается самоцензурой — не отказывается от каких-то идей, самостоятельно предполагая, что они слишком сложны в реализации. Всегда сложность разработки уточняет у верстальщика/программиста. То, что кажется сложным, может решаться очень просто и наоборот.

Если программист говорит: «Это нельзя сделать», проектировщик спрашивает: «Почему?». Нередко отвечая на этот вопрос, программист вдруг находит решение.

Чем «дороже» решение в реализации, тем подробнее проектировщик объясняет команде, почему был выбран именно такой дизайн. Понимая «путь к дизайну», его важность для пользователя, разработчики охотнее ищут возможность его сделать.

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

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

Прототип

Детализация прототипа должна соответствовать текущей степени понимания задачи:

  • высокая степень неопределенности, только начали думать над большой непонятной штукой — стикеры для записи идей и приоритизации;
  • если поняли что делать и надо представить это в виде интерфейса — набросок на бумаге/доске;
  • если интерфейсное решение есть и можно делать следующий шаг — прототип в Sketch;
  • провели юзабилити-тестирование — можно делать финальный прототип, добавлять дизайн.

Финальный прототип содержит:

  • окончательный графический дизайн для разрешения, с которым работает большая часть пользователей, как правило это 1280;
  • финальные интерфейсные тексты и рыбу, максимально приближенную к реальному контенту; не должно быть:
    • мата, неприличных названий, пошлых шуток и пр.;
    • названий реальных организаций, их данных;
    • задублированных строк в списках и таблицах;
    • текстов вроде «Заголовок» и «Длинное название компании».
  • все состояния страниц и контролов:
    • состояние «без данных», которое увидит пользователь войдя на страницу в первый раз;
    • прелоадеры и загрузчики;
    • дизайн интерактивного элемента при наведении и в момент нажатия;
    • кликабельные области элементов, если они больше видимых;
    • работа с помощью клавиатуры.
  • логику работы валидации, сообщения об ошибках;
  • анонс новых возможностей в сервисе, чтобы пользователи о них узнали;
  • комментарии для верстальщика и разработчиков:
    • как тянется дизайн;
    • описание анимации, а лучше специальный прототип;
    • Marketch или Measure.

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

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

Хороший проектировщик не применяет дизайнерские «хаки», которые делают прототип симпатичнее, но в реальном сервисе работать не будут либо вообще отвалятся на стадии разработки. Например:

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

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

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

  • промежуточные варианты отделены от финальных;
  • артборды расположены последовательно;
  • повторяющиеся элементы переведены в символы.

Прототип и графический дизайн — это один sketch-файл. Если дизайнер помогает проектировщику, он не должен создавать отдельные макеты — возникнет рассинхронизация и путаница.

Проектировщик думает про микровзаимодейcтвия. Если требуется показать, как что-то должно работать в динамике проектировщик, делает анимированный прототип или дает верстальщику подробные инструкции.

Матчасть

Прочитал и осознал основные книги:

Знает и понимает:

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

Знает специфику каждого контрола. Может объяснить, например, в каком случае лучше подойдет раскрывающийся список, а в каком автокомплит.

Знает руководство по фирменному стилю Контура и использует его в своей работе.

Использует стандартные контролы и паттерны из Контур.Гайдов. Без необходимости не придумывает свои контролы. Но когда стандартный контрол не работает — изобретает свой, «продает» его команде и доводит до качественной реализации. Не придумать уникальный контрол там, где он действительно нужен — так же плохо, как не использовать стандартные контролы там, где они работают.

Читал гайды других разработчиков, обращается к ним по необходимости:

Тексты

Весь текст в интерфейсе — зона ответственности проектировщика. Даже если какой-то текст написал другой человек, проектировщик должен контролировать качество.

Основные интерфейсные тексты проектировщик пишет сам: названия кнопок, сообщения об ошибках, всплывающие подсказки и контекстную справку.

Интерфейсные тексты емкие и понятные, соответствуют инфостилю и нашему гайдлайну по текстам.

Дизайн и верстка

Хороший вкус

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

Композиция

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

Знает следующие понятия:

Цвет

Знает устройство цветовой модели RGB.

Понимает что такое контрастность, насыщенность.

Знает особенности цветопередачи плохих мониторов.

Типографика

Делает аккуратную типографику в интерфейсах.

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

Знает типографскую терминологию:

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

Графический дизайн

С помощью дизайнера доводит до ума свои прототипы.

Может на основании существующих экранов сделать новый без помощи дизайнера.

Пользователи и предметная область

Проектировщик обладает эмпатией к своим пользователям, понимает важность их работы, понимает сложности профессии и ценности, уважительно к ним относится. Доносит это знание до всей команды.

Мы не используем слово «юзер». Совсем.

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

Знает портрет своего пользователя.

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

Понимает основы профессии пользователя: термины, задачи, законодательство.

Регулярно присутствует на юзабилити-тестированиях, использует другие возможности пообщаться с пользователями вживую.

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

Веб-технологии

Понимает устройство и ограничения веб-сервисов:

  • Различия и область применения графических форматов: JPEG PNG GIF SVG.
  • Масштабирование веб-страниц и шрифтов.
  • Ограничения старых браузеров.
  • Как работает URL.
  • Клиент-серверная архитектура и типы передачи данных в вебе:
    • Синхронная передача данных с перезагрузкой страниц (GET/POST).
    • Асинхронная передача данных.
    • Одностраничные приложения.

Знает основы верстки HTML/CSS.

Может открыть веб-инспектор и что-то быстро поменять-прикинуть.

Статистика

Просит фиксировать ключевые события, чтобы оценить использование функциональности, посчитать конверсию.

Умеет пользоваться Яндекс.Метрикой и/или Гугл.Аналитикой и/или внутренними системами и делать на основании них выводы:

  • Браузер, разрешение экрана, операционная система.
  • Посмотреть статистику использования.
  • Пути переходов по сайту и системе.
  • Тепловые карты.
  • Записи веб-визора.

Самоорганизация

Не прокрастинирует: не тратит рабочее время на Фейсбук, Твиттер, бесполезные чатики и т.п.

Правильно оценивает задачи, соблюдает сроки, если не успевает — предупреждает заранее.

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

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

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

Инструментарий

Не боится в ходе обсуждения рисовать интерфейсы на бумаге или доске.

Знает Sketch, умеет в нем быстро работать: использует символы, шорткаты и плагины.

Знает Invision, умеет быстро собирать интерактивный прототип для презентации или юзабилити-тестирования.

Саморазвитие и передача опыта

Читает книги, статьи, блоги, в курсе дизайнерских трендов, следит за развитием отрасли.

Изучает интерфейсы новых программ и сайтов, подмечает интересные решения. Расширяет свой визуальный опыт.

Окружает себя хорошим дизайном: гаджеты, книги и журналы, предметы интерьера.

Стремится перенять профессиональный опыт и знания у «старших» коллег. Распространяет свои знания среди команды и других дизайнеров.

Имеет широкий кругозор, интересуется современными технологиями, историей искусства и культуры.

Наблюдает за тем, как люди работают с интерфейсами. Накапливает и структурирует эти знания.

Стремится заниматься задачами, которые его развивают.

Взаимодействие в команде

Участвует в командных встречах: ежедневные скрамы, презентации, ретроспективы.

Не участвует в бесполезных встречах. Если понимает, что на встрече он не нужен, встает и уходит.

Хороший проектировщик делает так, что проектирует и генерирует интерфейсные идеи вся команда. Любой участник команды понимает: если он подойдет к проектировщику со своей идеей, его услышат и адекватно отреагируют. Плохой проектировщик узурпирует работу над интерфейсом, обижается, когда кто-то кроме него «лезет в дизайн».

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

Проектировщик правильно воспринимает критику в адрес своей работы: не бросается сразу всё переделывать, но с правильными замечаниями соглашается.

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

Для обсуждения дизайна использует личное общение, а не переписку в почте или чате.

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

Команда доверяет своему проектировщику, ей нравится интерфейс ее продукта.

Развитие продукта

Проектировщик чувствует ответственность за продукт. Знает бизнес-цели продукта и дизайном помогает их достигать.

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

Может предложить не только задачи, связанные с мелкими интерфейсными недоделками, но и новые сценарии работы.

Этика

Работы, сделанные в Контуре, можно выкладывать в свое личное портфолио. Нужно указать, что именно сделал владелец портфолио в этом дизайне.

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

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

Нельзя работать на конкурентов или участвовать в проектах, наносящих вред Контуру.

Нельзя в сторонних проектах использовать фирменный стиль и элементы графического дизайна Контура.

Нельзя выполнять сторонние проекты, находясь в офисе Контура.