В этом выпуске: статьи о тире, индустрии создания цифровых продуктов, всплывающих подсказках, рекомендациях, которые могут пригодиться даже опытным дизайнерам, а также о понятии расширяемой категории.
Тире
Анна Данилова написала о тире.
То, что мы обычно называем просто «тире», — это длинное тире.
В зависимости от убеждений дизайнера, технических возможностей и характеристик шрифта, тире отбивается межсловными пробелами, тонкими пробелами или не отбивается вовсе.
Если говорить о характеристиках шрифта, например, в Arial у тире нулевые полуапроши (расстояние от края кегельной площадки до крайней точки рисунка символа), в других — авторы сознательно закладывают большие полуапроши, чтобы не отбивать тире вовсе.
В вебе всё усложняется тем, что набирать пробелы разных толщин с клавиатуры нельзя. При копировании из текстового редактора многие платформы заменяют специальный пробел на обыкновенный межсловный. В соцсетях и вовсе не получится пользоваться специальными пробелами.
Исторически длинное тире делалось размером с прописную М (поэтому оно называется Em dash). Некоторые иностранные типографы считают его слишком длинным и не используют в тексте. В современных шрифтах у тире бывают разные пропорции, а некоторые шрифтовики делают несколько типов длинного тире — «устаревшее» длинное, более современное покороче и т. д.
Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.
По русским правилам вёрстки тире не переносится на следующую строку, кроме случаев с прямой речью. Если тире стоит в начале строки, по правилам корректуры — это прямая речь. Поэтому в тексте тире стоит отбивать слева неразрывным пробелом.
Индустрия создания цифровых продуктов
Вадим Митякин написал об индустрии создания цифровых продуктов — первая глава будущей книги о продюсерском подходе.
Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.
Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.
Типы проектов:
- Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений;
- Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях;
- Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.
Слабые специалисты не вытянут проект типа «мозги». Если крутые будут делать слишком простые проекты, разработка будет слишком дорогой, а специалисты потеряют мотивацию и покинут компанию.
Типы исполнителей:
- Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат;
- Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента;
- Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер;
- Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.
Бизнес-модели:
- Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента;
- Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.
Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама.
Настоящее проектирование в руках профессионалов — это инструмент, который даёт возможность точно целиться в бизнес-цели проекта и дальше решительно действовать. Оно сокращает бюджет и сроки проекта: вместо поисков в темноте наугад проектирование как фары автомобиля освещает дорогу, по которой движется проектная команда. Проектированию предшествует этап анализа бизнес-задачи клиента. Если задачи не сформулированы, то проектирование не даст результата. Также оно связывает разных участников экосистемы.
(Самая популярная ссылка в этой подборке, если судить по количеству лайков в ВК.)
Всплывающие подсказки
Адам Сильвер написал о всплывающих подсказках (tooltip).
Подсказки отображаются, когда пользователь наводит курсор на определённые элементы интерфейса. Они объясняют, что означают эти элементы и как работает интерфейс.
Проблемы:
- Пользователи не всегда замечают, что подсказки есть;
- Пользователь должен что-то сделать, чтобы получить подсказку. Плохо, если в ней находятся, например, требования к паролю. Скорее всего, пользователю придётся их посмотреть;
- Подсказки могут частично закрывать содержимое и элементы интерфейса. Чтобы заполнить поле, пользователю придётся запомнить текст подсказки;
- Подсказки могут обрезаться на маленьких экранах;
- Элементом, с которым пользователь взаимодействует для отображения подсказки, может быть иконка без подписи. В этом случае не всегда бывает понятно, как указать на этот элемент при голосовом взаимодействии с интерфейсом. «Нажми на колокол, нажми на уведомления…»;
- Отображение подсказки при наведении курсора — не самый удобный способ взаимодействия: курсора нет на тачскринах, ховер может быть отключен, сложно прицелиться, пользователь может навести курсор случайно, нельзя взаимодействовать с текстом подсказки (например, скопировать).
Решения:
- Переделайте дизайн. Если для работы с интерфейсом пользователю нужны подсказки, это плохой интерфейс;
- Подпишите иконки или замените их на текстовые ссылки;
- Сделайте важные пояснения видимыми по умолчанию;
- Для подсказок используйте inline toggle, который активируется кликом и не скрывает содержимое с элементами управления.
Рекомендации дизайнерам
Евген Эсану прочитал обновлённую версию «Не заставляйте меня думать» Стива Круга и сформулировал рекомендации, которые могут пригодиться даже опытным дизайнерам:
- Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова;
- Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные;
- Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение;
- Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1;
- Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться;
- Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого;
- Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт;
- Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях;
- Учитесь задавать правильные вопросы;
- Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».
В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь.
Расширяемая категория
На рынке FMCG есть интересное понятие — расширяемая категория. Это такие товары, потребление которых растёт при увеличении объёма товара в упаковке.
В среднем при покупке 950 мл молока люди возвращались в магазин через 7 дней, однако, когда эти же покупатели приобретали фасовку 1450 мл, период увеличивался до 8,5 дней. Таким образом, при покупке 950 мл потребление в день составляло 134 мл, а в случае 1450 млн возрастало до 173 мл.
В Европе самая расширяемая категория — шоколад, так как сколько бы потребитель ни приобрел за раз, он возвращается за покупкой практически через такое же количество дней, что и при обычной покупке.
(Заметка из моего личного телеграм-канала «Френч-пресс».)