Мы в Магнит с февраля ведём найм дизайнеров. Поток заявок довольно велик, иногда доходит до нескольких собесов в день.
Огорчает то, что 80% кандидатов, среди которых как мидлы, так и синьоры, не хотят или просто не знают, как рассказать про себя и свой опыт. Вместо рассказа о своей роли в продукте, своих взаимодействиях с командой, участии в процессах и влиянии на метрики продукта, все рассказывают про бизнес заказчика, про компанию и про то, как они целыми днями собирали экраны в Фигме. Часто это отягощается отсутствием какой-либо структуры подачи кейса, будто дизайнер сам не понимает, о чём рассказывает. В таких случаях почти со 100% вероятностью следует отказ.
Рекомендую самую простую и наглядную структуру презентации кейс-стади — STAR:
S (Situation — Ситуация):
дизайнер описывает ситуацию, в которой он оказался, каковы были ожидания от него, в какой стадии был продукт и был ли он или предполагалась разработка с нуля и др. Нанимающему важно понять то, с чего дизайнер начал в этом проекте.
T (Task — Задача):
дизайнер поясняет, какая была задача, которую нужно было решить в этой ситуации, как она валидировалась, кто её ставил, как это было интегрировано в дизайн-процесс, как дизайнер взаимодействовал с заказчиком, кого привлекал в помощь и пр.
A (Action — Действие):
дизайнер рассказывает, какие конкретные действия он предпринял для решения задачи, с кем взаимодействовал, на что повлиял, как проверял свои решения, какие были трудности, возможно ошибки.
R (Result — Результат):
дизайнер описывает результат своих действий и то, как это повлияло на метрики продукта, чего у далось достичь, чему научиться, какие сделать выводы, как изменился продукт.
Этот простой подход поможет выстроить структуру рассказа и сосредоточиться на важных аспектах кейса. С актуальными вакансиями в Магнит можно ознакомиться здесь ❤️
@designboat
Огорчает то, что 80% кандидатов, среди которых как мидлы, так и синьоры, не хотят или просто не знают, как рассказать про себя и свой опыт. Вместо рассказа о своей роли в продукте, своих взаимодействиях с командой, участии в процессах и влиянии на метрики продукта, все рассказывают про бизнес заказчика, про компанию и про то, как они целыми днями собирали экраны в Фигме. Часто это отягощается отсутствием какой-либо структуры подачи кейса, будто дизайнер сам не понимает, о чём рассказывает. В таких случаях почти со 100% вероятностью следует отказ.
Рекомендую самую простую и наглядную структуру презентации кейс-стади — STAR:
S (Situation — Ситуация):
дизайнер описывает ситуацию, в которой он оказался, каковы были ожидания от него, в какой стадии был продукт и был ли он или предполагалась разработка с нуля и др. Нанимающему важно понять то, с чего дизайнер начал в этом проекте.
T (Task — Задача):
дизайнер поясняет, какая была задача, которую нужно было решить в этой ситуации, как она валидировалась, кто её ставил, как это было интегрировано в дизайн-процесс, как дизайнер взаимодействовал с заказчиком, кого привлекал в помощь и пр.
A (Action — Действие):
дизайнер рассказывает, какие конкретные действия он предпринял для решения задачи, с кем взаимодействовал, на что повлиял, как проверял свои решения, какие были трудности, возможно ошибки.
R (Result — Результат):
дизайнер описывает результат своих действий и то, как это повлияло на метрики продукта, чего у далось достичь, чему научиться, какие сделать выводы, как изменился продукт.
Этот простой подход поможет выстроить структуру рассказа и сосредоточиться на важных аспектах кейса. С актуальными вакансиями в Магнит можно ознакомиться здесь ❤️
@designboat