Тестовые задания

Что думал в начале 2019
- Тестовое задание — важный этап при найме дизайнеров.
- Не всегда по портфолио удаётся понять, насколько у человека сильны навыки и как именно он мыслит. Например, человек мог работать в большой команде, и его личный вклад в итоговый результат не так уж значителен. Или его работы под NDA.
- Тестовое хорошо подсвечивает сильные и слабые стороны.
- Естественно, в качестве задания берётся ненастоящая задача, хотя и реалистичная. Если кандидат переживает, что компания воспользуется результатами его труда, это многое говорит о кандидате.
- Поскольку кандидат потратил на тестовое задание немало времени, нанимающая сторона тоже должна потратить время и дать развёрнутую обратную связь.

Что думаю в начале 2020
- Тестовые задания — это прошлый век. Гугл, Фейсбук, Интерком полностью отменили тестовые задания при найме дизайнеров.
- Главная причина — тестовые сильно перекашивают выборку кандидатов в сторону более молодых и менее опытных. Если человек уже состоялся в профессии, если у него есть свои проекты, семья, дети, коты и т. д., у него может и не быть нескольких свободных вечеров, ночей и выходных, чтобы сидеть над тестовым.
- Больше всего времени в работу над тестовыми заданиями готовы вкладывать молодые и свободные начинающие специалисты. Но далеко не всегда мы хотим нанимать только их.
- Особенный зашквар — тестовые про продукты самой компании (типа «нарисуйте нам новое приложение»). У кандидата заведомо нет и доли того контекста, который есть у людей внутри. Что ожидают увидеть нанимающие? Что кандидат угадает, о чём они думали последние полгода?
- Как без тестового получить достаточный сигнал при найме? Не так уж и сложно. Например, мы просим кандидата презентовать несколько своих последних проектов перед группой наших дизайнеров. И задаём очень много вопросов про всё: какая была задача, почему всё сделано именно так, какие ещё варианты рассматривались, как всё в итоге сработало, что бы человек сейчас переделал по-другому. Сразу и коммуникационные навыки проверяются, важные в нашей работе.
- Хороший процесс найма с несколькими этапами интервью и презентацией портфолио позволяет получить сигнал не менее точный, чем тестовое задание.
- А что если кандидат сам просит, чтобы ему дали тестовое? Иногда такое бывает. Не вопрос — пусть сам себе его и придумает, пусть сделает, заодно в портфолио выложит, сплошная польза.

Энтони из UX Movement написал, как показать в переключателе, какой вариант выбран.

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

Вместо инвертирования цвета может быть:

  • лёгкое затенение цвета заливки,
  • более жирная и тёмная обводка,
  • полужирное начертание текста.

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

https://ux.pub/pochemu-knopki-pereklyucheniya-toggle-buttons-sbivayut-s-tolku/

Принесла вам новый обзор на книжку Blitzscaling от Reid Hoffman, основателя LinkedIn.

Reid очень крутой и умный, у него отличнейший подкаст Masters of Scale, и на книгу у меня были высокие надежды.

Ну что сказать… Начали за здравие, кончили за упокой. Основная мысль довольно интересная – если хочешь стать глобальным стартапом, то в какой-то момент нужно ставить все на карту и инвестировать в взрывной рост: тогда приходят в действие network и virality effects, которые, в свою очередь, еще больше ускоряют рост и выручку.
С идеей можно, конечно, поспорить: например, Harvard Business Review в последнем выпуске восхваляет стартапы, которые фокусируются на постепенном и контролируемом росте https://hbr.org/2020/03/beyond-silicon-valley (https://hbr.org/2020/03/beyond-silicon-valley), – но о подходе, о котором рассказывает Reid, почитать тоже интересно, тем более, что его использует большинство стартапов в Долине. Понравились примеры с AirBnb и Dropbox.

Про это рассказывается на первых 100 страницах, все остальное (еще 200 страниц) – вода водой. Сначала Рид говорит, как успешно задизайнить бизнес-модель: по сути, это все те же старые-добрые постулаты из книжек 80-х годов про размер рынка, дистрибуцию, высокую маржинальность, (не)возможность масштабирования операционки, product market fit + из относительно новенького network effects. Если с network effects вы раньше не особо встречались, то эта часть, возможно, покажется интересной.

Части 3-6 – такие относительно философские рассуждения на тему, с пересказом идей из других книг или предыдущих глав. Мне очень это все напомнило The Hard thing about hard things https://t.me/proproduct/681 (https://t.me/proproduct/681), где автор под конец уже явно выдавливал из себя главы на немного рандомные темы. Знаю, что обе эти книжки многим нравятся: возможно, если вы заценили The hard thing, Blitzscaling вам тоже зайдет. Как говорится, на вкус и цвет :)

