Особенности работы над интерфейсами в “железном” проекте. Часть 2.
Здесь я опишу конкретные интерфейсные решения и свои наблюдения, которые были сделаны в процессе разработки.
В первой части описан проект “Симкомат”, о котором здесь идет речь, а также особенности работы с “железом”.
Интерфейсные решения
Я сразу перейду к делу, так как вступление было описано в предыдущей части.
Позиционирование объекта в устройстве при сканировании
В нашем Симкомате два сканера: для паспорта и для договора.
Договор — это узкая бумажка, в нижней части которой есть место для подписи. Сканируем договор мы для того, чтобы определить наличие этой самой подписи. После того, как человек ставит подпись на договоре, он должен “скормить” его сканеру и тут встает вопрос, как сделать так, чтобы человек правильно вставил договор в сканер. У меня, как обывателя, это всегда вызывает сложности. Когда нужно, например, прокомпостировать билет в автобусе, я никогда не попадаю нужной стороной с первого раза. Или даже банковские карточки: никак не могу запомнить, как правильно их вставлять!
Мне было любопытно, как можно сделать так, чтобы было все сразу понятно. В нашем случае решение оказалось довольно простым:
Явные стрелки на договоре и стрелки на верхней части щели сканера (как изображено на инструкции). Плюс вот такая лаконичная инструкция (она совсем немного анимирована) на экране. Всё. На тестироваии ни один человек не ошибся и даже не замешкался.
Изначально была мысль: “может снизу должны быть стрелки?”. Но после тестирования необходимость в таких размышлениях отпала.
Долгое время печати
Мы печатаем договор с помощью обычного термопринтера, который печатает чеки. На принтер в обязательном порядке (по закону) устанавливаются устройства ККМ (контрольно кассовая машина), которые создают отчеты для налоговой службы. Эти ККМ не предназначены для печати изображений и, если таковые попадаются, то печатают их о-о-очень долго. Но дело в том, что часть данных из паспорта покупателя, например, фамилию, после сканирования мы нарезаем в виде изображений и вставляем в таком виде в договор. Так мы делаем потому, что не всегда можем распознать то, что написано в российских паспортах. В итоге получаем до 40 секунд на печать одного договора.
Пока программисты ищут, как можно сократить время печати своими методами, мы оптимизируем процессы на своей стороне. Дело в том, что договор нам надо печатать два раза: один экземпляр для мобильного оператора, а другой — для абонента. Мы схитрили и реализовали печать второго экземпляра в фоне. Т.е. пока человек ставит подпись на первом экземпляре и вставляет его в сканер, принтер печатает второй экземпляр и располагает его в недрах Симкомата. После того, как приходит время, принтер выдает его за 1 секунду.
Возможно, договор в следующих версиях будет печататься другим принтером, но я привел здесь этот пример для иллюстрации интересного оптимизационного решения.
Куда девать ручку?
Договор в российской действительности с точки зрения закона может быть подписан только ручкой. Как бы мы не хотели поставить сайнпад (специальное устройство для подписывания) или предложить человеку поставить подпись прямо на экране, мы этого сделать не можем. Поэтому, когда приходит время подписи, мы выдаем человеку ручку. Для этого у нас есть специальное, разработанное нашим инженером, устройство. После того, как человек поставил подпись, у него возникает резонный вопрос: “Куда деть ручку”. “Могу ли я забрать ее себе? А не будет ли это преступлением?” Некоторые пытаются положить ручку обратно в лоток.
Сначала мы придумывали технологические решения, вроде того, чтобы добавить на лоток ручки датчик, и, если там уже лежит ручка, то не выдавать вторую ручку. И еще некоторые подобные решения. Но в результате победила простота. Мы решили в интерфейсе написать, что эта ручка — в подарок. Таким образом убили двух зайцев, один из которых лояльность и хорошие эмоции. Картинку показать не могу, потому что пока не реализовали это решение.
Бережная обработка возможных ошибок устройств.
Как я уже писал, в Симкомате очень много устройств и каждое из них может сломаться в самый неподходящий момент. Чтобы при этом не доставить человеку неприятностей, при покупке мы во-первых проверяем работоспособность устройств (на старте покупки и в начале оплаты). И во-вторых, отказ каждого устройства обрабатываем отдельно. Дело в том, что без определенных устройств невозможна продажа, а без других, в принципе, возможна, но с оговорками (вспомните стандартную ситуацию, когда заканчивается чековая лента в терминалах). Приведу пример: если человек внес деньги в Симкомат и после этого сломался диспенсер SIM-карт, то мы не отправляем человека несолоно хлебавши, а предоставляем ему возможность зачислить эти деньги куда-нибудь с помощью платежной системы.
Для всех возможных ошибок у нас разработаны несколько стандартных сценариев на уровне всей системы.
Использование возможностей устройств для получения фидбека и управления процессом покупки.
Некоторые функции теоретически можно возложить либо на человека либо на устройство. Часто бывает так, особенно в проектах, сделанных техническими специалистами, что на человека возлагается больше функций, чем это необходимо.
- Например, сканирование паспорта. Было бы неплохо избавить человека от необходимости наживать кнопку “сканировать”, а вместо этого определить наличие паспорта в сканере и автоматически запустить процесс (в нашем текущем сканере нет технологической возможности сделать это). У этого подхода есть минусы, но они решаемы.
- Вместо смены экрана по истечении определенного времени, используем фидбек от устройств. Например, принтер выдал покупателю чек. По задумке человек должен забрать этот чек и перейти к следующим шагам. Можно сделать так, чтоб в интерфейсе нотификация “возьмите ваш чек” висела 3 секунды и по их истечении автоматически появлялся следующий экран. При этом мы понятия не имеем, взял человек чек или нет, может он отвлекся, а на экране у него происходят другие вещи, не связанные с его текущим состоянием. Но, если позволяет функциональность принтера, то мы можем определить статус чека в нем и, если человек забрал чек, сразу, не дожидаясь 3 секунд, поменяь экран. А если не забрал, то так и показывать ему нотификацию о чеке. Плюс не забыть обработать ситуацию при большом времени бездействия, которое скорее всего у нас должно быть продумано на уровне системы, а не отдельного сценария.
3. Скорость подачи договора. Наш сканер договора умеет очень быстро сканировать и перемещать сканируемое. Казалось бы, это очень хорошо, но, оказывается, не всегда. Когда сканер быстро забирает договор, это приятно. Приятно эмоционально — появляется уважение к машине, что она так шустро работает. Но когда с такой же скоростью сканер отдает договор обратно (например, вы поставили подпись не в том месте), то ощущения возникают противоположные. Кажется, что машина относится к вам с пренебрежением, она будто выплевывает в вас этот договор. Поэтому мы отрегулировали скорость подачи, чтобы избежать подобных ощущений.
Заметки
Здесь я расскажу не решения, а выводы о конкретных вещах, которые я сделал для себя как проектировщик.
Количество экранов
Изначально я очень боялся плодить экраны (когда бОльшая часть интерфейса изменяется). Но сделав несколько вариантов интерфейсов и проведя тестирования мы поняли, что плохо — это много информации на одном экране. Для себя мы вывели правило: один экран — одна важная мысль.
Этот тезис справедлив для пошагового непростого интерфейса, который еще и не является типовым или привычным для людей.
Внимание только на один интерфейс
Здесь под интерфейсом я понимаю и экран и любое из устройств, с которым происходит взаимодействие человека.
Очень важно, чтобы конкретное устройство, с которым происходит взаимодействие, обращало на себя внимание, например, световой индикацией. И только одно устройство в один момент. В идеале мы представляли себе Симкомат с лицевой стороной в виде однородной поверхности, на которой по необходимости открывается только одно “окошко”, из которого нужно что-либо взять, либо поместить.
Аудио
В начальной версии каждый шаг в интерфейсе сопровождался комментариями голосом женщины. Вскоре мы от этого отказались из-за ее навязчивости, а также длительного времени проговаривания. Ну и поддерживать такой интерфейс сложнее.
Аудио сигналы мы решили использовать для привлечения внимания в критических ситуаций, например, если человек забыл взять карточку из карддиспенсера. Также использовать мягкие ненавязчивые звуки для фидбека о нажатии кнопок и подкрепления положительных действий, чтобы было ощущение прогресса.
Инструкции: схема VS видео
Простые понятные схемы работают лучше, чем видео.
У нас было такое вот видео, в котором мы говорили, что нужно сделать (на терминале оно сопровождалось голосом).
Люди бросали взгляд на экран и не досмотрев ролик до конца, а может даже и не поняв, что там видео, начинали пробовать взаимодействовать с устройством. Зачастую им приходилось возвращаться к просмотру ролика, который был зациклен. Это довольно нудное занятие.
В результате мы сделали такое решение:
На тестировании не произошло ни одной ошибки с этим шагом, хотя задача у человека была нестандартная.
Рассказать заранее, что ждет дальше.
Я уже говорил, что Симкомат довольно долго печатает договор. Так вот, мы решили использовать это время для того, чтобы рассказать человеку, что ему нужно будет делать дальше. Особенно это хорошо для случая с нетривиальным шагом выдачи ручки.
На конференции мне задали вопрос: “А что, люди читают эту надпись?” Да читают, потому что им в это время нечего делать)
В результате люди в ожидании договора УЖЕ начинали рассматривать Симкомат, чтобы найти там нанесенную нами надпись “ручка”. И когда пришло время, человек был уже готов к активным действиям.
Кнопки, стиль и “call to action”
На экране желательно размещать только одну приоритетную кнопку дальнейшего действия.
Разрабатывая стиль, мы предпочли оставить объем в кнопках, а не делать флэт стиль.
Мы ввели расширенные надписи на кнопках в некоторых местах. Это позволило дать больше контроля человеку и не плодить лишних текстов на экране.
Рабочий процесс
На вкусненькое я приберег несколько фотографий наших будней.
На этом всё. Если статья понравилась, поделитесь ею с коллегами.
Если вы не читали первую часть, можете это сделать сейчас.
Если вам нужно спроектировать интерфейсы или продукт целиком, то вы можете обратиться ко мне. Я работаю над софтовыми и хардварными продуктами. Портфолио и контакты на моем сайте.
