Журнал (ошибок) вопросов

Мы — дизайн-отдел в SVK.Digital. Решили поделиться опытом, как улучшить качество и ускорить работу на проектах с помощью анализа, типизации и устранения ошибок, возникающих при реализации.

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

Идею мы взяли из книги Рэя Далио «Принципы». Главная задача этого инструмента — выявить проблемы и их причины, проработать их и улучшить результат в будущих проектах за счет того, что эти проблемы уже не повторятся. Если сотрудник зафиксировал ошибку, ему ничего не грозит. Наказание или сильная критика приводят только к избеганию ответственности и замалчиванию проблем. Поэтому суть идеи — анализ, а не определение виноватого.

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

Мы назвали журнал «Журналом вопросов», чтобы снизить негативное влияние слова «ошибка». Не ошибается только тот, кто ничего не делает. Или тот, кто делает, но не думает и не сталкивается с последствиями. Мы смотрим на ошибки как на возможность извлечь опыт.

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

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

Для ведения журнала используем доску в Trello, где карточка – это ошибка,
в которой мы кратко описываем, что произошло. Добавляем ссылки на проект/ задачу/ скрин. Приглашаем в карточку ответственного. Если можно посчитать, то отмечаем, сколько времени ушло на исправление ошибки. Обязательно присваиваем карточке категорию.

Для экономии времени при ведении журнала создали в Trello шаблоны карточек с уже готовым содержанием и метками категорий.

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

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

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

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

Такие вопросы мы прорабатываем в user flow и тестируем готовые решения.

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

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

Элемент в макете не вмещает реальное количество контента.

Перед началом работ мы запрашиваем у клиента контент, который будет
на сайте. Однако, частая ситуация, что контент готовится не “до” дизайна,
а после завершения этапа разработки. Поэтому есть правило: показывать в UI kit все краевые состояния всех элементов.

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

Например, в адаптиве для мобильного разрешения используется стиль текста от десктопа – его просто забыли переназначить. Обычно такие ошибки появляются, когда исполнитель торопится, не внимателен. Глаз «замыливается», и не видит. На верстке эти недочеты выявляются, и нужно исправлять макет. Помогает такая проверка в Figma: Edit - Select all with same text properties

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

Многое зависит от того как мы общаемся по проекту. Вовремя ли назначили встречу. Насколько информативна обратная связь по проекту, насколько вся команда в курсе ситуации.

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

Ошибки зависят от уровня исполнителя, от специфики проекта и наличия корректной информации. Журнал не сработает:

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

Для поддержания рутины мониторинга ошибок наш арт-директор Таня ввела правило: к каждой планерке исполнитель заносит в журнал минимум 5 найденных ошибок. Это похоже на игру, но зато добавляет позитива. Такое микро-ретро в ленте.

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

Автор статьи: Елена Снегирёва, UX/UI дизайнер SVK.Digital