Автоматизированный сервис заказа электронных модулей (М10) для «Компэл»

Автоматизированный сервис заказа электронных модулей (М10) для «Компэл»

B2B-сервис
UX-проектирование
UI-дизайн

Содержание кейса

О клиенте

«Компэл» основан в 1993 году и является одной из крупнейших российских компаний, которая занимается поставками импортных компонентов и модулей для производителей электронной техники. В число постоянных клиентов «Компэл» входят известные заводы нефтегазового комплекса, машиностроения, чёрной металлургии, пищевой и обрабатывающей промышленности.

logo-lanta

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

О проекте

М10 — сервис по заказу и производству различных образцов электронной продукции.

Разберём, что это значит, на примере. Представим, что вы производите и продаёте светофоры с классическими лампами накаливания. При этом понимаете, что на рынке набирает популярность та же продукция, но со светодиодными (LED) лампами. У них дольше срок службы, а значит, для заказчиков они более выгодны.

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

Делать это на текущей линии производства — долго и дорого, ведь её придётся останавливать и перенастраивать.

Как же в такой ситуации запустить в производство новый вид продукции с выгодой для бизнеса?

Для таких случаев и нужен М10. Он позволяет создавать образцы продукции, тестировать их и совершенствовать, не используя производственные мощности заказчика.

М10 — это совместный проект компаний «Компэл» и «Резонит» (российский лидер по производству печатных плат и трафаретов для монтажа, входит в топ-3 крупнейших поставщиков плат из Китая).

«Компэл» отвечает за подбор электронных компонентов, которые будут монтироваться на плату, а «Резонит» — за изготовление и монтаж печатных плат. Аналогов у проекта в российском сегменте нет.

Целевая аудитория сервиса — разработчики прототипов электронных модулей и снабженцы, которые их заказывают.

До М10 разработчики создавали тестовые образцы в специальных программах по типу P-CAD или KiCad, а затем искали компоненты у разных поставщиков. Если каких-то деталей не было в наличии, сотруднику приходилось менять образец и заново искать компоненты.

После того как детали найдены, разработчик искал компанию, которая займётся монтажом печатной платы (сборка отдельных элементов и компонентов на предварительно подготовленную поверхность). У подобных компаний своя загрузка и свои менеджеры, с которыми нужно предварительно обсудить все условия. Это значит тратить время на согласования сроков и загрузки производственных линий.

С М10 пользователи создают прототипы и заказывают все необходимые компоненты и детали в режиме одного окна.

Задача

Нам предстояло разработать пользовательские сценарии, подготовить прототипы, сделать дизайн-концепцию и запустить первую версию продукта.

Глоссарий

Так как тематика проекта непростая, перед началом мы составили глоссарий, чтобы общаться с клиентом и разработчиками на одном языке. Это популярная практика, которую мы регулярно используем при работе над сложными проектами. Подобный глоссарий делали и для компании «Юнигрин», когда разрабатывали им корпоративный сайт.

Ниже поясним основные термины, которые встретятся в кейсе, на примере светофора.

  • Изделие — цельное электронное устройство, готовое к использованию или продаже. Весь светофор — это изделие.

  • Электронный модуль — небольшое устройство, которое выполняет свою работу внутри более крупного устройства. Один цвет в светофоре — это электронный модуль.

  • BOM-файл (Bill-of-materials) — список материалов и компонентов, необходимых для сборки устройства.

  • BOM-on-Board — полный список компонентов, которые монтируются на одной печатной плате. Например, плата управления переключением цвета в светофоре.

  • BOM-off-Board — часть изделия, которая не монтируется на плату. Сюда входят разные детали, например: разъёмы, соединители, дисплеи, источники питания, провода, крепёж, клавиатуры, корпуса, индикация, кнопки, переключатели.

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

Сценарии

Начали с разработки основного пользовательского сценария «Заказ тестового образца».  

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

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

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

Первая версия

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

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

Вторая версия

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

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

Третья версия

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

  • Микроинтерфейсы — блоки интерфейса, которые можно переиспользовать в рамках одной или нескольких систем клиента. Например, блок доставки.
  • Функциональные сервисы — программная часть системы, которая автоматизирует конкретные действия. Например, парсер документов, подборщик компонентов.

Эти данные нужны разработчикам для понимания архитектуры проекта.

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

Проектирование и дизайн

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

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

Мудборд

Работу над дизайном начали с подбора референсов и составления мудборда. Отсмотрели большое количество работ на dribbble и behance, реальные сайты и программы, включая профессиональные редакторы для создания плат, с которыми чаще всего взаимодействуют пользователи.

Главным критерием и ограничивающим фактором для будущего интерфейса было то, что это рабочий инструмент, а значит, должен обладать следующими свойствами:

  • понятный, не запутывает пользователей;

  • однозначный и легко читаемый;

  • контрастный, но не пёстрый;

  • с правильно расставленными акцентами;

  • помогает решать задачу.

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

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

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

В итоге получился такой мудборд:

