Как сделать дашборд по ТЗ

Этап 1. Понимание ТЗ — что искать в первую очередь

Первая ошибка начинающих BI-разработчиков — открыть Power BI и начать делать. ТЗ читается по диагонали, как инструкция к микроволновке. Через две недели заказчик говорит «я имел в виду другое» — и это справедливо, потому что вы не уточнили вовремя.

Правильный порядок чтения ТЗ:

1. Назначение и аудитория. Кто, как часто, на каком устройстве, какие решения принимает. Это диктует плотность информации, размер шрифтов и количество фильтров.
2. 3–7 ключевых вопросов. Если их нет — стоп, возвращайтесь к заказчику. Без них вы не спроектируете layout. Главные вопросы должны решаться за 3 секунды от момента открытия.
3. Метрики и формулы. Самое опасное место — спорные правила расчёта. «Выручка» в 1С может означать пять разных вещей. Уточняйте на этапе чтения, а не на этапе ревью.
4. Источники данных. Есть ли доступы. Если токена amoCRM нет — проект уже задержан, и это надо проговорить до старта, не на второй неделе.
5. Функциональные и нефункциональные требования. RLS, drill-through, экспорт, SLA. От этого зависит модель данных и архитектура — не добавляется потом «между делом».

На вопросы, которые остались без ответа в ТЗ — составьте список, отправьте заказчику одним блоком. Это дисциплинирует обе стороны и экономит две-три итерации правок потом.

Этап 2. Архитектура и модель данных

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

Звёздная схема как стандарт

Star schema — стандарт de facto для Power BI. Одна таблица фактов в центре, вокруг неё — таблицы измерений (dim). Связи 1-ко-многим, однонаправленные. Никаких bidirectional, кроме редких случаев. Никаких flat-таблиц — даже если «это всего лишь 100 тысяч строк».

Для двух фактов и общих измерений — это galaxy schema (несколько звёзд с общими dim). Тоже норма. Что не норма — это snowflake, когда измерения нормализованы дальше: dimProduct → dimCategory → dimDepartment. В Power BI snowflake почти всегда хуже star, особенно по скорости.

Что обязательно сделать в модели

• Удалить ненужные столбцы в Power Query, не на этапе модели. Каждый лишний столбец — это память VertiPaq и время загрузки.
• Скрыть технические поля (Hide in report view): ключи, поля для связей, служебные флаги. В поле выбора пользователь должен видеть только то, что он понимает.
• Установить Summarize By: Don't summarize на всех числовых полях, которые не должны суммироваться (год, ID, телефон). Иначе при перетаскивании в визуал получите «сумму годов» — классическая ловушка.
• Создать dimDate через DAX (CALENDAR или CALENDARAUTO). Никогда не используйте даты из factSales напрямую — time intelligence работать не будет.
• Включить Mark as date table для dimDate. Без этого SAMEPERIODLASTYEAR и другие функции возвращают пустые значения.
• Incremental refresh для больших исторических таблиц (>10М строк). Power BI Service умеет, но это надо настроить через политику в Power Query.

Меры и вычисляемые столбцы

Правило простое: если это значение можно посчитать на этапе агрегации — это мера. Если это атрибут отдельной строки — вычисляемый столбец. На практике 95% метрик в Power BI должны быть мерами.

Базовые меры ([Sales Amount] = SUM(factSales[Amount])) пишутся первыми. Производные ([Sales YoY] = [Sales Amount] − CALCULATE([Sales Amount], SAMEPERIODLASTYEAR(...))) опираются на базовые. Это единственный способ держать DAX-кодную базу читабельной — все time-intelligence версии метрики опираются на один источник, и при изменении формулы базовой меры всё пересчитывается автоматически.

Этап 3. Naming conventions

Это тот пункт, который пропускают чаще всего — и именно из-за него через 6 месяцев другой разработчик открывает PBIX и видит Page 1, Page 2, Page 3, меру m1 и test_KPI_new (2). Стандарт нужен сразу, не «потом причешу».

Файлы и workspace

Страницы отчёта

