Про что:
#систематика — про системное мышление, системный подход, анализ-синтез, онтологию-семантику-прагматику, etc (все — по версии Школы Системного Менеджмента, далее ШСМ или Школа); этих постов больше всего.
#инфоарх — про информационную архитектуру и интерпретируемость; этих постов поменьше.
#дизайн — про дизайн-как-проектирование и всё, что не вписывается в первые два тега; этого меньше всего.
#имплозия — оффтоп всякий.
Этот канал — публикация моих заметок / конспектов по курсам ШСМ.
Заметки в исходном виде связаны между собой, но здесь, в канале, только рубрикация по тегам.
Ссылки на заметки привожу там, где это необходимо. Для навигации на смежные записи можно использовать теги или задавать вопросы в чате.
#систематика — про системное мышление, системный подход, анализ-синтез, онтологию-семантику-прагматику, etc (все — по версии Школы Системного Менеджмента, далее ШСМ или Школа); этих постов больше всего.
#инфоарх — про информационную архитектуру и интерпретируемость; этих постов поменьше.
#дизайн — про дизайн-как-проектирование и всё, что не вписывается в первые два тега; этого меньше всего.
#имплозия — оффтоп всякий.
Этот канал — публикация моих заметок / конспектов по курсам ШСМ.
Заметки в исходном виде связаны между собой, но здесь, в канале, только рубрикация по тегам.
Ссылки на заметки привожу там, где это необходимо. Для навигации на смежные записи можно использовать теги или задавать вопросы в чате.
#дизайн /// Системный взгляд на UI (кажется, первый пост с меткой дизайн : )
Вчера вышла моя статья про системный взгляд на UI — по мотивам выпускного эссе на Практикуме в ШСМ (декабрь 2020), выступления на UX-марафоне (январь 2021) и доклада на конференции ШСМ (апрель 2021). (все ссылки есть в статье)
Эта текущее понимание моей деятельности проектировщика через призму системного мышления.
Статья на Хабре: https://habr.com/ru/company/posttech/blog/567170/
Буду рад любой критике, комментариям, вопросам. Всем хорошего дня!
PS: там лонгрид получился, я вас предупредил : )
Вчера вышла моя статья про системный взгляд на UI — по мотивам выпускного эссе на Практикуме в ШСМ (декабрь 2020), выступления на UX-марафоне (январь 2021) и доклада на конференции ШСМ (апрель 2021). (все ссылки есть в статье)
Эта текущее понимание моей деятельности проектировщика через призму системного мышления.
Статья на Хабре: https://habr.com/ru/company/posttech/blog/567170/
Буду рад любой критике, комментариям, вопросам. Всем хорошего дня!
PS: там лонгрид получился, я вас предупредил : )
Хабр
Системный взгляд на UI. Разбираем часть ИТ-платформы сети отделений Почты России
Обновление (1) от 1 ноября 2021. Исправлена грубая ошибка. Я ошибочно полагал, что созданное и доставляемое отправление уже эксплуатируется, но это не так. Эксплуатация начинается только в момент...
#дизайн /// UX-марафон 26. Проектирование сложных систем
Вчера состоялся 26-й UX-марафон, который я посмотрел и по мере возможности проконспектировал и сегодня в течение дня опубликую; 6 докладов — 6 постов.
Сам конспект на основе фраз, цитат и слайдов.
Мои комментарии даны курсивом и только там, где я не могу не высказаться.
Если мои комменты покажутся резкими — ну сорян : )
В конце каждого конспекта я пишу кратко впечатление + пытаюсь разложить основные мысли доклада через призму системного мышления.
———
#проектирование #UX #мероприятия
Вчера состоялся 26-й UX-марафон, который я посмотрел и по мере возможности проконспектировал и сегодня в течение дня опубликую; 6 докладов — 6 постов.
Сам конспект на основе фраз, цитат и слайдов.
Мои комментарии даны курсивом и только там, где я не могу не высказаться.
Если мои комменты покажутся резкими — ну сорян : )
В конце каждого конспекта я пишу кратко впечатление + пытаюсь разложить основные мысли доклада через призму системного мышления.
———
#проектирование #UX #мероприятия
#дизайн /// UX-марафон 26-1 — Проектирование сложных систем
Компьютерное зрение в сервисах Яндекса
Алексей Белицкий, Яндекс
(Рассказ про функцию “Умная камера” в приложении Яндекса)
1. Компьютерное зрение — ввод данных в компьютер через изображение
2. Для перевода изображения в данные используют алгоритмы, а для улучшения алгоритмов — нейронные сети
3. Сети обучаются через разметку, которую делают люди
4. Одно из актуальных применений — распознавание лиц
5. В Яндексе это применяется для распознавания актеров (Кинопоиск), дополнения составных фото-видео (авто.ру), etc
6. Продуктовые поиски Яндекса — что б такого сделать с компьютерным зрением? (То есть у вас есть функция, а цели нет, и вы думаете, куда б ее можно применить, для каких целей использовать… ну ладно, допустим)
7. Подборка уже существующих референсов приложений с компьютерным зрением
8. Применение двойного бриллианта (хм, ну в том виде как это рассказано, это частный случай V-диаграммы для придумывания)
9. Тестирование одной из концепций в UX-лабе Яндекса
10. Детальные пробы одного из интерфейсов (распознавание объектов на фото)
11. Мысли о режимах использования кадра (решение уравнений, перевод, сканер, etc)
12. Решение проблемы ощущения зависшей камеры — параллакс
13. “Выходить за рамки, но в рамках того, что уже сделано” (что? Разверните мысль, пожалуйста)
14. Статистика “что загружают в умную камеру”
15. Варианты обвеса результата поиск по фото, на примере авто
16. Аналогичные решения для фотографий еды и продуктов питания
17. Прочие нюансы отображения результата и его обвеса
18. Заключение:
- Mood board помогает выбрать стиль,
- двойной бриллиант позволяет выйти за рамки (как он помогает? И за рамки чего?),
- дизайнер должен влиять на продукт на каждом этапе (помимо того, что это очевидно, ничего не было сказано про сами этапы).
В целом доклад показался очень поверхностным, а скорее даже рекламой приложения яндекса и этой конкретной функции; про сложность систем не было сказано ничего.
Системно:
Компьютерное зрение — актуальная развивающаяся технология.
В докладе рассказано о том, для выполнения каких функций (для закрытия каких потребностей клиентов) можно применить такую технологию.
В общем виде технологии поддерживает практики; и было бы интересно узнать какие практики поддерживаются технологией компьютерного зрения. Очевидно, что спектр максимально широкий, так как любе визуальные данные можно поставлять на вход. В докладе речь шла в основном про поиск информации об объекте, это общая практика, входящая в более узкие, про которые было бы здорово услышать в будущем.
———
#проектирование #UX #мероприятия #практика #технология
Компьютерное зрение в сервисах Яндекса
Алексей Белицкий, Яндекс
(Рассказ про функцию “Умная камера” в приложении Яндекса)
1. Компьютерное зрение — ввод данных в компьютер через изображение
2. Для перевода изображения в данные используют алгоритмы, а для улучшения алгоритмов — нейронные сети
3. Сети обучаются через разметку, которую делают люди
4. Одно из актуальных применений — распознавание лиц
5. В Яндексе это применяется для распознавания актеров (Кинопоиск), дополнения составных фото-видео (авто.ру), etc
6. Продуктовые поиски Яндекса — что б такого сделать с компьютерным зрением? (То есть у вас есть функция, а цели нет, и вы думаете, куда б ее можно применить, для каких целей использовать… ну ладно, допустим)
7. Подборка уже существующих референсов приложений с компьютерным зрением
8. Применение двойного бриллианта (хм, ну в том виде как это рассказано, это частный случай V-диаграммы для придумывания)
9. Тестирование одной из концепций в UX-лабе Яндекса
10. Детальные пробы одного из интерфейсов (распознавание объектов на фото)
11. Мысли о режимах использования кадра (решение уравнений, перевод, сканер, etc)
12. Решение проблемы ощущения зависшей камеры — параллакс
13. “Выходить за рамки, но в рамках того, что уже сделано” (что? Разверните мысль, пожалуйста)
14. Статистика “что загружают в умную камеру”
15. Варианты обвеса результата поиск по фото, на примере авто
16. Аналогичные решения для фотографий еды и продуктов питания
17. Прочие нюансы отображения результата и его обвеса
18. Заключение:
- Mood board помогает выбрать стиль,
- двойной бриллиант позволяет выйти за рамки (как он помогает? И за рамки чего?),
- дизайнер должен влиять на продукт на каждом этапе (помимо того, что это очевидно, ничего не было сказано про сами этапы).
В целом доклад показался очень поверхностным, а скорее даже рекламой приложения яндекса и этой конкретной функции; про сложность систем не было сказано ничего.
Системно:
Компьютерное зрение — актуальная развивающаяся технология.
В докладе рассказано о том, для выполнения каких функций (для закрытия каких потребностей клиентов) можно применить такую технологию.
В общем виде технологии поддерживает практики; и было бы интересно узнать какие практики поддерживаются технологией компьютерного зрения. Очевидно, что спектр максимально широкий, так как любе визуальные данные можно поставлять на вход. В докладе речь шла в основном про поиск информации об объекте, это общая практика, входящая в более узкие, про которые было бы здорово услышать в будущем.
———
#проектирование #UX #мероприятия #практика #технология
#дизайн /// 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 #мероприятия #моделирование #коммуникация #требования
#дизайн /// UX-марафон 26-3 — Проектирование сложных систем
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
Как мы проектируем медицинскую систему EMИAC
Дария Потеряхина, Solit Clouds
(Рассказ о процессе проектирования продуктов для системы; с примерами)
1. Solit Clouds разрабатывают продукты для системы ЕМИАС (примерно 70 интерфейсных продуктов, десктоп, планшет, мобильные); другие компании также разрабатывают продукты для ЕМИАС
2. Ключевые особенности разработки медицинской системы:
⁃ Особый нюанс при переносе сценариев с “бумаги” в “цифру”, например, работа с документами
⁃ Количество данных колоссально, необходимо обрабатывать много разнородной информации
3. Далее про процесс разработки в Solit Clouds:
⁃ Бизнес-анализ
⁃ проектирование интерфейсов
⁃ (параллельно с 2 и после) — системный анализ
⁃ описанные результаты из 2 и 3 передаются в разработку
⁃ тестирование
4. Слайд про усложнение этого процесса и взаимосмешивание шагов
5. Коммуникация необходима на каждом шаге и, важно, между шагами
6. Далее про ошибки — распространенные и допущенные:
⁃ Ошибка 1 — неумение грамотно задавать вопросы и задавать грамотные вопросы + нежелание задавать вопросы; + примеры из практики
⁃ Ошибка 2 — НЕфискирование договоренностей; + примеры из практики
⁃ Ошибка 3 — не управлять ожиданиями => не соответствовать им (на самом деле это про критерии приемки)
⁃ Ошибка 4 — не описывать макеты; + слайды с примерами не описанных альтернативных состояний, кейсов, etc
⁃ Ошибка 5 — принятие решений НЕ на основе метрик
⁃ Ошибка 6 — не прорабатывать состояния компонентов
⁃ Ошибка 7 — не прорабатывать альтернативные сценарии
7. Далее про решения, которые переросли в практики:
⁃ Решение 1 — после получения БТ нажначается встреча для обсуждения деталей и нюансов
⁃ Решение 2 — все решения фиксируются (конфлюенс, почта)
⁃ Решение 3 — проговаривается объем, срок и формат представления работ
⁃ Решение 4 — опираемся на результаты исследований и опросов
⁃ Решение 5 — макеты обязательно презентуются, а не просто высылаются
⁃ Решение 6 — интерфейс проектируется вместе с аналитиками и разработчиками
⁃ Решение 7 — в макетах обязательно проработаны состояния компонент, особенно нестандартных
8. Далее несколько слов про удаленный формат — необходимо поддерживать коммуникацию, удаленно она строится иначе; это ответственность руководителей и лидеров.
Доклад показался очень очевидным, интересен скорее тем, кто хочет узнать нюансы профессии, или специалистам на стадии стажёр/джуниор. Отмечу методологический вектор доклада — о том, КАК происходит процесс проектирования, с примерами, что весьма ценно для аудитории на старте. Однако, про сложность систем и как эту сложность уменьшать, ничего сказано не было.
Системно:
Речь идет о том, что сложные системы обеспечивают множество рабочих сценариев (а по факту практик, деятельностей) профессионалов, в том числе работу с документами и большой объем типовых кейсов (тиражирование запусков этой системы в обеспечении).
Процесс разработки — жизненный цикл проекта, и показана его модель в пошаговом (“Водопад”) виде и также очевидная несостоятельность этой модели в системах со многими интеграциями.
Сказано про коммуникацию — это и очевидно, что коммуникация необходима, стоит обозначить, что необходима в разрезе обсуждения интересов (в данном случае интересов проектных и внешних ролей, вместе с их предпочтениями в интересе и намерениями).
Ошибки — неудачные коммуникации, несогласованные методы описания и моделирования, неучтенных кейсы и неудачные верификации. Вполне логично, что они “намотаны на ус” и представлены следов в виде “решений” (а в идеале их упаковать в чеклисты для внутренней валидации).
Слова про удаленный формат это еще раз про коммуникацию и методы описания, которые меняются при изменении взаимодействия с оффлайн на онлайн.
———
#проектирование #UX #мероприятия #метод_описания #коммуникация #ЖЦ
#дизайн /// UX-марафон 26-4 — Проектирование сложных систем
UX-исследования сложных систем: как проводить и выстроить плодотворные отношения с заказчиками
Анна Черныш, ВКонтакте для бизнеса
(Рассказ о том, как устроены исследования в большой бизнесовой платформе)
1. Рассказ будет не про юзабилити, а про UX в целом
2. Почему Реклама VK сложный продукт:
⁃ два продукта — навороченный декстоп для профи-спецов и приложение попроще для мелких общих рекламных задач
⁃ широкая функциональность; много сущностей
⁃ много частей в общем сценарии, составные сценарии и программы сценариев
3. Далее про подход — исследовать на разных уровнях: точечные, быстрые, сквозные
⁃ Точечные исследования — выявляется потребности, восприятие конкурентов, воскр новых фичей, etc
⁃ Сквозные — выявить целиком весь путь через платформу, выявить проблемы переходов между стадиями/модулями платформы, проанализировать ключевые фичи, провести аудит текущего продуктов; такие исследования важно делать постоянно, по сути это постоянный мониторинг взаимодействия пользователя со всей платформой — это требует инициативы исследователей
⁃ Быстрые тестирования — принять решение по конкретному вопросу, фиче
4. Далее про работу с внутренними заказчиками:
⁃ Следить за контекстом — участие в синках, чатах, етс
⁃ Общение даже при наличии подробного брифа
⁃ Построение коммуникации между всеми СХ и участниками
⁃ Инициировать исследования в проблемных точках
⁃ Публиковать позитивные случаи из набор исследований — канал с положительным фидбэком и веселыми историями
⁃ “Живой справочник” по пользователям — живая база знаний или хранитель базы знаний
5. Далее про донесение результатов — это ответственность исследователей:
⁃ Инсайт или проблема до подготовки отчета сразу отправляется в тематический чат
⁃ Разные форматы для отчета — длинный с подробностями и краткий + все инсайты собираются в отдельный CJM
⁃ Обеспечить прозрачность — отчеты и записи (не только отчеты) доступны всей команде и не только заказчикам
⁃ Пересылка инсайтов конкретным людям — на основании знания или гипотезы, что этом человеку пригодится этот инсайт
⁃ Регулярный возврат за фидбэком решена ли проблема
6. Далее про кейсы — точечное и сквозное исследование:
⁃ Кейс точечного исследования — про смещение выбора формата на выбор цели: клиент раньше выбирал формат, а стал выбирать цель, и уже по цели подбирался формат — слайд с программой тестирования; важные нюансы: лучше пойти к респондентам кто еще не рассказывал про это взаимодействие, интервью в начале задает контекст, тестируйте все макеты что есть даже если уже команда склонна выбрать какой-то.
⁃ Кейс сквозного исследования — дневник для новичка, запускающего рекламу в ВК; решение — снятие видео экрана с параллельным комментирование пользователем; какие этапы 1) заманить, было приглашение 2) вводное интервью 3) подробная инструкция 4) сам дневник в видео 5) ответы на вопросы команды, впечатления 6) заключительное интервью — было 10 человек
7. Как писать инструкцию — цели, что требуется, длительность, вознаграждение, все правила участия (в тч про возможность выхода), инструкция как записывать дневник, вопросы для итога
8. Еще нюансы:
⁃ Вознаграждение больше обычного — надо обсуждать с юристами: есть ограничения по величине вознаграждения
⁃ Оплата по этапам — 30% после первого видео, 70% после завершения + многие соглашались в тч из-за возможности пообщаться с командой и получить консультацию
⁃ 20% не дошли до конца
⁃ Просмотр и вопросы надо просматривать сразу же после получения от респондента, чтобы нюансы уточнить у него пока она помнит
⁃ Саммари (от респондента) помогает запустить рефлексию, самоописание эмоций работает плохо, люди не склонны описывать свои эмоции
UX-исследования сложных систем: как проводить и выстроить плодотворные отношения с заказчиками
Анна Черныш, ВКонтакте для бизнеса
(Рассказ о том, как устроены исследования в большой бизнесовой платформе)
1. Рассказ будет не про юзабилити, а про UX в целом
2. Почему Реклама VK сложный продукт:
⁃ два продукта — навороченный декстоп для профи-спецов и приложение попроще для мелких общих рекламных задач
⁃ широкая функциональность; много сущностей
⁃ много частей в общем сценарии, составные сценарии и программы сценариев
3. Далее про подход — исследовать на разных уровнях: точечные, быстрые, сквозные
⁃ Точечные исследования — выявляется потребности, восприятие конкурентов, воскр новых фичей, etc
⁃ Сквозные — выявить целиком весь путь через платформу, выявить проблемы переходов между стадиями/модулями платформы, проанализировать ключевые фичи, провести аудит текущего продуктов; такие исследования важно делать постоянно, по сути это постоянный мониторинг взаимодействия пользователя со всей платформой — это требует инициативы исследователей
⁃ Быстрые тестирования — принять решение по конкретному вопросу, фиче
4. Далее про работу с внутренними заказчиками:
⁃ Следить за контекстом — участие в синках, чатах, етс
⁃ Общение даже при наличии подробного брифа
⁃ Построение коммуникации между всеми СХ и участниками
⁃ Инициировать исследования в проблемных точках
⁃ Публиковать позитивные случаи из набор исследований — канал с положительным фидбэком и веселыми историями
⁃ “Живой справочник” по пользователям — живая база знаний или хранитель базы знаний
5. Далее про донесение результатов — это ответственность исследователей:
⁃ Инсайт или проблема до подготовки отчета сразу отправляется в тематический чат
⁃ Разные форматы для отчета — длинный с подробностями и краткий + все инсайты собираются в отдельный CJM
⁃ Обеспечить прозрачность — отчеты и записи (не только отчеты) доступны всей команде и не только заказчикам
⁃ Пересылка инсайтов конкретным людям — на основании знания или гипотезы, что этом человеку пригодится этот инсайт
⁃ Регулярный возврат за фидбэком решена ли проблема
6. Далее про кейсы — точечное и сквозное исследование:
⁃ Кейс точечного исследования — про смещение выбора формата на выбор цели: клиент раньше выбирал формат, а стал выбирать цель, и уже по цели подбирался формат — слайд с программой тестирования; важные нюансы: лучше пойти к респондентам кто еще не рассказывал про это взаимодействие, интервью в начале задает контекст, тестируйте все макеты что есть даже если уже команда склонна выбрать какой-то.
⁃ Кейс сквозного исследования — дневник для новичка, запускающего рекламу в ВК; решение — снятие видео экрана с параллельным комментирование пользователем; какие этапы 1) заманить, было приглашение 2) вводное интервью 3) подробная инструкция 4) сам дневник в видео 5) ответы на вопросы команды, впечатления 6) заключительное интервью — было 10 человек
7. Как писать инструкцию — цели, что требуется, длительность, вознаграждение, все правила участия (в тч про возможность выхода), инструкция как записывать дневник, вопросы для итога
8. Еще нюансы:
⁃ Вознаграждение больше обычного — надо обсуждать с юристами: есть ограничения по величине вознаграждения
⁃ Оплата по этапам — 30% после первого видео, 70% после завершения + многие соглашались в тч из-за возможности пообщаться с командой и получить консультацию
⁃ 20% не дошли до конца
⁃ Просмотр и вопросы надо просматривать сразу же после получения от респондента, чтобы нюансы уточнить у него пока она помнит
⁃ Саммари (от респондента) помогает запустить рефлексию, самоописание эмоций работает плохо, люди не склонны описывать свои эмоции
#дизайн /// 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 #мероприятия #функция #модуль #сервис
#дизайн /// 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 #мероприятия #практика #менеджмент #исследования #роли
#дизайн /// Требования в UI-задачах
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.