Комментарии 4
Хотелось бы больше прочитать про вашу практику использования различных инструменты для работы с данными, кроме Affinity map:)
А после интервью с экспертами и тестировании собранных прототипов, и полученной обратной связи по ним, на сколько имеет смысл заниматься вот этим всем?
Затем я анализирую, синтезирую и составляю необходимые под конкретную цель артефакты. Для этого использую различные инструменты для работы с данными: Affinity map (Affinity Diagram), User Story, CJM, JTBD, несколько раз составляла Value Proposition, для последующей работы и приоритизации — фреймворк RICE и Метод MoSCoW, а также бинарную приоритизацию.
Разве не выгоднее потратить больше времени на новую итерацию проработки интерфейса исходя из полученной обратной связи, затем протестировать это его еще раз, залатать найденные дыры и завершить свою работу? Или вы так структурируете свою часть работу для других дизайнеров, которые будут потом во всем этом разбираться и делать прототипы?
Спасибо за вопросы
Сперва собирается информация, потом она обрабатывается. Для того, чтобы к ней потом было удобнее вернуться я ее оформляю в нужный мне артефакт. Плюс, с выводами и частями могут работать коллеги (не только дизайнеры), собранную и структурированную информацию легче обсуждать и показывать.
Например, мы проектируем и «новое», от совместных обсуждений и потребностей может зависеть какие методы (это уже про бэк) будут разрабатываться, чтобы нужную информацию можно было вытащить на фронт.
«Вот это все» — наполняется и как раз создается на основе полученных данных. Бывает мы не знаем весь путь пользователя, не знаем один он или несколько, какие они, есть ли условия и ограничения и т.п. Есть истории становления «цифрового» процесса, когда нет «золотого пути», есть ручной процесс, нужна автоматизация, оцифровка и нужно с чего-то начинать. Поэтому все это, можем собрать в одну картину разными методами, но затем это требует обязательной обработки, осознанного подхода. Если не собрать полную картину и не выстроить по важности желания и потребности, а начать сразу собирать макеты, то можно сместить фокус. Как итог сделать «что-то менее нужное для большинства», «менее нужное для системы», что-то что нельзя реализовать, примеров много.
«Залатать дыры и завершить свою работу» — тут вопрос, что считать завершенной работой? Я свои макеты не считаю завершенной работой, это 50% от работы. Мне важно, чтобы пользователи закрыли свои потребности через интерфейс и не попали в тупик. После того, как они закрывают свои потребности, становится важным, чтобы этот процесс был мягким, не сложным, понятным. В идеале мы стремимся максимально учитывать сразу и функциональную завершенность и удобство, но это не всегда достижимо сразу.
Проектирование функционала бэк-офисного продукта на основе практического опыта