В мае 2018 года мы выпустили коробочную версию нового интерфейса BILLmanager. Но работа над ним началась за два года до этого, в апреле 2016-го. Все это время внутри ISPsystem происходили масштабные изменения. Появился отдел UX-дизайнеров, потом — отдел фронтендеров. От ситуации, когда решения по продуктам принимались руководством и программистами, мы пришли к матричной структуре управления разработкой: теперь UX-дизайнер есть в каждой продуктовой команде.
О том, как шла трансформация и как сейчас организованы дизайн-процессы в ISPsystem, рассказал Алексей Сорокин — руководитель UX-отдела и человек, с которого эта история началась.
Четыре месяца на новый интерфейс
Я пришёл в ISPsystem в апреле 2016 г. До меня решения по продуктам принимали руководители компании и программисты, никаких дизайнеров или проектировщиков не было. Я стал первым UX-дизайнером в ISPsystem и несколько месяцев, пока не собрал команду, работал один.
Первой моей задачей стало изменить клиентскую часть BILLmanager. Я изучал продукт, исследовал пользователей, знакомился с отзывами партнёров, общался с продукт-менеджером. Каждую неделю показывал наработки руководству компании. Решения по сложным вопросам мы находили вместе, а я их дорабатывал и превращал в прототип.
К августу 2016 г. прототипы новой клиентской части BILLmanager были готовы, с некоторыми доработками она сохранила все возможности старой. Дизайн решили заказать у сторонней компании, но быстро поняли, что это плохая идея, потому что над внешним видом панели надо было работать постоянно. В итоге от работы с подрядчиком отказались и взяли visual-дизайнера в штат. Вместе с ним за пару месяцев мы разработали свой визуальный язык. Язык дополнил элементы и шаблоны интерфейса, которые уже были готовы. В будущем все это стало частями дизайн-системы.
Мы продолжали работать, а программисты начали воплощать новый интерфейс. Ребята рассматривали прототип как альтернативу техническому заданию, и у них возникали вопросы, которые сводились к одному: мы делаем то, что быстро и просто реализовать, или то, что придумал и спроектировал дизайнер?
Для быстрого решения этих вопросов и упрощения коммуникации мы создали команду из дизайнеров и фронтендеров.
От нового личного кабинета к on-premise
К середине осени 2016 г. в компании появился UX-отдел под моим руководством. В нем были visual-дизайнер, UX-дизайнеры, фронтендеры и тестировщики. Ближайшей задачей стал запуск нового интерфейса личного кабинета ISPsystem (мы используем BILLmanager у себя). Срок — конец марта 2017 г.
Уже тогда нарисовалось две проблемы. Мы не понимали, как выстроить взаимодействие разработчиков и дизайнеров. А еще разработчики плохо прогнозировали сроки работы.
Налаживаем взаимодействие
Когда вы используете Sketch и Zeplin, взаимодействие дизайнеров и разработчиков очень простое. Но у нас 150+ страниц в интерактивном прототипе и нам было сложно. Со временем мы пришли к следующему подходу:
- Прототип — это техническое задание для программистов и спецификация для тестировщиков.
- С различными состояниями в Sketch отрисовываем только уникальные страницы.
- Все элементы — кнопки, поля форм и т. п. — должны быть в Zeplin.
Через какое-то время мы узнали, что такой подход применяется в других компаниях и даже имеет название — это дизайн-система на основе атомарного дизайна. У нас она всё ещё в разработке, но ей уже пользуются и проектировщики, и разработчики. Отвечает за дизайн-систему visual-дизайнер.
В итоге разработчики получают:
- макеты элементов в Zeplin,
- HTML-файл, сгенерированный из Axure (прототип продукта, альтернатива ТЗ).
UX-дизайнер всегда готов рассказать разработчикам и тестировщикам, что и как должно работать и выглядеть.
Улучшаем прогнозирование
Чтобы лучше прогнозировать сроки выполнения задач, мы решили внедрить Scrum. В команде разные по компетенциям и культуре участники. Дизайнеры не похожи на программистов, мы по-разному планируем свои задачи, по-разному относимся к тому, что считать хорошим результатом. Поэтому внедрить Scrum было сложно.
Как UX взаимодействует с разработкой:
- Дизайнеры работают на спринт вперёд.
- Общий вид продукта есть в прототипе, который выполняет роль бэклога.
- К планированию дизайнеры готовят прототипы и макеты той части продукта, которую разработчики будут делать в спринте. Прототипы детализированы до такой степени, чтобы разработчики могли ставить себе задачи.
- В момент планирования UX-дизайнер консультирует разработчиков и тестировщиков, что и как должно работать.
- Продукт-менеджер говорит UX-дизайнеру, какую часть продукта планируется делать в следующем спринте, чтобы UX-дизайнер мог подготовится.
Разработчики быстро осознали ценность UX-дизайнера. Когда непонятно, что и как должно работать, проектировщики помогают. Конфликты случаются, но Scrum-практики, командная работа и общие цели помогают их преодолеть.
Важной оказалось роль тестировщика. Он первый просматривает прототипы и говорит, соответствуют ли они функциональности. Утвержденные прототипы становятся для тестировщика источником знания о том, как должен работать продукт.
Приняв дизайн-систему и внедрив Scrum, мы справились с поставленной задачей — выпустили новый интерфейс личного кабинета ISPsystem в срок. Пришло время делать коробочную версию BILLmanager, и тут мы столкнулись с новой проблемой.
Гибкость как проблема
Когда мы начали делать коробочную версию, тестировщики стали проверять все настройки, возможные в BILLmanager. Стало понятно, что:
- Прототипы недостаточно полны, чтобы охватить возможности гибких настроек BILLmanager.
- Архитектура старого продукта недостаточно гибкая для реализации многих дизайнерских задумок.
Чем дизайн приложения отличается от дизайна плаката
Когда дизайнер рисует плакат, верстает книгу или делает обложку для журнала, он работает со статичной информацией. У него есть конкретный текст, изображения и прочий контент.
Когда дизайнер проектирует интерфейс приложения или сайта, контент не статичен. Есть информация о типах данных, но самих данных нет. Скажем, есть блог, у каждой записи в блоге есть заголовок, аннотация, дата выхода поста, изображение и т. п. Конкретного заголовка нет, но есть понимание, что заголовок всегда будет, а дата всегда будет иметь формат даты.
В нашем случае все еще сложнее. Например, в BILLmanager на форме заказа выделенного сервера может быть разный набор полей. В одном случае обязательно будет процессор, диск и память, а в другом — нет (или будет, но, например, одним полем), и предсказать это невозможно. Мы не знаем не только конкретных данных, мы не знаем типы этих данных… и это усложняет работу.
С осени 2017 до весны 2018 г. мы перерабатывали прототипы и искали компромиссы. С некоторыми ограничениями по настройкам выпустили коробочную версию клиентской части BILLmanager 6 Beta в мае 2018 г.
Новая роль отдела UX-дизайнеров
Пока UX-отдел решал проблемы с гибкостью BILLmanager, в компании решили взяться за интерфейсы других продуктов, внедрить Scrum и дизайн-процессы в остальные команды. Компания начала переход к матричной структуре разработки продуктов: когда над всеми продуктами работают не все, а на каждый продукт — своя команда.
После выпуска нового интерфейса BILLmanager большая часть UX-отдела стала частью команды BILLmanager и сейчас занимается решением архитектурных проблем и мобильной версией клиентской части.
Одновременно мы начали реформировать команду UX: в новых условиях она не могла существовать как продуктовый отдел. Теперь задача UX-команды — работать не с одним, а с несколькими продуктами.
Как UX-отдел выглядит сейчас
Сегодня у нас есть центр дизайн-компетенций и есть рядовые дизайнеры, которые работают в продуктовых командах.
Центр дизайн-компетенций состоит из нескольких человек, включая visual-дизайнера. Они формируют дизайн-политику продуктов компании, работают над дизайн-системой и внедряют дизайн-процессы в Scrum-команды. В их задачи входит обучение UX-дизайнеров, а также разработчиков, продукт и проджект-менеджеров работе с UX-дизайнерами. Если у дизайнера в команде возникает сложная задача, центр дизайн-компетенций помогает ее решить.
Свой UX-дизайнер есть у каждой продуктовой команды. Он готовит прототипы для планирования спринта и контролирует, чтобы все нужное для разработчиков было в pixelperfect-версии. Он отвечает за то, чтобы в результате разработки получался продукт, соответствующий дизайну. Он — проводник дизайн-политики компании в свою команду.
Вот так за два года в ISPsystem изменились дизайн-процессы. От одного UX-дизайнера мы пришли к полноценному отделу, который работает по самым современным подходам.
Подробнее о работе «рядовых» UX-дизайнеров читайте в статье Анастасии Леонтьевой, которая проектирует новую версию ISPmanager.