#систематика /// Построение причинно-следственной связи
ПСС строится из экспертных мнений и контрфактических суждений (КФ-суждения).
Базовый алгоритм:
1. Придумываем / выявляем цепочку событий, которые выглядят для нас наиболее логично и непротиворечиво. Проще говоря — "как надо", где надо == наш ролевой интерес.
2. Избегаем соблазна оставить в модели псевдо-связи, которые кажутся релевантными, однако на самом деле только "шумят" и создают дребезг. Их нельзя оставлять только потому что "они же тут рядом".
3. Отслеживаем: дребезг в модели, места где "непонятно как работает", контрфактические изменения (которые говорят о том, что причина и следствие не связаны). Если что-то из этого есть в модели, значит модель пока не готова, продолжаем поиск — ищем элементы для ПСС-модели + продолжаем исследования — напрягаем мозги (делаем контрфактические суждения) и экспертов (собираем априорные данные).
4. Альтернативный (или дополнительный) подход — фиксируем желаемый результат (следствие в строящейся модели) и ищем / подбираем наиболее сильные элементы-события, лучшие кандидаты на элементы-причины.
5. Если предыдущие четыре пункта пройдены и у нас есть модель со всеми элементами, то нам осталось только понять какие именно нужны данные для проверки модели. Данные получаем в ходе эксперимента. На этом этапе важно не поддаваться моде сбора данных: не собирать лишние, чтобы экономить на их сборе и интерпретации + не собирать данные для построения модели, а только для проверки уже построенной модели.
Когда есть модель с достаточным количеством элементов, и определены необходимые данные, то можно приступать с эксперименту, который включаем сбор данных и собственно проверку гипотезы.
___
#псс #причинно_следственная_связь #моделирование #эксперимент
ПСС строится из экспертных мнений и контрфактических суждений (КФ-суждения).
Базовый алгоритм:
1. Придумываем / выявляем цепочку событий, которые выглядят для нас наиболее логично и непротиворечиво. Проще говоря — "как надо", где надо == наш ролевой интерес.
2. Избегаем соблазна оставить в модели псевдо-связи, которые кажутся релевантными, однако на самом деле только "шумят" и создают дребезг. Их нельзя оставлять только потому что "они же тут рядом".
3. Отслеживаем: дребезг в модели, места где "непонятно как работает", контрфактические изменения (которые говорят о том, что причина и следствие не связаны). Если что-то из этого есть в модели, значит модель пока не готова, продолжаем поиск — ищем элементы для ПСС-модели + продолжаем исследования — напрягаем мозги (делаем контрфактические суждения) и экспертов (собираем априорные данные).
4. Альтернативный (или дополнительный) подход — фиксируем желаемый результат (следствие в строящейся модели) и ищем / подбираем наиболее сильные элементы-события, лучшие кандидаты на элементы-причины.
5. Если предыдущие четыре пункта пройдены и у нас есть модель со всеми элементами, то нам осталось только понять какие именно нужны данные для проверки модели. Данные получаем в ходе эксперимента. На этом этапе важно не поддаваться моде сбора данных: не собирать лишние, чтобы экономить на их сборе и интерпретации + не собирать данные для построения модели, а только для проверки уже построенной модели.
Когда есть модель с достаточным количеством элементов, и определены необходимые данные, то можно приступать с эксперименту, который включаем сбор данных и собственно проверку гипотезы.
___
#псс #причинно_следственная_связь #моделирование #эксперимент
#систематика /// Сбор данных и эксперимент
Пререквизит для проведения эксперимента:
- Хорошо ли сформулирована гипотеза? Она должны хорошо объяснять.
- Есть ли оценка априорных шансов? Нам необходимы известные данные по нашему вопросы в домене.
- Есть ли свидетельства против нашей гипотезы? Необходимо провести контрфактические суждения, проверить связность модели.
- Посчитана ли правдоподобность? Важно численно выразить следствие в нашей модели, убедиться, что это следствие есть именно то, что мы хотим получить когда будем принимать решение по итогу проведения эксперимента.
Если чего-то из этого списка нет в наличии, то высок риск, что проверять гипотезу на эксперименте "в мире" (а не в голове) будет дорого и, вероятно, бессмысленно. То есть, гипотезу надо доформулировать. Достроить модель.
Если чего-то из этого нет, и при этом не получается добыть (элементы модели, данные), то надо создать связанную гипотезу — "соседнюю" / "прокси"-гипотезу. Это часто случается при проверке гипотез, связанных с абстрактными вещами, такими как креативность, мышление, успешность, etc.
Финальная проверка на дешевизну проверки гипотез:
- Осталась ли какая-либо неопределенность?
- Нужны ли еще элементы модели или уже только данные?
Если в ответах на эти вопросы есть хоть одно "да", то дополняем модель данными.
Если среди ответов нет "да", то переходим к сбору данных.
Данные:
1. Каких данных минимально достаточно? Нам не нужны лишние данные, чтобы не тратить ресурсы на их поиск, обработку, интерпретацию.
2. Проверка на опровержение — представляем, что у нас есть идеальные данные. Возможно ли обнаружить еще какие-либо данные, которые опровергнут нашу идеальную модель с подстваленными идеальными данными?
3. По итогу этих двух пунктов решаем, какие еще данные нужны, какие еще элементы модели нужны. То есть, откатываемся на построение ПСС, если необходимо, и снова переходим к сбору данных.
4. Итерируем эти шанги до максимально стройной и сильной модели.
Основной принцип дешевизны проверки гипотез — не проверять то, что можно проверить в голове (чаще всего на КФ-суждениях). Чаще всего дешевле потратить полдня с блокнотом и ручкой, чем несколько дней на сбор и интерпретацию в в лучшем случае ненужных, а в худшем искажающих данных.
___
#псс #причинно_следственная_связь #моделирование #эксперимент
Пререквизит для проведения эксперимента:
- Хорошо ли сформулирована гипотеза? Она должны хорошо объяснять.
- Есть ли оценка априорных шансов? Нам необходимы известные данные по нашему вопросы в домене.
- Есть ли свидетельства против нашей гипотезы? Необходимо провести контрфактические суждения, проверить связность модели.
- Посчитана ли правдоподобность? Важно численно выразить следствие в нашей модели, убедиться, что это следствие есть именно то, что мы хотим получить когда будем принимать решение по итогу проведения эксперимента.
Если чего-то из этого списка нет в наличии, то высок риск, что проверять гипотезу на эксперименте "в мире" (а не в голове) будет дорого и, вероятно, бессмысленно. То есть, гипотезу надо доформулировать. Достроить модель.
Если чего-то из этого нет, и при этом не получается добыть (элементы модели, данные), то надо создать связанную гипотезу — "соседнюю" / "прокси"-гипотезу. Это часто случается при проверке гипотез, связанных с абстрактными вещами, такими как креативность, мышление, успешность, etc.
Финальная проверка на дешевизну проверки гипотез:
- Осталась ли какая-либо неопределенность?
- Нужны ли еще элементы модели или уже только данные?
Если в ответах на эти вопросы есть хоть одно "да", то дополняем модель данными.
Если среди ответов нет "да", то переходим к сбору данных.
Данные:
1. Каких данных минимально достаточно? Нам не нужны лишние данные, чтобы не тратить ресурсы на их поиск, обработку, интерпретацию.
2. Проверка на опровержение — представляем, что у нас есть идеальные данные. Возможно ли обнаружить еще какие-либо данные, которые опровергнут нашу идеальную модель с подстваленными идеальными данными?
3. По итогу этих двух пунктов решаем, какие еще данные нужны, какие еще элементы модели нужны. То есть, откатываемся на построение ПСС, если необходимо, и снова переходим к сбору данных.
4. Итерируем эти шанги до максимально стройной и сильной модели.
Основной принцип дешевизны проверки гипотез — не проверять то, что можно проверить в голове (чаще всего на КФ-суждениях). Чаще всего дешевле потратить полдня с блокнотом и ручкой, чем несколько дней на сбор и интерпретацию в в лучшем случае ненужных, а в худшем искажающих данных.
___
#псс #причинно_следственная_связь #моделирование #эксперимент
#дизайн /// UX-марафон 26-2 — Проектирование сложных систем
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования
Как сделать интерфейс атомной электростанции понятным для всех
Диана Ударцева, Никита Беллер, Тинькофф
(Рассказ про опыт проектирования внутренних бизнес-продуктов для профессиональных сотрудников — разработчики, аналитики, трейдеры, etc)
1. Какие задачи решают — берут данные и делают интерфейсы для работы с ними
2. Сложности со сложными системами
⁃ отсутствие референсов,
⁃ техническая сложность разработки,
⁃ проф-пользователи и их майндсет,
⁃ каждая задача — выход из зоны комфорта (кажется, имелось в виду, что каждая задача решается нетипичным образом; это имхо никак не связано с комфортом)
3. Порог входа VS эффективность интерфейса
⁃ “Продукт должен быть легким” — утопия для сложных интерфейсов;
⁃ человек с улицы НЕ должен сразу разобраться в сложном интерфейсе;
⁃ сразу закладывается обучаемость, etc
4. Пример: приложение для инвестиций — для всех, низкий порог входа, а терминал для трейдинга — для знающих трейдеров, высокий порог входа
5. Про мнимое упрощение — если бездумно упростить, то может получиться хуже, так как многие сложные/непонятные (массам) вещи являются якорями и ориентирами в сложных интерфейсах (показалось невнятно или не уловил мысль, изложил как понял )
6. Пример сложности с терминами, их не стоит упрощать, например, margin call, “ноут” — устоявшиеся термины; их упрощение — мнимое
7. Разрабатывайте на реальных данных — предполагаемые данные и их отображение могут не соответствовать реальности и моделирование нарушается
8. Учитывайте масштабируемость — заложите на будущее функционал + пример: шапка страницы под десяток пунктов, а их по факту на порядок больше
9. Определяйте ограничения заранее — выявляйте технический границы решений + пример, таблицы не получилось представить дашбордами, так как данные принимаются не в реальном времени, а раз в сутки
10. Прорабатывайте алгоритмы — работайте с (базовыми) сценариями, и только потом с интерфейсами
11. (Показан скрин диаграммы — гибрид bpmn и service blueprint)
12. Коммуницируйте с командой, особенно с аналитиками и разработчиками
13. Таймлайн жизни на проекте:
⁃ прогресс от полугода: 0-1 месяц это понимание “что вообще происходит” — потому что во внутренних системах проектировщик на является пользователем;
⁃ 2-4 месяц это стадия более уверенного решения задач, продолжаем постигать;
⁃ 5-8 месяц это стадия некоторой экспертизы, мышление базовыми и смежными сценариями, все равно продолжаем постигать;
⁃ примерно 1 год это стадия уверенной экспертизы, есть риск профдеформации и замыленности/зашоренности, продолжаем коммуницировать с коллегами, в тч из смежных направлений для размыливания.
14. Заключение: сложность — это прокачка софтовых и хордовых скиллов;
Хороший доклад, ориентированный на junior/middle-проектировщиков.
Системно:
⁃ Сформулирована “сложность” систем — отсутстивие или недоступность типовых решений, выделенная профессиональная аудитория (а она — один из основных стейкхолдеров),
⁃ Указано на назначение сложных систем — ими пользуются для выполнения профессиональных, рабочих задач (практик), а не повседневных и бытовых.
⁃ Сказано про язык коммуникации с пользователем — примеры с терминами и мнимым упрощением как раз про общение с аудиторией в его концептуальной сетке его языком.
- Моделирование на реальных данных — абсолютно согласен; важно моделировать на реальных данных, если есть возможность, это позволяет приблизить модель к отсечкам проверки и приемки.
- Сказано про работу с требованиями (правда другими словами) — масштабируемость и технические ограничения это именно работа с требованиями, их выявление, трассировка потребностей к требованиям, обозначение и снятие ограничений.
- Моделирование по сценариям — названо проработкой алгоритмов, но суть та же; все сценарные методы и фреймворки (JTBD, CJM, US map, Service Blueprint) действительно позволяют выявить теневые кейсы и учесть множество требований на ранних этапах.
———
#проектирование #UX #мероприятия #моделирование #коммуникация #требования