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

1. Проектирование админок

2. Обо мне Занимаюсь проектированием интерфейсов с 2002 года Работал и штатным, и внешним проектировщиком Руковожу отделом проектирования в компании UIDesign Group с 2007 года

3. Админки – что это? Админка это система настройки другой системы

4. Почему?!

5. Причины Модели взаимодействия Модель реализации Модель представления Ментальная модель Сдерживающие силы Политическая Экономическая Техническая Пропустим или нет?

6. Модели

7. Модели представления это «лицо» системы --интерфейс!! «опытные» пользователи – это те, кто подстроил свою ММ под МР

8. Как исправить?

9. Ответ ПИ админки оперирует понятиями из модели реализации ПИ админки рассчитан на «опытных» пользователей Нет прямой зависти качества ПИ админки от продаж основного продукта

10. Как рождаются ПИ Любой ПИ рождается в муках Сложности бывают везде: на глобальном уровне, в микрорешениях Но любые решения должны приниматься на основе фактов Пропустим или нет?

11. Сбор данных: текущая ситуация Анализ текущей ситуации Ревизия имеющегося добра Выявление паттернов Выявление хороших решений (запомнить) … и плохих (выяснять истинные причины) Знакомство с разработчиками Конкурентный анализ Персонажи/роли

12. Сбор данных: конкурентный анализ Конкуренты ищем общие тенденции, осознаем, чем они вызваны, оцениваем качество ищем интересные решения, анализируем на применимость … и другого поля ягоды смотрим интересные решения

13. Сбор данных: персонажи дают прочувствовать предметную область дают понять уровень пользователей влияют на вашу степень свободы удобны, когда в проекте несколько человек удобны, когда проект затяжной (док-ва!!1)

14. но пользы нет, когда ты все делаешь один, быстро и не сопровождаешь ПИ

15. Перепроектирование С нуля Когда с нуля экономически выгоднее, чем по-божески … либо когда новая концепция существенно лучше старой По-божески Если нет больших огрех (изучаем текущую ситуацию) Если «с нуля» сильно задевает армию пользователей (переобучение, МП сильно отличается от ММ) Если «с нуля» дорого

16. Перепроектирование: концепция Структура меню системы Навигация по ней распределение функций по ролям (никто не забыт, ничто не забыто!) Структура основных экранных форм Должна наглядно демонстрировать выполнение типовых сценариев пользователя

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

18. Какие бывают админки По системам Управляют железом Управляют софтом По степени интеграции Stand-alone Встроенные в основной ПИ По пользователям Опытные Неопытные Всякие-разные

19. По типу системы Для железа Влияют на работу функций железа Не бывают «встроенными» Свойственные задержки реакции железа Для софта Бывают «встроенными» и stand-alone Влияют на «лицо» настраиваемого софта

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

21. По типу пользователей Опытные развязанность проектироващика Сложности с защитой идей Неопытные Идеи защищать с одной стороны легко, с другой -- сложно Челлендж проектировщика! Всякие-разные Несколько интерфейсов Как сделать, чтобы одни не мешали другим

22. Роли/Функции

23. Полезные фишки для админок Поиск функций в системе Справка, из которой можно выполнять действия Командная строка Удобная работа с большими массивами данных

24. Суперадминки Интерфейс бога Массовые операции Внутресистемная статистика Гибкость работы с нестандартными ситуациями без призыва девелопера Требования к удобству часто понижены Они смешные, там специфический юмор программистов Есть скриншоты админки твиттера. Будем смотреть?

25. Что делать in - house проектировщикам Делать гайдлайны дать девелоперам доступ поощрять их использование Следить за обратной связью Возможность отправить отзыв прямо из системы Готовить пользователей к новому публикация анонсов новой функциональности сбор фидбека Формализовать принятие интерфейсных решений мнение пользователей внешний опыт собственный опыт Дружить с девелоперами

26. Что почитать Alan Cooper , About Face Luke Wroblewski, Web Form Design 37Signals, Getting Real

27. Конец. Спасибо! [email_address]

28. Добавка

35. Вопросы Как эффективно проектировать роли? выявление требований для разных ролей Как человек, несколько лет проектировавший «эту хрень» хотел бы поинтересоваться как, например, удавалось пробить уйму сложившихся стереотипов, выйдя за рамки «да еще на эту хрень время тратить, сделай попроще», «админ не дурак — разберется», «да, херня вышла, ну мы же мануал пишем» и т.д. При том, что значительная часть админок (читай доступные паттерны) — показательно низкого качества. У меня вопрос по части CMS. Если проект мультиязычный, то как лучше организовать админку, чтобы там можно было редактировать контент на разных языках? Скажите, как так получается, что все админки, даже не для админов (пример: личный роутер) — такое УГ? как исправить ситуацию

36. Как можно спроектировать интерфейс для максимальной производительности, но не забыть о людях) Сбор метрик по оценки удобства и эффективности админской части сайта ( и какие это метрики). Best Practices. Гайды для админских систем. Влияние интерфейса админки на интерфейс основного сайта.» Интерфейсы в зависимости от различных типов и целей Интернет-ресурса с учетом многоролийности: - Контентные, медийные, игровые проекты (новостные издания \ соц. сети \ игры...) - Онлайн-сервисы (рекламные сети \ спец. инструменты)