Как создать продукт, который полюбят - читать онлайн книгу. Автор: Скотт Херф cтр.№ 35

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна-две недели — хорошее время, чтобы прийти с качественными идеями и реализовать их без лишних наворотов и крутизны. Его вполне достаточно, чтобы остановиться, выдохнуть и принять продуманное решение, но и не слишком много, чтобы бездумно его тратить.

Важно, чтобы вся команда была вместе и заодно. Одна из самых больших проблем в том, что членов команды набирают из других проектов и они могут уделять спринту то тут, то там по одному часу. Но вы либо садитесь на автобус, либо нет.

Как вы считаете, прототипы помогают создавать лучшие идеи?

Конечно. Все, что заставляет проговаривать и организовывать мышление, помогает определить сильные и слабые стороны, возможности, угрозы. Самое классное в быстрых прототипах то, что они учат забывать об эго в работе, так как процесс занимает гораздо меньше времени, чем обычно.

Быстрое прототипирование позволяет находить эффективные идеи, потому что это инклюзивный процесс. Все люди, вовлеченные в него, могут внести посильный вклад. Конечно же, необходима многодисциплинарная и прагматичная команда, так как сохраняется опасность угодить в ловушку дизайна, но в целом я работал и в команде из двух человек, одним из которых был я, и в команде с сорока членами — и результат всегда был успешным.

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

Довольно часто я в буквальном смысле менял дизайн посреди дискуссии и спрашивал: «Вы это имеете в виду?». А затем мы его тестировали и обсуждали. Это сэкономило часы и дни, которые иначе пришлось бы потратить на написание электронных писем, встречи, дополнительные обсуждения и дебаты.

Благодаря предложениям клиентов, дизайнеров, разработчиков, менеджеров продуктов, маркетологов и бизнес-команд мы находили более крутые и эффективные пути. Моя роль изменилась: от дизайнера, «презентующего идею сидящим в комнате», я перешел к фасилитации и лидерству в UX-дизайне — я подключал свой опыт и высказывал профессиональное мнение, когда требовалось принять определенное решение. Я постоянно тестировал идеи, отталкиваясь от цели и запросов пользователей, для которых все это разрабатывалось.

Работа в команде помогала не-дизайнерам лучше понять, почему принимаются те или иные решения, а дизайнерам — почему необходимы те или иные бизнес- и инженерные решения для изменения продукта ^[113].