Corner Cases (корнер-кейсы) в UX-дизайне: как они ломают интерфейс и психику команды

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

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

Спустя неделю на дизайне сидела команда разработки и ребята хлопнули. «А что, если у пользователя плохой интернет?» — спросил бэкендер. Я честно ответил: «Тогда он перезайдёт». Слышу следующее: «А если сервер отдаёт 502, ты предлагаешь ему просто смотреть на кнопку?»

В другой жизни я бы спорил. Но тут влетело следом:

• У одного фамилия из четырёх слов. Не помещается.
• У второго — номер начинается на +688. Это Токелау. Да, это страна.
• У третьего — кнопка «назад» не работает, потому что ты зачем-то сделал её на absolute и забыл fallback.
• И ещё: если он отправил форму дважды — данные улетают дважды. Потому что ты не предусмотрел блокировку.

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

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

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

Что такое корнер-кейсы и почему они важны

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

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

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

Я видел, как интерфейс ломался из-за одного пробела в конце email. Как дата рождения 31 февраля крашила приложение. Как пользователь из Монголии не мог зарегистрироваться, потому что в списке стран не было Монголии (но был Ватикан дважды).

Никто не пишет тесты на такие темы. Никто не рисует пустые состояния на «сервер умер, но пользователь жив». А потом приходит тикет в поддержку — и ты понимаешь, что макет красивый, но слепой.

Это не ошибка, ты просто забыл, что пользователи бывают настоящими

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

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

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

Хочешь сделать интерфейс, который не рухнет при первом чихе? Тогда тебе придётся признать: у пользователей бывают плохие дни. Странные телефоны. И фамилии, которые не влезают в твой идеальный input.

Где прячутся корнер-кейсы

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

Самое популярное место их обитания — формы. Да, те самые поля, которые ты копируешь из проекта в проект, не глядя. Имя, фамилия, email, номер телефона. Вот только иногда у людей нет фамилии вообще, или наоборот — их три. Иногда номер телефона начинается с +870, и это не выдумка, а спутниковая связь. А иногда пользователь решает не указывать пол. Ни мужской, ни женский. Просто оставляет пустым. Что делает твой макет в этот момент — зависит от твоей предусмотрительности. Или её отсутствия.

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

Кажется, мелочь. На деле — поломка всего флоу

Корнер-кейсы любят шнырять по «второстепенным» экранам:

• Уведомления, у которых нет текста.

• Шторки, которые открываются без данных.

• Кнопки, которые ведут в никуда, если нет интернета.

• Окна подтверждения, в которых уже ничего нельзя подтвердить.

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

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

Вот пример: пользователь отправляет форму дважды. Потому что ему показалось, что не сработало. Два клика. Два заказа. Два возврата. Один дизайнер — и много новых слов от продуктовой команды.

Откуда они появляются

Ты не видишь их в начале. Потому что никто не описывает их в требованиях. Потому что они не входят в MVP. Потому что тестировщик просто не подумал, что кто-то захочет ввести пробел в поле «имя».

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

Чем опасны корнер-кейсы

Сначала они выглядят безобидно. Ну подумаешь, пользователь ввёл лишний пробел в email. Или у него фамилия через дефис, а твоя система решила, что это тире. Или у него адрес вида «а/я 49», а у тебя строго «улица — дом — квартира». Это не баг. Это мелочь. До первого реального пользователя.

А потом начинаются тикеты. Поддержка закипает. Аналитика показывает неестественные дропы в воронке. И все смотрят на тебя, потому что форма была «твоей».

Корнер-кейсы опасны тем, что они не бросаются в глаза. Они не крашат всё сразу — они портят всё по чуть-чуть. Убивают доверие. Бьют по UX. Дезориентируют. А в конце концов — сжирают время всей команды. И это время не на развитие, а на латание дыр.

Один сценарий — минус вся экономика

Допустим, пользователь не может оплатить, потому что у него карта с необычным кодом или номером. А ты показал ему «Ошибка», потому что тебе лень было придумать нормальное сообщение. Он ушёл. Но самое обидное, что он не вернётся.

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

Самое подлое — они всплывают на запуске. Не в тестах. Не в прототипе. А когда всё в проде, а ты уже в отпуске. Именно тогда пользователь с браузером IE9 на десктопе Windows XP решает купить подписку — и покупает дважды. А потом пишет в поддержку.

