Nø.11

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

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


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

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

— Не все метрики одинаково полезны. Нужно выбрать две-три ключевые, и следить за ними day-by-day. Остальные доставать по необходимости. 

— С тех пор как я начал заниматься продуктом, я почти перестал писать письма в саппорты небольших компаний со своими предложениями по улучшению. Чем меньше команда стартапа, тем ревностнее отношение к роадмапу, тем меньше вероятность туда втиснуть свои гениальные идеи (хотя, к идеям нескольких наших юзеров я прислушиваюсь больше чем, к своим; спасибо, что пишете ❤️). А вот репорты о багах наоборот всегда ценятся. Лучше десять раз получить сообщение об одной и той же ошибке, чем что-то упустить. 

— Судя по всему, каждый пользователь Андроида прячет в кармане Айфон в качестве второго телефона. Иначе не объяснить тот факт, что самый частый запрос в комментариях на Google Play — «сделайте приложение по функционалу таким же как на iOS». Да как они узнали вообще? 

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

— Переход на Фигму сильно ускорил нашу работу. Даже самому не верится: веб-инструмент перебил по производительности и удобству нативный код. Добро пожаловать в 2018. 

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

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

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

— Когда у компании есть сформулированная миссия, через которую можно пропускать все принимаемые решения, жить и работать становится намного проще. Why/How/What это не только про маркетинг. Когда встает вопрос, какую фичу делать первой, ответ всегда очевиден и вытекает из миссии продукта.

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

— Чем больше времени потратить на изучение проблемы и подготовку к работе ещё до того момента открытия Скетча или Фигмы, тем больше вероятность получить эффективное решение. Дизайн это решение проблем. Чтобы решить проблему нужно знать о ней все: цифры, аналитика, фидбеки, бест практис. Это, наверное, главный мой сдвиг в процессах за последний год. Раньше я сходу бросался делать наброски, разбираясь с остальным на ходу.

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

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

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

— Сегодня дизайн это 50% времени в графическом редакторе, и 50% в создании прототипов и микроанимаций. Причём чем дальше, тем с большим перевесом во второе. 

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

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

— Процессы в команде важны, но люди важнее. 

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


Пост изначально опубликован в Late Night Sekachov