Истории из производства

В проектной работе есть этап, когда команды заказчика и исполнителя присматриваются друг к другу. Можно ли вообще доверять этим людям? Хватает ли у них профессионализма? Мы вообще друг друга понимаем? Так принято, что эти вопросы в более-менее явном виде задает заказчик. Но и команду исполнителя интересует ровно то же самое и ровно с той же целью: сделать работу хорошо. Какой-то кредит доверия на старте есть. Со стороны заказчика он закреплен предоплатой, со стороны исполнителя — взятыми обязательствами. Важно, что это стартовое доверие нужно развивать. Давайте на примере. Дано: заказчику нужен редизайн зоомагазина. Он признает нашу экспертизу во всем, что касается интерфейсов и визуала, но с осторожностью относится к нашим попыткам выйти в надсистему и посмотреть на жизнь пользователя в целом, не только в контексте заказа корма, лотка и вкусняшек. А нам надо в эту надсистему, потому что задача поставлена шире, чем редизайн того, что есть. У заказчика есть концепция развития, отдельные пункты которой в явном виде влияют на интерфейс и на пользовательское поведение. Понять друг друга помогают таблички, схемы, CJM. Конкретно в этом проекте мы параллельно (это важно!) с работой по проектированию быстро-быстро (и это важно!) собрали карту потребностей пользователя и показали заказичку. А заказчик показал свою почти такую же, про которую мы даже не знали. Мы увидели, что у нас одинаковый ход мыслей. Без ложной скромности заметим, что наша карта оказалась чуть более подробной. Доверия друг к другу стало больше. Теперь про важное. Нет ничего хуже, чем подменять «работу руками» обсуждением схем и табличек. Поэтому «притирка» должна идти параллельно основной работе. Короче: делайте больше ожидаемого, чтобы завоевать доверие — и делать ещё больше.

«Соберите нам дизайн-систему, покажите, как пользоваться, а дальше мы сами». Это достаточно типовой запрос к нам, и мы всецело его поддерживаем. Биться в истерике «как же вы без дизайнера соберете себе целую страницу с тремя формами и таблицей» как-то непрофессионально, что ли. Знаем, что соберут, если в руках будут необходимые кирпичики. И не будет лишних. Проблема универсальных дизайн-систем в том, что нужно обладать отдельной компетенцией, чтобы их использовать. И в дизайне, и в разработке. Если коротко, то готовое жмет по двум пунктам. 1. Слишком много лишнего, которое только запутывает дизайнера и вызывает неодолимое желание использовать всю палитру возможностей. То есть превращать интерфейс в винегрет. 2. Не хватает двух суперважных лично для нас элементов. Всего двух! Но важных. Так что желание сделать маленькую, но свою дизайн-систему — понятно и часто более чем оправданно с точки зрения бизнеса. Задача по созданию дизайн-системы всегда идет от частного к общему. Сначала надо сделать работающий интерфейс, а потом разобрать его на отдельные кирпичики. Можно срезать путь, сейчас покажем на примере. 1. В качестве вводных заказчик предоставил скриншоты существующей системы. Но не просто скриншоты, а компиляции интерфейса. Без контекста, без объяснений, как оно работает. Так, чтобы на нескольких картинках присутствовали все существующие в системе интерфейсные куски — от элементарных до крупноблочных. Все это наши дизайнеры внимательно изучили. 2. Мы перерисовали и расставили по сетке. Ценности в этой рутинной работе никакой нет (как бы нам ни хотелось верить в обратное). Особенно когда требования к визуалу не «покрасивше», а «попроще и поплотнее». 3. Самый важный этап — разобрать спроектированные макеты на составные части. Собрать ту самую маленькую, но дизайн-систему. Здесь есть нюансы, потому что почти наверняка захочется итеративно вернуться ко второму пункту. Нам хотелось, и мы возвращались. Собственно, всё. Добавить нечего. Разве что респект опытному заказчику. Как ни странно, оперирование абстрактными интерфейсами требует отдельной квалификации. В более общем случае нам понадобилось бы отрисовывать реальные страницы и сценарии, что увеличило бы объем работы. Короче: дизайн-системы — не для дизайнеров.

Усталость от проекта. Сталкивались с таким? Проект идет долго, самое интересное уже сделано, все стадии по Егору Летову успешно пройдены, концептуальные решения приняты, архитектура финального решения понятна во всех деталях. А проект все не заканчивается. И все устают. И заказчик, и исполнитель. Бывают изначально «скучные» проекты. В кавычках, потому что это не скука на самом деле, а просто такой тип работы — без креативного полета дизайнерской фантазии. Какой-то интерес всегда есть. Например, в том, чтобы настроить конвейерную поставку макетов по четкому заданию. Речь про другое, речь про проекты, которые длятся долго и не спешат заканчиваться. Это тот редкий случай, когда есть простое решение, как вернуть в работу необходимую толику драйва и интереса. Сменить менеджера. Как ни странно, в этом почти нет рисков, если новый менеджер вменяемый и профессиональный (а других-то у нас и нет). Получается интересно. Смена менеджера (обычно вынужденная) в начале и даже в середине проекта почти всегда проходит болезненно. Смена дизайнера в начале работы — почти незаметно, порой даже с пользой. В конце затянувшегося проекта все с точностью до наоборот. Срабатывает коммуникационная магия. Новому менеджеру интересно разобраться. Команде заказчика интересен новый человек. Работаем дальше! Короче: меняйте менеджера под конец затянувшегося проекта.

Этот проект претендовал на звание «самый скучный проект года». Дизайн несложного корпоративного портала по 56-страничному ТЗ. «6.2.3.1.3. Заявки на хозяйственные/канцелярские товары, визитные карточки, штампы, ремонт и мебель». Не то чтобы жалуемся. Все работы хороши. Кто-то же должен красить забор и собирать портал по четкому (и, кстати, очень внятному) заданию. Мы же профессионалы, какое нам дело до интереса. Ведь так? Не так. Интерес участников к тому, что они делают, всегда сказывается на качестве. Интерес нужно искать. Причем искать его внутри своей профессиональной области. В случае с порталом «часть» интереса нам задал заказчик. В качестве вводных нам достались скриншоты некоторых (далеко не всех) страниц прошлой версии. Сам портал не сохранился. Это уже челлендж — сделать так, чтобы было похоже на что-то, что мы видели только на картинках. Похожесть нужна для пользователей, которые меньше всего хотят изучать новый сайт. Второй челлендж нашли сами: свести все шесть разделов к минимальному набору типовых страниц. За это скажут спасибо не только пользователи, которые везде будут видеть схожий паттерн расположения информации, но и разработчики, которым будет проще переиспользовать уже сверстанные куски. Врать не будем, задача не сверхсложная. Может быть, немного рутинная: перебирать наброски, прикладывать их к разным разделам ТЗ, смотреть, удается ли соблюсти единообразие, или блок со ссылками на документы нужно еще потаскать по экрану, чтобы и в пункте 6.1.4.1.12 было хорошо, и в 6.3.2.2.7 ничего не поехало. Как в любом дизайнерском приеме, здесь есть техника безопасности. Критично важно, чтобы интерес дизайн-команды бился с интересом бизнеса. Упростить разработку — это круто. А радиус скругления уголков может быть любой. Короче: поиск интереса — задача команды.