Отличная статья от одного из основателей Abstract о том, что дизайнеры, как и люди многих креативных профессий, не застрахованы от изменений. Меняется все в нашем домене.

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

— Ваша роль может скакать как бешеный кролик. Если вы остаетесь любознательным и вкладываетесь в развитие, то рано или поздно, перед вами станет выбор: оставаться индивидуальным контрибьютором, или вкладываться в команду, качая менеджерскую ветку. Каждый путь несёт что-то своё, но все почему-то считают, что естественный путь дизайнера — это переходить в управление. Типа, сам уже наигрался, теперь говори другим, как и что делать. По-мне, это булшит. Человек должен сам выбирать, что ему интересно: если это работа руками — отлично, управление — так тому и быть. Главное, чтобы ему нравилось, что он делает и он продолжал развиваться, а не закинул ноги на стол и закурил сигару.

— Дизайн инструментарий полниться каждый день. Помню времена, когда у нас был только Фотошоп. Фотошоп, Карл! И ничего больше. И я даже боялся открывать Иллюстратор, чтобы ни дай Бог не забыть ФШ. А сейчас? Плодятся как религии и кто знает, где отрасль будет через пару лет.

— Тренды меняются ещё быстрее, чем тулы. Я уже давно перестал за ними следить. Думаю комментарии здесь излишни.

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

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

Хорошая коммуникация ещё один из столпов, на которых зиждется профессия.

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

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

https://www.abstract.com/blog/design-career-growth/

Олег Якубенков написал о разнице между Customer Development и Custdev.

Знание термина Customer Development в англоязычном IT очень низкое. Не говорите, что вы кастдевили своих клиентов, вас не поймут. Также это будет звучать странно в контексте изначального значения термина.

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

  1. Обнаружение клиентов;
  2. Подтверждение клиентов;
  3. Создание клиентов;
  4. Построение компании.

На этих этапах используются разные инструменты для проверки гипотез и получения инсайтов: глубинные интервью, опросы, AБ-тесты, тестирование рекламных каналов и всё остальное, что делают в рамках стартапа.

В русскоязычном IT методология сузилась до конкретного метода проверки гипотез — глубинных интервью. То, что мы называем кастдев, англоязычные коллеги называют User Research.

https://gopractice.ru/customer-development-custdev/

Не забывать напоминать

Друзья, заметка про любопытство и тягу к знаниям получается довольно объёмной. Обросла примерами и цитатами — оформлю её отдельной статьёй и скоро поделюсь.
А сегодня немного практичных советов, которые относятся к навыку "умение доставать нужную информацию".

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

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

👉 Отправка почты по расписанию. Если кто-то мне что-то должен в определённый день, то я заранее отправляю отложенное письмо, которое придёт адресату за день до срока долга и напомнит. Примерно так: "Напоминаю, завтра жду от вас ...". Отложенная отправка есть и в Gmail, и в Яндекс почте и наверное, много где.

👉 Если долгов много — ставлю мероприятия в Гугл. Календарь, подключаю туда "должника" и в настройки ставлю: уведомить на почту за 1 день" (или несколько интервалов).

👉 Пару раз использовал отложенные сообщения в Телеграм (их недавняя опция) — тот же смысл, что и с почтой, но более личный.

👉 Можно задействовать Trello, подключая "должника" как исполнителя на задачи со сроком — этот путь чуть сложнее, так как требует вовлечения должника в Trello.

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

Сила комментария

Сила комментария

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

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

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

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

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

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

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

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

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

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

Действие, не состояние

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

Неизвестная ошибка

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

То есть мы предполагаем действие, но не говорим его. Почему бы тогда не сказать прямо:

Ошибка — попробуйте ещё раз или напишите нам

Или вот вы тест с несколькими вариантами на выбор. Если пропустить, появляется красненькая надпись:

Не выбрано ни одного пункта

Вроде пытаемся что-то донести, но что — еще надо додумать. Почему бы не избавить пользователя от лишних додумываний?

Выберите хотя бы что-то

Действует практически во всём. Попробуйте еще раз и напишите, если не получится.

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

В первой статье разбирается просмотр данных.

1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
6. При наличии цветовых индикаторов полезно отображать легенду цветов.
7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
10. Нет ничего страшного при появлении горизонтальной прокрутки.
11. В некоторых случаях полезно маркировать просмотренные записи.
12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
13. Переход к просмотру записи удобно сделать по двойному клику.
14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».