Вот здесь лежат отзывы на другие продуктовые книжки (не поверите, там даже есть позитивные))
https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe (https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe) ^_^

Команда это важно

Проблемы с UI, которые возникли на нашем проекте, были также очень тесно связаны с плохой коммуникацией в команде. Многие команды, которые смогли добиться больших успехов в UI, сделали это благодаря грамотному распределению сил в команде — кто-то прорабатывает продуктовую часть и UX, а кто-то подхватывает работу и начинает накидывать UI.

У нас этого не произошло, и на это было две причины.

Первая, и самая большая — я не хотел делиться работой. Я поставил себе глобальную цель использовать учебу как трамплин для раскачки своих навыков (я писал об этом ранее https://t.me/bukhtiyar/152), поэтому мне было в кайф брать на себя как можно больше нагрузки, а не быть менеджером команды. В итоге ребята, увидев мой запал, вместо того, чтобы включиться в конкуренцию за работу над проектом, отступили и дали мне полный карт-бланш.

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

Но чем ближе к защите, тем больше я понимал что не справляюсь в таком одиночном режиме. Мне нужна команда. Поэтому мы собрались с ребятами, и честно все друг другу высказали. Это оказало отрезвляющий эффект (к слову о ценности ретро в продуктовых командах). Со своей стороны я перестал ревновать проект, а ребята действительно активнее включились в работу.

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

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

Аврора Харли написала о непредсказуемой работе крестиков, закрывающих окна с формами.

Если пользователь открыл модальное окно с формой и что-то в ней изменил, становится непонятно, что произойдёт, когда он нажмёт на крестик. Сохранятся изменения или пропадут? В разных продуктах крестик ведёт себя по-разному.

Чтобы продукт вёл себя предсказуемо:

1. Запрашивайте подтверждение перед деструктивным действием, когда могут пропасть пользовательские данные. Например, если пользователь закрывает фильтр, не применив его, отобразите диалоговое окно: «Вы хотели бы применить фильтр перед возвращением в список товаров? Да / Нет».

2. Замените крестик на текстовую кнопку, которая чётко даст понять, что произойдёт: отмена или закрытие.

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

https://ux.pub/otmenit-ili-zakryt-dizayn-neodnoznachnyh-deystviy/

UX

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

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

Если продолжать тему про любимые занятия, то в первом семестре Антон в начале каждого занятия давал нам прокачку, после которой я теперь не боюсь сталкиваться с поиском быстрого и креативного решения любой проблемы. В этих прокачках нужно было очень быстро, за 10-15 минут, придумать, нарисовать и сделать бумажный прототип конкретной задачи. Например, придумать приложение по разделению счета в баре, по поиску собутыльника, приложение для знакомства в общественном транспорте, для настройки фортепиано и т.д. Круто, когда через 5 занятий до тебя наконец доходит алгоритм по которому нужно действовать, и ты начинаешь играться этими кейсами в своё удовольствие, но это уже отдельная история.
___________

Так вот, закончили мы исследовать наш продукт и настало время для конкретных действий. За блок UX нам было необходимо:

⁃определиться с парадигмой навигации (гамбургер меню, либо таббар);
⁃найти основную работу на которую пользователи нанимают наше приложение, воспользовавшись фреймворком JTBD;
⁃составить карту экранов;
⁃составить информационную архитектуру;
⁃нарисовать вайрфреймы экранов и собрать из них прототип;
⁃протестировать прототип;
⁃подготовить отчет по тестированию и внести правки.

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

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

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

Например, в нашем приложении есть карточка заказа — как, без реальных бизнес метрик, определить какая информация важна, а какая нет? Нужен просто адрес или подробная карта? Как подать информацию об авторе объявления? Что из этого важнее и должно располагаться выше?

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

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

Например, сначала мы сделали все макеты под роль дизайнера — дизайнер регистрируется в сервисе и хочет стать фрилансером. Собрали прототип и протестировали именно такой сценарий, в этом был и свой плюс, так как тестирование проходили в основном другие дизайнеры.
Но когда мы спросили заказчика — какая самая массовая аудитория специалистов, он ответил, что это репетиторы, мастера по ремонту и мастера красоты.
Получается, что правильно было бы выбрать один из этих трех типов специалистов. Мы подумали и выбрали мастеров ремонта, потому что в их кейсе встречается практически все элементы дизайна — и карта и шаблонные данные (площадь стяжки, тип пола) и текстовое описание вакансии. В итоге нам пришлось все перерисовать.

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

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

Подводя итог — на блоке UX каждая команда сначала придумывает бизнес ограничения, а потом героически их преодолевает.

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