С прошлой заметки прошло три месяца, и вот появилась тема для новой.

Иногда говорят:

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

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

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

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

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.
5. Мне достался сложный проект.
6. Борем неуверенность.
7. Красота vs удобство.
8. Заблуждение: они обучатся.
9. Заблуждение: мы потестим.

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

Тестировать интерфейсы на пользователях — очень круто. Только есть один момент. Иногда у проектировщика возникает соблазн отдать в тестирование сырое решение:

«Мы ж все равно на пользователях проверим, можно не упарываться».

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

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

До новых встреч

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.
5. Мне достался сложный проект.
6. Борем неуверенность.
7. Красота vs удобство.
8. Заблуждение: они обучатся

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

Иногда говорят:

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

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

Иногда простые для пользователя решения оказываются нелегкими в разработке, и тогда проектировщики идут на компромисы, придумывают менее элегантное решение, которое быстрей и проще реализовать. Это нормально. Но это не значит, что под соусом «обучения продукту» надо проектировать сервис на постоянной основе. Ваша задача делать взаимодействие с продуктом простым и понятным.

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.
5. Мне достался сложный проект.
6. Борем неуверенность.
7. Красота vs удобство.

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

Всегда есть больше одного решения задачи. Представим, что у нас есть два решения.

Решение первое

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

Решение второе

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

Что же выбрать?

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

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

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

В следующей заметке читайте про заблуждение «они обучатся».

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.
5. Мне достался сложный проект.
6. Борем неуверенность.

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

Я ни на что не влияю

Иногда дизайнер говорит: «Я сильно не вмешиваюсь, я же новенький, меня никто не послушает». А ты попробуй. Не попробуешь, не узнаешь. Не послушают раз, два, послушают на третий. Это не причина не пробовать. Вмешивайся, влияй, предлагай решения. Говори о проблемах в интерфейсе, объясняй свою точку зрения. Не забывай про конструктивную форму общения.

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

Я не уверен в своих решениях

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

Повышай насмотренность. Так ты будешь видеть больше вариантов решений задачи, начнешь понимать, чем одно отличается от другого. Читай разборы работ у Горбунова, Лебедева, Штанга. Общайся с дизайнерами из своей группы. Разбирайте работы вместе, обсуждайте их.

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

Я решаю задачи хуже других

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

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

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

Я не могу объяснить свое решение

Ты чувствуешь, что твое решение правильное, но не можешь нормально объяснить. Задавай себе вопросы. Какую проблему ты решал? Какой у пользователя сценарий? Из каких шагов он состоит, что на каждом шаге важно? Где могут быть проблемы у пользователя, чего стоит опасаться? В чем сложность решения задачи? Какие еще варианты были у тебя? Почему они хуже? А можно ли придумать еще одно решение или несколько? Были ли подобные решения в сервисе, какие они? Или может другие дизайнеры решали схожие задачи?

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

О том, как презентовать свое решение, я рассказывала в одной из прошлых заметок.

Я не знаю ответа на вопрос

Бывает так, что кто-то из команды задает вопрос, ответа на который ты не знаешь или с ходу не можешь придумать. Попроси время подумать: «Мне надо 10 минут, я поразбираюсь и отвечу». Обычно ребятам это подходит, никто не ждет мгновенного ответа, так что не паникуй, не думай, что ты какой-то неважный дизайнер, раз не можешь ответить сразу. Нет задачи ответить мгновенно. Причем это относится не только к проектировщикам. Время на подумать бывает нужно всем, это нормально.

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

И вообще, я не люблю общаться

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

Выводы

Будь смелее. Учись рассуждать и объяснять, повышай насмотренность. Проси о помощи, когда нужно. Не паникуй.

В следующей заметке читайте про муки выбора.

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.
5. Мне достался сложный проект.

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

Это нормально

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

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

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

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

Обращение к командам

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

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

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

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

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

Выводы

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

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

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

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

В следующей заметке читайте про страхи и сомнения нового проектировщика.

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.
4. Хочу все переделать.

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

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

За что хвататься?

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

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

Так что же делать?

Выбери самое важное

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

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

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

Прими наследие

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

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

Переделывай

Иногда ребята из команды говорят: «Мы это переделывали год назад. Почему мы делаем это снова? Где гарантии, что через год вам не захочется все изменить?» Захочется. И это нормально. Так сервисы развиваются. Нельзя один раз написать сервис и больше не улучшать его. Конечно, большие серьезные изменения надо продумывать тщательно, тестировать решения, собирать информацию. Это очень ответственная работа. Лучше сделать все качественно, чтобы этих изменений хватило надолго. В это время можно заняться новыми фичами, которые ждут пользователи. Но переделывать — это нормально.

Выводы

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

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.
3. Презентуй свои решения.

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

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

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

Рассказывай связно

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

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

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

О том, что дизайнер должен отстаивать свою точку зрения, учиться слушать, адекватно воспринимать критику, я писала в самой первой заметке.

Не торопись

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

Многообразие вариантов

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

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

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

То есть общее правило такое: изменились условия, появилась новая информация — заново решай задачу. Обычно удается исправить лучшее из решений, а не проектировать задачу с нуля.

Почему команды хотят выбирать из множества вариантов?

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

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

Не могу выбрать лучшее

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

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

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

Выводы

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

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.

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

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

Задавай вопросы

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

Пользователи и сценарии

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

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

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

Как это работает

Как все работает в сервисе знают не только аналитики, но и разработчики. А если не знают, то могут почитать код и узнать. Да, бывает так, что какие-то старые части кода писали люди, которые уже не работают в проекте, и поэтому сложно с ходу сказать, как все устроено. Но чаще всего разработчики знают, спрашивай.

Проработка деталей

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

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

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

Тексты

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

Процессы и внутренняя кухня

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

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

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

Выводы

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

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

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

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

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

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

Заметки будут сильно ориентированы на проектировщиков Контура и наши процессы. У меня нет цели рассмотреть, как все устроено в других компаниях, наш опыт может отличаться. Но что-то вы можете переложить на свои ситуации, и это может оказаться полезным.

Первая тема — про наши ожидания от проектировщика.

Что мы ценим и ожидаем

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

Умение общаться и рассказывать свои решения

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

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

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

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

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

Ну, и конечно, надо уметь договариваться. Задача не решена, пока все не сошлись на одном решении. Нехорошо, когда кто-то говорит «я не согласен, но делайте, что хотите». Стоит обсудить возражения, понять, почему человек сопротивляется. Возможно ты что-то не учел. Это важно для будущих отношений с ребятами. Как только ты начнешь делать «что хочешь», так сразу доверие к тебе будет утеряно. Восстанавливать его будет сложно. Когда ты не считаешься с кем-то, этот кто-то потом тоже не будет считаться с тобой.

Критическое мышление

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

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

Здоровое отношение к критике

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

Критикуй чужие работы аккуратно, без эмоций. Скажи, что было бы лучше и почему.

Неравнодушие

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

Будь готов, что по поводу фигни придут и к тебе :) Если ты плохо сделал задачку — это повод ее переделать, а не расстраиваться. Ошибаются все. Ребята не хотят задеть тебя лично, они просто не хотят фигни.

Самостоятельность

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

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

План решения задачи

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

Ты можешь составить подобный для себя с учетом особенностей твоего проекта. Наш чек-лист периодически дополняется новыми пунктами. Актуальный ты можешь найти в Фигме, если включишь библиотеку компонентов «Эльба». Если у тебя есть вопросы про какие-то пункты в нем — пиши в комментариях, я расскажу.

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

Многообразие решений

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

Выводы

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

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