Числовой префикс для порядка, бизнес-имена для понятности. Служебные страницы — в конец с префиксом 90+:

00_Home              ← навигация / титульник
01_Overview          ← главные KPI
02_Sales Trend       ← динамика
03_Region Analysis   ← разрезы
04_Product Detail    ← drill-through
90_Definitions       ← словарь метрик
99_Tech              ← техническая

Таблицы и поля модели

Колонки — PascalCase или snake_case (выбрать одно и использовать везде). Видимые пользователю поля — Title Case с человеческим именем («Сумма продаж», не SalesAmt). Технические ключи — ProductKey, CustomerKey. Флаги — IsActive, IsCurrent.

Меры

• Базовые: [Sales Amount], [Order Count], [Gross Margin]
• Производные: [Sales Amount YoY], [Sales Amount vs Plan], [Gross Margin %]
• Time-intelligence: [Sales Amount YTD], [Sales Amount MTD]
• Запрещены: [m1], [test], [KPI_new], [мера1], [Copy of Sales]

Если поле отображается как процент — добавляйте % в имя: [Margin %]. Сразу видно тип, и форматирование подсказывается.

Папки мер

В отчёте на 30+ мер без папок ориентироваться невозможно. Обязательная структура:

01 Core KPIs           ← главные показатели
02 Revenue
03 Margin
04 Customer
05 Time Intelligence   ← YoY, MTD, YTD
06 Plan vs Actual
99 Technical

Этап 4. Дизайн и компоновка

F-паттерн и Z-паттерн

Айтрекинг показывает: люди читают экраны слева направо и сверху вниз, F-образно. Главное — в левом верхнем углу. Поэтому:

Правило 3-30-300

Хорошо спроектированный отчёт читается на трёх уровнях:

• 3 секунды — пользователь видит главный тренд / KPI. Если этого нет — главное не на своём месте.
• 30 секунд — понимает структуру, основные разрезы. Пробежал глазами по графикам, увидел контекст.
• 300 секунд — изучает детали в таблицах и фильтрах. Тут drill-through, экспорт, копирование цифр.

Если ваш дашборд работает только на уровне «300 секунд» — это аналитический отчёт, и executive его открывать не будет.

Количество визуалов на странице

Магическое число — 6–8 визуалов на страницу. Это не каприз — это граница когнитивной нагрузки. Глаз воспринимает 4–7 объектов одновременно. На 15 визуалах внимание распределяется так, что ни на одном не фокусируется.

Если по ТЗ нужно показать 30 метрик — это три страницы по иерархии «обзор → детализация → таблица», а не одна с 30 плашками.

Отступы и выравнивание

• Используйте сетку: View → Show gridlines, Snap to grid. Все визуалы выравниваются по линиям.
• Единые отступы между визуалами (16–24 px — рабочий диапазон).
• Белое пространство — это не «пустота, надо заполнить», а инструмент управления вниманием.

Этап 5. Выбор визуализаций

Главный принцип: не более 3 типов визуализаций на дашборд. Каждый новый тип повышает когнитивную нагрузку. Linear, bar, table закрывают 99% задач. Ушли в sankey, радар и treemap — значит, вы либо аналитический отчёт делаете (там можно), либо хочется красиво (это плохая мотивация).

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

Несколько частных правил по Power BI:

• Линии толщиной ≥2pt. Тонкие не видны на удалённых экранах и при стриминге через Teams.
• Не соединяйте линии при null. Разрыв несёт информацию — «здесь данных нет». Power BI по умолчанию интерполирует, отключайте: Format → Shapes → Show items with no data.
• Stacked area — только когда сумма имеет смысл, и вы не планируете сравнивать верхние ряды между собой (у них плавающая база).
• 3D вообще не используйте. Pie, bar, line — всё в 2D. 3D искажает пропорции и не добавляет смысла.
• Gauge / спидометр — единственный сценарий «прогресс к чёткой цели». Без цели — заменяется horizontal bar с маркером.

Этап 6. Цвет

Стратегия «меньше — лучше»

