Адам Сильвер написал о всплывающих подсказках (tooltip).

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

Проблемы:
1. Пользователи не всегда замечают, что подсказки есть.
2. Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть.
3. Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки.
4. Подсказки могут обрезаться на маленьких экранах.
5. Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»
6. Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).

Решения:
1. Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс.
2. Подпишите иконки или замените их на текстовые ссылки.
3. Сделайте важные пояснения видимыми по умолчанию.
4. Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.

https://ux.pub/problemy-s-podskazkami-tooltips-kak-ih-razreshit/

Время собирать фрукты

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

В выступлении Евгения Гурьянова из DocDoc на Product Sense (да, я всё ещё досматриваю то, что не успел послушать вживую в Минске) было про опыт использования этого подхода в масштабах компании и с активным использованием экспериментов. Команда Евгения проводит быстрые A/B проверки гипотез и примерно 2-3 из 10 экспериментов приносят рост конверсии. Причем не на пару процентов, как это обычно бывает, а сразу на 20-30! Вы удивитесь какие простые изменения могут дать заметный прирост в заявках от клиентов и, следовательно, в деньгах для компании!

Формат доклада тоже хорош. Фрукты Евгений классифицировал — будут и ананас, и груша, и даже картошка. Дело было в Минске... ;)

Вопрос читателя: “Какие образовательные программы и сертификации считаете полезными для продакта?

Не говорю про самообразование и постоянное "затачивание пилы", а именно с целью документального подтверждения навыков (например, при собеседовании) – что было и полезно вам и ценно для работодателей”.

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

Лично мой честный вам ответ – никакие. Ни в одном месте, куда я устраивалась на работу, меня не просили предъявить “корочки”. Я сама ни разу не смотрела на список законченных курсов кандидата, когда принимала решение о найме.

У меня нет ни одной сертификации или диплома (кроме как о получении высшего образования). Когда я устраивалась на работу в Яндекс, одно из собеседований было про статистику – а я в статистике была ни в зуб ногой. Когда я пришла работать в Suitepad, мне надо было проводить пользовательские исследования, что я раньше никогда не делала. В Intercom нужно было уметь работать с SQL, чего я, опять же, не знала.

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

1. По своей природе, профессия продакта похожа на любую руководящую должность. Не могу представить ситуацию, где интервьюер говорит: “Ну да, вы классный менеджер, умеете строить команды с нуля, вести людей за собой и приносить деньги компании, но вот сертификатика про Agile у вас нет. Жаль-жаль, придется вам отказать”. Des Traynor, один из основателей Intercom, успешно переключается между разнообразными C-level должностями: какое-то время был CMO, до этого – CPO, а после - COO. Многие tech компании также практикуют “взаимозаменяемость” топ менеджеров. Все потому, что их ключевые навыки, как и у продактов, в большей степени относятся к soft skills или к независимым от функции hard skills (например, стратегия или приоритезация).
2. Продакт-менеджер – это швейцарский нож; набор “инструментов”, который вам потребуется, будет сильно зависеть от нанимающей компании. Где-то будет нужен уклон в маркетинг, где-то в анализ данных, и так далее. Все знать невозможно, и адекватные работодатели это понимают.
3. Хороший продакт должен уметь быстро во всем разбираться – и иногда курс или сертификация действительно могут в этом помочь. Однако даже в этом случае “корочка” – лишь ненужный артефакт. Ни один диплом не докажет, что вы не просто усвоили знания, но и, что гораздо важнее, научились их применять на практике. Ни одной компании не нужен продакт с сертификатом по Data Science – но нужен продакт, который умеет принимать решения на основе данных. Фокусируйтесь на результате, а не на средствах его достижения. В этом случае часто оказывается, что нам не нужен курс за 20 тысяч рублей; можно прочитать книгу, пару статей, а все остальное осваивать уже в “бою” :)

