Общий вид таблички до и после

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

Анализ

Для начала подумаем, как школьник выполняет домашние задания и зачем он это делает:

• Зачем: чтобы завтра на уроке не получить двойку.
• Как: смотрит, что задано на завтра, выбирает один из предметов и выполняет; потом берёт следующее задание.

Текущая табличка решает свою задачу, но заставляя пользователя напрячься:

1. С ходу всё внимание на себя забирает столбец «Статус»: красная заливка прямо кричит — ЕСТЬ ЗАДАНИЕ! Ну есть и есть, чего кричать?
2. Потом, с трудом оторвав взгляд от колонки со статусом мы начинаем искать глазами первую цель — дату, на которое задано задание. Находим его в четвёртом столбце.
3. Теперь смотрим предмет — он рядом, хоть и слева.
4. Зная дату и предмет мы хотим посмотреть задание, но тут спотыкаемся о название школы и недоумеваем — зачем оно?

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

Итак, у нас есть проблемы:

1. Акцентный элемент забирает наше внимание, но никакой полезной информации нам не говорит. А ещё цвет акцентного элемента такой же, какой мы привыкли видеть в сообщениях об ошибке.
2. Люди читают слева направо и сверху вниз, поэтому поля должны давать ответы на наши вопросы в этом порядке: на какой день задано задание, по какому предмету, что нужно сделать и статус, чтобы ничего не пропустить. У нас же здесь наоборот: само задание, потом зачем-то школа, потом предмет и только потом когда это нужно.

Что не так в текущем варианте таблицы

Решение

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

1. Не нужно с ходу кричать на школьника — убираем красный цвет.
2. Первым столбцом ответим на вопрос — к какому уроку нужно сделать домашнее задание.
3. Во втором столбце расскажем по какому предмету домашнее задание.
4. Дальше показываем само задание, а заодно подписываем колонку.
5. Колонка статус у нас стала справочной: теперь она не оттягивает внимание и даёт полезную информацию — выполнено или нет домашнее задание.

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

Также выровняли текстовые столбцы и их заголовки по правому краю, но оставили колонку «Статус» с выравниванием по центру.

Как можно сделать лучше

Результат

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

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

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

Оба варианта рядом: было → стало

Обсуждение сценариев и текста с продактом в Figma

Задача

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

Инфраструктура проекта:

• На входе и выходе из магазина стоят терминалы с турникетами и сканерами QR-кодов.
• Система с помощью камер автоматически понимает, какой товар взял с полки покупатель и передаёт данные на сервер.
• Магазин подключён к онлайн-кассе, что позволяет оплачивать покупки сразу из приложения. Оплата наличными не предусмотрена.
• В магазине есть обслуживающий персонал, который может помочь покупателю в случае проблем и следит за выкладкой товара.

Приложение должно:

1. Организовать доступ покупателю в магазин с помощью QR-кода.
2. Привязать карту российского банка.
3. Провести покупателя через весь процесс покупки: от выбора товара до оплаты.
4. Помочь покупателю отказаться от покупки, если он того желает.

Выбор инструментов

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

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

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

Я делаю сторифреймы в Figma — здесь сразу вся команда может наблюдать за процессом и комментировать. Есть история версий и можно создавать компоненты из элементов.

Элементы для построения сторифреймов

Анализ задачи

Формализуем функциональные и бизнес-требования:

1. Регистрация учётной записи или вход в неё.
2. Привязка новой карты или выбор уже привязанной. Оплата только картой — покупателей без привязанной карты в магазин не пускаем.
3. Доступ покупателя в магазин и выход и него.
4. Учёт товаров в корзине на основе данных системы.
5. Отказ покупателя от покупки.
6. Оплата покупки.
7. Генерация ключа для выхода покупателя из магазина.
8. Система помощи покупателю: помочь зарегистрироваться, рассказать о процессе покупки, подсказать нужные действия для возврата товара.

На основе требований сформулируем пользовательские сценарии, которые нам нужно описать.

Возможные сценарии приложения, основанные на функциональных и бизнес-требованиях

Решение

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

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

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

Когда мы узнали пользователя и привязали или выбрали карту, то выводим на экран телефона QR-код, с помощью которого пользователь попадает в торговый зал магазина.

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

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

В финале пользователь открывает турникет QR-кодом и выходит из магазина.

Авторизация, выбор карты и вход в магазин

Покупка товаров и возврат

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

Итоги

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

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

Скачать полную версию сторифреймов pdf / zip, 600кб

Ситуация

Компания разрабатывает решения для управления мобильной торговлей: мобильное приложение для торговых агентов и товароведов (мерчендайзеров), а также модули подключения к учётным системам на платформе «1С: Предприятие».

