Перевёл Андрей Третьяков 9–19 января 2016 (в продолжение статьи «Дизайн, ориентированный на пользователя»).

От концепта к продукту

Дайте определение своему приложению

Определение приложения — это краткое, концентрированно чёткое заявление о том, какова главная цель приложения и кто его целевая аудитория.

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

Шаг 1. Составьте список всех фич, которые, по вашему мнению, могут понравиться пользователям вашего приложения

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

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

• составление списков;
• получение рецептов;
• сравнение цен на продукты;
• нахождение адресов продуктовых магазинов;
• оставление примечаний под найденными рецептами;
• возможность найти скидочные купоны и воспользоваться ими;
• просмотр видео с примерами готовки того или иного блюда;
• возможность изучать кухни различных народов мира;
• возможность находить замену тому или иному ингредиенту.

Шаг 2. Определите, кто является пользователем вашего приложения

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

• обычно готовят дома — или предпочитают уже готовые блюда?
• приверженцы использования купонов — или же считают купоны ерундой, с которой и смысла нет связываться?
• испытывают удовольствие, отыскивая какой-то нетипичный, особый ингредиент, — или редко выходят за рамки типовых ингредиентов?
• строго следуют последовательности действий, указанной в рецепте, — или используют рецепты как вдохновение, «отправную точку»?
• покупают понемногу, но часто — или «затариваются по полной», но редко?
• хотят иметь доступ сразу к нескольким спискам для разных нужд — или просто хотят не забыть о паре-тройке вещей, которые нужно купить один раз по пути домой?
• отдают предпочтение только какой-то конкретной торговой марке — или вполне обходятся любой наиболее доступной альтернативой?
• обычно покупают примерно одинаковый набор продуктов каждый раз — или предпочитают покупать строго лишь те ингредиенты, которые перечислены в рецепте?

После того, как вы достаточно долго и вдумчиво посидите, размышляя над этими вопросами, представьте, что вам теперь требуется отобрать только 3 характерные особенности, наилучшим образом описывающие вашу целевую аудиторию. Для нашего с вами примера, пусть это будут следующие черты:

• любят экспериментировать с рецептами;
• всегда в спешке, когда покупают продукты;
• бережливы по мере возможности (если не нужно тратить много усилий, чтоб сэкономить).

Шаг 3. Отфильтруйте ранее составленный перечень фич с помощью характерных черт, присущих целевой аудитории вашего приложения

Если вы составили список, лучше всего отражающий суть вашей целевой аудитории (ЦА), и пропустили через него подготовленный список фич, и в результате всего этого у вас осталось всего 2–3 фичи, ценных для выбранного сегмента ЦА, — знайте: так и должно быть, вы на верном пути. Помните: наиболее успешные iOS-приложения обладают предельно чёткой сфокусированностью на задаче, помочь с которой пользователю они призваны.

Так, например, рассмотрим длинный перечень потенциальных фич для нашего приложения покупок, который мы составили на шаге 1 (см. выше). Несмотря на то, что все эти фичи могут быть полезны в контексте того или иного приложения для покупок, — именно для нашего приложения, нацеленного на сегмент ЦА, определённый на шаге 2 (выше), пригодятся далеко не все из перечисленных фич.

Когда вы проанализируете список фич в свете установленного сегмента ЦА, вы можете прийти к заключению: такое приложение должно быть сосредоточено вокруг трёх основополагающих фич:

• составление списков;
• получение и использование скидочных купонов;
• получение рецептов.

И вот теперь вы можете сформулировать окончательное определение своего приложения, в котором предельно чётко говорится, что делает ваше приложение и для кого. В нашем случае подойдёт такая формулировка:

“Инструмент для создания списка покупок для бережливых людей, обожающих готовить.”

Шаг 4. Не останавливайтесь на достигнутом

В дальнейшем используйте сформулированное определение приложения на протяжении всего процесса его разработки. Оно подскажет вам, насколько приемлемыми будут для него те или иные фичи, элементы управления (контролы) и терминология. Например:

Когда вы решите добавить в приложение новую функцию, сначала спроси́те себя, является ли выбранная фича жизненно необходимой в свете основной задачи вашего приложения для выбранного сегмента ЦА. Если окажется, что она не является критически необходимой, то лучше не добавляйте её в приложение; но, в то же время, она может лечь в основу какого-то другого приложения (но не того, над которым вы сейчас работаете).

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

Когда вы продумываете внешний вид и поведение интерфейса, спроси́те себя, будет ли вашим пользователям больше по душе простой и изящный UI — или более необычный. Руководствуйтесь своим представлением о том, в процессе какой деятельности будут находиться люди, использующие ваше приложение в качестве подходящего инструмента — например: будут выполнять какую-то серьёзную задачу, искать и получать быстрый ответ на интересующий вопрос, глубоко вникать в какой-то исчерпывающий материал, или же просто хотят развлечься. Так, например, хоть ваше приложение для списка покупок должно быть простым для понимания и быстрым в использовании (не должно быть ничего лишнего, что мешает за минимальное количество действий выполнить целевую задачу), ваши пользователи, вероятно, будут рады видеть в нём элементы кастомного UI, в котором есть место большому количеству замечательных изображений ингредиентов и готовых блюд.