Сразу также отвечу на популярный вопрос от проджект-менеджеров: нужна ли сертификация PMBOK или Agile, чтобы найти работу. Прежде всего должна сказать, что уже давно не сталкивалась с подобными вакансиями в продуктовой разработке; мне кажется, за границей это все больше и больше становится рудиментом (конечно, не говорю здесь об агентствах). Когда я работала в России, ни у кого из моих знакомых проджектов таких сертификатов не было.

И еще одна важная оговорка: мы не затронули тему MBA, так как это отдельная и очень объемная история. Приходите слушать нашу трансляцию с Юлей Нечаевой, где она будет говорить про свой опыт с MBA в одном из топовых американских университетов и как это повлияло на ее карьеру https://t.me/proproduct/956 (https://t.me/proproduct/956)

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

Что вообще нужно для того, чтобы научиться делать красивый UI (ну, кроме таланта, конечно)? Необходимо пройти через большое количество проб и ошибок, т.е. чем больше повторений сделано — тем более качественный результат.

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

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

Недожали — это универсальный ответ, который я слышал практически на все действия по UI. Обычно это означало, что можно было сделать лучше. Причем, как именно лучше, было не совсем ясно. Все валится, ничего не выходит, не знаешь что делать дальше — ты просто «недожал».

Но однажды я все же получил небольшое пояснение этого термина. Одним вечером, после занятий я решил спросить, Сергея, что же делать когда ничего не получается? Он поделился своим опытом — когда ничего не получается можно начать решать проблемы постепенно, брать какую-то одну небольшую часть проекта, например, контролл и доводить его до совершенства. То есть фокусируешься на одном моменте, не отвлекаясь ни на что больше. И… постепенно «дожимаешь» весь проект.

Напомню, что мы работали в командах по 2-3 человека, и работа над UI выглядела следующим образом: каждый из студентов делал заход на визуал проекта, составлял мудборд и на основе его рисовал несколько экранов. В итоге, в каждой команде отбиралась самая проработанная концепция. На её основе составлялся UI-Kit, который затем раскатывался на всё приложение с дальнейшей шлифовкой.

На зачете по блоку UI наша команда предоставила три одинаково плохие концепции, и Женя Бондарев посоветовал смешать несколько идей из каждой концепции. На этом его активное участие в обучении закончилось. А мы остались один на один с очень сырым UI, и тут же стали его переделывать. Про мои страдания вы можете почитать в прошлом посте, скажу лишь, что все майские праздники я потратил на погружение в особенности работы над UI. Это время не прошло зря, я открыл для себя много нового и из зачаточных мои навыки стали чуть более крепкими.

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

По итогу мы нашли общее видение направления, и оно звучало следующим образом:
«Чистый интерфейс с понятной типографикой, умеренный и местами незаметный, но со своим стилем и продуманной навигацией. Он не должен быть грубым и непонятным, не должен напоминать голый ios, не детский, не захламленный, не космический».

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

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

Самое главное правило сдачи работы

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

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

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

Не хочешь слить в трубу результаты работы — презентуй её лично.

Найти рынок

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

Часто продукты рождаются из собственной потребности основателя. Это классика. У тебя что-то настолько болит, что ты просто придумываешь решение. Дальше видишь, что у других болит также и они готовы тебе платить (это рынок). Масштабируешь решение, растешь и т.д.

Есть две короткие истории про это.

1. Дженифер классно писала эссе в институте. Ее одногрупница попросила помочь, но Джен была сильно занята. Тогда ей предложили выполнить работу за $20 (нащупывается рынок).

Заказ за заказом и Дженифер наняла себе в помощь других писателей. Так родился продукт EssayService.

2. Джилбоа - парень, который носит очки, как-то потерял их во время своего путешествия. Они просто выпали у него из рюкзака. Он провел небольшой ресерч для покупки новой пары и обнаружил, что наценка составляет Х10-20 от себестоимости.

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