Спрашивали про точки развития для дизайнера.

designsniper Спрашивали про точки развития для дизайнера.

Точек роста для дизайнера четыре:

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

— Творческое развитие. Создание индивидуальной творческой траектории независимости и автономной работы. Частный проект в котором дизайнер один на один со своей личной задачей. Создание личного проекта с осознанными и глубокими мотивами самореализации.

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

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

Метод гипотез в решении технических задач

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

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

Вместо результата у непонятных задач лучше фокусироваться на процессе. К примеру, можно пообещать проверять по одной гипотезе раз в два дня. Садимся, и раз в два дня выдвигаем гипотезу, скажем «я считаю, что виноват redis, потому что он иногда падает, а потом долго грузит сохранённые данные с диска».

Дальше садимся и проверяем гипотезу: как быстро запускается redis с сохранёнными данными? А под нагрузкой? Может избавиться от промежуточных сохранений кеша и вообще отключить сохранение? Придумали эксперимент, запустили проверку — и на пару дней переключаемся на другие задачи.

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

Евгений Арутюнов рассказал, как устроено дизайн-бюро «Интуиция».

Каждое правило работы бюро Евгений оценил с позиции «а буду ли я его выполнять?». В итоге решил, что ни у кого не будет режима и места работы (все работают удалённо), утренних стендапов, обязательства в течение получаса ответить на письмо или ответить на незапланированный звонок.

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

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

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

Дизайнеры учатся писать код, текст, работать менеджерами, общаться с клиентами и управлять своим временем. В проекте люди выступают в разных ролях. Это не значит, что один человек делает в проекте всё (и работа на нём замыкается), но каждый умеет выступать в разных ролях.

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

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

У каждого есть право сказать «нет». Например, дизайнер не хочет работать с конкретным клиентом. Так вовремя можно получать сигнал, что что-то не так: с руководителем клиент — зайка, а с дизайнером ведёт себя некорректно.

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

Если есть проект, но под него надо взять ещё 3 дизайнеров и 10 разработчиков — проект не берут. Растут только когда есть готовые внутренние ресурсы. Подбирают проекты под команду (на момент записи это 7 человек).

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

Зарплат нет. Есть открытая информация о деньгах в проектах. Люди, которые делают эти проекты, распределяют эти деньги. Есть подсказки, как это делать, но всё держится на персональном представлении о справедливости того человека, который координирует проект на конкретном этапе (дизайн, разработка).

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

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

Есть полочка, на которую надо отложить 20-25% от бюджета проекта. С неё можно брать деньги на развитие, обучение, компенсации ударов судьбы, офис и поездки (когда они были). На маркетинг трат сейчас нет. Если на полочке что-то пролежало 2 месяца и осталось невостребованным, это прибыль, которую забирает Евгений. Это мотивирует работать над развитием бюро на длинной дистанции.

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

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

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

Это не рецепт организации работы, это образ жизни. «Мы хотим играть, а не искать баланс между работой и жизнью». Этой схеме работы примерно 2 года, к которой пришли от более классического фриланса с помощниками.

Может показаться, что всё завязано на Евгении, но это не так. Проект всегда можно поручить команде с отдельным руководителем, и выгрузить его из своего головы.

Командообразование

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

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

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

Внутри команды мы поделились на несколько ролей: менеджер, аналитик и дизайнер (нас как раз было трое). Аналитик мог пользоваться только браузером, дизайнер мог искать референсы и рисовать прототипы, менеджер не мог делать ничего кроме как говорить и координировать.

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

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

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

Обзор книги Runing Lean

Недавно прочитал Runing Lean от Ash Muraya поделюсь впечатлениями.

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

Внутри вам предлагают посмотреть на свой будущий продукт через Lean Canvas. Это таблица/шаблон, которая позволяет последовательно отвечать на ключевые вопросы. Ниже под постом положил сам канвас. Если читали Остервальдера с его бизнес моделями, то это версия немного с другого ракурса.

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

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

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

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

Семантика и синтаксис интерфейса

Семантика — то, как элементы интерфейса сочетаются, группируются и как их воспринимает человек.

Cемантика опирается на ожидания от продукта и привычки. Например, что в форме регистрации есть кнопка «Зарегистрироваться», а в соцсетях — лента новостей.

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

Элементы без текста — чаще всего просто иконки и фреймы. С них не так-то легко считать информацию.

К чему это я? Круто, когда UX-писатель умеет писать. Но ещё круче, когда разбирается в семантике. Это уже хай левел.