На презентации вместе с клиентом проходились по каждому референсу и присваивали ему характеристики:
— простой/сложный,
— надёжный/ненадёжный,
— сложно сказать.

Победителей в категориях «простой» и «надёжный» взяли за основу для дизайн-концепции.

Шрифт

В качестве основного шрифта использовали Inter, а для элементов взаимодействия — PT Root UI. Основными требованиями для шрифтовой пары были:
— хорошая читабельность,
— поддержка большого количества знаков,
— мультиязычность.

Оба шрифта обладают этими качествами. И к тому же разрабатывались специально для использования на экранах. У Inter большие строчные буквы, что повышает его читабельность. А PT Root обладает уникальным свойством — фиксированной шириной знаков. Это значит, что если изменить жирность, размер текста не изменится. Это ценно при использовании в контролах и элементах навигации.

case-page01
Процесс поиска основного шрифта

Для лучшего понимания системы и её возможностей пройдёмся по каждому этапу отдельно.

1. Стартовая страница

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

Первыми пользователями М10 стали текущие клиенты «Компэла» — им отправляли ссылку на сервис.

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

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

2. Создание нового модуля

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

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

3. Параметры печатной платы

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

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

Решили проектировать собственный вариант калькулятора — более простой и понятный. Разделили параметры на 5 частей и выдавали их пользователям порционно. Такой подход позволил управлять вниманием пользователя.

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

Шаг #1. Основные параметры

Здесь указывается размер модуля, количество слоёв и выбирается материал.

Для наглядности добавили интерактивные схемы, которые реагируют на вводимые данные и подсвечивают соответствующую область печатной платы.

Шаг #2. Маска и маркировка

Отвечает за цвета платы и маркировок на ней. Для лучшей визуализации сразу показываем, как цвет надписей будет смотреться на печатной плате.

Шаг #3. Дополнительные параметры

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

Шаг #4. Сложность изделия

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

Шаг #5. Подтверждение параметров

На этот экран вынесены все ранее указанные характеристики с возможностью проверить и исправить ошибки.

4. Загрузка спецификации

Загрузка BOM

Напомним, что bom-файл (Bill-of-materials) представляет собой список материалов и компонентов, необходимых для сборки устройства.

Чаще всего (особенно у зарубежных разработчиков) это excel-таблица, состоящая из следующих столбцов:

  • Наименование компонента

  • Положение на плате

  • Общее количество компонентов на плате

  • Корпус

  • Бренд или производитель

  • Технические характеристики

В других случаях вместо excel может быть и pdf, doc и даже простой файл txt с разделителем строк и столбцов.

Чтобы пользователю не пришлось вручную перепечатывать данные из документа в M10, клиент написал парсер, который распознаёт информацию из документа и загружает её в систему  

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

1. Точно определиться с видом области drag-and-drop и видом загрузки, чтобы можно было без лишних сложностей переиспользовать это решение в других местах сервиса.

2. Сформулировать текст подсказки. Он должен был быть коротким, ёмким и точно давать понимание того, что именно нужно загрузить и в каких форматах.

3. Отрисовать все состояния: ховеры, вид при перетаскивании файла, вид во время загрузки и т. д. К тому же нельзя было забыть об ошибках и негативных сценарияхи (например, возврат на эту страницу со следующего шага).

Сопоставление столбцов

Как мы писали выше, М10 умеет распознавать загруженный документ, его тип и внесённые данные. Но есть сложность. Зачастую пользователи именуют колонки по своему усмотрению. Где-то могут использовать точное наименование компонента, а где-то указать только его характеристики. Чтобы избежать огромного количества ошибок, спроектировали функционал сопоставления столбцов.

Для проверки ошибок запросили у заказчика все возможные типы файлов BOM, которые им присылали клиенты. Проанализировали их и собрали вот такую схему:

case-page01
Объём проделанной работы
case-page01
Часть из аналитики

В ней содержатся возможные ошибки при загрузке разных типов документов. Далее распределили ошибки на две группы:

  • Можно исправить в сервисе. Для этого спроектировали соответствующие функции и макеты.

  • Нельзя исправить в сервисе. Разработали тексты ошибок, которые оповещают пользователя о причинах и просят исправить загружаемый файл.

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

После сопоставления всех столбцов происходит проверка строк на наличие ошибок или пустых значений.

Если система нашла ошибки, то пользователю необходимо исправить их в своём файле и загрузить его заново. Если ошибок нет, то происходит переход на следующий этап.

5. Подтверждение предложений по каждой строке

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

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

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

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

Приведём несколько вариантов поиска решений для различных блоков.

Поиск решения для таблицы:

Поиск решения для работы со строкой:

Поиск решения для фильтров:

Было проделано много работы, но ни одно из предложенных решений выше не ушло в финальный релиз. Бесспорно, это был важный этап, так как в процессе обсуждений каждого варианта и у клиента, и у нас возникали новые идеи и инсайты, которые способствовали пониманию специфики сервиса и его функциональности.

