Неразрывный дизайн

Мы в третий раз поддержали Буквальный челлендж. В этом году полевой номинацией была Л: мы обещали, что выберем свой топ-3, но это оказалось слишком сложно, поэтому редакция пошла на обман. Представляем наш топ-5 букв Л и их авторов 🙂

🔘Алёна Савчак и Л как объект номер 13-1

Моё исследование архитектуры опиралось на методику обследования заброшенных объектов: интересно рассматривать такие здания не целиком, а через составные части. Так и появилась идея о находках, которые не создавались специально: они были такими изначально.

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

🔘Ярослав Ярко и Л как Эль

Для меня Эль Лисицкий — пособие по композиции, как и все авангардные художники того времени.

🔘Оксана и Л как карельский петроглиф

Я давно изучаю петроглифы, лыжники из Залавруги — одни из моих любимых. Лыжники — часть большого батального полотна. Это почти пиктографическое письмо. Не имея букв, человек тысячи лет назад картинками описал важное для себя событие. Я сравниваю этот рассказ с легендарными античными поэмами и с нашими былинами о богатырях.

Целиком композиция состоит из изображений воинов, пронзённых стрелами, лодок, сцен нападения, отступления и преследования. И трое лыжников выделяются среди остальных — они крупнее, они изображены пропорционально, с широкой грудной клеткой, мускулистыми ногами, с анатомическими подробностями. Очевидно, что они не рядовые воины, и, возможно, именно благодаря им случился перелом в этой битве. Этакие наши Илья Муромец, Добрыня Никитич и Алёша Попович.

Если уметь читать петроглифы, в них можно найти много мифов, легенд и поэзии.

🔘Ксюша Крылова и Л как стрекоза из семейства люток

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

🔘Олег Поручиков и Л лирического осеннего настроя

Эта Л — скорее собирательный (простите за каламбур) образ, проявившийся из пластики листиков. Они берут за душу способностью в своём угасании запечатлеть печальное очарование временного.

#поле_графики

Я всё собираюсь написать пост про то, чему ещё учиться и что ещё дизайнить продуктовому дизайнеру, кроме собственно продуктового дизайна. Но это когда-нибудь потом, а сегодня вот что)

Я участвую в Буквальном челлендже (там каждый день нужно рисовать букву русского алфавита), просто для развлечения, потому что люблю буковки. Но мою букву Л забрал к себе в подборку дизайн-канал «Поле», так что несу похвастаться😊 👇

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

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

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

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

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

Я сейчас снова учусь на курсах. Они не связаны с работой напрямую, но я обязательно про них напишу, как если доучусь.

Финальный проект мне даётся ппц тяжело, я долго стопорилась на уровне идеи. Несколько дней гоняла мысли по кругу и так и не могла начать.
Но! чтобы начать, нужно начать. Не бесконечно думать, а делать хоть что-то: просто выписать мысли, поискать рефы. Идея в голове сильно отличается от идеи с хоть какой-то начальной формой.

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

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

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

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

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

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

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

1. Форма загрузки файла

• Есть ли ограничения на количество файлов, их объём по весу, количеству строк?
• Где написать об этих ограничениях?
• Есть ли шаблон для заполнения и где его можно взять?
• Можно ли давать выбирать файлы только определённых форматов?
• Как удалить прикреплённый файл из формы?

2. Тип обработки файла

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

• Что в этот момент может делать пользователь — он должен дождаться полной обработки файла или может выполнять другие задачи?

• Если пользователь должен дождаться обработки, что он видит?
Например, крутящийся лоадер, задизейбленный интерфейс, модалку, которую нельзя закрыть, прогресс бар

• Если перезагрузить страницу, процесс работы сбросится или частично выполнится? Как пользователь об этом узнает?
• Если перезагрузка критична, где и как об этом предупредить?

• Если пользователю не нужно ждать окончания (это обычно называется асинхронный / фоновый процесс), то как пользователь узнает, что процесс завершился? Где он увидит результаты?
• Где он сможет посмотреть, что сейчас происходит с файлом и понять, что система работает, файл обрабатывается?

Часто делают некий центр задач (фоновые задачи, фоновые процессы — любое название). Там есть список всех процессов со статусами, информацией, временем до завершения, кнопками действий и прочим важным.

3. Ошибки и предупреждения

• Как мы будем показывать ошибку, если вообще не можем прочитать данные?

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

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

