В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

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

Но это тонкий лёд. Люди часто воспринимают нейминг как что-то очень личное, как будто это не инструмент, а ребёночек. Поэтому ругать название нужно крайне деликатно:

1. Сначала узнать, есть ли в принципе сомнения. Можно просто спросить, окончательный ли это вариант, можно как-то ещё осторожнее, но главное спросить.

2. Если сомнения есть, нужно получить явное разрешение на критику. И очень аккуратно её сформулировать, не типа «вот почему это хрень», а «вот в каких ситуациях это может плохо работать». Неудобно произносить, неудобно писать, неудобно склонять, неудобно собирать по полу вытекающие глаза, по ситуации.

3. И если критика находит отклик, получить разрешение придумывать новое, и с этим разрешением придумывать.

4. И показывать не названия текстом, а быстрые логотипы из разных названий.

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

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

Это я книгу пишу и некоторые мысли туда просто не влезают. Вторая глава близко.

Прокачка

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

Одна из таких прокачек была посвящена теме транспорта: необходимо было выбрать бренд автопроизводителя и с привязкой к их айдентике сделать концепт приложения.

Я выбрал мототему и хонду в виде бренда. Это концепт, который графически завязан на логотипе, тут практически нет продукта и UX-а.

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

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

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

Шот на дриббле:
https://dribbble.com/shots/4714587-Honda-s-app-concept-for-motorcycle

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

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

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

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

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

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

Денис Ломов #1 - о номинации «Агенство года» и процессах.

Креативный директор Red Collar.
http://redcollar.ru/

— Привет, давай начнем. Вы стали первой студией из России, которая выиграла в номинации «Агенство года» по версии CSS Design Awards. Почему так сложилось и что было залогом успеха?

Я сам был удивлен, и до сих пор не могу это осознать. После того, как мы взяли первый «Сайт дня» с нашим сайтом, начали стараться делать на высочайшем уровне для клиентов. И последние 2 года старались не выпускать проходных проектов. В каждый вкладывались по максимуму. За год выиграли 10 наград на CSS Design Awards. Видимо это огромный скачок, и жюри решили что мы достойны называться лучшими в мире по итогам 2017 года.

— Круто ) Что-нибудь изменилось в жизни агенства после?

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

— Воронеж наверное гордится вами ) А какой может быть твоя следующая цель?

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

— Желаю удачи! Давай поговорим про процесс. Большинство твоих работ — промо с крутым дизайном и качественной разработкой. Как у тебя происходит процесс поиска дизайн-решения?

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

— Интересно ) А как ты налаживаешь взаимодействие дизайнеров и разработчиков?
Я пишу в фейсбуке про Creative Frontend Developer. Так вот у нас именно такие. Дизайнер и фронтенд-разработчик совещаются, обсуждают, предлагают решения. Нет такого, что все, что предложил дизайнер должно быть реализовано 1 в 1. От некоторых вещей можно отказаться, а другие изменить. И разработчик часто сам предлагает очень интересные решения, о которых дизайнер и не думал даже. А возможные конфликты между ними решаются арт-директором.

Наталья Стурза, автор канала @UX_sturzaman, рассказала, когда продуктам полезны UX-исследования:

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

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

3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.

4. Сравнить между собой конкурирующие продукты или отдельные фичи.

5. Понять, сколько потенциальные клиенты готовы платить.

6. Найти ошибку в интерфейсе.

Исследования не пригодятся:

1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.

2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.

https://vc.ru/design/86942

Работа в офисе

Что думал в начале 2019:
- По-настоящему эффективно работать можно только вместе, лицом к лицу с людьми.
- Самые крутые продукты создаются в офисах. Apple, Google, Facebook, Spotify, Tesla, SpaceX, что угодно — у всех есть Главный Офис, где и придумывается всё самое интересное.
- Удалённо работать могут только фрилансеры над отделяемыми неважными задачами.

Что думаю в начале 2020:
- Будущее за распределёнными компаниями и удалённой работой.
- Если у компании несколько офисов — это уже распределённая компания. Если на большинстве встреч ты созваниваешься с людьми по видеосвязи, то не так уж и важно, сидят ли они в другом офисе, в кафе или у себя дома.
- Figma, Slack, Notion, Miro, Loom и многие другие инструменты позволяют работать совместно, как будто вы сидите за соседними столами, даже если на самом деле вы в разных концах Земли.
- В работе бывают моменты, когда вы что-то придумываете, формируете — и тут правда есть ценность в том, чтобы быть физически в одной комнате, рисовать на одной доске. А есть моменты, когда основы придуманы и надо просто сфокусированно фигачить. И вот тут офис нередко может больше мешать, чем помогать.
- Города не резиновые. Если стремиться перевозить высокооплачиваемых айтишников со всего мира в один город, качество жизни там падает для всех. Посмотрите на Сан-Франциско. Дублин, кстати, рискует повторить ту же историю. В будущем всё больше людей будут жить вообще вне городов, потому что для работы достаточно хорошего интернета.