Журнал ошибок вопросов
Мы — дизайн-отдел в SVK.Digital. Решили поделиться опытом, как улучшить качество и ускорить работу на проектах с помощью анализа, типизации и устранения ошибок, возникающих при реализации.
Год назад мы начали вести журнал ошибок, в который записываем все проблемные места при работе над проектами.
Откуда появилась идея
Идею мы взяли из книги Рэя Далио «Принципы». Главная задача этого инструмента — выявить проблемы и их причины, проработать их и улучшить результат в будущих проектах за счет того, что эти проблемы уже не повторятся. Если сотрудник зафиксировал ошибку, ему ничего не грозит. Наказание или сильная критика приводят только к избеганию ответственности и замалчиванию проблем. Поэтому суть идеи — анализ, а не определение виноватого.
Также нас вдохновила книга Мэтью Сайеда «Принцип «Черного ящика», в которой на потрясающих по убедительности примерах автор доказывает, что ошибки — это путь к успеху. Конечно, при условии их внимательного анализа и внедрении изменений в процессах.
Почему журнал вопросов?
Мы назвали журнал «Журналом вопросов», чтобы снизить негативное влияние слова «ошибка». Не ошибается только тот, кто ничего не делает. Или тот, кто делает, но не думает и не сталкивается с последствиями. Мы смотрим на ошибки как на возможность извлечь опыт.
Запись в журнале надежнее и нагляднее воспоминаний. На дизайн-планерках мы прорабатываем ошибки и думаем, как избежать их в будущем. Все в команде могут извлечь опыт и поучаствовать в обсуждении.
Задаемся вопросами:
Что произошло?
Почему?
Как нужно было поступить, чтобы этого не случилось?
Что нужно сделать, чтобы улучшить результат?
Как поступим в следующий раз?
Почему так важно зафиксировать ошибку?
Наша психика защищается от негативных переживаний и со временем вытесняет их. Мы с детства привыкли, что ошибка - это плохо. Чувствовать себя в чем-то неправым неприятно. Поэтому мы быстро забываем ошибку или не признаем, перекладываем ответственность на обстоятельства. Если признать, обсудить и проанализировать ошибку, то можно заставить мозг запомнить ситуацию и принятое решение.
Как мы работаем с журналом
Для ведения журнала используем доску в Trello, где карточка – это ошибка, в которой мы кратко описываем, что произошло. Добавляем ссылки на проект/задачу/скрин. Приглашаем в карточку ответственного. Если можно посчитать, то отмечаем, сколько времени ушло на исправление ошибки. Обязательно присваиваем карточке категорию.
Для экономии времени при ведении журнала создали в Trello шаблоны карточек с уже готовым содержанием и метками категорий.
Например, приходит срочная задача, и исполнитель рассчитывает, что до него в макете коллеги соблюдали принятый регламент, и он уложится в обещанное время. Но в файле оказываются недоделки, которые требуют дополнительного времени на исправление. Исполнитель вносит в журнал ошибки, которые обнаружил и отмечает ответственного. Становится ясно, почему сроки сдвинулись. Не важно, чьи это ошибки, важно, их отметить, проработать, и донести до всех участников.
Фиксируем ошибки и на этапе передачи макетов в верстку. У фронтендеров возникают вопросы, почему выбрано именно такое решение или почему что-то не учли.
Дизайнеры забирают на проработку эти вопросы, обсуждают и меняют регламенты, если необходимо. В результате дальнейший программинг ускоряется, а количество возвратов задач в доработки уменьшается.
Примеры ошибок в нашем журнале
Нарушен регламент работы в Figma
- Не сделан компонент
- Не привязан стиль текста/цвета
- Не применяется Autolayout (AL)
- Не соблюдается UI kit
- Не вынесен компонент в UI kit (оставлен в макете, вынесен не мастер-компонент)
- Ошибка в компоненте
- В UI kit положен не компонент
- Нет вариантов у связанных компонентов
- Компонент задублировался (такой же по оформлению, такой же по смыслу, для того же действия)
- UI kit оформлен небрежно, трудно найти элемент
Эти ошибки чаще совершают новички. Не понимают процесса, не имеют опыта для аккуратной и техничной работы. Поэтому у нас есть регламент командной работы в Figma, где мы описали правила работы в макете с учетом требований верстки и эффективности.
Ошибка стиля (UI)
- Стиль проекта/элемента не решает задачу
- Стиль текста выбран ошибочно (крупный/мелкий/блеклый)
- Отступ нарушает правило близости (навигация и информационная иерархия затруднены)
- Решение по стилю не принято стейкхолдерами
Здесь поможет прокачка насмотренности, детальный брифинг клиента, защита мудбоарда перед началом работ и досточное время на эскизный поиск.
Ошибка использования (UX)
- Сложно взаимодействовать (понять/увидеть/применить)
- Элемент не считывается, вводит в заблуждение
Такие вопросы мы прорабатываем в user flow и тестируем готовые решения.
Ошибка сценариев
- Не предусмотрен сценарий в макете
- Изменение сценария и/или новый сценарий влияет на сделанный макет
Когда мы получаем задачу от менеджера, то сначала её обдумываем и задаем вопросы. Менеджер отвечает сам или уходит за информацией к клиенту. Готовое решение ревьюит арт-директор.
Но иногда случается, что какой-то сценарий взаимодействия все равно упустили. Таких ошибок помогает избежать погружение в проект всех участников, еженедельные митинги команды и ведение проектной документации.
Несоответствие контенту
Элемент в макете не вмещает реальное количество контента.
Перед началом работ мы запрашиваем у клиента контент, который будет на сайте. Однако, частая ситуация, что контент готовится не “до” дизайна, а после завершения этапа разработки. Поэтому есть правило: показывать в UI kit все краевые состояния всех элементов.
Переиспользование
- Отрисован макет заново, вместо использования готового
- В верстке внесли изменения, а в макете продолжается использование неактуальных элементов и стилей
- Близкие по функции и оформлению элементы используются по-разному
- Сделанные ранее кейсы не используются
- Изобретается «велосипед»
- Проводится кастомизация для базовых компонентов (для проектов на фреймворке)
Правильно составленный UI kit и документация проекта, в которых легко разобраться дизайнеру, который прежде в проекте не участвовал
Технический баг
- Явный баг (так быть не должно в принципе)
- Поехал отступ/текст/цвет
- Послетали привязки к компонентам
- В макете оставлено несколько вариантов
- По весу макет перегружен (лишние слои, лишние страницы, крупный размер изображений)
Например, в адаптиве для мобильного разрешения используется стиль текста от десктопа – его просто забыли переназначить.Обычно такие ошибки появляются, когда исполнитель торопится, не внимателен. Глаз «замыливается», и не видит. На верстке эти недочеты выявляются, и нужно исправлять макет. Помогает такая проверка в Figma: Edit - Select all with same text properties
Ошибка коммуникации
- Неверно понял ТЗ
- Члены команды неправильно поняли друг друга
- Ошибка в терминологии (не верно назван элемент/функция/цель)
- Перебои со связью дали неверное понимание задачи
- Ошибки из разряда «говорил одно, имел в виду другое»
Ошибки коммуникации эмоционально труднее всего фиксировать и прорабатывать. Часто они затрагивают не один отдел, а систему работы в целом. На исправление подхода требуется иногда много времени и сил. Помогает прокачка эмоционального интеллекта и софт скиллов. На эту тему есть книги и тренинги. Начать можно с книги Максима Ильяхова «Новые правила деловой переписки».
Многое зависит от того как мы общаемся по проекту. Вовремя ли назначили встречу. Насколько информативна обратная связь по проекту, насколько вся команда в курсе ситуации.
Это выходит за рамки ведения журнала, но понимание, что к результату привела именно ошибка коммуникации - шаг в верном направлении.
Когда журнал может не сработать
Ошибки зависят от уровня исполнителя, от специфики проекта и наличия корректной информации. Журнал не сработает:
- Если исполнители часто меняются и не заинтересованы вести какую-то историю. Мы сталкивались с тем, что журнал игнорировали люди, которые не хотели признавать ошибки. Или жалели на это время. У некоторых не было навыка описывать проблемы, в записях было трудно разобраться;
- Или если нет ответственного, который следит за этим процессом и напоминает всем, чтобы не забывали вносить записи.
Такой журнал актуален скорее для постоянных команд, не для фрилансеров. Проработка ошибок обязательно должна происходить с правильной коммуникацией, чтобы ошибкой не страшно было делиться. Это просто сбор информации, из которой можно делать выводы.
Для поддержания рутины мониторинга ошибок наш арт-директор Таня ввела правило: к каждой планерке исполнитель заносит в журнал минимум 5 найденных ошибок. Это похоже на игру, но зато добавляет позитива. Такое микро-ретро в ленте.
Результаты фиксирования ошибок
Через 3 месяца:
- обнаружили основные типы ошибок, их причины и способы решения;
- сняли флер перфекционизма* при командной работе над проектом;
- сфокусировались на улучшении процессов;
- поняли слабые стороны каждого из исполнителей, чтобы помогать их прокачать.
Через полгода:
- уменьшили количество типовых мелких ошибок;
- подробно прописали регламент командной работы на основе полученной информации;
- сделали гибкий шаблон UI kit для проектов;
- увеличили скорость работы в дизайн-отделе;
- собрали обратную связь от всех членов компании – фронты тоже ускорили свою работу.
Через год:
- можем предотвратить серьезные ошибки, которые успели изучить из прошлого опыта;
- свели потери времени на ведение журнала к минимуму, благодаря настройке шаблонов Trello и устранения большинства мелких ошибок;
- клиенты стали хвалить дизайн-отдел за полную прозрачность процессов и понимание, на каком этапе находится проект;
- проверили эффективность инструмента в отделе дизайна и можем его рекомендовать в другие отделы и вам.
*Мы приняли тот простой факт, что ошибаются все, и результат тем лучше, чем лучше мы работаем над собой.
