Интересная статья о ментальных моделях (ММ) для дизайнеров.

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

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

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

2) Инверсия. Мы часто концентрируемся на поиске идеального решения, однако порой это слишком тяжело даётся. Чтобы облегчить себе «роды» решения, можно воспользоваться инверсией: представить не самое хорошее решение, а наоборот, плохое. А после просто спросить, как нам этого избежать? Очень напоминает метод решения задач «от обратного», не правда-ли? Например, все таже проблема становления вас как прекрасного специалиста может впасть в ступор на вопросе «А кто такой этот прекрасный специалист?». Однако стоит вам задать вопрос, как «Кем он не является?», как сразу повалят признаки: звёздная болезнь, отсутствие опыта, теоретический дизайн, затворничество и т.д. Останется только придумать, как этого избежать и вуаля.

3) Лестница абстракции. Этот метод позволяет выйти из тупиковой ситуации, если задача кажется неразрешимой. В таком случае, нам стоит переместиться на уровень выше (построить надсистему по ТРИЗ) и рассмотреть проблему в ней. А делается это при помощи мозгов и качественных вопросов (почему, зачем, как, чем... и т.д.) Например, перед нами стоит задача создать ручку, которая будет писать в условиях невесомости. И это довольно сложная задача. Но если мы выйдем в надсистему «фиксирование информации в условиях невесомости», то на столе появляются и другие опции, типа «цифровой дисплей» или «простой карандаш». Конечно, каждый из них будет иметь свои недостатки, но и положительные моменты можно будет перенять.

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

Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Провели работу наш ошибками над тем, что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах.

О чем вообще ты говоришь, женщина?
А вот о чём:
— У нас есть период онбординга нового члена команды, за который он выравнивается с командой на этом безопасном плато.
— Есть система обучения: разные форматы и подходы, которые помогают научиться писать тексты
(рассказывали на VC и давали примеры домашек)
— А есть критерии качества текстов и типографики — каждый может свою работу проверить, а до командного ревью она доходит уже без ошибок по этим чеклистам.

Спустя год, нам было над чем поразмыслить.

И вот что работает хорошо:

1. Рассказывать новичку о чеклистах — о том как надо, а как не надо писать текст, до первых задач смысла нет. Критерии не четкие как, например, в типографике, поэтому понятия «Краткость», «Человечность» тоже размыты.
Их не измеришь, а значит, теория до первого опыта неприменима. Рассказывать стоит уже в первых задачах, на примере уже написанного текста и с личным разбором. Показывать и объяснять, что плохо или хорошо и почему.

2. Сильно помогает предварительная UX-аналитика и интервью c ЦА. Портреты и характеристики пользователей помогают писать в правильном тоне и с единым уровнем детализации сложных понятий.

Грубо говоря — пишем как для офлайнового предпринимателя в продукте валютного контроля, или как для разбирающегося relations-менеджера в KYC-продукте.

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

4. Ролевые игры 🙂
Практика, которую мы применяли в обучении UX-исследователей, работает и в обучении дизайнеров UX-текстам. Устраивает исследователь для дизайнера на его задачах. Многим новичкам помогает, так как они не понимают о пользователе ничего, включая реакции и потребности на конкретном шаге конкретного процесса.


А вот что у нас не работает или приносит несущественную пользу:

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

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

3. Мудборды по UX-текстам: сложно находить специально, человеку без опыта сложно понять, что хорошо, а что плохо.
— Мудборд нужно делать общекомандным и обязательно нужно разбирать и оставлять комменты о том что и почему в конкретном примере хорошо и плохо.

4. Главред — это зло, когда не умеешь им пользоваться. Сколько не говори о рейтинге и о том, что не надо на него смотреть и доводить свой текст до 8 и выше, люди в это выдрачивание всё равно скатываются.

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

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


Ну вот и всё. Удачи вам с microcopy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Визуализация данных

Визуализация данных не самая простая штука. Бывает потеряны часы времени в поиске подходящего формата. "Bubble Chart", "Bar Chart", а может быть "Scatterplot"?

Коллеги собрали большинство примеров вместе и показали правильное использование графиков и диаграмм. Кратко так:

  • столбики (Bar Chart). Используют для сравнения нескольких наборов данных. Горизонтальные столбцы обычно используют, когда нужно сравнить большое количество показателей или визуально выделить явное превосходство одного из них. А вертикальные столбцы хорошо иллюстрируют, как менялись показатели в разные периоды, например, ежегодная прибыль компании за несколько лет
  • точечная диаграмма (Scatterplot). Помогает найти взаимосвязь между двумя показателями. Например, с его помощью можно узнать, как меняется коэффициент конверсии в зависимости от размера скидки на товар.
  • пузырьковая диаграмма (Bubble Chart). Позволяет сравнить два параметра по третьему. Возьмем коэффициент конверсии и размер скидки. Добавим к ним доход (за который отвечает размер круга) и получим примерно такую диаграмму. Глядя на этот график, можно заметить, что самая высокая конверсия у товаров со скидкой 30%, однако больше всего дохода приносят товары без скидки и товары со скидкой 5% (см. пример ниже).

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

Переговоры: возможность принять финальное решение

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

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

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

Посмотрите, может быть у вас так же?

Качество кода и счастье

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

Вот, к примеру, качество кодовой базы. По-идее, можно очень долго жить с горами говнокода в продакшене — просто нанимаешь в 2–3 раза больше программистов, игнорируешь высокий churn, пытаясь загасить проблему корпоративами/тимбилдингами/мотивацией, и привычно умножаешь все сроки на 3.

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

Ключевой элемент счастливой команды — качество кодовой базы: архитектура, стандарты кодирования, тесты и автоматизация рутины.

Вчера на сайте бюро вышел первый совет в серии о качестве кода (http://bit.ly/bureau-code-quality), с детальным рассказом о том, зачем это нужно бизнесу. Особенно совет полезен тем, у кого нет времени (или кому не дают времени) на рефакторинг.