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