Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

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

Комментарий — элемент хаоса. Но с ним система устойчивее.

Эдвард Скотт написал о сравнении товаров в интернет-магазине.

Прежде, чем добавить эту функцию:

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

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

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

Если вы уже добавили:

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

2. При наведении курсора на контрол «Сравнить» показывайте подсказку с кратким пояснением: что это за инструмент и как он работает. Так его не примут за функцию сравнения цен с другими магазинами.

3. Дайте легко перейти к сравнению выбранных товаров. Например, отобразите панель с кнопкой «Сравнить выбранные товары» и миниатюрами этих товаров, прикреплённую к нижней или верхней границе окна браузера.

https://ux.pub/ux-rekomendatsii-po-uluchsheniyu-instrumenta-sravnenie-tovarov/

Вы должны побывать на «дне», чтоб было с чем сравнивать

Вы должны побывать на «дне», чтоб было с чем сравнивать

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

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

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

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


Вспоминаю, как пришла работать в 1C:Битрикс.
По грёбаному дождю еле нашла их офис в какой-то вонючей(буквально) промзоне. Сначала час на вот этот текст на логику с шнусмумриками…

Потом задача на цикл, которая не хотела решаться. А в результате оказалась с ошибкой в условии. Какой-то прыщавый лид-программист, чьё ЧСВ было таким же жирным как и он сам.
Скептический настрой, только потому что ты девочка.
И вообще всё это нахер ему не надо. Эти тупые кандидаты, которые не могут решить придуманную задачу. «Господи, как же вы заебали» — читалось в его уставших красных глазах.


А работа в банке Русский Стандарт.
Более депрессивный, подставляющий друг друга персонал ещё поискать: тёлочки конкурировали друг с другом, рвали бумаги, вырывали клиентов друг у друга. Двухнедельное(с утра до ночи) бесплатное обучение всей системе рассчёта кредитных продуктов, страховок, выявления мошенников и поддельных документов. Страх отчисления, ежедневные чистки, унижения. Отсутствие эмоций и поток людей. Угрозыск, задержания, показания, золотые цепи на груди. Немые младенцы мошенников. Стопки налички из рук в руки под столом.


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


Для 90% компаний, люди — это мясо, средство достижения цели.
На ваши эмоции плевать. Ваши идеи никому не нужны.


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


С любовью ❤️ гав-гав

Нечто большее

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

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

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

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

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

Представьте, что вы как заказчик, оставляете заявку и вам за считанные дни проводят целое исследование. Прелесть!

Идеальный процесс

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

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

Женя Бондарев рассказал нам о типичной структуре разработки цифрового продукта:

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

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

Usability test
Тестирование всего продукта и финальные изменения — Женя советует писать гипотезы в гугл-доке на протяжении всего исследования, чтобы во время тестирования не упустить что-то важное.
По итогу тестирования выявляются критичные и не очень ошибки, после чего нужно решить, с чем можно выходить на рынок, а что требует обязательной доработки. На этом шаге может всплыть много неожиданностей, на эту тему как-то писал Костя Горский — t.me/desprod/239

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

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

1. Погружение

1. Связаться с заказчиком
Сделать:
- интервью с заказчиком
- запросить метрики
Итог:
- утвержденное направление работу
- утвержденные с заказчиком сроки
Срок: 4.03

2. Поиск референсов/конкурентов
Срок: 04.03

3. Интервью с пользователями
Сделать:
-подготовить вопросы
-найти респондентов
На выходе:
- уточненный портрет
- проблемы пользователей
Срок: 13.03

4. Попробовать
Сделать:
- Сделать заказ (понять процесс, опросить мастера)
- Зарегаться как мастер (понят, процесс, взять заказ)
На выходе:
- проблемы
- полное понимание бизнес-процесса
Срок: 11.03

Анализ полученных инсайтов
Артефакты: понять на каких проблемах фокусируемся, список инсайтов, фичерлист
Показываем заказчику — 12.03
— Ретро —


2. UX — проектирование

1. Информационная архитектура — 20.03
2. Структура — 20.03
3. Карта экранов — 31.03
4. Сценарии
5. Прототип
6. Тестирование прототипа (проверка гипотез) - 7.04

Анализ полученных решений
Артефакты: протестированный прототип, карта экранов, структура, информационная архитектура
Показываем заказчику — 9.04

— Ретро —


3. UI — визуальный язык

1. Существующие гайды продукта
2. Мудборд
3. Дизайн концепт 3-5 экранов — 14.04
4. Масштабирование
5. Анимация

Анализ полученных решений
Артефакты: финальный дизайн продукта, анимация
Показываем заказчику — 30.04

— Ретро —


4. Передача в разработку
5 занятий 10.05-19.05

5. Подготовка портфолио
9 занятий 22.05-09.06

6. Презентация
3 занятия

7. Защита
23 июня


По сути, этот план также может являться оглавлением моего дальнейшего повествования.
Как вы могли заметить, на сегодняшний момент мы заканчиваем стадию «2. UX — проектирование» и переходим к поиску визуальной концепции.
Уже сейчас можно сделать какие-то выводы о том, как мы двигаемся по этому плану: что-то из написанного в плане мы так и не сделали до сих пор, что-то наоборот — сделали с опережением. Так, мы до сих пор не утвердили окончательный набор фич, но, с другой стороны, у нас уже готовы все необходимые артефакты — можно начинать готовить мудборды

Наталья Стурза рассказала, что на сайтах российских банков мешает клиентам (предпринимателям) выбрать оптимальный тариф.

Тёмные паттерны и просто плохой дизайн:

  1. Важные условия и ограничения написаны мелко и малоконтрастно, чтобы человек не обратил на них внимания.
  2. Тарифам даны эмоциональные названия. Например, тариф «Успех» (подороже) и «Лоукост» (самый дешёвый).
  3. Некоторые важные условия тарифа есть только в огромном документе со всеми условиями. Например, показаны только лимиты, но не показано, что будет после их превышения.
  4. Сломана привычная логика отображения информации. Например, показаны сначала свойства тарифа, а потом стоимость. Или показаны тарифы слева направо от большей стоимости к меньшей.
  5. Общие формулировки и канцеляризмы.
  6. Все тарифы показаны на отдельных страницах без единой сводной таблицы.

Как делать:

  1. Расположите тарифы по возрастанию цены и предложения.
  2. Выделите приоритетный тариф с помощью дизайна.
  3. Дайте сравнить, но не больше 4 тарифов в таблице.
  4. Называйте тарифы осмысленно, без манипуляций и оценок.
  5. Чётко прописывайте 4 главных критерия: абонентскую плату, количество бесплатных платежей, комиссии за снятие и пополнение наличных, лимиты и комиссии на переводы физлицам.
  6. Давайте ссылку на подробное описание тарифов.
  7. Отдельно выносите скидки, они интересны только продвинутым пользователям.
  8. Прописывайте пункты на языке пользователя: вместо «платежи» — «платежи юрлицам и ИП».
  9. Расскажите про превышение лимитов.
  10. Дайте посмотреть цены при ежемесячной оплате и оплате за год вперёд.

https://vc.ru/design/90038