• Где выводить такие ошибки? Как пользователь будет исправлять эту ошибку?
• Если часть информации с ошибками, а часть нет — система проигнорирует всё или возьмёт в работу то, что без ошибок? Как пользователь поймёт, что применилось, а что нет?

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

• Есть ли предупреждения, что пользователь может с ними сделать? Как просмотреть, как исправить, как проигнорировать?

4. Успешная обработка

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

И вот из 2 экранов флоу превращается в огромную паутину макетов с корнеркейсами и разветвлениями. Зато потом пользователь не сидит в растерянности с мыслью «я что-то загрузил, оно куда-то делось, что теперь?»

Про дизайнерскую задачу

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

Например: «я не могу сделать нормальный отступ, потому что в графике уже свои отступы» (ладно, это от студента, надеюсь, просто верил в высшую меру наказания за раздетачивание).

Или: «сделал неудобно и некрасиво, потому что у нас в ДС нет нужного элемента 😢»

Или: «заказчик хочет именно этот синий, поэтому оставлю тут нечитаемый неконтрастный текст, зато он будет по ТЗ».

Ограничения существуют, легаси там, сроки, та же ДС, требования заказчика, технические ограничения, брендбук, всё что угодно.

Но ограничение — это часть задачи, а не индульгенция на плохое решение.

Если в ДС нет нужного элемента, можно пересмотреть весь флоу, обсудить кастом, в крайнем случае, честно сказать, что решения не существует в заданных рамках (но в реальности обычно можно что-то приемлемое придумать).

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

«Сделал как просили, какие ко мне вопросы» — не решение, а иллюзия снятия с себя ответственности.
Работу дизайнера всё равно будут оценивать по конечному результату. И заказчик, увидев нечитаемый текст, вообще не будет вспоминать, какой он там синий хотел.

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

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

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

И вот мне попался пост в канале TypeFeed, где автор собрал список статей про хорошую кириллицу в гуглфонтс с type.today. Сами статьи подробные и интересные, а я сделала с иишкой для себя из этого список-выжимку, и им и делюсь.

🟢 Подходят

Гуманистические гротески: PT Sans, Arsenal, Commissioner, Yanone Kaffeesatz
Геометрические гротески: Montserrat — для заголовков и акцидентного набора
Неогротески: IBM Plex Sans, Golos Text
Статические антиквы: IBM Plex Serif
Динамические антиквы: Piazzolla, Spectral
Переходные антиквы: PT Serif, Source Serif Pro, Literata, Alice, Lora
Рукописные: Shantell Sans

🟡 Средне: можно, но с оговорками

Гуманистические гротески: Open Sans, Ubuntu, Finlandica, Ysabeau, Alegreya Sans
Геометрические гротески: Rubik, Raleway
Неогротески: Roboto, Nunito
Статические антиквы: Prata
Динамические антиквы: Alegreya, EB Garamond, Cormorant
Переходные антиквы: Merriweather, STIX Two Text, Playfair Display, Tinos, Vollkorn
Рукописные: Bad Script, Lobster 🙈, Pacifico, Caveat, Comforter

🔴 Не подходят или лучше не использовать для кириллицы

Гуманистические гротески: Fira Sans, Source Sans 3, Exo 2, Andika, Istok Web, M Plus 1p, Ruda, Lunasima, Bellota Text, Carlito
Геометрические гротески: Jost, Didact Gothic, Jura, Play
Неогротески: Oswald, Arimo, Inter, Manrope, Alumni Sans, Overpass
Статические антиквы: Old Standard TT, Ledger, Brygada 1918
Динамические антиквы: —
Переходные антиквы: Noto Serif
Рукописные: Marck Script

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

Только что вернулась из мини-путешествия, и в этот раз про UX поездов.

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

А вот включение воды в раковине я без подсказки не осилила (фотка из интернета, сама так негодовала, что не сфоткала).

Я думала, что картинка рядом означает, что вода польётся, если поднести руки к крану. А оказалось, они имели в виду, что этой водой надо мыть руки, а не пить её.

Синяя наклейка при этом — на самом деле кнопка 🙈 аффорданс никакущий, по-моему. Даже лампочки вокруг не спасают.

Канал уходил в отпуск на месяц (а я нет 🥲), но зато идеи накопились.

Про паттерны продукта

Макеты со всеми состояниями, корнеркейсами, экранами ошибок выглядят как паутина. Но даже она не всегда даёт ответ, как интерфейс должен вести себя в очередной непредусмотренной ситуации, потому что реальность намного сложнее своей модели.

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

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

