Меня тут спрашивают, зачем нужны шпаргалки, о которых я написал постом выше

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

Например, вы знаете основы JS, но всё чаще встречаете в примерах непонятный новый синтаксис — ES6. Вы можете прочитать про него длинную статью (например: http://babeljs.io/learn-es2015/), но, скорее всего, сразу всё забудете. Тут вам и придёт на помощь шпаргалка https://devhints.io/es6

Или вы установили себе модный редактор кода Visual Studio Code, но не знаете ни одного хоткея в нём. Вот шпаргалка с ними: https://devhints.io/vscode

Или вы решили научиться верстать флексбоксами, но постоянно забываете синтаксис. Шпаргалка вам его быстро напомнит: https://devhints.io/css-flexbox

Смена лого Google Maps

Смена лого Google Maps

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

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

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

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

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

Владимир Лалош написал о FAQ (частых вопросах).

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

Формулируйте вопросы так, как их задал бы человек. «Вы гарантируете безопасность оплаты банковской картой через интернет?» → «А платить у вас картой безопасно?»

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

Если вопросов много, распределите их по разделам.

В тексте ответа должен быть только ответ на вопрос, без рекламы и лирики.

https://medium.com/maratori/501067e7a8da

Бывает, сервисы прикидываются добрыми друзьями, пока платишь.

А как только перестаешь платить, переобуваются и переходят к формализму и снисходительному тону.

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

Netflix остаются друзьями до конца и держат тональность и с теми, кто не платит. Давай, говорят, обновим платежную инфу и будем снова наслаждаться. Приятно.

Чтобы не прогадать, можно вообще не прикидываться другом и всегда держаться нейтрально, как Apple Music.

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

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

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

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

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

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

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

Как спрашивать «зачем»?

Как вы помните из заметки про фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98), вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.

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

Вот пара трюков, чтобы процесс задавания вопросов пошел легче:

  • Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
  • Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
  • Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры