Проектирование админок для  #uidesignersmeetup
Upcoming SlideShare
Loading in...5
×
 

Проектирование админок для #uidesignersmeetup

on

  • 1,841 views

Presentation by Alexey Kalenyuk for #uidesignersmeetup

Presentation by Alexey Kalenyuk for #uidesignersmeetup

Презентация Алексея Каленюка для #uidesignersmeetup

Statistics

Views

Total Views
1,841
Views on SlideShare
1,838
Embed Views
3

Actions

Likes
10
Downloads
14
Comments
0

2 Embeds 3

http://www.slideshare.net 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Проектирование админок для  #uidesignersmeetup Проектирование админок для #uidesignersmeetup Presentation Transcript

    • Проектирование админок
    • Обо мне
      • Занимаюсь проектированием интерфейсов с 2002 года
      • Работал и штатным, и внешним проектировщиком
      • Руковожу отделом проектирования в компании UIDesign Group с 2007 года
    • Админки – что это?
      • Админка это система настройки другой системы
    • Почему?!
    • Причины
      • Модели взаимодействия
      • Модель реализации
      • Модель представления
      • Ментальная модель
      • Сдерживающие силы
      • Политическая
      • Экономическая
      • Техническая
      Пропустим или нет?
    • Модели
    • Модели представления
      • это «лицо» системы --интерфейс!!
      • «опытные» пользователи – это те, кто подстроил свою ММ под МР
    • Как исправить?
    • Ответ
      • ПИ админки оперирует понятиями из модели реализации
      • ПИ админки рассчитан на «опытных» пользователей
      • Нет прямой зависти качества ПИ админки от продаж основного продукта
    • Как рождаются ПИ
      • Любой ПИ рождается в муках
      • Сложности бывают везде: на глобальном уровне, в микрорешениях
      • Но любые решения должны приниматься на основе фактов
      Пропустим или нет?
    • Сбор данных: текущая ситуация
      • Анализ текущей ситуации
        • Ревизия имеющегося добра
        • Выявление паттернов
        • Выявление хороших решений (запомнить)
        • … и плохих (выяснять истинные причины)
        • Знакомство с разработчиками
      • Конкурентный анализ
      • Персонажи/роли
    • Сбор данных: конкурентный анализ
      • Конкуренты
        • ищем общие тенденции, осознаем, чем они вызваны, оцениваем качество
        • ищем интересные решения, анализируем на применимость
      • … и другого поля ягоды
        • смотрим интересные решения
    • Сбор данных: персонажи
      • дают прочувствовать предметную область
      • дают понять уровень пользователей
      • влияют на вашу степень свободы
      • удобны, когда в проекте несколько человек
      • удобны, когда проект затяжной (док-ва!!1)
    • но пользы нет, когда ты все делаешь один, быстро и не сопровождаешь ПИ
    • Перепроектирование
      • С нуля
      • Когда с нуля экономически выгоднее, чем по-божески
      • … либо когда новая концепция существенно лучше старой
      • По-божески
      • Если нет больших огрех (изучаем текущую ситуацию)
      • Если «с нуля» сильно задевает армию пользователей (переобучение, МП сильно отличается от ММ)
      • Если «с нуля» дорого
    • Перепроектирование: концепция
      • Структура меню системы
      • Навигация по ней
      • распределение функций по ролям (никто не забыт, ничто не забыто!)
      • Структура основных экранных форм
      • Должна наглядно демонстрировать выполнение типовых сценариев пользователя
    • Перепроектирование: деталка
      • Интерфейсные решения принимаются на основе:
        • мнение пользователей
        • внешний опыт
        • собственный опыт
      • Используются визуальные и поведенческие паттерны
        • приучаем пользователей к единству
        • облегчаем работу девелоперам
      • Показываем критические ситуации
    • Какие бывают админки
      • По системам
        • Управляют железом
        • Управляют софтом
      • По степени интеграции
        • Stand-alone
        • Встроенные в основной ПИ
      • По пользователям
        • Опытные
        • Неопытные
        • Всякие-разные
    • По типу системы
      • Для железа
        • Влияют на работу функций железа
        • Не бывают «встроенными»
        • Свойственные задержки реакции железа
      • Для софта
        • Бывают «встроенными» и stand-alone
        • Влияют на «лицо» настраиваемого софта
    • По типу интеграции
      • Stand-alone
        • Нет сложностей с расширяемостью
        • Недостаточная наглядность там, где это необходимо
      • Встроенные
        • Загромождают функционал основной системы
        • Сложно интегрироваться при скинизации
        • Все под рукой
        • WYSIWYG
    • По типу пользователей
      • Опытные
        • развязанность проектироващика
        • Сложности с защитой идей
      • Неопытные
        • Идеи защищать с одной стороны легко, с другой -- сложно
        • Челлендж проектировщика!
      • Всякие-разные
        • Несколько интерфейсов
        • Как сделать, чтобы одни не мешали другим
    • Роли/Функции
    • Полезные фишки для админок
      • Поиск функций в системе
      • Справка, из которой можно выполнять действия
      • Командная строка
      • Удобная работа с большими массивами данных
    • Суперадминки
      • Интерфейс бога
      • Массовые операции
      • Внутресистемная статистика
      • Гибкость работы с нестандартными ситуациями без призыва девелопера
      • Требования к удобству часто понижены
      • Они смешные, там специфический юмор программистов
      Есть скриншоты админки твиттера. Будем смотреть?
    • Что делать in - house проектировщикам
      • Делать гайдлайны
        • дать девелоперам доступ
        • поощрять их использование
      • Следить за обратной связью
        • Возможность отправить отзыв прямо из системы
      • Готовить пользователей к новому
        • публикация анонсов новой функциональности
        • сбор фидбека
      • Формализовать принятие интерфейсных решений
        • мнение пользователей
        • внешний опыт
        • собственный опыт
      • Дружить с девелоперами
    • Что почитать
      • Alan Cooper ,
      • About Face
      Luke Wroblewski, Web Form Design 37Signals, Getting Real
    • Конец. Спасибо!
      • [email_address]
    • Добавка
    •  
    •  
    •  
    •  
    •  
    •  
    • Вопросы
      • Как эффективно проектировать роли? выявление требований для разных ролей
      • Как человек, несколько лет проектировавший «эту хрень» хотел бы поинтересоваться как, например, удавалось пробить уйму сложившихся стереотипов, выйдя за рамки «да еще на эту хрень время тратить, сделай попроще», «админ не дурак — разберется», «да, херня вышла, ну мы же мануал пишем» и т.д. При том, что значительная часть админок (читай доступные паттерны) — показательно низкого качества.
      • У меня вопрос по части CMS. Если проект мультиязычный, то как лучше организовать админку, чтобы там можно было редактировать контент на разных языках?
      • Скажите, как так получается, что все админки, даже не для админов (пример: личный роутер) — такое УГ? как исправить ситуацию
      • Как можно спроектировать интерфейс для максимальной производительности, но не забыть о людях)
      • Сбор метрик по оценки удобства и эффективности админской части сайта ( и какие это метрики). Best Practices. Гайды для админских систем. Влияние интерфейса админки на интерфейс основного сайта.»
      • Интерфейсы в зависимости от различных типов и целей Интернет-ресурса с учетом многоролийности: - Контентные, медийные, игровые проекты (новостные издания соц. сети игры...) - Онлайн-сервисы (рекламные сети спец. инструменты)