Скотт Хёрф - Как создать продукт, который полюбят

Еще я бы выяснил, пытаемся мы создать что-то сфокусированное на конкретном пользователе или ориентируемся на всех. Иногда важно сконцентрироваться только на одном пользователе в особом контексте; а иногда мы должны принимать во внимание всех, кто вовлечен, и показать им преимущества и выгоды. Я бы всегда разрабатывал продукт для всех, но в системе с пользовательским лицом и лицом администратора понимание того, что вы делаете продукт для потребителя, помогает сконцентрироваться и там, где необходимо, ссылаться на расширение до уровня администратора, не создавая под него отдельного дизайна.

Мне нравится разбираться, что станет успехом для обеих сторон – и для бизнеса, и для пользователя, – чтобы иметь возможность задать стандарты во всем, что я делаю.

Кроме того, я провел бы интервью с конечным потребителем, для которого мы разрабатываем продукт, сохраняя непредвзятость и уделив внимание его рабочим потокам. Тот способ, который помогает мне использовать обратную связь, чтобы создавать Пользовательское Чувственное Путешествие, детализированный поток целостного , а не только цифрового опыта.

И наконец, поверх старого я создал бы новый сценарий (чтобы обозначить выгоды, например – меньше шагов или меньше вариантов). Я бы обозначил цветом, какие экраны необходимы. Так команда поймет, где в масштабном опыте будет находиться цифровой.

Все это я делаю еще до того, как сажусь за компьютер и начинаю что-либо рисовать.

Насколько функциональными вы делаете свои прототипы? Сценарий целиком? Конкретную анимацию?

Зависит от ситуации. Мне нравится создавать сценарий целиком, чтобы рассказать историю. История позволяет продемонстрировать варианты пользовательского пути, продать преимущества и одновременно установить эмоциональную связь с пользователем / заказчиком. Одной функции вполне достаточно, если все участники процесса хорошо понимают (как преданная продуктовая команда), как она улучшает продукт, но если команда не в курсе, то это выпадет из контекста и не будет оценено по достоинству. Это то же самое, как если бы я пытался показать вам преимущества кедровых окон в доме, в котором вы даже не были. А теперь сравните с тем, если бы вы в этом доме были.

Когда в процесс включается разработчик? Как это выглядит?

Мне нравится, когда в моей команде есть многопрофильный инженер. Для меня идеальная команда – это менеджер проектов, UX, UI, многопрофильный техлид / инженер при условии, что они все понимают роли друг друга (например, менеджер проектов должен понимать азы кода, дизайнер должен обладать навыками UX, все должны хорошо коммуницировать между собой и демонстрировать баланс коммерческого прагматизма и технической работы).

Чаще всего (за редким исключением) инженеры – самый крупный и лучший источник дизайнерских предложений просто потому, что они уже обладают знанием «А что будет, если мы сделаем это» и «Почему это должно быть разработано именно в таком виде?». Это неоценимый ресурс для получения обратной связи в режиме реального времени, позволяющий понимать, как может работать функционал. Обычно я что-то создаю и затем передаю инженеру, спрашивая: «А что, если сделать вот так?». Это действительно очень хорошо дает им понять, как я думаю, чего пытаюсь достичь, и на основании этого они могут предлагать варианты, строить предположения и предоставлять поддержку.

Кому и когда вы показываете разработку – внутри компании или клиенту? Как работает обратная связь?

Зависит от уровня взаимоотношений с клиентом, но в целом мне нравится сначала сделать, а потом идти за одобрением. У меня есть очень успешные примеры работы с клиентами: например, с применением таких инструментов, как InVision, особенно когда работы много и клиент хочет быть максимально вовлечен, быть в курсе и видеть прогресс. Многие клиенты активно вовлекаются в процесс дизайна, что всегда позволяет сделать более совершенный продукт и легче его продавать.

Как результат – все замотивированы и чувствуют себя профессионалами, частью команды, все ответственны за свой вклад.

Сколько времени обычно занимает стандартный процесс?

Я делал быстрые прототипы и за 24 часа, и за три месяца. Вообще, чем длиннее временной отрезок спринта, тем сложнее сохранить импульс. Это же спринт, в конце концов. Но на деле, чем сложнее проект, тем больше деталей нам необходимо знать о пользователях и их поведении, а на это требуется время.