#дизайн /// UX-марафон 26-6 — Проектирование сложных систем
Философия производства сложных интерфейсов
Алексей Курлаев, Сбер
(Попытка ответить на вопросы про сложные системы, заданные в чате)
1. Что считать сложными системами — (не все простые системы внутри просты и наоборот) — вот такие:
⁃ Критично важно стоит вопрос о скорости решения сценария (решения сценария? Что это значит???)
⁃ Сценариев много. Основных может быть около 10, но суммарно будет на порядок больше
⁃ Пользователи продвинуты, их можно назвать “операторами интерфейса” (это правда)
⁃ Место на экране плотно забито, подчинено строгой иерархии/навигации, к месту на экране относимся критично (это очень натянуто, тогда и выдачу товаров в Amazon можно назвать сложными и покупателей считать операторами интернет-магазина)
2. Продуктовый дизайнер VS дизайнер сложных систем
⁃ Разные пользователи — массовый VS “Оператор” (вот это TRUE)
⁃ Работа на проекте — 1-2 года VS 3+ или всю жизнь (ну блин, неправда, при хорошем кругозоре и опыте можно и за год на сложных системах трудиться продуктивно)
⁃ Пример с редизайном Flash — с Macromedia на Adobe, с “подстройкой” под интерфейс Фотошопа, Иллюстратора, etc; здесь сложный проф-интерфейс, пользователь принимает такое, переучивается.
⁃ Пример с редизайном Кинопоиска — здесь публичный массовый интерфейс, пользователь негодует, протестует.
3. Какие навыки необходимы для проектирования сложных систем, но не обязательны для проектирования простых
⁃ Методы исследований — опросные (интервью, фокус-группа, анекты) и неопросные (наблюдение, эксперимент, анализ)
⁃ Про тепловую карту — это пример про большие и малые данные — 10к и 100к (серьезно? 10К и 100К это малые и большие данные? про саму тепловую карту VS коридорку TRUE)
4. Работа с пользователем массового продукта
⁃ Анализ больших объемов пользователей (что за бред? Есть множество сложных систем с относительно небольшой аудиторией и массовых продуктов с почти бескрайней аудиторией)
⁃ Критичность “модного” дизайна
⁃ Навыки интуитивного дизайна (Что такое интуитивный дизайн? может имеется в виду интуитивный интерфейс?)
5. Работа с пользователем массового продукта
⁃ интервью с пользователем — основной инструмент работы со сложными системами
⁃ Стоит учитывать работу памяти человека: внушение, заблуждение, критичность кол-ва интервью и выбор способа проведения, столкновение интересов…
⁃ Аналитические навыки в продукте (ну тут без них никуда, надо уметь в анализ, с этим не поспорить)
⁃ Навыки работы с пространством — скорость важнее удобства (что есть скорость и что есть удобство в этом контексте понять не удалось)
6. Лучшие (а также не лучшие, но используемые) практики “удержания всего вместе, чтобы ничего не упустить” — Расстановка приоритетов: ИА > сбор инфо о тех.ограничениях > редизайн системы (размыто сформулировано; звучит так, что ИА важнее учета технических ограничений, но если так, то на стоит ли проанализировать взаимные влияния ИА и этих ограничений?)
7. Общий journey map — оказалось, что для пользователя два продукта воспринимались как один.
Доклад в целом расстроил, показался непоследовательным. Многие утверждения хоть и верные, но они как будто понадерганы из разных частей большего (раз так в 10) доклада.
Системно:
⁃ Делается попытка объяснения какую систему считать сложной — пользователи-профессионалы, которые с помощью интерфейса выполняют рабочие практики, функций много и потому сценариев в интерфейсе много и они сильно ветвятся => интерфейс насыщен, чтобы это множество сценариев/функций поддержать.
⁃ Упоминается практика проектирования — исследования (опросы и эксперименты); её корректно считать одной из основных, так как пользователь один из основных стейкхолдеров, выявление его интересов-предпочтений-намерений возможно через исследования.
⁃ Упомянуты приоритеты в работе, это практики на стыке (само)менеджмента — какие работы выполнять в какую очередь.
———
#проектирование #UX #мероприятия #практика #менеджмент #исследования #роли
Философия производства сложных интерфейсов
Алексей Курлаев, Сбер
(Попытка ответить на вопросы про сложные системы, заданные в чате)
1. Что считать сложными системами — (не все простые системы внутри просты и наоборот) — вот такие:
⁃ Критично важно стоит вопрос о скорости решения сценария (решения сценария? Что это значит???)
⁃ Сценариев много. Основных может быть около 10, но суммарно будет на порядок больше
⁃ Пользователи продвинуты, их можно назвать “операторами интерфейса” (это правда)
⁃ Место на экране плотно забито, подчинено строгой иерархии/навигации, к месту на экране относимся критично (это очень натянуто, тогда и выдачу товаров в Amazon можно назвать сложными и покупателей считать операторами интернет-магазина)
2. Продуктовый дизайнер VS дизайнер сложных систем
⁃ Разные пользователи — массовый VS “Оператор” (вот это TRUE)
⁃ Работа на проекте — 1-2 года VS 3+ или всю жизнь (ну блин, неправда, при хорошем кругозоре и опыте можно и за год на сложных системах трудиться продуктивно)
⁃ Пример с редизайном Flash — с Macromedia на Adobe, с “подстройкой” под интерфейс Фотошопа, Иллюстратора, etc; здесь сложный проф-интерфейс, пользователь принимает такое, переучивается.
⁃ Пример с редизайном Кинопоиска — здесь публичный массовый интерфейс, пользователь негодует, протестует.
3. Какие навыки необходимы для проектирования сложных систем, но не обязательны для проектирования простых
⁃ Методы исследований — опросные (интервью, фокус-группа, анекты) и неопросные (наблюдение, эксперимент, анализ)
⁃ Про тепловую карту — это пример про большие и малые данные — 10к и 100к (серьезно? 10К и 100К это малые и большие данные? про саму тепловую карту VS коридорку TRUE)
4. Работа с пользователем массового продукта
⁃ Анализ больших объемов пользователей (что за бред? Есть множество сложных систем с относительно небольшой аудиторией и массовых продуктов с почти бескрайней аудиторией)
⁃ Критичность “модного” дизайна
⁃ Навыки интуитивного дизайна (Что такое интуитивный дизайн? может имеется в виду интуитивный интерфейс?)
5. Работа с пользователем массового продукта
⁃ интервью с пользователем — основной инструмент работы со сложными системами
⁃ Стоит учитывать работу памяти человека: внушение, заблуждение, критичность кол-ва интервью и выбор способа проведения, столкновение интересов…
⁃ Аналитические навыки в продукте (ну тут без них никуда, надо уметь в анализ, с этим не поспорить)
⁃ Навыки работы с пространством — скорость важнее удобства (что есть скорость и что есть удобство в этом контексте понять не удалось)
6. Лучшие (а также не лучшие, но используемые) практики “удержания всего вместе, чтобы ничего не упустить” — Расстановка приоритетов: ИА > сбор инфо о тех.ограничениях > редизайн системы (размыто сформулировано; звучит так, что ИА важнее учета технических ограничений, но если так, то на стоит ли проанализировать взаимные влияния ИА и этих ограничений?)
7. Общий journey map — оказалось, что для пользователя два продукта воспринимались как один.
Доклад в целом расстроил, показался непоследовательным. Многие утверждения хоть и верные, но они как будто понадерганы из разных частей большего (раз так в 10) доклада.
Системно:
⁃ Делается попытка объяснения какую систему считать сложной — пользователи-профессионалы, которые с помощью интерфейса выполняют рабочие практики, функций много и потому сценариев в интерфейсе много и они сильно ветвятся => интерфейс насыщен, чтобы это множество сценариев/функций поддержать.
⁃ Упоминается практика проектирования — исследования (опросы и эксперименты); её корректно считать одной из основных, так как пользователь один из основных стейкхолдеров, выявление его интересов-предпочтений-намерений возможно через исследования.
⁃ Упомянуты приоритеты в работе, это практики на стыке (само)менеджмента — какие работы выполнять в какую очередь.
———
#проектирование #UX #мероприятия #практика #менеджмент #исследования #роли
#систематика /// Системный менеджмент
Системный менеджмент — набор дисциплин/практик построения систем обеспечения. Основан на системном мышлении и работает с альфами работ, метода, команд; обязательно строит эти альфы вокруг целевой системы, тем самым создавая обеспечивающую систему. При менеджменте сервиса также необходимо прослеживать связь с целевой системой. Это важно, так как для разных целевых систем будут разные обеспечивающие системы.
Рассматривается только в связке с предпринимательством (что делать) и инженерией (как делать). Системный менеджмент НЕ работает с содержанием (!), а только с обеспечением, содержанием же занимаются предпринимательская и инженерная зоны интереса. Это контринтуитивно, однако позволяет фокусироваться на обеспечении, то есть на альфах работы, метода и команды.
Системный менеджмент рассматривает создание систем по их уровням, на каждом из которых меняется состав менеджерских альф.
Чуть подробнее
---
#менеджмент
Системный менеджмент — набор дисциплин/практик построения систем обеспечения. Основан на системном мышлении и работает с альфами работ, метода, команд; обязательно строит эти альфы вокруг целевой системы, тем самым создавая обеспечивающую систему. При менеджменте сервиса также необходимо прослеживать связь с целевой системой. Это важно, так как для разных целевых систем будут разные обеспечивающие системы.
Рассматривается только в связке с предпринимательством (что делать) и инженерией (как делать). Системный менеджмент НЕ работает с содержанием (!), а только с обеспечением, содержанием же занимаются предпринимательская и инженерная зоны интереса. Это контринтуитивно, однако позволяет фокусироваться на обеспечении, то есть на альфах работы, метода и команды.
Системный менеджмент рассматривает создание систем по их уровням, на каждом из которых меняется состав менеджерских альф.
Чуть подробнее
---
#менеджмент