Post #464

Как согласовать интерфейсы. Ну ладно, мы разобрались, что, когда пользователь впервые видит интерфейс будущей системы, он не воспринимает это, как финальную версию — а скорее как повод наконец-то подумать, как оно на самом деле будет работать (если вы, конечно, заранее не прорабатывали именно процесс решения задачи, а просто "собирали требования"). Но, допустим, первое впечатление уже получено, и уточняющие требования собраны, и всё уже дважды переделано и вроде мы дошли до стадии утверждения интерфейсов. И с этим очень часто возникают большие проблемы. Они возникают у аналитиков, у дизайнеров и иногда даже у продактов, как ни удивительно. Потому что вместо того, чтобы подтвердить и согласиться, стейкхолдеры в очередной раз начинают просить передвинуть кнопку, добавить ещё пару полей и поиграть со шрифтами. И конца этому не видно. Что здесь обычно происходит? А происходит неуправляемая встреча. Как такая встреча может быть устроена? ❌ Дизайнер или аналитик просто показывает экран системы. Ну вот мы сделали вот такой экран, есть к нему замечания? Это прямо мощная подача — ведь если стейкхолдер скажет "нет", это может значить, что он что, не заинтересован в системе? Или не успел разобраться, и это сейчас замечаний нет, а потом появятся? Дали ли мы время на то, чтобы ознакомиться? Знаем ли мы сами — каких замечаний мы от этого стейкхолдера хотим услышать? Ещё хуже вопрос "вам нравится?" Тут мы полностью снимаем с себя ответственность и отдаемся в руки человека на другой стороне. Так быть не должно. Эксперты здесь мы. Мы спроектировали всё правильно — красиво, удобно и логично, и мы за это отвечаем. Не нужно перекладывать решение на человека, который в нём не специалист. ❌ Аналитик показывает экран и начинает рассказывать последовательно про каждый элемент. Не надо так. Люди видят, что нарисовано на прототипе. И понимают, для чего каждый элемент нужен. А если не понимает — кажется, у нас есть проблема. Вот только объяснение делу не поможет — ведь в реальной жизни аналитика или дизайнера рядом не будет, чтобы объяснить, что тут зачем. А визуально человек воспринимает информацию гораздо быстрее, чем на слух. Пока вы рассказываете про каждый элемент, ваш визави уже рассмотрел весь экран, и теперь скучает. ✔️ Как правильно построить презентацию интерфейсов: 1. Рассказать, для каких пользователей создан этот интерфейс (для какой роли или персоны) и в какой ситуации этот пользователь находится, когда использует этот интерфейс. 2. Перечислить сценарии, которые пользователи могут выполнить при помощи этого интерфейса. Обычно есть 1-2 основных сценария и дополнительные, куда входят граничные ситуации, альтернативы, исправления и настройки. 3. Демонстрация прохождения сценария пользователем с какой-то ролью. В качестве пользователя выступает аналитик, либо это предлагается сделать одному из согласующих. Сценарий показывается по шагам, при переходе с одного шага на другой можно спросить у зрителей — понятно ли, как перейти к следующему шагу (как вернуться на предыдущий, как исправить что-то или посмотреть дополнительную информацию). Это закрытый вопрос, он предполагает ответ "да"/"нет". Если на этапе разработки требований вы задавали в основном открытые вопросы, на этапе согласования лучше задавать закрытые вопросы. Теперь это не рассуждения, это вопросы на констатацию факта. Задаем конкретные вопросы — понятен ли этот переход, ясно ли, где мы сейчас, что тут самое важное, где ошибка. Все вопросы на уточнение и выяснение вы, надеюсь, задали заранее. Если стейкхолдер стремится высказать своё замечание, возвращайте его в ту же схему: про какую роль он говорит? В какой ситуации? Какая цель у пользователя? Что он делает? Что происходит, и что он ожидал? Часто оказывается, что либо ситуация надуманная и так не бывает, либо в сознании у критика спутаны несколько ролей, либо, возможно, мы действительно пропустили какую-то важную ветвь сценария. Конечно, про формат нужно предупредить участников заранее. Описание контекста, ролей пользователей и сценариев для демонстрации заранее отправить. И про формат обратной связи рассказать.