Хороший дашборд использует 1 основной цвет данных + 1 акцент + 1 нейтральный. Всё. Радужный дашборд — карго-культ из PowerPoint-эпохи. Каждый дополнительный цвет снижает внимание к каждому отдельному сигналу.

Семантика — один цвет = одно значение

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

Доступность и дальтонизм

До 8% мужчин и 0,8% женщин имеют ту или иную форму нарушения цветового восприятия. Поэтому:

• Не используйте только красный/зелёный как единственное различие. Дублируйте текстом (OK / Warning / Error, ↑ / ↓).
• Избегайте пар: красный+зелёный, синий+фиолетовый, зелёный+коричневый.
• Используйте встроенные accessibility-темы Power BI: Accessible Default, City Park, Tidal, Neutral, Orchid — как отправную точку.

WCAG-контраст

Соответствие WCAG 2.1 AA:

• Текст на фоне: соотношение ≥4.5:1.
• Графические элементы (оси, границы): ≥3:1.

Проверяйте через Color Contrast Analyzer или онлайн-сервис. Большинство «дизайнерских» серых на серых не проходят.

Theme JSON

Создайте корпоративный JSON-файл темы один раз и применяйте во всех отчётах. Это даёт мгновенную консистентность — и позволяет менять брендинг централизованно без правок 50 PBIX:

{
  "name": "DEEONE Corporate Theme",
  "dataColors": ["#3B52D5","#17C2BF","#A932C9","#F7A81B","#0EA5E9","#10B981"],
  "good": "#10B981",
  "neutral": "#F7A81B",
  "bad": "#C73E5A",
  "background": "#FFFFFF",
  "foreground": "#1F2025",
  "textClasses": {
    "title":  { "fontSize": 14, "fontFace": "Segoe UI Semibold", "color": "#1F2025" },
    "header": { "fontSize": 12, "fontFace": "Segoe UI Semibold", "color": "#1F2025" },
    "label":  { "fontSize": 10, "fontFace": "Segoe UI", "color": "#1F2025" }
  }
}

Этап 7. Типографика

Segoe UI — дефолт Power BI и системный шрифт Windows. Чистый, современный, отлично читается при малых размерах. Для кросс-платформенности подойдут также Arial и Helvetica.

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

Ограничьте до 2 семейств шрифтов: одно для заголовков, одно для данных. На практике — одно достаточно.

Иерархия размеров

Выравнивание — по левому краю. Центрированный текст уместен только на афише. На дашборде создаёт рваные края и визуальный шум.

Числа

Сокращайте до 3 значимых цифр: 1 234 567 → 1.2M или 1.2 млн. Всегда указывайте единицы измерения — отсутствие единиц мгновенно подрывает доверие к дашборду. Сохраняйте единообразие десятичных знаков на странице (либо везде ноль, либо везде одна).

Этап 8. Принципы гештальта

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

Принцип Прегнанц. Мозг предпочитает простое и упорядоченное. Любой элемент, который можно убрать без потери смысла, — нужно убрать. Это и есть концепция chart junk Эдварда Тафта в другой формулировке.

Этап 9. Что убрать — визуальный шум

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

Этап 10. Интерактивность

Фильтры и слайсеры

Каждый слайсер генерирует 2 запроса к модели. Поэтому:

• Убирайте редко используемые фильтры. «На всякий случай» — это не аргумент.
• Группируйте в одной зоне: верхняя полоса или левая колонка. Не разбрасывайте по странице.
• Длинные выпадающие списки — заменяйте иерархическим слайсером или поиском.
• Sync slicers между страницами — включайте обдуманно: пользователь не всегда хочет, чтобы фильтр «оставался» при переключении вкладок.

Drill-through и навигация

• Кнопки + закладки (bookmarks) — стандартный способ навигации между страницами с контекстом.
• Drill-through — для «кликнул на строку → ушёл в детали с уже отфильтрованной страницей». Не перегружайте основной дашборд — детали в drill-through.
• Ссылки из таблиц на исходные системы (CRM, ERP) через гиперссылки — очень удобно для операционных дашбордов.

Tooltip-страницы

