Полезная привычка: всегда обьяснять правки

Нет ничего хуже редакторских правок без объяснений.

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

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

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

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

Короче, объяснения — часть товара, который продаёт редактор.

Мы учили продукт, продукт учил нас

Хорошо, когда ты пишешь с рождения продукта и можешь придумывать всё с нуля. Но чаще будет не так. Будут продукты, в которых кто-то уже годами писал до твоего прихода. Будет наследие, с которым придётся что-то делать. И если дать слабину, наследие победит. Чем больше продукт, тем сильнее его влияние.

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

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

Сергей Гуров #2 - путь новичка, студия и фриланс.

Арт-директор в Redmadrobot.
be.net/milkwork

— Почему после долгих лет фриланса ты решил пойти работать в студию?

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

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

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

— Как дизайнеру-одиночке поддерживать свои навыки на высоком уровне?

Мне кажется, что все зависит от человека. Я знаю дизайнеров-интровертов, которым проще ни с кем не общаться. Одиночество для них — зона комфорта для творчества. В конце концов интернет позволяет общаться на расстоянии, а для дизайнера общение может происходить без слов. Достаточно следить за новыми работами своих любимчиков и копаться в том, что было сделано дизайнерами задолго до нашего рождения.

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

— Дай три совета дизайнерам-фрилансерам.

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

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

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

Качество кода и счастье

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

Вот, к примеру, качество кодовой базы. По-идее, можно очень долго жить с горами говнокода в продакшене — просто нанимаешь в 2–3 раза больше программистов, игнорируешь высокий churn, пытаясь загасить проблему корпоративами/тимбилдингами/мотивацией, и привычно умножаешь все сроки на 3.

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

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

Вчера на сайте бюро вышел первый совет в серии о качестве кода (http://bit.ly/bureau-code-quality), с детальным рассказом о том, зачем это нужно бизнесу. Особенно совет полезен тем, у кого нет времени (или кому не дают времени) на рефакторинг.

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

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

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

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

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

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

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

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

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

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

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

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

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Почему мы предпочитаем делать юзабилити-тесты финсервисов вживую?

Есть три группы ограничений, которые уводят в общение тет-а-тет.

1. Технические.
– Мы тестируем интерфейсы и важно видеть, как именно люди держат телефоны. Поэтому для удалённых тестов нужны камера и штатив.
– Надо рассылать инструкции, просить пользователя установить необходимое оборудование и подключить наушники. Уходит минут 20 на настройку и технические неполадки.
– Многие респонденты просто технически не продвинуты и не могут всё подготовить.
Эта возня отъедает время общения и терпение респондента.

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

3. Секьюрность.
– Мы работаем с чувствительными данными клиента, тестируя финансовые сервисы иногда на данных пользователя. В онлайне запустить такое сложно. У пользователя меньше доверия — он может опасаться, что лишние люди увидят экран.
– С другой стороны, мы работаем с банками-заказчиками под NDA и должны гарантировать, что новый продукт не утечёт за пределы команды дизайна, разработки и тестов до запуска проекта.

Иногда от этого приходится отходить, например, когда респонденты из Европы или США. Всё это грозит двойной потерей качества — из-за онлайна и языковых барьеров.