Московский: Дизайн & Тимлид

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

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

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

По мере развития продукта начинают копиться интерфейстные проблемы, о которых никто заранее не думал. Например, добавляли фичу по одной, и интерфейс стал перегруженным. Разработчик отложил мелкую правку на потом и все забыли. На юзабилити-тесте увидели проблему, но исправить ее руки не дошли. Сюда же задачи, созданные на основе фидбэка от пользователей. 📍Все это — дизайн-долг. И чем дольше живет продукт, тем больше подобных задач появляется. Просто копить задачи в одном списке — мало. Поэтому мы действуем по шагам: 0...

Раньше я пользовался стандартным приложением на часах, чтобы считать шаги и фиксировать пробежки. Нажал «закончить тренировку», и все данные сохранились. Никаких лишних действий. А потом попробовал приложение Strava. Там после клика на «Finish» появляется экран со статистикой и крестик в углу. Я на автомате закрывал окно, как и раньше, и снова видел кнопку «Finish». Подумал, что глюк. Переустановил — история повторилась. И только со второй попытки понял, что экран с данными за тренировку надо было прокрутить вниз — там кнопка «Save»...

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

Я редко спорю — стараюсь договариваться и искать компромиссы. Но несколько лет назад так сделать не получилось. Разработчик предложил решение, которое шло вразрез с базовыми принципами UX: он предложил модальное окно не закрывать по клику снаружи. Я был против. Для пользователя такое решение будет странным и непривычным: везде оно закрывается, а у нас нет. Поэтому прямо сказал «нет» и пошел на конфликт. Мои аргументы не работали, а разработчик запрашивал исследование — хотя для меня очевидно, что оно не нужно...

Ранее писал про тест Хогана — посмотрите, если не видели. Он открыл мне еще одно качество, которое я раньше не замечал — мнимое согласие. Бывает, что с идеей я не полностью согласен, но при этом и спорить не хочется. Я формально соглашаюсь, но внутри остаюсь при своем. Особенно, когда вопрос кажется мелким: согласился, чтобы не идти на конфликт, а потом могу сделать немного по-другому. Или, например, просили один вариант дизайна, а я сделал два — тот, на который договорились, и тот, который считаю «идеальным»...

Из инсайтов в тесте Хогана — выяснилось, что у меня высокие значения по шкале «власть». Сначала я вообще не понял, о чем речь — раздавать приказы не моё. Оказалось, это про влияние, а не про контроль. То есть мне важны масштаб моих решений, ответственность, которую я беру, и в целом ощущение того, что я делаю что-то значимое. При этом, по результатам своей деятельности, ожидаю признания со стороны. Действительно — мне интереснее работать над масштабным продуктом, чем над небольшим внутренним. Из-за...

Недавно прошел тест Хогана — это одна из самых популярных международных методик оценки личности для руководителей. Думал, будет как всегда — непонятный тест с бесконечными согласен/не согласен. Оказалось — «нифига себе». Всего в тесте три блока, в каждом 200+ вопросов: — «Светлая сторона» — как человек ведет себя в обычной рабочей среде, когда следит за своим поведением. — «Темная сторона» — черты, которые проявляются под давлением или в расслабленном состоянии (когда давно работаешь и тебе похер) — Внутренние ценности и мотивации — что лежит в основе принятия решений и поведения...

Когда стал руководителем, поменялся мой рабочий ритм, и я заметил особенность. Рабочий день вроде и начинается как обычно, но вместо фигмы — календари, встречи, синки. И когда всё это заканчивается, в голове — каша. А делать дизайн уже тупо нет сил. Хотя «нормальной» работы стало меньше. Той, которая руками делается. Три часа фигмы в день, если повезёт. И каждый раз садишься за макеты как будто с похмелья: мозг не в ресурсе, фокус рассыпается. Долго думал, что не вывожу, плохо организую работу. Пытался «поднажать»...

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