———
Оговорюсь, что полностью не эстимирую свои задачи (это делает лид или стаффер), но я могу влиять на скорость выполнения и процесс (если возможно). Ну и за мной посматривает стаффер,
———
🔷 Итак, поехали. Первым делом, конечно, нужно ознакомиться с постановкой таски. Перечитываю её несколько раз, чтобы понять, что хотят/ где/ зачем/ кто стейкхолдер + к кому обращаться с вопросами (если вводных мало или нет — уточняю у лида/стаффера). Для внутренних проектов заказчиками обычно выступают сотрудники компании (аналитики, менеджеры, другие отделы).
Если есть ссылки на документацию — обязательно изучаю перед встречами. Выписываю в словарик незнакомые термины, чтобы быстро пробежаться на дэйли со стаффером или уже что-то доуточнить на след.этапе. Про словарик тема, это еще поняла до Озона, когда сталкивалась с похожими сложными продуктами. Пользователи-специалисты общаются на своем слэнге и ожидают, что система будет делать тоже самое 😓
🔷 После этого, как правило, пишу список доп. вопросов. Часть из них я могу задать команде, т.к ребята уже в курсе и знакомы с большинством продуктов. Всё, что касается бизнес-процессов, логики в рамках которой живет задача, оставляю на созвон с аналитиком.
Параллельно в Figma собираю все артефакты, чтобы прийти на встречу подготовленной и не возвращаться к этому лишний раз. Делаю описание юзер-флоу текстом или картинками для себя. Перетаскиваю экраны, которые потенциально будет затрагивать задача. Повезло, если уже указаны экраны/ флоу. Но иногда инфу нужно добыть самостоятельно.
🔷 Затем назначаю встречу, где формирую общее понимание и у себя, и у заказчика. Дополняю требования. Также обсуждаем какие-то артефакты и вообще все, что аффектит.
Стоит оговориться, хоть за мной наблюдает сеньор дизайнер, стараюсь оперативно решать вопросы по-возможности сама, чтобы стаффер подключался только в моменты дизайн-ревью и при возникновении сложных вопросов.
🔷 Далее стандартно отрисовываем сценарий или нужный кусочек. Учитываем ДС-ку и правила оформления задачи в команде.
Минутка очевидного:
Кроме консистентности ui, нужно понимать логику именно вашей части продукта и узкие паттерны именно вашего пользователя.
Дизайнеры из команд, работающих в веб-сервисе для B2C, используют одни правила коммуникации с пользователями и набор знакомых им паттернов. Дизайнеры внутренних продуктов используют совершенно другие. Каждая часть большого внутреннего продукта наследует логику «собрата».
То есть, я могу работать с 3-4 разными под продуктами в рамках одного большого стрима, и мне нужно понимать, на каком этапе сценария, где и в каком виде мой пользователь привык взаимодействовать при решении задач, когда мы вводим такую-то шторку, меню или инпут. Как собираем экраны, какие именно компоненты ДС-ки используем и как. Есть ли что-то локальное и т.д.
🔷Собираю все, описываю сценарии. Пишу спеку для разработки и могу зафиналить встречей-презентацией заказчикам (если надо). Где-то тут тестирование.
Естественно, возникают моменты, когда решение могут развернуть на этапе согласования. Тогда процесс откатывался на этап сбора аналитики и добавлялся еще круг дизайн-процесса.
Бывало и такое, что я защищала решение со стороны пользователя (да, даже стажер/джун/джун+, по-моему мнению, должен сам общаться со стейкхолдерами за решения), но бизнес требовал здесь и сейчас или разработка пока не могла взять это. Тогда делаем требуемый минимум для статуса Done, и на всякий закидываем лучшую версию на обсуждение.
В любом случае лучше не ждать
———
Решила поделиться процессом сейчас, уверена, со временем все сильно измениться. Но пока так) Пока у меня нет задач на нормальные исследования, а очень хочется, поэтому замучаю лида с этим. Интересно же, во что по итогу выливается.
А как вы работаете над задачей? 💃