Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
Flash, который сейчас Adobe Animate поддерживает публикацию в html5.
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Тоже не вижу причин, описывайте Хаск-модель в формате BPMN, вам никто не запрещает. Если всей команде будет понятно, кто же вас отговорит от этого.
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
В схеме bpmn есть: клиент —> принятие заявки —> регистрация заказа —> принятие оплаты —> доставка —> закрытие заказа.
В ioHasC: Получить данные от пользователя —> Проверить наличие товара —> Получить оплату от пользователя —> Доставить товар
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
да, пишите в личку