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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вадим Митякин написал о проектировщике в рамках продюсерского подхода к созданию цифровых продуктов

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

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

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

Проектировщик — человек, имеющий привычку принимать решения. И имеющий достаточно смелости для этого.

Как состояться в профессии:
1. Насмотренность — знакомство с разными областями знаний;
2. Исследования — освоение выбранной области знаний;
3. Мастерство — использование своих знаний и создание новых областей знаний.

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

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

Кажется, неплохая статья о том, как анализировать данные

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

Вот несколько советов о том, что ж делать-то:

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

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

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

4. Проверьте, что контекст сбора данных был верным. Если вы собрали данных за два года, то половина из них может оказаться нерелевантной из-за изменившегося контекста (например, был проведён редизайн сайта).

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

6. Выделите свои основные KPI и смотрите на них. Так не потонете в пучинах таблиц и цифр.

7. …но сравнивайте их и с другими метриками, которые идут с KPI в противоречие.

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

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

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

11. Визуализируйте ваши данные. Порой, так будет проще делать выводы, чем просто пырясь в таблицу.

12. Используйте цветовое кодирование… очевидно. ✅

13. Используйте когортный анализ, когда это возможно. (Ну такое)

14. Используйте специальные тулы. (Тут в статье реклама видимо)

https://databox.com/how-to-analyze-data

Алан Купер написал, почему сейчас трудно делать удобные продукты.

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

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

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

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

Специалисты, будучи ответственными гражданами, пытаются примирить непримиримое. Они спрашивают: «Хотите, чтобы это работало быстрее?», «Хотите, чтобы я рассчитал окупаемость инвестиций?», «Хотите, чтобы я сделал это более джазовым, сексуальным, привлекательным?», «Стоит ли мне быть более гибким?», «Стоит ли мне использовать дизайн-системы, дизайн-мышление, дизайн-методы?».

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

Мы ищем ответы не в том месте.

https://vc.ru/design/97289

Как писать сообщения об ошибках

Как писать сообщения об ошибках

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

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

Если пользователь отправлял письмо, а оно не отправилось, то так и пишем: Письмо не отправлено

Хорошо:
✅ Не удалось загрузить сообщения
✅ Фотографии не отправлены
✅ Платёж не прошел

Плохо:
❌ Что-то пошло не так
❌ Ошибка!
❌ Память не может быть read

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

✅Хорошо для простого человека:
Не удалось сохранить документ. Документ слишком большой. Уменьшите размер документа до 800 символов или разбейте на части.
Разбить на 3 части
Закрыть

✅Хорошо для профессионала.
Не удалось сохранить документ. Размера файла подкачки не хватает для сохранения. Увеличьте размер файла подкачки до 1 ГБ или уменьшите размер вашего документа до 800 символов.
Увеличить файл подкачки
Разбить на 3 части
Закрыть

❌ Плохо:
Не писать причину
Писать профессиональным языком для непрофессионалов

Если причина неизвестна, то можно так и писать: Ошибка произошла по неизвестной причине. Помогите нам разобраться, отправьте отчёт.

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

✅Хорошо
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Позвонить в службу поддержки
Написать в службу поддержки
Закрыть

❌Плохо:
Вы ввели неверный пароль слишком часто. Чтобы восстановить пароль, обратитесь в службу поддержки.
Закрыть

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

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

Защита прошла!

Студенты MAD #5 защитили свои проекты! Ребята молодцы: проделали огромную работу, ответили на вопросы жюри, волновались, конечно, но прошли этот важный рубеж.

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

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

Теперь о самих проектах, точнее о тех, что зацепили.

Всех поразил проект Labyrinth Алины Русаковой (facebook.com/rusakova.alina) — приложение для горнолыжников и сноубордистов. Когда она выступала, и зал, и жюри были полностью поглощены, само собой, кто-то достал телефоны и снимал. И даже после защиты обсуждение проектов так или иначе заканчивалось её проектом. Если бы у нас были приз зрительских симпатий и признание выпускников, она бы унесла их оба.

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

А вот приложение для борьбы со словами–паразитами Tomato Word от Ани Васильевой (facebook.com/annvasiliska) однозначно мой фаворит. Все эти «эм», «и», «ну», «как бы», «собственно» и прочие — настоящая головная боль для тех, кто готовится к выступлению (Аня сама честно призналась, что была бы рада наличию такого приложения, когда готовилась к выступлению). Простое визуальное решение и платный режим со штрафом в 1₽ за каждое слово–паразит — это огонь.

Идём дальше. Кто бы мог подумать, что между кураторами и художниками нет чёткого канала коммуникации?! Оказывается, так и есть. Аня Пестич (facebook.com/anya.pestich) узнала, почему так происходит, и взялась решить эту проблему и свести их друг с другом в своём приложении re: art (жаль, не знаю, как и почему она докопалась до этой боли). Приятно, что она провела такой ресерч и смогла предложить решение проблем пользователей — именно так и должен работать дизайнер.

Ира Кухтерина (facebook.com/ira.kuhterina) нашла боль в том, что она сильно пала духом, пытаясь найти тему для своего проекта, и это сильно цепляет (год назад сам прошёл через такое же). Чтобы как-то с этим справиться, она создала Nevergiveapp (нейминг, кстати, огонь; у ребят на курсе с этим вообще хорошо) — приложение для поддержки и поднятия самооценки. Жюри очень высоко оценило степень проработки MVP, ведь она практически показала бета–версию, которую уже завтра можно протестировать на себе. Не могу сказать, что такое решение сработает (всё–таки эмоциональные состояния уникальны), но сам факт того, как много она сделала, впечатляет.

Остальные ребята тоже старались, и я мог бы продолжать и дальше, но у нас ограничение по времени (ba-dum-tss), поэтому ограничимся этим топ-4. Впереди у ребят второй семестр, где они будут работать в командах над проектами по брифам реальных заказчиков (даже самому интересно, что за проекты у них будут). Увидимся с ними и с вами уже в 2019 году!🎄