Комментарии 5
Было бы очень интересно каждый пункт рассмотреть на примере. Как человеку, далёкому от проектирования интерфейсов (но которому приходиться проектировать интерфейс) мне не очень понятно о чем идёт речь и как мне это использовать.
Ожидание понятно, но боюсь, что просто примеров будет недостаточно. Это надо писать с детальными объясненинями, а это уже может превратиться в учебное пособие. А до такого я еще не созрел.
Насколько я понимаю, ты на разных стадиях проектирования создаёшь у себя представление о том, как элементы/интерфейс/взаимодействие разных частей программы должно выглядеть и иллюстрируешь это в виде графиков и деревьев.
Однако я ни одного интерфейса так и не спроектировал и поэтому эту теорию что я выложил мне ещё предстоит проверить на практике.
Основная идея в том, что перед тем, как спроектировать интерфейс нужно пройти еще каки-то шаги. И когда хочется включить в работу команду, чтобы получить синергию участников, то нужны промежуточные артефакты, которые можно обсуждать и которые обеспечивают разную степень детализации проекта. И все вместе обеспечивает надежный результат.
Я конечно понимаю что есть гугл (и сам им только что воспользовался), но все-таки нехорошо писать аббревиатуру без расшифровки (я про KPI).
Кстати, в ней K соответствует Key, так что "ключевые KPI" как масло масленое получается (но это уже придирка)
7 артефактов проектирования, которые улучшат дизайн