Мобильное приложение имеет встроенную функцию сканирования штрих-кодов с помощью камеры мобильного устройства.

Окно сканера штрих-кодов в момент чтения линейного кода EAN-13

Проблема

Пользоваться существующим решением неудобно:

• низкая скорость запуска,
• медленное чтение кодов,
• одиночный режим чтения кодов: нет возможности сканировать несколько кодов подряд,
• нельзя использовать вспышку мобильного устройства для подсветки объекта,
• нет поддержки инвертированного кода DataMatrix, который используется системой маркировки «Честный знак».

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

Основные элементы существующего сканера штрих-кодов, проблемы: ландшафтная ориентация, незаметное и малоинформативное сообщение внизу окна, отсутствие элементов управления

Схема положений мобильного устройства в процессе работы со сканером

Решение

Используемая библиотека сканирования не поддерживает инвертированный код DataMatrix, поэтому мы приняли решение её сменить. Это сразу решило часть проблем: сканер стал запускаться быстрее, полная поддержка кодов DataMatrix, высокая скорость чтения.

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

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

Простым исключением повторного запуска сканера мы получили прирост скорости считывания кодов в два раза

Но для этого нам пришлось идти на компромисс — в сценарий одиночного сканирования добавился один шаг, что добавило целую секунду ко времени всего цикла

Реализация

Запишем требования к интерфейсу:

• портретный режим,
• кнопка «включить» / «выключить» фонарик,
• пакетный режим сканирования кодов.

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

Всего получается три экрана:

1. Сканирование кода.
2. Сообщение об успешном сканировании и информация о добавленном в документ товаре.
3. Сообщение об ошибке.

Сканирование кода

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

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

Этот подход имел два недостатка:

1. Возможна ситуация, когда два различных кода размещены рядом, например, блоки сигарет с маркировкой «Честный знак». В этом случае невозможно гарантировать чтение нужного кода.
2. Автоматический выбор типа кода снижал скорость сканирования.

Ещё мы выяснили, что код в системе «Честный знак» содержит в себе и код EAN-13 (GS1-128), то есть для работы с маркированной продукцией достаточно чтения кодов DataMatrix. А там, где используется только код EAN-13 или GS1-128 кода маркировки нет. Поэтому мы решили сделать переключение режимов сканирования: 1D (EAN, GS1 и т.п) и 2D (QR-Code, DataMatrix и т. п.).

Во втором варианте в верхнюю часть экрана мы добавили переключатель режимов. Также режимы можно было переключать смахиванием (swipe).

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

Эволюция экрана сканирования кода

Успешное чтение кода

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

Ещё во время тестирования библиотеки мы обнаружили, что неудобно пользоваться бесконтрольным потоковым сканированием. То есть когда сканер сканирует все, что есть вокруг — мы решили дать пользователю возможность самостоятельно запускать поиск кодов.

Все эти нюансы мы учли во второй версии экрана: сообщение об успешном добавлении позиции стало всплывающим и переехало в верхнюю часть экрана. Кнопки «отмена» больше нет. Оно просто выводит информацию о добавленном товаре и не блокирует работу со сканером.

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

Код считан успешно, позиция добавлена в каталог

Сообщение об ошибке

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

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

При чтении кода или добавлении позиции в каталог произошла ошибка

Дизайн-макет

Результат

Приложение

Заключение

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

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

Перейти на страницу продукта на сайте компании

Команда

Идея, концепт и прототип в Figma — Саша Дегтярев

Программисты:

• Саша Лещёв
• Максим Сёмин
• Дима Макеев

Советы и тестирование — Серёжа Кузьменко

Продакт — Искандер Мильгизин

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

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

Расписание до и после изменения

Было

Было. Много текста, дни недели занимают много места

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

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

Стало

Стало. Дни недели в строчку, время выбираем после них

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

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

Заключение

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

Дизайнер: Александр Дегтярев
Инструменты: Figma, GIMP

Экран приветствия, onboarding — это наш шанс заинтересовать пользователя, поэтому он должен быть:

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

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

Как было

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

Проблем на экране много:

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

Как могло быть

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

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

Если пользователь имеет аккаунт в социальной сети, то он точно знает ее логотип — делаем кнопки круглыми и смещаем вниз. Сверху простая и лаконичная кнопка «Войти с помощью e-mail».

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

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

Как стало

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

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

Снизу обязательно нужно разместить прогресс—бар. Пользователь должен видеть сколько осталось листать.

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

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

Заключение

С помощью простых приемов за 20 минут мы сделали онбординг приветливым и дружелюбным. Для этого потребовалось добавить немного пользы и убрать лишнее.

UX-редактура: Александр Дегтярев
Инструмент: Figma

Загрузить полные версии:

• вариант 1
• вариант 2