Spec-Zone .ru
спецификации, руководства, описания, API

Библиотека Разработчика iOS

Разработчик

Инструкции по Интерфейсу пользователя iOS

iBook

От понятия до продукта

Определите свое приложение

Оператор определения приложения является кратким, конкретным объявлением основной цели приложения и ее целевой аудитории.

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

1. Перечислите все функции, Вы думаете, что пользователям могло бы понравиться

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

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

  • Создание списков

  • Получение рецептов

  • Сравнение цен

  • Определение местоположения хранилищ

  • Аннотирование рецептов

  • Получение и использование купонов

  • Просмотр демонстраций кулинарии

  • Исследование различных кухонь

  • Нахождение замен компонента

2. Определите, кто Ваши пользователи

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

  • Обычно приготовьте дома или предпочтите готовую еду

  • Фиксировавшие купонные пользователи или думают, что купоны не стоят усилия

  • Любите искать для компонентов специальности или редко рискуйте вне основ

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

  • Покупайте мелкие суммы часто или покупайте оптом нечасто

  • Хочу сохранить несколько происходящих списков в различных целях или просто хотеть помнить несколько вещей купить по дороге домой

  • Настаивайте на определенных брендах или сумейте обойтись самыми удобными альтернативами

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

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

3. Пропустите список функций через определение аудитории

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

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

При исследовании списка функций в контексте целевой аудитории Вы приходите к заключению, что Ваше приложение должно фокусироваться на трех основных функциях: Создание списков, получение и использование купонов и получение рецептов.

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

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

4. Не останавливайтесь там

Используйте свой оператор определения приложения в течение процесса разработки для определения пригодности функций, средств управления и терминологии. Например:

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

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

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

Настройка адаптации к задаче

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

Запустите путем рассмотрения задач в приложении: Как часто пользователи выполняют их и при каких обстоятельствах?

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

image: ../Art/fancy_calculator_2x.png

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

image: ../Art/completely_custom_garageband_2x.png

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

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

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

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

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

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

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

Моделируйте и Выполните итерации

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

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

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

Самый простой способ создать вероятный прототип состоит в том, чтобы использовать основанный на раскадровке шаблон Xcode, чтобы создать основное приложение и заполнить его с некоторым надлежащим содержанием заполнителя. (Файл раскадровки получает весь UI Вашего приложения, включая переходы среди различных экранов.) Затем установите прототип на устройстве так, чтобы Ваши тестеры могли иметь максимально реалистический опыт.

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

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