Нечто большее

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

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

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

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

Напомню, что как в юду, так и в профиру нужно заплатить за то, чтобы твое предложение увидел заказчик (в районе 20-150 рублей).

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

А что там в юду?
Тем временем в юду я, не выходя из приложения, нажал кнопку «стать мастером» и начал свой путь воина — предоставление личных данных, знакомство с внутренними правилами, небольшой тест на усвоение этих правил. И все, можно выходить на охоту за заказами.

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

И каково же было моё удивление, когда на следующий день мне перезвонил один из заказчиков! Он попросил скинуть портфолио, после чего мы минут 20 обсуждали варианты дизайна того приложения, который он задумал.
Мягко говоря я был поражен )

Я считаю мне повезло оказаться в этих ситуациях — данные кейсы отлично проиллюстрировали разницу подходов двух сервисов.

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

Цитата про формальный vs реальный дизайн-процесс из эссе Майкла Бейрута —дизайнера и сейчас партнера Pentagram, команда которого работала над новыми логотипами Mastercard, Slack, Yahoo, Verizon и дизайном предвыборной компании Хиллари Клинтон.

-----

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

Интересно, как бы все обернулось, если бы я рассказал правду о том, что происходит в процессе дизайна?

Это могло бы звучать примерно так:
«Работая над дизайн-проектом, я поначалу внимательно слушаю, как вы рассказываете о вашей задаче, и читаю все найденные справочные материалы по проблемам, с которыми вы сталкиваетесь. Если вам повезет, у меня случайно окажется личный опыт работы в ситуации, похожей на вашу. Идея дизайна появляется в моей голове по ходу процесса, из ниоткуда. Я не могу это объяснить; это сродни магии. Иногда это случается даже раньше, чем вы успеваете рассказать мне о вашей задаче! Если идея хороша, я стараюсь придумать стратегическое обоснование такого решения, чтобы объяснить его вам, не полагаясь на хороший вкус, который у вас может отсутствовать. По ходу я могу предлагать другие идеи либо потому, что вы заставили меня согласиться на это, либо потому, что не уверен в первой идее. Во всяком случае, надеюсь, на ранних этапах я сумею заручиться вашим доверием и к этому моменту вы будете готовы принять мои рекомендации. Понятия не имею, как вы собираетесь проверять их пригодность, за исключением того, что в прошлом другие люди — по крайней мере те, о которых я вам рассказал, — последовали моему совету и преуспели. Иными словами, не могли бы вы просто, ну, знаете... верить мне?»

-----

Конец цитаты.

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

Затем попробуйте понять, а для чего вам собственно нужно разбираться? Если хотите иметь больше веса в обсуждениях (условное «чтобы вас не наебали») — тоже не выйдет: во-первых — вы не прораб на стройке и наёбывать вас никто не собирается, а во-вторых всё равно обманут, если захотят.

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

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

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

У этого инструмента есть несколько вариаций, поэтому важно подобрать подходящую механику для конкретного продукта, в зависимости от его сложности и популярности.

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

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

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

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