Достижения через преодоление себя против наслаждения процессом достижения целей

Достижения через преодоление себя против наслаждения процессом достижения целей

Рассмотрим две популярные точки зрения.

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

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

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

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

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

Определимся со спортивными целями. Они могут быть разными:
1. Не хочу быть толстым, поэтому буду бегать 2-3 раза в неделю.
2. Хочу красивое тело — буду ходить в зал 3-5 раз в неделю.
3. Хочу стать марафонцем.
4. Хочу пробежать марафон из 3-х часов.
5. Хочу стать КМС в каком-либо виде спорта.
6. Хочу поучаствовать в ЧМ по триатлону.

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

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

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

Чем выше планка — тем больше страданий и дисциплины. Это нужно либо принять, либо поумерить свои амбиции.

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

Однако, в условиях цифровизации мира, есть вероятность, что необходимость в таких специалистах рано или поздно пропадет.

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

10 принципов этичного UX-дизайна

10 принципов этичного UX-дизайна

Использование честного UX-дизайна для создания надежного и заслуживающего доверия опыта.

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

"Чтобы быть убедительным, мы должны быть правдоподобными; чтобы быть правдоподобным, мы должны быть достоверными; чтобы быть достоверным, мы должны быть правдивыми". - Эдвард Р. Марроу

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

Джошуа Портер пишет в книге "Честные интерфейсы": "Когда часть нашего продукта сбивает с толку, вводит в заблуждение или вызывает подозрения, доверие пользователей начинает ослабевать. Когда прокрадывается даже малейший намек на плохое поведение, пользователь уже начинает отказываться от дальнейшего взаимодействия."

1. Уведомить меня

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

Мы должны информировать наших пользователей и давать им возможность отменить подписку после бесплатной пробной версии, если она им больше не нужна.

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

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

2. Выделяйте негативную информацию

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

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

3. По умолчанию выбирайте наиболее безопасный для пользователя вариант.

Слишком много форм автоматически ставят галочку в маленьком квадратике, который приглашает вас в их рассылку. Я не хочу присоединяться к вашей чертовой рассылке!

4. Опыт важнее дохода

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

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

5. Прозрачность цен

Что вы видите, за то и платите.

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

6. Прекратите рассылку спама

Ничто не заставляет меня удалять приложение быстрее, чем спам-уведомления.

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

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

7. Прозрачность конфиденциальности

Перестаньте прятать все за политикой конфиденциальности.

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

8. Честные предложения

Если на вашем сайте постоянно проводятся распродажи, перестаньте делать вид, что это новогодняя распродажа, которая закончится через два часа.

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

9. Сделайте отмену заказа легкой, как пирог

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

Если я подписался на ваш продукт, сделайте так, чтобы ликвидировать его было очень просто.

Мне не нужно звонить на линию поддержки, отправлять электронное письмо, читать FAQ или общаться с агентом. Просто дайте мне чертову кнопку с надписью "отменить" и позвольте мне жить дальше.

10. Спрашивайте разрешения

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

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

Не предпринимайте никаких действий от имени пользователя в фоновом режиме без его согласия.

UX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

Молодой фрилансер постоянно фигачит, учится, весь такой на подрыве.

Я всегда думал, что взросление обязательно связано с переключением в роль управленца — стать арт-директором или CTO, растить команду, учить, брать больше ответственности. «Солдат, что не мечтает стать генералом» казался мне неправильным. Ребят, которые попробовали руководить и откатились до исполнителей, я считал слабаками и дауншифтерами.

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

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

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

А удовольствие от работы — это когда ты в потоке. Это когда сииидишь себе и делаешь штукенцию. И так её повернёшь, и эдак, и никто тебя не трогает, и не спрашивает, сколько процентов уже готово, и главное ты сам у себя это не спрашиваешь. Ты просто знаешь, кому она нужна и зачем, и ты её делаешь как-то, как ты сам хочешь.

И вот мне кажется, что «быть старым фрилансером» — это иметь возможность работать в потоке. Конечно, старый фрилансер умеет делать и всё остальное. Если надо, он встрепенётся, спроектирует, декомпозирует, раздаст всем по хорошему совету, разрулит конфликт. Но у старого фрилансера есть возможность ничего этого не делать и личное время для медленной работы в удовольствие.

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

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

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 и в отраслевых изданиях.
Это потрясающая точка роста - в том числе, для развития продуктового чутья и генерации идей.

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

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

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

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