Насколько влияет самое первое письмо будущему работодателю на потенциальное трудоустройство

Осенью прошлого года мне довелось поучаствовать в любопытном исследовании. Ваня Васильев, руководивший в разное время дизайном Альфабанка и Scentbird, решил выяснить, насколько влияет самое первое письмо будущему работодателю на потенциальное трудоустройство.

Эксперимент проходил так:
- Ваня нашёл десяток примеров описаний вакансий продуктового дизайнера и скомпилировал из них усреднённый текст (https://research.mintblaster.com/#vacancy). Cамо по себе, кстати, интересное упражнение.
- Собрал группу из 16 экспертов (https://research.mintblaster.com/#experts) (в которую попал и ваш покорный слуга) — нанимающих дизайн-руководителей и руководительниц из Яндекса, Альфа-Банка, Почты России, Сбербанка, МТС, Mail.ru, Acronis, Miro, Revolut и других компаний.
- Сделал лендинг (https://research.mintblaster.com/) и предложил заинтересованным дизайнерам написать ровно одно письмо — такое, как если бы они по-настоящему хотели устроиться на работу. Всего удалось собрать 243 отклика, из них 228 человек отметили, что действительно искали работу.
- Дальше каждый эксперт отсматривал заявки дизайнеров-претендентов. Отреагировать на заявку можно было только кнопками «да» и «нет» — продолжил ли бы я общение с кандидатом на основании этого первого письма или отказал бы сразу. Практически Тиндер!
- Чтобы результаты были точнее, каждое письмо независимо оценивали минимум семь экспертов.
- В конце каждому кандидату пришла взвешенная оценка шансов оказаться приглашенным на собеседование на основании письма.

Получились такие результаты:
- Кандидаты распределились по нескольким группам по количеству положительных оценок экспертов:
- 3% — Все эксперты нажали «да».
- 8% — Больше 80% положительных голосов экспертов.
- 25% — От 50% до 80% положительных голосов.
- 22% — Между 30% и 50% положительных голосов.
- 40% – меньше 30% положительных голосов.
- (ещё 2% были отмечены как спам.)
- То есть по-настоящему сильных откликов — всего 11% (первые две группы). Это очень соотносится с моим опытом поиска дизайнеров.
- Почти половина всех откликов — 40% — очень слабые.
- Другая добрая половина (47%) попала в средние группы, когда голоса экспертов разделились.
- В среднем эксперты тратили 50 секунд на просмотр одной заявки (включая просмотр портфолио и вообще всех приложенных ссылок). Вот столько времени у письма есть, чтобы произвести впечатление.

Продираясь через десятки писем, я искал только одно: портфолио с хорошими работами (писал про это давным-давно (http://t.me/desprod/9)) и/или внятный свежий опыт работы над продуктами. Всё.

Остальное не важно. Длинные тексты, перечни навыков и дипломов, списки инструментов или интересов, желания и мечты — всё это больше мешает. Стаж работы вообще идёт во вред, если не подтверждается результатами.

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

Вот, кстати, Ксения Стернина, которая тоже была экспертом в Ванином исследовании, подробно рассказала про то, что стоит и не стоит писать в письме работодателю (https://blog.uxssr.com/2020/01/29/cover-letter-for-designers/).

Почитать полностью все результаты исследования можно тут (https://designer.mintblaster.ru/results). Там же Ваня проводит следующий эксперимент, в котором кандидаты могут рейтинговать друг друга. Кстати, по отзывам участников, когда они смотрят чужие письма и работы и сравнивают с тем, что написали сами, очень хорошо начинают понимать, как стоит писать и как не стоит.

Боязнь простых решений

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

Бояться надо сложных решений.
Любое решение, в котором есть куча "если" — бомба замедленного действия.

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

Чем больше "если", тем больше проблем в поддержке, в развитии, в понимании.
В итоге, в какой-то момент на отдельные логические ветки начинают забивать или забывать: что-то развивается, а что-то начинает устаревать.

Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".

В общем, надо стремиться к упрощению.

Брюс Стерлинг о пользе написания дизайн-фантастики

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

Я пишу "дизайн-фантастику" уже много лет. Дизайн-фантастика во многом похожа на научную фантастику; на самом деле, нормальному читателю и в голову не приходит разделение этих двух понятий. Основное различие заключается в том, что дизайн-фантастика имеет больше прикладного смысла на странице книги, чем научная фантастика. Научная фантастика хочет использовать величие и достоверность науки для своего собственного фокуса-покуса, но дизайн фантастики может быть более практичным, более полезным. Она приносит в жертву некое чувство магии, но гораздо ближе к пылающему накалу социально-бытового конфликта»

Записал вводное видео про регулярные выражения

Предпоказ выявил закипание мозгов у зрителей. Но более подробное видео получилось в полчаса длиной и скучное.

https://youtu.be/b-EkpnLINKw

Если кратко. Регулярные выражения помогают искать в тексте куски по сложному шаблону. Например, шаблон /[0-9]+/ найдёт в тексте все цифры, которые повторяются один или более раз подряд.

Но это самый простой случай. В примере я разбираю как работает вот такое выражение: /^(Смартфон\s)?(Apple)\s([a-z ]+)\s(\d+)GB\s(.*)\(([^(]+)\)\s([\d ]+)\sруб.$/igm.

Регулярные выражения помогают обрабатывать большие объёмы данных и приводить их к читаемому виду.

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

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Есть три группы ограничений, которые уводят в общение тет-а-тет.

1. Технические.
– Мы тестируем интерфейсы и важно видеть, как именно люди держат телефоны. Поэтому для удалённых тестов нужны камера и штатив.
– Надо рассылать инструкции, просить пользователя установить необходимое оборудование и подключить наушники. Уходит минут 20 на настройку и технические неполадки.
– Многие респонденты просто технически не продвинуты и не могут всё подготовить.
Эта возня отъедает время общения и терпение респондента.

2. Коммуникация.
– Часто люди волнуются перед тестом, стесняются. Когда разговариваешь с респондентом лично, представляешься и завязываешь беседу, располагаешь человека к себе.
– Люди быстрее доверят важную или личную информацию живому человеку, а не голосу в наушниках и картинке на экране.
– Важно и эмоциональное состояние — показатель отклика и реакции на удобство интерфейса: качественно такое можно считать только в офлайне.
– Кроме того, во время удалённого разговора респондента могут отвлечь: когда вы общаетесь лично, человек посвящает около часа тестированию один на один.
– Вы видите ситуацию целиком, считываете эмоции, реакцию, поведение и позу пользователя — это даёт контекст, который теряется при удалённом тесте.

3. Секьюрность.
– Мы работаем с чувствительными данными клиента, тестируя финансовые сервисы иногда на данных пользователя. В онлайне запустить такое сложно. У пользователя меньше доверия — он может опасаться, что лишние люди увидят экран.
– С другой стороны, мы работаем с банками-заказчиками под NDA и должны гарантировать, что новый продукт не утечёт за пределы команды дизайна, разработки и тестов до запуска проекта.

Иногда от этого приходится отходить, например, когда респонденты из Европы или США. Всё это грозит двойной потерей качества — из-за онлайна и языковых барьеров.

История одного дня пользователя

Еще один метод, способный проиллюстрировать флоу взаимодействия пользователя с будущим продуктом с учетом контекста. Этот метод помогает понять мотивы и примерный бэкграунд в котором находится пользователь — что было до того как у него возникла потребность в продукте? Что он делал после, почему поступил так, а не иначе?

Итак, история про Алексея:
«Алексей офисный работник, который проводит на работе с 9 до 19. У него нет свободного времени. Алексей женат, но жена, также, все время проводит на работе. Они живут в старой квартире, которая досталась от бабушки. Жена, периодически пилит Алексея, что он никак не может сделать хотя бы косметический ремонт. В конце концов, Алексей накопил денег и решил для начала поменять старый паркет. Он задумался над тем, что ему нужен хороший специалист, который выполнит конкретную работу. Но он не знал как отобрать нужного кандидата, чтобы и по цене не обманули и по качеству не кинули. На работе Алексей поделился проблемой со своим коллегой Леонидом, и тот посоветовал сервис профи.ру.

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

В итоге, Алексей получил список подходящих специалистов. Он выбрал лучшего по соотношению рейтинга/цены/отзывов. Оставил заявку. Приложение потребовало сделать оплату, Алексей воспользовался Apple Pay. Оплата прошла. Через какое-то время мастер ответил согласием и взялся за заказ.

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

-сделана ли работа полностью?
-производились ли дополнительные работы?
Приложение просит оценить специалиста и его работу, он ставит 5 звезд.
После чего Алексей видит, что заказ закрыт и деньги за работу списаны.
В этот вечер у Алексея был секс».

Как видите, мы также в первую очередь стремились показать особенности сервиса глазами клиента — но, я думаю, подобное проговаривание сценариев на ранней стадии помогло нам понять в какую сторону стоит двигаться.