Кастомные tooltip-страницы (Format → Page Information → Tooltip) — способ дать дополнительный контекст без нагрузки основной страницы. Наведение на карточку клиента — раскрывается мини-карточка с тремя графиками. Главное правило: tooltip должен дополнять, не дублировать.

Этап 11. Производительность

Пользователи перестают использовать дашборд, если он грузится дольше 3 секунд. Это не маркетинговая статистика — это граница терпения.

Модель данных

• Star schema, не flat. Уже говорили; повторяем — это база.
• Удалите ненужные столбцы в Power Query, до загрузки в модель. Каждый столбец — это память.
• Используйте integer ключи. Текстовые GUID-ключи — в 5–10 раз медленнее.
• Aggregations для больших факт-таблиц (>10М). Power BI сам решает, идти в агрегат или в детальную таблицу.
• Incremental refresh — чтобы не перезагружать всю историю каждый день.
• 1-ко-многим, однонаправленные связи. Bidirectional — только в явных случаях, и всегда документировать почему.

Дизайн отчёта

• 6–8 визуалов на страницу — магическое число для скорости.
• Фильтруйте на уровне запроса (Power Query), не на уровне визуала.
• Не используйте кастомные визуалы там, где стандартные справляются. Custom visuals часто медленнее в 5–20 раз и могут блокировать обновление при падении в App Source.
• Отчёт и источник данных — в одном workspace для Power BI Service. Cross-workspace связи дороже.

Этап 12. Доступность

В корпоративных отчётах доступность — не опция. Часть автоматическая, но значимая часть зависит от автора:

• Alt-text — для всех значимых визуализаций. Описание того, что показывает график (не сами цифры — их считает screen reader).
• Tab order — проверьте на каждой странице. View → Selection → Tab order. Декоративные элементы исключите из tab order.
• Контраст — текст ≥4.5:1, графика ≥3:1.
• Не только цвет. Статус не должен передаваться исключительно цветом — дублируйте иконкой, текстом или паттерном.
• Title и description — заполните для каждой визуализации, screen reader их использует.

Этап 13. UAT — приёмочное тестирование

«Само работает» — это не тест. UAT по чек-листу — то, что отличает релиз от «сделал и будем смотреть в PROD». Чек-лист ниже — минимально достаточный для корпоративного дашборда. Проходите его собственноручно перед UAT с заказчиком, и потом ещё раз с ним вместе.

В конце — раздел «Подтверждение заказчика»: подпись, что он согласен на публикацию в PROD. Без этого формально дашборд не принят, и любые претензии типа «а где это? а это?» вне UAT — это уже Phase 2.

Шаблон отчёта (Template)

Если в компании несколько BI-разработчиков или планируется делать дашборды регулярно — заведите стартовый шаблон. Это PBIT-файл с готовой структурой страниц, темой, библиотекой типовых KPI-карточек и заготовками служебных страниц (Definitions, Tech).

В комплекте к шаблону — README с инструкцией:

• Назначение шаблона (executive / operational / analytical).
• Что входит (структура страниц, theme, KPI-заготовки).
• Предусловия использования (есть ли brief, утверждены ли формулы, доступы получены).
• Что разработчик должен настроить перед публикацией: подключить semantic model, переименовать страницы, удалить тестовые меры, заполнить titles, alt-text.
• Что запрещено: оставлять Page 1, публиковать с тестовыми мерами, использовать кастомные визуалы без согласования.
• Версия шаблона, дата обновления, контакт владельца.

Шаблон без README — это вирус: каждый разработчик копирует и добавляет свои привычки. Через год вы имеете 7 «версий шаблона» в разных PBIX, без единого источника правды.

Финальный чек-лист сдачи отчёта

Связанные материалы

• «Как собрать ТЗ на дашборд» — парная статья для заказчика. Шаблон ТЗ для скачивания.
• Гид по визуализациям — 9 семейств графиков с интерактивными примерами и TopoJSON для Power BI Shape Map.
• BI начинается не с подрядчика — что нужно навести в учётной системе до старта.
• Финансовая отчётность простым языком — если вы делаете финансовый дашборд.
• Методология DEEONE — как мы ведём проекты от ТЗ до сопровождения.