Не начинать с отмазки и нытья

Плохая практика начинать свой рассказ с отмазки, давления на жалость и запроса преференций:

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

Зачем ты мне это показываешь, если не хочешь, чтобы я дал честную обратную связь?
Если сам знаешь, что показываешь откровенное Г., то зачем вообще показываешь?
Если у тебя нет опыта, но ты почему-то взялся и написал/сделал — почему я не должен критиковать?

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

Как отличить проработанное решение задачи от поверхностного

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

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

Есть универсальный вопрос, который позволяет отличить проработанное решение от поверхностного:
"Ты уверен, что лучше эту задачу нельзя было решить ?"

Если решение проработано, то исполнитель расскажет про другие тупиковые ветки решения и почему выбрал то, что сделал.
Если решение поверхностное, то будет что-то вроде: "Ну, я точно не могу сказать. Давай я ещё подумаю?" или "А почему нет? Вроде, нормальное решение".

В общем, прорабатывайте решения и будьте в них уверены. Вдруг спросят: "Ты уверен?"

Денис Ломов #2 - о работе с заказчиком и Воронежском дизайн-сообществе.

Креативный директор Red Collar.
http://redcollar.ru/

— Немного рефлексии. Какой твой проект ты считаешь самым неудачным?

Ох, тяжело ответить. Я понимаю под словом "неудачный" когда мы хотели сделать круто, но не получилось по каким-то причинам, и от этого обидно. Например, insider.moscow - первая версия сайта была стильная и цельная, а потом мы пошли на поводу у клиента, и сначала сделали главную страницу "светлой" - мы прозвали это "кокаиновый инсайдер". А после он стал превращаться в монстра. Ну а сейчас уже другая компании все дорабатывает, меняет, поэтому лучше на него не заходить))

— Что ты бы сделал по-другому, чтобы этого не случилось?

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

— Хорошая позиция. Немного про работу в Воронеже. Что из себя представляет местное дизайн-сообщество?

Да его по сути нет. Есть некоторые хорошие дизайнеры, но сообществом это не назвать. Мы стараемся на это повлиять. В прошлом году проводили 2 серии бесплатных офлайн лекций, где дизайнеры Red Collar делились знаниями с желающими: были как студенты, так и ребята из других студий.

— Как устроится к вам на работу дизайнером? И на какие навыки или качества ты смотришь в первую очередь?

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

— Так, а какого дизайнера ты точно никогда не возьмешь на работу?

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

— Последний вопрос. Как ты думаешь, нужно ли новичкам равняться на авторитетов в дизайне?

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

Хочу с вами сегодня поделиться несколькими правилами, которые помогают держать мой календарь (и встречи) под контролем.

1. У нас в команде есть no meetings Wednesday - день без встреч. Это договоренность с командой, что в этот день встречи мы не назначаем и полностью блокируем день. Очень крутая штука для фокуса! Важно, что такая традиция должна уважаться не только другими людьми в вашей компании, но и вами самим: если вам прилетает приглашение на этот день, обязательно спрашивайте – насколько это срочно? В большинстве случаев люди спокойно готовы подождать несколько дней.

2. Я также блокирую как минимум один часовой слот в день под сфокусированную работу и бронирую "встречи" на то время, когда я недоступна (например, с 6 до 10 вечера). Еще лучше, если на то время, когда вы хотите уходить с работы, у вас стоит какое-то занятие (например, спорт).

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

4. Я никогда не участвую во встречах, где непонятна повестка и ценность от моего участия. Если прилетает приглашение типа "Анна-Антон" или "Проект Х", я всегда отправляю автоматический ответ – а какая цель у этой встречи и зачем я вам там нужна? Удивительно, но часто этот вопрос приводит к тому, что вся встреча отменяется, и вопрос решается в другом формате (через чат или таски, например).

5. Дефолтная продолжительность моих встреч - 25 минут; 5 минут на то, чтобы осмыслить action items и переключить контекст на следующий митинг.

6. Если вы идете на встречу, уважайте своих коллег: будьте вовлечены в дискуссию, не сидите в телефоне и закройте-таки свой ноутбук.

@proproduct

Вадим Шлячков написал о законе Хика.

В статьях (и даже в википедии) пишут, что закон Хика утверждает следующее: с увеличением количества вариантов увеличивается время принятия решения.

В своей работе Хик пишет не о «времени принятия решения», а о «времени реакции выбора», что не одно и то же.

1. Время простой реакции (simple reaction time) — испытуемый даёт единственный ответ на единственный раздражитель.
2. Время реакции выбора (choice reaction time) — от испытуемого требуется реагировать различным образом на разные типы раздражителей.
3. Время реакции различения (discrimination reaction time) — предполагает единственный ответ на один из нескольких раздражителей.

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

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

Также исследования показали, что закон:
— Перестаёт работать после практики. После 6000 попыток время реакции на 8 вариантов раздражителей приблизилось ко времени реакции на 2 варианта.
— Не работает, когда раздражитель и способ реакции взаимосвязаны. Надо указать стилусом на подсвечиваемую область.
— Не распространяется на реакцию зрачков.
— Не учитывает эффект последовательностей.
— Ограничен количеством вариантов. Время реакции в эксперименте с 1023 вариантами отличалось всего на 20−30 мс от эксперимента с 31 вариантом.
— Не всегда хорошо описывает ситуацию, когда пользователь может связать предлагаемые варианты ассоциациями.

https://medium.com/v.shliachkov/2d577e005a69

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

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

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

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

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