Поэтому тут появляются паттерны поведения продукта. То есть вид основных состояний показан, но ещё написано правило типа «Если на предыдущем уровне произошло это, то текущий уровень отображается так, если на предыдущем — то, то текущий — эдак».

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

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

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

Паттерны подукта — это не то же, что правила дизайн-системы. ДС определяет, например, как выглядит модалка, какие у неё отступы, скругления и шрифт, но структура этой модалки, tov, доступные действия уже определяются на уровне продукта.

Фигма выкатывает кучу обновлений, недавно агента своего анонсировала (в вейтлисте жду, чтобы добавили).

Но самая радостная для меня обнова — эта та, что на скрине. Я так давно мечтала, чтобы они это сделали и они, наконец, сделали! У меня всегда открыто 100500 файлов и найти тот, которого уже не видно, прямо боль была)

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

Студентка поделилась, что изучение темы accessibility сильно перевернуло её представление о роли дизайнера и его ответственности. Например, что «дизайнерский» серый тонкий шрифт — это не очень идея 🤓 Очень здорово, что начинающие дизайнеры сразу изучают этот вопрос.

Про а11y в b2c уже довольно много говорят, и, главное, делают. А вот в b2b всё не так радужно. Часто попытки дизайнеров уделять больше внимания доступности встречают сопротивление команды, потому что считается, что рабочие инструменты должны проектировать под «нормальное» состояние пользователя.
Но это состояние очень хрупкое.

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

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

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

Так что accessibility и в b2b — не отдельный режим для особых случаев, а просто нормальная страховка интерфейса на тот случай, когда у пользователя всё пошло не так.

Когда вы пишете отложку, вы указываете, что это отложка?

Я иногда прямо пишу «(отложка)» в тексте.

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

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

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

Ситуации, в которых пометка об отложке не нужна, тоже бывают, и, возможно, даже чаще. Но что интересно, ни в одном популярном мессенджере (возможно, вообще ни в одном, с перплексити так и не выяснили) нет возможности при отложках показывать дату, когда сообщение было на самом деле отправлено.
Хотя я сама регулярно получаю от других людей сообщения, начинающиеся с «Это отложенное сообщение тебе на после отпуска», то есть я точно с такой потребностью не одна 🫠

Странно, что такая штука до сих пор нигде не решена. В общем, продолжаю писать «(отложка)» вручную))

Недавно в вендинговом автомате пыталась купить печенье. Начала вводить неправильные цифры, потому что перепутала номер товара с ценой, а когда поняла ошибку, не нашла кнопки сброса или удаления. Пришлось ждать, пока автомат сбросит сам.

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

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

В этом часто нет вины интерфейса — просто люди это люди. Нам свойственно ошибаться и передумывать.

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

А в реальности всё иначе. В процессе можно понять, что хочется не с огурцом, да и вообще не роллы, забыть проверить состав на аллергены и ещё куча всего.

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

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

Хороший и плохой момент одновременно — это приходит с опытом. Чем больше знаешь контекстов и проживаешь ситуаций, тем лучше это работает.
Опыт ≠ возраст, тут речь о внимательности и любопытстве.
Можно в любой ситуации взаимодействия задавать себе вопрос: а что здесь могло пойти не так и как система должна на это отреагировать?

Ну и есть вообще-то эвристика на эту тему — user control and freedom. Так что это не я придумала))

Студент недавно пожаловался, что волнуется перед юзтестами с пользователями, переживает из-за этого и спросил, пройдёт ли это со временем или он безнадёжен.

За 15+ лет в дизайне я провела огромное количество юзтестов. Проводила тесты онлайн и офлайн, сидя рядом с респондентом. Училась на курсах по исследованиям.

И я до сих пор волнуюсь перед юзтестами.

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

Я не боюсь общаться с людьми. Прийти на глубинку, посмотреть, как пользователь работает, или поставить встречу незнакомому человеку с «привет, у нас теперь общий вопрос» — вообще не проблема.

Но сколько раз я сидела перед началом юзтеста, ждала респондента и втайне надеялась, что он не придёт.

Не всегда, конечно. Чаще всего это первый тест в серии. К последнему отпускает, а после перерыва всё начинается заново.

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

Ну и да, со временем становится привычнее и легче. Не полностью отпускает, но точно проще, чем в начале.