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

80% стратегии – это глубокое понимание вашего рынка и ваших пользователей; 20% – это диагностика проблем/трендов и создание рекомендации по тактике и политике.

Мы сейчас не будем вдаваться в детали, но, если вы хотите сделать карьерный скачок и начать отвечать за стратегию, рекомендую начать с тщательного изучения рынка, на котором вы работаете. И вот еще несколько вопросов, которые вам помогут:

1. Кто наши конкуренты и что о них говорят пользователи? Проверка: прямо сейчас назовите как минимум 7 ваших конкурентов. Ответ "мы одни такие в голубом океане" не принимается. Почитайте вот это (https://medium.com/no-flame-no-game/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-jobs-to-be-done-%D0%B8-job-stories-4c57c1dc84cf)

2. По каждому конкуренту – назовите как минимум 3 вещи, которые они делают не так, как другие. Почему они их делают не так?

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

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

5. Какие уникальные сильные стороны есть у нашего продукта? Почему мы в наилучшей позиции, чтобы решать проблемы, которые мы решаем? Почему мы должны это делать именно сейчас?

6. Что мы НЕ будем делать в ближайшие три года?

Очень много информации можно найти просто поиском в гугле и через уточнение запроса; если вы в b2b - идите на специализированные форумы и чаты.
Я выделяю как минимум 2 часа в неделю, чтобы делать подобный мониторинг + слежу за новинками на ProductHunt и в отраслевых изданиях.
Это потрясающая точка роста - в том числе, для развития продуктового чутья и генерации идей.

Массовый опрос

Цель: провести анкетирование людей в определенные часы в пределах заданной территории.
Исторически, в этом методе использовались только бумажные анкеты, но с недавнего времени стали применяться мобильные приложения. На сегодня доступно множество разнообразных решений; в студии транспортного проектирования остановились на приложении Квизер.

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

После инструктажа и обучения, полевик выходит на точку (кластер). Обычно, в одном исследовании требуется собрать данные с 25 респондентов, число которых, в свою очередь, ограничено квотой — то есть заданным количеством людей определенного возраста. Например, 4 мужчины и 4 женщины возрастом от 18 до 34 лет и т.д.

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

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

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

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

Оплата за опрос происходит только за полностью заполненную квоту (она, напомню, обычно составляет 25 человек), то есть за 24 человека не заплатят ничего. И наоборот — если ты перевыполнил план, то сверх квоты доплачивать не будут.

Действие, не состояние

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

Неизвестная ошибка

Кажется, что просто сообщили информацию. Но мы же сделали это для какой-то цели? Наверное, чтобы пользователь сделал какое-то действие с этой информацией: обратился в поддержку, вернулся на предыдущий этап и больше не пытался или чтобы попробовал снова.

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

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

Вроде пытаемся что-то донести, но что — еще надо додумать. Почему бы не избавить пользователя от лишних додумываний?

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Метод гипотез в решении технических задач

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

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

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

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

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

Чтобы обратиться к какому-либо узлу, его сначала надо найти

Для этого есть разные методы, но в современном прототипировании чаще всего применяются два метода:

let el = document.querySelector(selector)
и
let elems = document.querySelectorAll(selector)

Оба метода получают на вход CSS-селектор элемента. Например:

let el = document.querySelector(".someClass b");

Отличие их в том, что querySelector вернёт один узел, который попался первым, а querySelectorAll вернёт список всех узлов на странице, соответствующих селектору.

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

Если же вам всё-таки нужен метод map, то вы можете преобразовать список узлов в массив при помощи конструкции [...nodeList]:

let arr = document.querySelecroAll("a");
[...arr].map(el => el.innerText);

Подробнее в видео: https://youtu.be/KIBv7QMToP4
И в примере с кодом: https://codepen.io/detepr/pres/mQqKZO

Дюжина типов мышления среди дизайнеров

Дюжина типов мышления среди дизайнеров

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

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

Второй тип мышления воспитывает отношение к дизайну, как к деятельности созидательной, результатом которой является трансформация исходной ценности, зачастую формулирование самой проблемы в расширении ценности исходного объекта.
Дизайн как расширение задачи — «Найти вариант написания для вывески “Мы открылись”».
Дизайнер анализирует сотни похожих решений, сочетаний слов, композиций, шрифтов и понимает, что ценность сообщения будет выше если его филологически разработать. Начинает разбираться с функцией слов, смыслом сообщения, желаемым результатом. Возникающей эмоциональной связи. Начинает складывать новые слова в комбинации в рамках 12-15 знаков.

Простые альтернативы с демонстрацией заинтересованности, от самоуверенной радости «А вот и мы!» (10 знаков), до нейтральных «Заходите в гости» (16 знаков, перебор), «Мы вам рады» (11 знаков), до буквальности и констатации выгоды — «Вкусно — здесь!» (13 знаков).

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