{"id":14252,"url":"\/distributions\/14252\/click?bit=1&hash=6dd736497be6f4b5df84f9b826d7f3d8b3ea195a64e74fa302e414535ad9c574","title":"\u041c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u043e\u043c\u0443 \u043d\u0430\u0434\u043e\u0435\u043b\u043e \u0441\u043b\u0443\u0448\u0430\u0442\u044c: \u00ab\u0410 \u0443 \u0432\u0430\u0441 \u0441\u0434\u0430\u0447\u0438 \u043d\u0435 \u0431\u0443\u0434\u0435\u0442\u00bb?","buttonText":"\u0427\u0438\u0442\u0430\u0442\u044c","imageUuid":"https:\/\/leonardo.osnova.io\/41ea37ba-b3c8-5bd8-9f5d-b05a52be8069\/"}

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

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

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

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

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

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

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

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

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

Спроектировали и разработали внутренний сервис для сотрудников инвестиционного банка. Сократили операционные затраты проектного отдела более чем на 30%. (кейс на VC)

Разработали инструмент для сотрудников крупной страховой компании из США. Через нашу систему прошло сделок на сумму более триллиона долларов.

Цифровизировали процессы на одном из самых крупных заводов в РФ. Заменили бумажные бланки на современную ИТ-систему.

А также множество других не клиентских сервисов для разных компаний по всему миру.

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

Кейс: от бумажек к приложениям

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

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

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

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

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

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

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

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

«Семь раз проверь, один раз подпиши»

ИТ-мудрость

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

  • планшет закреплён в кабине водителя вертикально;
  • в кабине не всегда хорошее освещение;
  • пользователи управляют машинами на опасном производственном объекте, так что нужно приложение не отвлекающее внимание.

И как бонус:

  • будущим юзерам чужды все эти «цифровые приблуды».

— Лучше карандаша ничего нет, он даже в космосе пишет. ©

Пожелал сохранить анонимность.

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

Это ненастоящий интерфейс приложения, но смысл сохранён.

Итого:

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

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

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

Ещё один небольшой кейс в ту же тему

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

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

Кейс: от MVP до полноценной системы

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

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

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

Маленький фикс-прайс проект — говорили они… Будет весело! — говорили они…

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

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

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

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

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

  • Сколько есть заготовок, из которых мы делаем блюда? Как это отследить и понять на дашборде?
  • Какая карточка относится к конкретному заказу?
  • Как на одном экране понять, кто из поваров чем занят?
  • А ещё было бы здорово иметь возможность отследить количество выполненных заказов ретроспективно и спрогнозировать уровень загрузки в конкретные дни, чтобы не было простоя и завалов. И ещё вот это, и вот то.
Это ненастоящий интерфейс приложения, но смысл сохранён. Карточки одного цвета - один заказ. 

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

Вывод

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

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

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

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

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

  • подключение дизайнера заметно снижает вероятность «наговнякать в стол»;
  • подключение дизайнера и аналитика снижает эту вероятность ещё сильнее.

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

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

P.S.

0
11 комментариев
Написать комментарий...
Софья Мулыгина

Как от дизайнера - лайк ❤

Ответить
Развернуть ветку
Аспирити
Автор

Спасибо ❤

Ответить
Развернуть ветку
Elena Mikhailenko

Лллллллайк!

Ответить
Развернуть ветку
uxvoin

Делайте, как хочет заказчик. Вместо дизайнера лучше подключить UX-аналитика в перспективе на фикс прайс, на предмет тестирования и фидбека от пользователей.

Ответить
Развернуть ветку
Аспирити
Автор

Хороший комментарий. Спасибо!

Заказчику часто не так важно, как именно и кто будет делать. Ему важен результат, чтобы работало за определённый бюджет. :)

Если бюджет и сроки позволяют, то подключить UX-аналитика может быть хорошей идеей.

И ещё пара мыслей из опыта на этот счёт:

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

Принцип примерно такой: если с задачей может справиться Т-специалист, то мы подключим его. (например UX/UI-дизайнер, который может в базовый UX-анализ при необходимости) Это дешевле и быстрее.

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

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

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

Ответить
Развернуть ветку
Andrey Andreykin

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

Ответить
Развернуть ветку
Andrey Andreykin

Как и все остальные роли, что уж. Сам у себя и закажет также.

Ответить
Развернуть ветку
Игорь Александрович

Здравые рассуждения. Согласен во всем с вами

Ответить
Развернуть ветку
Артем Салютин

Нередко реально на основе прототипов собрать на готовых компонентах, и этого вполне хватает для решения задачи

Ответить
Развернуть ветку
Аспирити
Автор

Да, конечно. Нередко можно обойтись шаблонами.

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

Но совершенно точно, что к любому проекту нужно подходить индивидуально и не изобретать велосипеда там, где нет такой необходимости.

Ответить
Развернуть ветку
Аспирити
Автор

Ну и желательно, чтобы всё равно дизайнер собирал даже если и из стандартных компонентов интерфейс. :) А то

Ответить
Развернуть ветку
8 комментариев
Раскрывать всегда