Когда вы решаете, какую терминологию использовать в приложении, стремитесь привести в соответствие опыт вашей ЦА с темой приложения. Например, хоть ваша аудитория может и не состоять полностью из искусных шеф-поваров, вы вполне можете быть уверены, что ваши пользователи захотят видеть соответствующую терминологию применительно к ингредиентам и способам приготовления.

Адаптируйте кастомизацию пользовательского интерфейса приложения к задаче, выполняемой с его помощью

Разработчики лучших iOS-приложений, занимаясь кастомизацией их интерфейса, стремятся сохранить разумный баланс между ясностью, понятностью цели приложения и простотой его использования.

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

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

Например, представьте себе приложение-калькулятор, которому присущ замысловатый художественный стиль и кнопки в котором расположены не стандартным образом, а в угоду неким творческим пожеланиям. Тщательно отрисованная картинка-подложка и нестандартное расположение кнопок, конечно, не являются для пользователей критическим препятствием при понимании, как нажать на кнопки такого калькулятора и как прочесть результат вычислений. Но людей, которым просто нужно выполнить свою работу, такой подход к «новизне» применительно к обычному калькулятору быстро разочарует, а красота необычного интерфейса станет лишь помехой в работе.



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



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

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

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

Будьте последовательны внутри приложения. Чем более нестандартен интерфейс вашего приложения, тем более важно обеспечить последовательность, непротиворечивость внешнего вида и поведения этих нестандартных элементов везде в вашем приложении. Если уж вы ввели какой-то нестандартный UI, и пользователь потратил время на его изучение, то везде в аналогичных местах своего приложения используйте этот же UI.

Дизайн не должен мешать контенту. Поскольку стандартные элементы интерфейса так знакомы пользователям, они не конкурируют с контентом приложения за внимание пользователя. Если вы приняли решение использовать нестандартные элементы интерфейса, позаботьтесь о том, чтобы эти кастомные элементы не оставляли в тени важный пользователю контент, чтоб не перетягивали на себя внимание.

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

Дважды задумайтесь перед тем, как переделывать стандартный элемент. Так, если вы собрались значительно переделать стандартный элемент UI, обязательно убедитесь, что ваш переделанный элемент несёт в себе столько же необходимой информации, сколько и стандартный.

Например, если вы делаете переключатель «вкл/выкл», из которого непонятно, что кроме текущего его положения есть ещё и противоположное, люди могут не понять, что это именно двухпозиционный переключатель.

Уделите внимание тщательно пользовательскому тестированию нестандартных элементов UI, раз уж вы их ввели в приложение. В процессе тестирования внимательно наблюдайте за пользователями:

• получается ли у них предугадывать, что делают ваши нестандартные элементы UI?
• можно ли назвать лёгким их взаимодействие с этими элементами?

Если, например, вы делаете элемент управления с площадью касания менее, чем 44×44 точки, пользователи непременно испытают трудности, пытаясь нажать на такой элемент, так как он слишком маленький. Или если по тапу будет происходить то, что обычно происходит по свайпу (и наоборот), то пользователям придётся помучиться, привыкая, что в рамках вашего приложения эти действия активируются противоположным образом.

Делайте прототипы и итерируйте

Перед началом собственно разработки дизайна приложения стоит заняться созданием прототипов для пользовательского тестирования. Даже если вам удастся привлечь для такого тестирования всего пару коллег, у вас уже будет преимущество в том, что кто-то свежим глазом взглянул на функционал и UX вашего приложения.

На самых ранних этапах работы над приложением вы можете использовать бумажные прототипы или электронные мокапы, чтобы прикинуть, как будут располагаться основные экраны и элементы управления, а также набросать карту переходов в соответствии с базовыми флоу пользователя. Конечно, благодаря такому подходу вы полу́чите определённое количество полезных отзывов, но будьте готовы к тому, что «разреженность», фрагментированность таких прототипов может ввести испытуемых в заблуждение. Это потому, что простым людям трудно представить, как изменится опыт взаимодействия с приложением, когда мокапы превратятся в реальное приложение с настоящим контентом.

Вы сможете получить более ценные отзывы и предложения, если превратите электронный или бумажный мокап в базовую версию прототипа, который можно запустить на iOS-устройстве (про такие прототипы ещё говорят «без эмоционального наполнения»). Ведь в том случае, если человек может «поиграть» с прототипом на настоящем, физическом устройстве, то, без сомнения, тогда он с большей вероятностью обнаружит такие места в вашем приложении, где оно не работает так, как он ожидает, или где взаимодействие приложения с пользователем устроено чересчур сложно и запутанно.

Самый простой способ сделать надёжный прототип, подходящий под указанные выше требования, — использовать в Xcode основанный на storyboard шаблон, чтобы сделать базовый каркас, и наполнить его надлежащими плейсхолдерами, соответствующими тем или иным элементам дизайна вашего приложения. (Storyboard-файл хранит в себе UI вашего приложения целиком, включая переходы между различными экранами.) Затем установите такой прототип на iOS-устройство, чтоб первая группа тестовых пользователей могла получить как можно более реалистичный опыт взаимодействия с вашим приложением (в данном случае — с его прототипом).

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

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

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

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

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

Оригинал статьи доступен по этой ссылке.