Зачем дизайнер, если не нужно красиво?

Всем привет! На связи Аспирити — студия разработки из Сибири.

Мы специализируемся на внутренних сервисах и инструментах для бизнеса.

Как разработчикам внутренних сервисов, иногда приходится отвечать на вопросы типа:

— Зачем дизайнер на проекте, да ещё и на такой срок? Нам не нужно красиво. Можем вместо дизайнера подключить ещё одного разработчика?

Ситуация понятная: клиент хочет разработать внутренний инструмент без дизайнерских изысков. Продавать его не собирается, поэтому вкладываться в отточенный UX/UI не кажется важным. Бюджет на дизайн интуитивно хочется порезать до минимума.

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

Почему мы можем об этом писать?

У нас множество подобных кейсов как в РФ, так и за рубежом.

Так что постараемся обойтись без лишней теории, а вместо этого покажем пару свежих кейсов, поделимся успехами и факапами. Погнали!

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

Что за приложения?

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

Оно должно было заменить старый добрый планшет с закреплённой бумажной таблицей и карандаш за ухом.

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

Может ли это сделать фронтенд-разработчик? Возможно.

Но учтёт ли он все подводные камни, нетипичные сценарии и решения для них, чтобы приложением не было больно пользоваться? Не факт.

Изначальное ТЗ было подробным, но не было развёрнутого описания контекста использования приложений. Так как проект был фикс-прайс, мы отправили нашего дизайнера-проектировщика в командировку на сам завод. Ибо жизнь научила: насколько бы подробным и точным ни было ТЗ, проверь его ещё раз, перед тем как подписываться в договоре.

На месте вскрылись интересные подробности:

И как бонус:

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

Итого:

В проектах подобных этому часто упускаются важные детали контекста использования будущей ИТ-системы. И также часто не закладывается бюджет на ввод в эксплуатацию.

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

Обеспечить это всё — одна из важных задач дизайнера на проекте в Аспирити.

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

Подбор цветовой палитры, размера кнопок и т. д. — это не самая профильная работа для разработчика. И результат такой работы предсказать не всегда легко. Соответственно, это лучше поручить дизайнеру.

Недавно мы взяли в работу нетипичный для себя проект. Автоматизация производства одной известной сети доставки.

Изначально это планировалось как маленькая шалость — MVP/R&D за недорого. Чтобы заказчику попробовать новые технологии в оптимизации производства, а нам порешать интересный бизнес-кейс и технологические задачки. В частности, нужно было интегрироваться с системой «Iiko», для нас это был первый опыт.

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

Ещё раз: «семь раз проверь, один раз подпиши».

Вернёмся к проекту. На дашборде отображаются карточки — конкретные блюда из заказов, исполнители (они же повара на смене), а также имеющиеся ингредиенты для приготовления блюд (заготовки). Карточку можно назначить на повара. Несколько карточек = один заказ.

Дашборд позволяет оценить степень загрузки поваров, чтобы оператор в онлайн-режиме смог дать точный прогноз готовности заказа и отследить все этапы приготовления. Если проще — приложение помогает понять, когда заказавшим себе еду стоит готовить тарелки и встречать курьера. Так что это приложение с высокой социальной значимостью. :)

Но как это всё отобразить, чтобы было не просто полотно текста и таблица со скроллом в бесконечность? Желательно сделать так, чтобы ребята на кухне и операторы не плакали кровавыми слезами, пытаясь привыкнуть к новой системе. В итоге мы сдались и решили, что это вопрос для дизайнера, подключили UX/UI на полставочки.

По ходу работы начали выползать дополнительные вопросы:

И в итоге маленькая шалость разрастается в объёмную систему, для которой нужен и полноценный дизайн, и нормальная аналитика. То есть для масштабирования системы по-хорошему нужен UI-kit с учётом особенностей использования приложения. Чем раньше заложим правила дизайна, тем меньше вероятность, что не придётся переделывать какие-то части в дальнейшем, когда решим добавлять новую функциональность. Очевидно, для этого в команде с самого старта неплохо быть дизайнеру.

Во внутренних сервисах, в отличие от рыночных продуктов есть бизнес-задача заказчика. Сам заказчик часто не является пользователем системы, поэтому не кажутся важными UX/UI практики.

Если убрать всю философию в сторону, то любая бизнес-задача — это деньги.

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

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

До какого масштаба целесообразно раздувать команду? — нужно решать по каждому проекту отдельно. Многое зависит от этапа жизненного цикла, целей и планов. Нужно правильно балансировать на грани вложенных средств и возврата инвестиций.

Но это уже другая история. Всем спасибо, кто дочитал!

P.S.

Если понравилось, чекайте нашу первую статью про кейс цифровизации.