#систематика /// Сервис и функция
Сервис — это поведение системы по отношению к её надсистеме. То, что делает система для изменения надсистемы.
Функция — это взгляд надсистемы на поведение системы. То, что нужно надсистеме от системы.
Таким образом, функция системы — предоставление сервиса в адрес её надсистемы.
При системном разбиении необходимо не только выделить надсистему, но также понимать как она устроена, чтобы выявить основную функцию нашей системы, чтобы реализовать её сервис, отдаваемый "наверх".
Функция — поведение системы для надсистемы или систем в окружении. Это поведение удовлетворяет потребности внешних ролей, то есть проектных ролей надсистемы.
Для реализации функции системы необходимо удовлетворить требования к рассматриваемой системе.
Функция системы = эмерджентность.
Сервис в виде его регулярных экземпляров, инстансов — работы, вот этот каждый экземпляр это работы по применению практик, эти работы выдают сервис в ходе своего выполнения.
___
#сервис #функция #подсистема #надсистема #потребности #требования #эмерджентность
Сервис — это поведение системы по отношению к её надсистеме. То, что делает система для изменения надсистемы.
Функция — это взгляд надсистемы на поведение системы. То, что нужно надсистеме от системы.
Таким образом, функция системы — предоставление сервиса в адрес её надсистемы.
При системном разбиении необходимо не только выделить надсистему, но также понимать как она устроена, чтобы выявить основную функцию нашей системы, чтобы реализовать её сервис, отдаваемый "наверх".
Функция — поведение системы для надсистемы или систем в окружении. Это поведение удовлетворяет потребности внешних ролей, то есть проектных ролей надсистемы.
Для реализации функции системы необходимо удовлетворить требования к рассматриваемой системе.
Функция системы = эмерджентность.
Сервис в виде его регулярных экземпляров, инстансов — работы, вот этот каждый экземпляр это работы по применению практик, эти работы выдают сервис в ходе своего выполнения.
___
#сервис #функция #подсистема #надсистема #потребности #требования #эмерджентность
#систематика /// Прикладная компетенция
Прикладная компетенция в каком-то деле — способность действовать на трёх смежных уровнях:
На уровне надсистемы: понимать как использовать и в каком окружении, для чего воплощается система, какой сервис она будет выдавать.
На уровне целевой системы: понимать как должна быть устроена сама система, чтобы воплотить нужную эмерджентность.
На уровне подсистемы: знать какие нужны части для изготовления целевой системы.
____
#эмерджентность #компетенция #сервис
Прикладная компетенция в каком-то деле — способность действовать на трёх смежных уровнях:
На уровне надсистемы: понимать как использовать и в каком окружении, для чего воплощается система, какой сервис она будет выдавать.
На уровне целевой системы: понимать как должна быть устроена сама система, чтобы воплотить нужную эмерджентность.
На уровне подсистемы: знать какие нужны части для изготовления целевой системы.
____
#эмерджентность #компетенция #сервис
#систематика /// Проект
Проект есть оргзвено в смысле группы людей с инструментами и технологиями и общей целью воплотить продукт или оказать сервис; группа эта специально организована для этого, и ведёт работы по воплощению продукта / оказанию сервиса.
Проект всегда включает оргроли — проект всегда включает людей / оргзвенья, играющие оргроли.
Проект есть система в обеспечении.
___
#проект #сервис #оргроль #оргзвено
Проект есть оргзвено в смысле группы людей с инструментами и технологиями и общей целью воплотить продукт или оказать сервис; группа эта специально организована для этого, и ведёт работы по воплощению продукта / оказанию сервиса.
Проект всегда включает оргроли — проект всегда включает людей / оргзвенья, играющие оргроли.
Проект есть система в обеспечении.
___
#проект #сервис #оргроль #оргзвено
#дизайн /// UX-марафон 26-5 — Проектирование сложных систем
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис
Объектно-ориентированный UX
Алексей Сорокин, Мой склад
(Метод, применяемый для проектирования сложных продуктов и систем, основанный на ОО-практиках)
1. Есть дизайн “по-быстрому” — понять задачу > применить интуицию, опыт, здравый смысл, насмотренность > макет/гипотеза
2. Во втором шаге происходит “магия”
3. При применении JTBD, CJM, etc — задача уточняется, но “магия” остается
4. Статистика с прода, тестирования, etc — это все равно обвес вокруг “магии”, лишь уточняющий данные на вход
5. Макет/гипотеза — подчиняется циклу гипотеза > эксперимент > сбор данных > анализ и вывод; цикл стоит денег
6. Чем точнее гипотеза, тем меньше циклов
7. Сложный продукт — где много сценариев; аналогия: сам интернет-магазин это поезд, он едет по рельсам, а админка интернет-магазина это самолет, он летает как хочет
8. В сложном продукте тем более цикл выглядит так: гипотеза > эксперимент > сбор данных > “магия”
9. “Попробуем без сценариев” (без сценариев? Интересно как это…)
10. Три вопроса про пользователя: каков его опыт? в каком состоянии/контексте пользователь? использует систему чтобы что?
⁃ На первые два вопроса отвечает метод персон, на третий отвечает jtbd
⁃ Задачи в персонах — это job в jtbd
11. Пользователь работает с объектами; работа = действие + объект + контекст
12. Далее про связь объектов и их обозначений
13. Объект в системе: у него есть свойства, методы, представления
⁃ Свойства — атрибуты объекта, то, как его можно охарактеризовать
⁃ Методы — действия, которые можно сделать с объектом
⁃ Представления объекта — проекция объекта из ментальной модели пользователя на интерфейс; полное представление есть перечисление всех его свойств и методов; например, в навигации используются краткие представления объектов
14. Принципы работы с представлениями:
⁃ Нужно полное представление объекта — вся информация для создания проекций; пример: карточка объекта
⁃ Нужен полный набор допустимых действий над объектом
⁃ Нужно дать пользователю контроль над “его” объектами
⁃ Если связь между объектами есть, то ее необходимо показать в интерфейсе
15. Далее про сценарии:
⁃ На основе сценариев выбираем представления объектов в контекстах
⁃ Также на основе сценариев строим порядок представления объектов
⁃ На основе сценариев понимаем необходимый набор представлений
⁃ И также на основе сценариев …не успел записать…
16. Для работы с объектами помогает ER-диаграмма, отражающая набор объектов, их свойства и методы, и связи объектов
17. Заключение — что дает OOUX:
⁃ Доп. инструмент проектирования
⁃ Меньше “магии” и больше аргументировать
⁃ “Меньше интуиции, больше логики”
⁃ Можно не держать в голове сложные объекты
Доклад на важную тему — о том как превратить интуицию и “магию” проектирования в объясняемые паттерны.
Что хорошо — доклад вызывает интерес к моделированию на концептуальном уровне.
Что плохо — не звучало убедительно: да, есть объекты и у них есть свойства и представления; но как связаны объекты и функции (операции пользователя, поддерживаемые интерфейсом)? Методы и функции? Непонятно, почему на первое место выносится то, что можно делать с объектом, а не то, что делает пользователь (та самая Job из jtbd).
Я ожидал развитие доклада с Profsoux-2020, но показалось даже более смазанным.
На январском UX-марафоне про ИА был доклад на почти эту же тему, мне он показался более цельным.
Системно:
⁃ Сделана попытка рассмотреть моделирование сценариев через модули системы — названы объектами, — обеспечивающие операции — названы методами, но в пассивном рассмотрении: действия “над объектом” вместо “модуль выполняет функцию F”.
⁃ Показалось, что есть попытка рассмотреть метод вне сценарной парадигмы, но я не понял, как от неё отказаться, так как про цели-операции-действия пользователя не было сказано.
———
#проектирование #UX #мероприятия #функция #модуль #сервис