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

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

Анализ

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

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

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

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кб

Задача

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

Поиск решения

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

Процесс

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

Процесс монтажа ролика в программе Movavi Video Suite

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

Аня отлично справилась с заданием и на основе моих пожеланий, набросала логотип в минималистичном черно-белом стиле и с надписью ГОСТовским шрифтом «Уроки».

Кадры из видео

Итоги

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

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

Команда

Идея, скринкаст и монтаж: Саша Дегтярев
Оформление заставки: Аня Гуленко

Задача

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

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

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

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

Решение

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

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

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

Макеты в Figma сэкономили время и деньги на вёрстке, а также позволили «пощупать» результат

Вариант 1. Всего и побольше

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

Вариант 2. Играем в шахматы

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

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

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

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

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

Блоки Протоколы, Интерфейсы, Особенности и Архив

Вариант 3. Оптимизируем

Получилось хорошо, но длинно — решили сократить.

Можно было просто выкинуть часть блоков, но не для того мы это так усиленно пытались вытащить наружу. Поэтому мы блоки объединили и чуть сократили описание — так нам удалось сократить в объеме, но сохранить весь сок страницы.

Вариант 4. Реальность

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

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

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

Структура итогового варианта страницы

Мобильная версия страницы

Заключение

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

Иллюстратор и редактор: Саша Дегтярев
Советы и тестирование: команда компании Wiren Board

Посмотреть страницу на сайте компании
Скачать копию страницы png / zip, 2440кб

Ситуация

Компания разрабатывает решения для управления мобильной торговлей: мобильное приложение для торговых агентов и товароведов (мерчендайзеров), а также модули подключения к учётным системам на платформе «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 — Саша Дегтярев

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

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

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

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

Задача

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

Процесс

Пост мы делали вместе с маркетологом Катей.

Она следила за соответствием текста ton of voice компании и фотографировала оборудование в нашем офисе. Абзац про Джеймс Бонда тоже она написала.

Структура поста в Телеграм

Результат

Опубликованные версии постов в Телеграм и Инстаграм.

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

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

Задача

Написать статью о веб-интерфейсе контроллера Wiren Board для потенциальных покупателей.

Процесс

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

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

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

Анимация, в которой показана суть виджета

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

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

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

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

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

Рабочий стол в Figma: компоненты, экраны веб-интерфейса, кадры анимации и визуализация внешнего вида статьи

Кадры анимации

Виртуальные экраны веб-интерфейса

Компоненты веб-интерфейса

Верстка и публикация

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

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

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

Галерея на мобильном устройстве смотрится плохо

В мобильной версии мы развернули галерею — стало лучше

Итог

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

Текст и иллюстрации: Александр Дегтярев
Копия статьи: png / zip, 1579кб
Публикация: Читать статью на сайте Wiren Board

Ко мне обратился наш маркетолог с текстом о восстановленных устройствах, который она взяла с одного из наших ресурсов.

Текст напоминал статью из энциклопедии: обезличенное повествование, непонятно зачем вообще это нужно.

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

Было-стало

Благодарность от маркетолога

Один из промежуточных вариантов, который не очень стыдно показать

Отредактировал текст маркетолога: рассказал про конкурс и сообщил, что будут новые.

Было → Стало

Публикация на сайте

Читать новость на сайте Wiren Board

Подготовил иллюстрацию к новости о новых функциях контроллера Wiren Board 6.

Публикация

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

Черновые варианты

Перейти к описанию функции в Вики Wiren Board.
Перейти в Инстаграм к публикации