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

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

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

Про другие роли в наших продуктовых командах можно почитать в заметке на VC.ru

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

Как именно мы видим развитие проектировщика, и где проводим границы между джуном, мидлом и сеньором — описано в нашей модели оценки.

Соль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во время обсуждения дизайна записывает все комментарии. Самое подходящее место — прямо в макете. Невыполненное обещание «всё запомнить» демотивирует команду и снижает доверие к дизайнеру: зачем что-то говорить, если твои идеи будут просто забыты.

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

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

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

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

Не подписывает в прототипе каждое расстояние и размер. Вместо этого учит верстальщика самостоятельно подмечать детали, и делать «как на картинке».

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

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

Прототип

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

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

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

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

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

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

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

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

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

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

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

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

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

Матчасть

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

  • Алан Купер «Психбольница в руках пациентов»
  • Влад Головач «Дизайн пользовательского интерфейса»
  • Дональд Норман «Дизайн привычных вещей»
  • Джеф Раскин «Интерфейс: новые направления в проектировании компьютерных систем»
  • Джейсон Фрайд, Дэвид Хайнемайер Хенссон «Rework. Бизнес без предрассудков»
  • Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
  • Максим Ильяхов, Людмила Сарычева «Пиши, сокращай. Как создавать сильный текст»
  • Артем Горбунов «Типографика и верстка»
  • Илья Бирман «Пользовательский интерфейс»
  • Роберт Брингхерст «Основы стиля в типографике»

Влад Головач разочаровался в своей первой книге и просит не ставить на нее ссылки.

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

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

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

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

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

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

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

Тексты

Слова в дизайне продукта не менее важны, чем пиксели. © Костя Горский

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

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

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

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

Хороший вкус

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

Композиция

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

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

Цвет

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

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

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

Может подобрать цветовые сочетания для нового продукта.

Типографика

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

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

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

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

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

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

Может подобрать и встроить иллюстрацию.

Может нарисовать набор иконок.

Может разработать дизайн сервиса с нуля.

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

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

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

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

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

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

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

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

Регулярно слушает записи разговоров техподдержки.

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

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

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

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

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

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

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

Статистика

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

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

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

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

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

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

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

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

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

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

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

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

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

В Контуре не проектируют в редакторах, которые устарели или плохо подходят для дизайна интерфейсов: Photoshop, Illustrator, InDesign и пр.

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

Умеет делать прототипы анимации интерфейсов.

Знает Photoshop, Illustrator, может подготовить спрайт для верстальщика или подправить макет за отсутствующим дизайнером.

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

Когда есть только молоток — всё вокруг превращается в гвозди.

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

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

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

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

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

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

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

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

Обучает стажеров и начинающих проектировщиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принимает участие в формировании планов по развитию продукта.

Этика

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

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

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

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

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

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