Комментарии 4
На моменте с Дейенерис - просто в голос... У меня до сих пор такое лицо, когда приходят десятые правки по макету (я веб-дизайнер). Но ты же профессионал, ты не должен показывать эмоций. Ты должен быть психологом. Жиза.
Вообще полезное разъяснение. Я бы, кстати, поработала с таким спецом. Но пока самой приходится тексты писать для своих интерфейсов.
Спасибо, было интересно.
В идеале процесс работы над проектом выглядит следующим образом. ...
Выглядит монструозно.
Продакт-менеджер придумывает идею нового продукта и получает её одобрение от руководителей.
Самое интересное слово здесь — это "придумывает". Было бы проще "брать" приложения уже из готового хранилища приложений ("всё, что называется новым, уже дано придумано до нас"). Если бы у фирмы была своя специализация, то имелись бы готовые модули.
Затем он несёт эту идею UX-редактору и UX-дизайнеру, после чего они втроём составляют User flow – визуализированный сценарий действий пользователей в приложении или на сайте, которые позволяют юзеру достичь его цели (например, запросить выписку по счёту или открыть вклад). Зачастую этот сценарий представляет собой систему прототипов окон и блоков, на каждом из которых неизбежно находится какой-то поясняющий текст. На этом этапе UX-редактор уже видит всю картину целиком и понимает, для каких элементов нужно будет писать текст.
Почему зразу в UX? Кажется, что визуализация — это последнее священнодейство, которое должно произойтив этой цепочке. Здесь нужен системный аналитик, который укажет все рабочие части и распишет все алгоритмы.
После обсуждения и утверждения прототипов у продуктолога UX-редактор пишет тексты, а дизайнер рисует макеты. При этом в команде ведётся постоянное обсуждение того, как будут согласовываться между собой текст и визуализация.
Значит, если текст по какой-либо причине будет ошибочным, то работа над макетом может довольно долго крутиться вокруг-да-около.
Готовый макет отправляется на UX-исследование.
Здесь происходит ещё одна ошибка: пользователям предлагается некое наилучшее решение. А у пользователя должна быть возможность самому выбирать способ взаимодействия с информацией. Например, одну и ту же форму заполнения можно разложить на одной странице, а можно растянуть на целый мастер, где на каждой отдельной странице отображается свой обозримый и управляемый блок информации.
«Почему заполнение этого поля вызвало у вас трудности?», «Хватило ли вам информации об условиях вклада в этом окне?», «Понятно ли назначение этой кнопки с первого взгляда? Ясно ли, что произойдёт после её нажатия?»
Немного странные вопросы. Их может задать разработчик сам себе. И так же сам себе доблесно ответить.
Вопрос следовало бы поставить противоположным образом: если нам нужно получить от пользователя такую-то информацию, какой элемент управления мы должны предложить для этого. Традиционная ошибка заключается в использовании некоторого довольно ограниченного круга элементов пользовательского интерфейса. А для каждый задачи должен создаваться свой элемент управления.
Иногда, крайне полезным может быть возможность "холостого" хода по интерфейсу, когда берутся фикстивные данные, и пользователь привыкает к заданному поведению. Не говоря, уж, об анимации, которая может сигнализировать (вне завистимости от языка пользователя) о том, какое поведение скрывается за каждым элементом.
Затем может следовать ещё несколько корректировок от ответственных за продукт лиц, например юристов, и все их необходимо обсуждать с командой и вносить те или иные правки в текст и макет.
Эти вопросы должны решаться ещё на этапе системного анализа и построения потока управления. Внесение изменений потребует отката на довольно раннюю статидию разработки продукта.
После одобрения макет уходит в продакшн.
Не в продакшен, а в саппорт. Ибо всё, о чём забыли подумать, будет постоянно всплывать при реальном использовании продукта. Между тем, кажется, что наилучший продукт — это такой продукт, который не надо поддерживать, ибо он работает, как ему и предписано.
Не только тексты для кнопок: чем занимается UX-редактор