Когда я только начинала работу в проектах, моим самым большим заблуждением было то, что пользователям важно, чтобы система много умела, а не красиво выглядела. У меня в целом вкус на интерфейсы довольно скудный. Для меня важно, чтобы значки были крупные. А то пока разглядываешь мелочь всякую, глаза выпасть грозятся. Второй пункт интерфейса – поменьше ярких цветов. Лучше монохром. Опять же, чтобы глаза не уставали от ярких пятен.
Но оказалось, что таких как я минимум. Из системы каждый раз делают разукрашку. Давайте покрасим то, что покрасить в целом нереально. Сделаем текст синим, а зальем все зеленым. Да здравствует радуга.
Вот на одном из первых проектов меня просто убивали встречи со стейкхолдерами. Суть проекта была в том, чтобы встроить в базовые алгоритмы системы фичи для застройщика. Неотъемлемой частью СРМ, сайта, BI системы застройщика является Шахматка. Вот вокруг нее и были построены все обсуждения.
На том проекте мы работали на субподряде и диктовать какие-то правила или дирижировать процессом не могли. Лишь ходили на некоторые встречи и должны были разработкой заниматься.
Интересно, что нужна была не только шахматка. В целом людям нужна была функциональная срм. Но обсуждать необходимые сущности системы никто не хотел. Суть функционала была вообще неизвестна. Т.е. непонятно было, что в итоге должно быть в системе. Наша задача, как субподряда, была основана на том, чтобы разработать сложную шахматку с рядом функциональностей и необходимых процессов. Но обсуждать хотели только интерфейс.
Шахматка должна была быть красивой. Началось все с того, что Шахматка базовая, уже реализованная в системе, не понравилась. Начали придумывать свою. С функциональной точки зрения сложностей не было: 3 вида с разным набором параметров в зависимости от масштаба. В целом не сложно и реализуемо. Но приступать к разработке не разрешали. Сначала макет.
Пришлось накидать 3 варианта в фигме. На встрече показали мокапы и началось обсуждение. Встречи длились по 3 долгих неповторимых часа. Первый час мы обсуждали цвет ячеек шахматки. Не то, чтобы кардинально, просто оттенки. Купленные квартиры должны светиться красным цветом. И пошли выбирать: винный, гранатовый, вишневый, роза, алый, арбузный, кровавый… Я так цвет маникюра тщательно не выбираю! Да вообще разница в оттенках для меня не очевидна. Быть может я не дизайнер. Ах да, я ж аналитик! Ну и цвета «вырви глаз» мне претят в интерфейсе системы. Поэтому я предлагала бледно-розовый. Но нужен был красный. Я смирилась и просто меняла цвета. А стейкхолдеры все никак не могли определиться.
Потом еще час мы двигали ячейки шахматки туда-сюда, чтобы придумать, какое расстояние будет между ячейками: 2 или 3 пикселя. Опять же. Разница не существенна. Мы перебрали всё: цвета, положение, шрифты. Казалось бы, круто! Заказчик знает, чего хочет. Сейчас отрисуем все по таким жестким требованиям. Переделывать не придется. Но нет.
Я предположила, что играет роль моя неопытность и несостоятельность, как дизайнера. Поэтому был предложен вариант: накидать прототип на ангуляре, его вывести в нужный вид и встроить в систему. Все поддержали. Разработчик подготовил все ко встрече, с учетом предыдущих требований, но это не помогло. Дальше Заказчики уже и сами начали спорить, а какие цвета хотят? Встречи заканчивались ничем. Ведущий этих встреч сотрудник никак не помогал. Мы предлагали, что могли, но все не то. Меня, как мега деятельного человека, раздражал сам факт, что мы месяц потратили на подбор цветов. Ну честно, изменить цвет – одна секунда. Мне кажется, на такие нюансы и время тратить не стоит. Уж не знаю, как обстояли дела с остальными задачами проекта, мы там не участвовали, но проект завернули. Я думала, что это просто исключение из правил. Возможно, я не поняла, что было нужно Заказчику. Где-то повлияли и условия внедрения нас в проект. Но все же, я при своем мнении – тратить столько времени на обсуждения радуги – это в сказочные сказки.
Но в следующих проектах я увидела, что интерфейс – это чуть ли не самая важная задача проекта. Должно быть красиво, удобно, просто. Должно подходить всем. Конечно, таких сложных обсуждений по выбору цветов не было. Но я в полной мере осознала важность нефункциональных требований. Сколько бы мы не реализовали логики в системе, а смотрят все равно на интерфейс. И если кнопочка расположен чуть ниже, чем хочется, то не о чем и говорить. Попросят переделать.
Работу front-end считают не самой важной и сложной. Но скажу я Вам, что бэк все-таки проще. Там уж точно никто не понимает, как надо. Поэтому и аналитик, и разработчик сидят спокойно и пилят процессы, методы, классы – главное, чтобы работало без багов. А вот front – вечный камень преткновения. Потому что объяснить, что хочется, мало кто может. Аналитик, конечно, всегда обрабатывает требования, приводит к понятному разработчику виду. Но в 90% случаев что-то приходится менять. Сейчас я в таких задачах всегда действую через мокапы. Пока мне каждый оттенок не подтвердят, я не отдам в разработку. Но это действительно тяжкий труд. Мне проще продумать архитектуру объектов, взаимодействие процессов и методов. Обсудить решение с разработчиком. Отдать в реализацию. А вот интерфейсные задачки могут просто изничтожить всю нервную систему.
Отсюда делаю вывод, что нефункциональные требования важны. Но хоть бы мне поменьше такие прилетали.