Примерно через два месяца работы над макетом пятая экранная форма приобрела свой итоговый вид.

Этот вариант вобрал в себя всё лучшее из своих предшественников.

Интерфейс

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

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

В конце строки, как финал проверки, предлагаем подтвердить предложение или выбрать альтернативное, нажав на значок «бургер».

В нижней части страницы отображается прогресс-бар, который заполняется по мере подтверждения компонента. Цвет символизирует разные состояния строк. Например, нераспознанные строки отображаются оранжевым цветом, а подтверждённые — зелёным.

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

В правом верхнем углу показываем прогноз по сроку изготовления и дату отгрузки. Данные основываются на самом максимальном подтверждённом сроке из предложенных.

Прелоадер

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

Строки, на которые подобрались предложения, подгружаются постепенно.

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

Система показывает лучшие предложения по каждой из строк BOM-файла. При этом пользователь может подтвердить или выбрать альтернативу.

Альтернативные предложения

Так как алгоритм подбирает оригинал запрашиваемого компонента, срок поставки может быть долгим. Это обусловлено разработкой электронных компонентов. Инженеры работают со своими базами и не всегда следят за новыми ревизиями или обновлениями. Указывают старые или вышедшие из оборота компоненты. Это усложняет их поиск и увеличивает сроки поставки.

Чтобы предлагать пользователям минимальные сроки изготовления, заложили в интерфейс функцию выбора альтернативного предложения. Воспользоваться этой опцией можно, нажав на иконку «бургера», рядом с кнопкой «Подтвердить».

Помимо выбора альтернативы пользователь может совершить дополнительные действия с компонентом:

1. Исключить компонент из расчёта.

2. Указать, что компонент «давальческий» и самостоятельно отправить его на производство. Способ подойдёт для уникальных компонентов, которые невозможно купить либо пользователь разработал сам.

3. Не монтировать компонент. В таком случае компоненты просто положат вместе с заказанной платой и пользователь сможет их смонтировать самостоятельно.

4. Найти нужный компонент вручную. В первом релизе продукта отказались от этого функционала из-за сложности в реализации.

5. Уточнить у менеджера. При нажатии на кнопку строка с компонентом уходила в статус «Ожидает ответа». После этого отдел технической поддержки связывался с пользователем для выяснения причин обращения.

Карточка товара

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

Чтобы перейти на следующий этап, пользователь должен обработать каждую строку и либо подтвердить её, либо выбрать альтернативное действие.

6. Загрузка конструкторской документации

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

case-page01
Пример гербер-файла из CadSoft Eagle

7. Получение предложения на расчёт

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

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

8. Оформление заказа

Для размещения заказа на этом этапе нужно проверить информацию о доставке и условии оплаты. 

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

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

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

Релиз и цикл улучшений

После запуска M10 «Компэл» пригласил в него часть своих клиентов для тестирования интерфейсов. Через несколько недель наша команда собрала статистику, обратную связь от пользователей и составила список доработок.

Самые существенные изменения претерпел интерфейс сопоставления столбцов.

Было:

Стало:

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

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

Есть обязательные столбцы (наименование, количество) и дополнительные (например, бренд или характеристики). Без заполнения первых нельзя перейти на следующий этап, а вторые помогают улучшить поиск.

Итог и выводы

В результате мы с нуля разработали высоконагруженную b2b-систему, аналогов которой в России нет:

  • Детально проработали пользовательские сценарии. Сфокусировались на целях экранных форм и их последовательности. Учли ключевые действия пользователей, микроинтерфейсы и функциональные сервисы, которые будут переиспользоваться в других цифровых продуктах компании.

  • Подготовили прототипы с акцентом на UX, разработали дизайн-макеты и обширный UI-кит.

  • Запустили первый релиз продукта и провели работы по циклу улучшений: собрали статистику, обратную связь от пользователей и внесли ряд улучшений.

Над проектом работали

icon
Вадим
Руководитель отдела управления проектами
icon
Евгения
Аккаунт-менеджер
icon
Максим
Руководитель проектов
icon
Ирина
UX Team-lead
icon
Серёжа
UX-аналитик
icon
Катя
UI-дизайнер
icon
Мила
UI-дизайнер

Другие кейсы

Корпоративный сайт для «Сибирской горно-металлургической компании»

UX-проектирование
UI-дизайн
Битрикс
+ ещё 1

Продуктовый листинг и товарный лендинг для «Ангстрема»

UX-проектирование
UI-дизайн
E-commerce
+ ещё 3

Лендинг к 10-летию Российского научного фонда

UI-дизайн
Спецпроект
Анимации
+ ещё 2

Корпоративный сайт для «Нового Втормета»

UX-проектирование
UI-дизайн
Битрикс
+ ещё 1
Сайт для новой государственной компании «Роскадастр»

Сайт для новой государственной компании «Роскадастр»

UX-проектирование
UI-дизайн
Битрикс
+ ещё 1
Обсудить проект