HIFDocs
HIF / Документация / Смысл

Содержание и информационная архитектура

Версия: 0.2

1. Позиция

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

Человек MUST иметь возможность ответить на четыре вопроса:

  1. Где я?
  2. Что здесь находится?
  3. Что я могу сделать?
  4. Что произойдёт дальше?

2. Доменная модель до навигации

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

Для каждого типа содержания зафиксируйте:

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

3. Потребности и главные задачи

Каждая важная страница MUST обслуживать подтверждённую пользовательскую потребность или операционное обязательство. Формулировка потребности SHOULD описывать ситуацию, результат и причину, не предписывая интерфейс.

Главные задачи MUST иметь приоритет в навигации, поддержке содержания, performance budgets и тестировании. Организационная структура MUST NOT навязываться человеку, если она не совпадает с его моделью задачи.

4. Классификация и названия

Таксономия SHOULD быть понятной, стабильной, расширяемой и выраженной на языке аудитории. Её MUST проверять репрезентативными задачами на findability.

Название MUST описывать назначение, тему или эффект. Параллельные элементы SHOULD иметь параллельную грамматику. Внутренние названия отделов, сокращения и рекламные формулировки MUST NOT заменять слова, которые ищут пользователи.

Управляемый словарь, синонимы, aliases и устаревшие термины SHOULD храниться отдельно от видимых навигационных названий.

5. Навигация

Используйте минимальный набор, объясняющий продукт:

  • global navigation для стабильных областей;
  • local navigation для соседних элементов области;
  • contextual links для смысловых связей;
  • breadcrumbs для иерархической ориентации;
  • history и recents для возврата во времени;
  • search для прямого поиска;
  • task progress для упорядоченной транзакции.

Повторяющаяся навигация MUST сохранять относительный порядок и идентификацию. Текущее местоположение MUST NOT обозначаться только цветом. Модель MUST работать с клавиатурой, zoom, reflow и assistive technology.

Не используйте breadcrumbs как историю действий, tabs как иерархию сайта, а pagination — для сокрытия обязательной последовательности.

6. Поиск

Качество поиска включает обнаружение, интерпретацию запроса, ranking, понимание результата и восстановление.

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

Измеряйте успешное нахождение и reformulation, а не только число запросов.

7. Структура страницы и содержания

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

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

Plain language — язык, подходящий аудитории, а не отказ от необходимой точности.

8. Формы и транзакции

Форма — разговор с состоянием, проверкой, восстановлением и последствиями.

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

Разбивайте процесс на шаги, когда это снижает нагрузку или отражает реальные зависимости. Progress MUST отражать процесс и MUST NOT создавать ложную уверенность.

9. Empty, loading, error и completion

Каждое состояние требует спроектированного содержания. Empty state SHOULD объяснять отсутствие, значение и доступное действие. Loading MUST NOT обещать неподтверждённый результат. Error MUST сообщать, что произошло, что сохранено и что делать. Completion MUST фиксировать результат, persistence, последующие шаги и свидетельство завершения.

10. Локализация и internationalisation

Исходная модель MUST поддерживать расширение текста, иной порядок слов, plural rules, форматы даты и чисел, направление письма и культурно зависимые примеры. Строки MUST NOT собираться из фрагментов, которые нельзя переставить.

Переключение языка SHOULD сохранять текущий объект и задачу. Locale, регион, валюта и язык MUST NOT считаться одним параметром. Машинный перевод MAY помогать черновику, но нормативное, юридическое, safety-critical и ценное транзакционное содержание требует человеческой проверки.

11. Findability и машинное представление

Сначала проектируется человеческая информационная архитектура. Metadata, structured data, sitemap и semantic HTML SHOULD правдиво раскрывать её браузерам, поисковым системам и assistive technology.

URL SHOULD быть стабильным, читаемым, canonical и независимым от временного UI-состояния. Redirect MUST сохранять идентичность при миграции.

SEO MUST NOT создавать скрытый текст, вводящие в заблуждение заголовки, doorway pages или содержание, противоречащее видимому продукту.

12. Оценка

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

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

Источники