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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Многие дизайнеры проектируют только идеальное состояние, когда всё отображается корректно и контент идеален. Но есть ещё состояния:

1. Пустое: контент ещё не добавлен, нулевые результаты поиска, пользователь удалил контент.
2. Загрузка: когда загружается контент или выполняется какое-то действие. Важно донести до пользователя, что программа не зависла.
3. Частичная наполненность: когда есть только часть контента. Подумайте, как помочь пользователю сделать так, чтобы получить идеальное состояние.
4. Неидеальное: слишком длинный или короткий текст, изображения в неправильном формате или отсутствуют, нет части контента. Пользователь не должен думать, что программа сломалась.
5. Интерактивное: фокус на элементе, заполнение поля и другие изменения интерфейса после взаимодействия с пользователем.
6. Ошибка: нет подключения к сети, пользователь сделал что-то не то, системная ошибка. Важно, чтобы пользователь понимал суть ошибки и что ему делать.
7. Выполнение действия: когда пользователь справился со своей задачей. Состояние может отличаться для разных пользовательских задач.

https://ux.pub/proektirovanie-razlichnyh-sostoyaniy-interfeysa/

Цитата про формальный vs реальный дизайн-процесс из эссе Майкла Бейрута —дизайнера и сейчас партнера Pentagram, команда которого работала над новыми логотипами Mastercard, Slack, Yahoo, Verizon и дизайном предвыборной компании Хиллари Клинтон.

-----

Уже более 20 лет я пишу предложения по проектам. И почти в каждом из них есть пассаж, который начинается примерно так: «Проект включает четыре этапа: ориентирование и анализ, дизайн-концепция, разработка дизайна и реализация». Все клиенты хотят этого.

Интересно, как бы все обернулось, если бы я рассказал правду о том, что происходит в процессе дизайна?

Это могло бы звучать примерно так:
«Работая над дизайн-проектом, я поначалу внимательно слушаю, как вы рассказываете о вашей задаче, и читаю все найденные справочные материалы по проблемам, с которыми вы сталкиваетесь. Если вам повезет, у меня случайно окажется личный опыт работы в ситуации, похожей на вашу. Идея дизайна появляется в моей голове по ходу процесса, из ниоткуда. Я не могу это объяснить; это сродни магии. Иногда это случается даже раньше, чем вы успеваете рассказать мне о вашей задаче! Если идея хороша, я стараюсь придумать стратегическое обоснование такого решения, чтобы объяснить его вам, не полагаясь на хороший вкус, который у вас может отсутствовать. По ходу я могу предлагать другие идеи либо потому, что вы заставили меня согласиться на это, либо потому, что не уверен в первой идее. Во всяком случае, надеюсь, на ранних этапах я сумею заручиться вашим доверием и к этому моменту вы будете готовы принять мои рекомендации. Понятия не имею, как вы собираетесь проверять их пригодность, за исключением того, что в прошлом другие люди — по крайней мере те, о которых я вам рассказал, — последовали моему совету и преуспели. Иными словами, не могли бы вы просто, ну, знаете... верить мне?»

-----

Конец цитаты.

Год назад мы перестроили процесс работы команды с китом в Figma и перестали проебываться с правками по десяткам экранов разом.

Для этого в общей теории атомарности мы вели специальные организмы.

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

В нашей дизайнерской вселенной живут пять сущностей, две из них — наша находка.

1. Атомы
Базовые элементы-одноклеточные. Отвечают за стиль и используются много раз. Атомом бывает фигура или иконка.

2. Молекулы
Сумма атомов, основа дизайна: это целостный элемент, например кнопка, инпут, меню или тапбар. Отвечает за разметку (расстояния).

3. Организмы
Это состояния молекулы, которые передают цвет и отображение атомов. Например, состояния кнопки: при наведении или при нажатии.

4. Специальные организмы
Отвечают за текст и иконки и конкретный текст внутри сценария.

5. Общие организмы
Это специальные организмы, которые используются в неизменном виде в нескольких сценариях.