Общаемся с разработкой

Бывает такое, сидишь себе на очередном грумминге с разработкой и тут начинают сыпаться странные термины «микрофронты», «апи», «дергать ручку», «кафка». Сидишь и думаешь — Чегоооо бл#*ь? Если так, то этот лонгрид спешл вор ю.



Сразу спойлер: я не разработчик (дизайнер), никогда им не была и имею поверхностное представление о работе кода. НО, даже такого уровня достаточно, чтобы не впадать в тильт на рабочих созвонах и уверенно отстаивать свои идеи.



Итак, зачем дизайнеру понимать термины разработки?


Первое и самое базовое — так быстрее вникать в задачу. Когда вам приходит таска, а из информации только схемы бизнес-процесса и куча писанины что с чем связывается и кто что дёргает, приходится тратить добрые часы на выяснение.


Умением читать аналитические диаграммы (сиквенсы процессов) вы упрощаете себе жизнь в 10 000 раз. Вам не нужно отвлекать разработку, не нужно ставить созвоны на пояснения странных слов. Просто выписываете текстом, что вам не ясно из процесса и идете обсуждать предметно. Экономия времени и вам и команде


Второе и не менее базовое — появляется понимаете, о чем говорят ваши коллеги. Следовательно, лучше знаете свой продукт и его ограничения
. Теперь гипотезы генерятся качественнее.

Третье — вытекает из второго, теперь вы можете проектировать лучше и точнее. Нет ничего обиднее, чем потратить спринт впустую, потому что не учли тех. особенности. Нарисовать можно все, но не пошлют ли вас ваши же разрабы?)) 
Проектируя лучше и точнее, ну вы сами знаете, лучше будет опыт и вот это все…


Четвертое — уважение в команде. Сколько написано статей про передачу макетов, термины дизайна для недизайнеров, кажется уже все всё знают. Только дизайнеры почему-то не особо хотят вникать в смежную предметную область и предпочитают сидеть в свое мани-мирке. Без обид. Я сама так делала до недавнего времени.

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


Заботливо собрала для вас понятные видео и статьи о базовых терминах в разработке:




• Что такое микрофронты/ микросервисы/ архитектура проекта
• Что такое апи и что оно делает
• Как читать сиквенсы процессов
• Про ручки и не только

И не забываем
Если вам ничего не понятно, конечно спрашивайте у разработчика, это нормально. Вы точно не покажитесь глупым, скорее наоборот (но сначала попробуйте погуглить). Взаимный интерес к работе друг друга и поддержка сильно влияют на конечный продукт.

@OpenSource_ux
Лайк, шэр, подписка))

Итак, про сам whiteboard
Тайминг: ~50 минут
Формат: удаленно
Тулы: Figma
Этапы: Введение - Понимание задачи - Брейншторм - Пример решения - Защита

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

Ну шо

Как это происходило у меня. Пришла на созвон, вкратце прогнали по теории, но это необязательно. Затем начался сам whiteboard. Продублировала себе файл с брифом и расшарила экран. Сам бриф состоял из краткого описания задачи, требований, контекста, пары юзер-сторией. Бывает,что контекст отсутствует, и тут надо включить навыки UX интервью и поспрашивать.

Тут было бы неплохо описать интервьюеру, по какому фреймворку будете работать. Например сначала соберу данные 10 мин, поресерчу 15 мин, накидаю гипотезы 10 мин и отрисую решение за 10-15 мин. Это покажет, что вы придерживаетесь дизайн-процесса и системно подходите к любой таске. Было такое (но не в рамках этого вб) когда я уделила меньше внимание нормальному пониманию задачи и качественному этапу брейншторма. В итоге сильно забуксовала на первом решении и уже подбивала его под условие, что не окэй)

Ознакомилась с вводными, начала расспрашивать непонятные детали. Параллельно составляла карту полученных знаний. Правильно понять задачу — это 80% успеха. Даже без очевидных вопросов есть риск, что уйдете не туда и будете решать несуществующие проблемы, в итоге провалите собеседование.

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

После сбора первичных данных, пошла составлять user flow, не картинками, просто текстом. По мере накидывания flow задавала еще больше уточняющих вопросов.

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

Почему такое решение

Поясняйте каждую гипотезу/идею, которую хотите внедрить, исходя из задач. Я сверялась в ходе вб с задачами и сториями, поговорила про возможные сценарии. Также рассказала, как и что можно тестировать, как собрать реальные данные и доработать решение. Интервьюер может спросить, что будет, если у нас 100 заявок? А если три? А если пользователь не поймет, как залогинился? А если заявка будет зафэйлена? А что будем отображать тогда? А как изменится флоу? Всякие тупиковые кейсы хорошо шатают предложенное решение. На этом этапе я заметила несколько упущений и вернулась снова в фазу сбора информации, чтобы понимать точнее ограничения.

Рисовала примитивными квадратиками, линиями, подключила Figma Pencil. Если у вас подготовлен любимый UI-кит или хорошая вкладка assets, пользуйтесь ассетами, это удобно и ускоряет работу над визуальным решением. На этом этапе можно не запариваться насчет UI, главное показать, почему вы пришли к этому решению. Тут кстати я заготовила заранее площадки с рефами, UI Kit который часто использую. Но в итоге они мне не понадобились, защищала решение на квадратиках и линиях.

Никто не запрещает пользоваться референсами, если умеете их быстро находить. Учтите, что весь процесс от получения задачи до финального результата должен занимать ~55 минут. Если укладываетесь, пожалуйста. Очень помогает насмотренность, которую нужно тренировать. Тоже скилл, которой стоит прокачивать всегда.

Ну и финалочка — защитить свое решение. Пробежаться по брифу, пояснить ход работы, рассказать про свое решение. Обязательно ответить (или подумать вслух) на вопросы Почему именно такое решение? А что будет, если ..? Какие метрики успеха? А что дальше?

Можно порассуждать как бы вы тестировали решение и какие данные бы собрали, чтобы двигаться дальше.

Вайтборд я прошла хорошо, меня взяли, хоть и переживала. Но попробовала воспринимать это просто как разговор в переговорке и обкатывание идеи с коллегами. Поэтому желаю и вам успешных собесов!

Полезные ссылки оставлю внизу. Подготовила пост бриф в своем телеграме, можете быстро ознакомиться с самым важным, если хотите. Всем спасибо, до связи.

@OpenSource_ux

https://neiko.notion.site/Whiteboard-3e7a4c319f2b45d0848d451bb959497b

https://habr.com/ru/articles/713366/

https://www.uxdesigninstitute.com/blog/design-challenges-for-ux-designers/

https://youtu.be/c8fDRm2qnQo?si=UP14grdx5WypkNop