Истории Танского про флекс

Миша Танский показал видос своего доклада с 404феста:

Там четыре истории, которые полезно послушать начинающим дизайнерам. Прокомментирую.

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

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

Просто запомните как принцип: в первую очередь рассматривать решение в виде плейнтекста, а уже потом в виде специально придуманного под задачу интерфейса.

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

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

Третья история про «анду без анду». Типа люди иногда по ошибке делали в приложении Y и просили анду (правильно просили). Но технически реализовать анду было суперсложно (я в это, конечно, не верю, но это сейчас не важно), поэтому перед действием сделали подтверждение. Фишка в том, что вместо текста «Точно сделать? Да / Нет» в окне подтверждения написано «Готово! Завершить / Отменить». Подтверждение вместо анду — нормально как флекс, но, конечно, это плохой интерфейс. И замена одних слов другими в этом ничего не меняет, потому что проблема подтверждений не в словах, в чём легко убедиться, представив, что интерфейс на венгерском.

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

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

Четвёртая история похожа на первую. Как только Миша рассказал, что люди недозаполняли форму, а потом у них пропадали данные, первый же вопрос в моей голове был — «А чего их в локалсторидж-то не писать»? Я несколько лет назад проходил подобную историю в Эгее, когда думал о том, как не терять недописанные заметки при сбоях интернета. Перед тем, как так и сделать, ребята пытались спроектировать какой-то сложный мир черновиков с горой интерфейса для всего.

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

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

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