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

Потом появляются требования к следующему релизу, и мы наворачиваем улучшения, и все постепенно становится лучше и лучше… Пазл аккуратно складывается, просто мечта.

Ха-ха-ха!

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

В итоге, наш классный дизайн на очередном релизе выглядит как Франкенштейн, который просит его убить, чтобы не мучаться. Как к этому привыкнуть? Как подстраховаться?

Вселяемся ненадолго в измученное тело разработчика.

В нефункциональных требованиях определяется как и в каких условиях система будет работать, какие технологии и методы подойдут.

Например, если мы не поддерживаем старые браузеры, то на них может нифига не работать. Зайдя на какой-то сайт с древнего Internet Explorer можно увидеть заглушку «Пожалуйста обновите свой браузер». А можно увидеть кривую-косую, но работоспособную версию.

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

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

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

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

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

Уже недостаточно проработать «А что будет если тут нет данных». Корнер кейсы глубже, чем ты думаешь. Теперь надо думать: «А что будет если тут нет фичи вообще нахрен?».

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

Теперь, если мы получили 1 колонку вместо 5 вместо таблицы мы покажем список. Если у нас отвалилась интерактивная карта, мы покажем адреса. Если красивые графики не построились, это текст с акцентом на цифры.

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

Теперь это не идеальный шот для дрибла, это путь с точками отказа. Так упрощенная версия дизайна из Франкенштейна становится приоритетной версией.

Пустой блок где должен быть отчет с надписью «Здесь ничего нет, скоро будет» — плохо. «Скачать отчет» — хорошо. Нет визуала, увы, но пользователь достигает цель.

Разработчики: — Мы не успеваем запилить эту фичу, ее в этом релизе не будет…

Раньше: — Бляяяя…мой дизайн.

Теперь: — Окей, переходим к плану Б, у меня уже есть макет.

Изящная деградация дизайна это не провал, это уже стратегия.