3 инструмента дизайн-мышления для разработки дашбордов

Дизайн-мышление (design thinking) — это подход к решению проблем, который ориентирован на пользователя и направлен на создание инновационных решений.

🧔🧑Особенность дизайн-мышления в том, что этот метод ориентирован в первую очередь на людей, а не на бизнес-задачи. Главные вопросы, которые задает дизайнер при поиске решения: «кто будет пользоваться продуктом?» и «как это повлияет на жизнь пользователя?».

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

1️⃣ Портрет пользователя (user persona)

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

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

На первой картинке представлен пример шаблона такого профиля. Он обычно включает такие элементы:

• Имя и фото — вымышленное имя и изображение, которое помогает сделать персонажа более «реальным» и понятным.
• Цитаты или истории — анонимные высказывания, собранные во время сбора требований, об ожиданиях от дашборда, недовольстве или типичном рабочем дне. Они помогают сделать персонажа более живым и конкретным.
• Общая информация — образование, профессия, опыт и др.
• Потребности и цели — что хочет достичь пользователь, какие проблемы он решает, какие у него основные цели при взаимодействии с BI-инструментом.
• Мотивация — что побуждает пользователя взаимодействовать с BI-инструментом, какие у него ожидания и желания.
• Предпочтения к виду данных, регулярности и способу использования BI-решения.
• Болевые точки — трудности и проблемы, с которыми сталкивается пользователь в своей работе или в процессе использования BI-решения.

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

2️⃣ Скетчинг или макетирование (Wireframing)

Делать макет можно как от руки (как на второй картинке), так и в любой программе, например, в Power Point, Google Slides, Figma, Illustrator, Miro или самом BI-инструменте.

Получение обратной связи уже на этапе эскиза значительно cэкономит время и силы всех участников процесса.

3️⃣ Тестирование

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

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

Перед началом тестирования важно определить следующее:

• Цели тестирования
Какие конкретные аспекты мы хотим оценить? Это может быть удобство использования, понятность, вовлеченность или выполнение конкретных пользовательских задач (по опыту важно все вместе😁).

• Целевая аудитория
Кто должен участвовать в процессе тестирования?

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

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

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

#дашборд #uxui

Универсальный дашборд или «под себя»

Не думаю, что буду единственным BI-разработчиком, который слышал от заказчика/пользователя отчетности «мне так удобнее» и «я считаю, что так красивее».

Я сталкивалась с такими нестандартными запросами, как «разместить фильтр, влияющий на все графики дашборда, в нижнем правом углу» или «сделать карточки KPI в виде цветных фигур с тенью, как в Power Point». 😳

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

Немного отвлечемся и посмотрим на картинки. На них представлены 2 квартиры с разным ремонтом:

1️⃣ Светлая комната с современным лаконичным оформлением. Есть цветовые акценты, но цвета подобраны гармонично. Есть необычные детали, но они не бросаются в глаза.

2️⃣ Комната с цветастыми обоями и ковром, которые не сочетаются с цветом мебели. Есть декоративные занавески-обманки, хотя окна нет...одним словом, с ремонтом «под себя».

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

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

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

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

🔹Странные, нелогичные планировки >> Нестандартная компоновка элементов дашборда

🔹Обои вырвиглазного цвета >> Яркий фон дашборда

🔹Загроможденность мебелью >> Метки данных накладываются друг на друга

🔹 Детали интерьера не гармонируют друг с другом >> Шрифты в дашборде относятся к разным семействам (кроме случая, когда их 2, где второй для заголовка)

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

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

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

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

Ставь 👍, если голосуешь за первый вариант, и 😁, если за второй.

#мысли

Зачем знать номер версии FineBI, которая у вас установлена?

Причина 1: Проверить, что та или иная функция из документации есть в вашей версии FineBI.

Для этого:

1️⃣ Выясняем номер используемой версии в разделе System Management -> Registration Management -> вкладка Version Information.

2️⃣ Сверяем ее с документацией или 3️⃣ уточняем у виртуального помощника, есть ли необходимая функция в конкретной версии.

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

4️⃣ Делаем скриншот ошибки. Спойлер: это лишняя скобка в конце выражения.

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

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

❓А вы знаете, какая версия FineBI у вас сейчас установлена?

#база