Корнер-кейсы выжирают ресурс команды

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

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

Как дизайнеру научиться думать корнерами

Хорошая новость: ты не обязан предугадать все корнер-кейсы. Плохая новость: ты обязан хотя бы признать, что они точно будут. Думать корнерами — это не про тревожность. Это про здравый смысл. Ты не параноик, если добавляешь «а что, если нет данных» — ты взрослый.

Первое правило — не влюбляйся в happy path. Это как в фильмах про ограбление века: всегда есть план, и всегда что-то идёт не так. Нарисовать путь, где пользователь плавно заполняет все поля и радостно нажимает «Отправить» — это только половина работы. Вторая — нарисовать, что будет, если у него отрубится интернет, закончится сессия или он случайно нажмёт дважды.

Хорошая практика — устраивать себе 15 минут паранойи перед макетами. Садишься и выписываешь всё, что может пойти не по плану. Нет данных? Неверный формат? Человек нажал не туда? Вернулся назад? Всё сбросилось? Отлично, у тебя уже есть список экранов, которых пока нет, но которые точно нужны.

Сценарий без данных — тоже сценарий

Ещё один простой приём: прорабатывать не только то, что есть, но и то, чего нет. Экран без заказов. Пользователь без фото. Профиль без имени. Лента без карточек. Все эти штуки чаще всего оборачиваются пустотой или заглушкой из стоков. А потом ты удивляешься, почему retention rate такой низкий. Потому что пользователь чувствует: ему тут не рады.

Добавь нормальное пустое состояние. Объясни, что происходит. Дай действие. Поверь, один хороший zero state спасает больше пользователей, чем три идеальных баннера.

А ещё — блокируй всё, что может поломать логику. Кнопки «назад», которые делают не то. Форма, которую можно отправить дважды. Возможность нажать что-то, пока грузится. Это скучно. Но это спасает.

Как показать корнер-кейсы в кейсе, чтобы тебя заметили

Большинство кейсов на Behance — как витрина в барбершопе: красиво, модно, но всё слишком чисто. Идеальные скриншоты, идеальные юзеры, идеальный флоу. Такое ощущение, что никто никогда не отменял заказ, не забывал пароль и не пытался ввести имя «Илон-Маск-младший™».

Проблема в том, что реальные работодатели и продуктовые команды это видят. И понимают, что ты не сталкивался с жизнью. Потому что если бы сталкивался — ты бы точно где-то показал: «А тут мы предусмотрели, что пользователь может быть без телефона. Или наоборот — с двумя».

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

Что можно показать в кейсе?

• Сценарий пустого состояния: как выглядит экран, если нет данных.
• Ошибка: как ты отрисовал фолбэк и продумал UX-сообщение.
• Сценарий отмены или нестандартного действия (передумал, вернулся назад, закрыл приложение).
• Адаптация формы под разные страны / языки / форматы.
• Вариант, когда пользователь делает всё «не по плану» — и всё равно получает нормальный опыт.

Если ты такие штуки делал — обязательно показывай их. Не в комментариях под макетами. Не в сторис. А прямо в кейсе. Подпиши: «Вот тут мы учли, что пользователь может нажать дважды. А здесь — что он может вообще не указать email».

Это честно. Это интересно. Это вызывает доверие. Потому что таких дизайнеров мало. И такие дизайнеры не просто оформляют, а проектируют опыт.

Зрелость дизайна — это не пиксели, а предусмотреть исключения

Хороший дизайнер делает красиво. Отличный — делает, чтобы работало. А зрелый — делает так, чтобы работало даже тогда, когда всё пошло не по плану.

Корнер-кейсы — это не edge-кейсы, не мусор, не крайности. Это то, что проверяет прочность твоей логики. И твоей ответственности. Потому что кнопка «Продолжить» — это просто прямоугольник, пока ты не задумаешься, что будет, если пользователь нажмёт её без интернета, с пустыми полями, дважды подряд, через прокси, с отключённым JavaScript и одним глазом.

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

В этом и есть суть зрелого UI-дизайна: предусмотреть хаос и подготовить интерфейс к нему заранее. Не драматизируя. Не усложняя. А спокойно. С уважением к тем, кто придёт в наш продукт — не с идеальной воронкой, а с реальной жизнью.

И если ты это читаешь и киваешь — значит, твой дизайн уже взрослеет. А вместе с ним и ты.