описание для мобильного приложения
Как создать идеальное описание приложения для App Store и Google Play
Как правило, приложения выполняют довольно много разных функций от регистрации до terms and conditions. Однако, для описания продукта нам не нужны абсолютно все функции.
Екатерина Абросимова, директор по маркетингу в Yalantis, написала руководство о том, как правильно составлять описание приложения для магазина.
App Definition включает в себя 3 части: название, описание, и скриншоты. Давайте рассмотрим вопрос app definition кратко и более подробно.
Название
В названии должны быть ключевые слова. Без них, пользователям будет сложно найти ваш продукт.
Описание
Скриншоты
Первый скрин — самый важный, здесь нужно описать основную функцию приложения. В описании к скриншотам лучше всего использовать глаголы. Именно они могут наиболее качественно объяснить пользователю, что нужно делать на конкретном экране и подталкивают его к действию. Глагол — самая сильная часть речи.
А теперь подробнее.
1. Как называется ваш продукт? Зачем он нужен?
Чаще всего, у продукта какое-то абстрактное название, которое совсем не намекает пользователю на то, для чего он предназначен. Поэтому в полное название для апп стора должно входить прямое предназначение приложения. Это важно не только для улучшения понимания продукта, а в первую очередь, для того, чтобы пользователи могли найти ваш продукт и скачать его.
Предназначение продукта — это ключевое слово, по которому пользователи находят приложение в апп сторах или google. Забив в google «app development company» мы найдем Yalantis, потому что наше полное название — Yalantis is a native iOS and Android app development company.
А если мы загуглим travel app, то поиск выдаст нам TripIt (с полным названием TripIt Travel Organizer — Free), TripAdvisor (TripAdvisor Hotels Flights Restaurants), TripCase (TripCase — Travel Organizer) и прочие приложения туристической тематики.
Возьмем, к примеру My Day. Его название на апп сторах звучит так:
My Day — Countdown Timer
Именно countdown timer, countdown app в данном случае, ключевое слово, по которому наше приложение находят пользователи.
Flipboard: Your Social News Magazine
Четко и понятно зачем нам нужен Flipboard, и сразу 3 ключевика: news, social и magazine.
Один из наших недавних проектов, Vochi, назвается на App Store:
Vochi messaging — Future Delivery
В данном случае, мы даем понять пользователю не только то, что это месенджер, а и его преимущество перед похожими продуктами.
Вот еще примеры названий продуктов, которые акцентируют внимание пользователя на своем отличии от других подобных приложений:
В названии приложения допустимо иметь максимум 25 символов. Если слов будет больше, в поиске их просто не будет видно.
Теперь приступим к составлению описания для апп стора.
2. Как написать описание продукта?
1. Правила
Стараясь описать приложение для апп стора как можно лучше, необходимо соблюдать следующие правила:
Описание желательно писать от второго лица, с точки зрения того, как пользователь будет использовать продукт.
Для того, чтобы составить дельное описание, нужно четко ответить на следующий вопрос.
2. Какие функции выполняет ваше приложение?
Как правило, приложения выполняют довольно много разных функций от регистрации до terms and conditions. Однако, для описания продукта нам не нужны абсолютно все функции. Достаточно выделить несколько основных, и одну самую важную. Важная функция — это ваше value proposition, конкурентное преимущество и позиционирование вашего продукта на рынке.
Если ваше приложение позиционируется, как лучший блокнотик — сосредоточьтесь на этом функционале. Лучше говорить об одном специфическом use case, чем рассыпаться мыслями по древу обо всех фичах, которые вы вложили в продукт.
Для нашего My Day, самая важная функция — countdown clock with reminder. Другие функции, перечисленные в описании, это обои, праздники, виджет, настройки цвета и стиля, и единицы времени, которые аппа способна высчитывать. Мы позиционируем My Day как красивый и удобный продукт, и в этом его ценность.
3. Из чего состоит описание?
Повествование о приложении для апп сторов можно разделить на 5 частей:
4. 255 первых символов
255 символов появляются на странице сразу, то есть пользователю не нужно нажимать на кнопку, чтобы читать дальше. Именно этот текст больше всего влияет на решение пользователя скачать приложение. Здесь мы описываем самую важную функцию, или как говориться, value proposition.
Начните с сильного, четкого предложения которое объясняет, зачем пользователю приложение и почему оно крутое. Опишите проблему и скажите, как ваше приложение ее решает. Если проблемы на первый взгляд нет, создайте ее.
Иногда проблема, которую решает приложение, очевидна. Например, для фитнес приложения — это возможность брать тренировки с собой и заниматься физкультурой где душе угодно. Для дейтинговых апп, matching на основе технологии face recognition увеличивает шансы пользователя встретить свою половину. Социалочка для механиков дает им возможность обсудить аккумулятор не выходя из гаража. Приложение для недвижимости — счастливое освобождение от несговорчивых риэлторов и траты времени впустую.
Даже если твой продукт носит развлекательный характер, к его описанию тоже можно подойти с точки зрения проблемы и ее решения. Давате посмотрим на Vine, приложенько для смешных видосов.
Vine is the entertainment network where videos and personalities get really big, really fast.
Здесь создатели акцентируют внимание на том, что и ты, и твое видео быстро станете популярными, что очень важно для целевой аудитории Vine.
А дальше идут такие слова:
Watch videos that create trends, influence culture and make you laugh. Discover stories, characters and remixes you can’t find anywhere else. Be the first to hear incredible new artists and songs.
Ну все, тут меня уже окончательно купили. Я и тренд могу создать, и посмеяться, и вообще, там есть stories you can’t find anywhere else, то есть Vine — уникальное предложение.
И заметьте, watch videos, discover stories, new artists and songs — это явно ключевики, правильно вставленные в контекст.
Однако, бывает и так, что проблема не очевидна. Например, Uber и Instacart — это продукты, созданные ради комфорта. Когда их только выпустили, пользователи и сами не знали, что у них была проблема, которую эти ребята хотели решить. Но теперь-то знают!
Rewind Time Tracking app: The best time tracking solution is the one you don’t even have to think about. Rewind automatically tracks your time based on your location. You just have to set up your important places and you’re done.
Tracks time based on your location — вот она суть.
The best time tracking solution is the one you don’t even have to think about. — а вот это проблема, которую решает приложение.
You just have to set up your important places and you’re done. — а вот как пользоваться трекером.
Не так уж и много информации, не правда ли? Суть мы поняли, и звучит интересно, потому пойдем читать дальше.
5. Ревью и награды
Если вам удалось получить ревью от уважаемого источника, цитату из него нужно вставить в описание приложения.
То есть, упомянув награду, нужно сказать за что вы ее получили:
Ну худой конец, если нет ни награды, ни ревью от уважаемого источника, иногда вставляют ревью от обычных пользователей, но, как правило, в этом случае у приложения очень специфический use case, например, медицина.
Ревью и награды повышают доверие пользователя к приложению, но не являются обязательными.
6. Основной текст
Описания для апп стора похожи на статьи в газетах: самая важная новость идет вперед, а менее важная и детали следуют за ней.
Если писать описание маленькими абзацами, пользователю будет проще понять содержание и убедиться в том, что аппу нужно скачать.
В первых 2–3 предложениях мы уже сказали все самое главное:
Wunderlist helps millions of people around the world capture their ideas, things to do and places to see. (Wunderlist: To-Do List & Tasks)
Теперь, пришло время немного углубиться в детали и характеристики. К тому же, основной текст — отличное место для ключевиков (но ни в коем случае не повторяйте то, что уже сказали в начале).
Whether you’re sharing a grocery list with a loved one, working on a project, or planning a vacation, Wunderlist makes it easy to share your lists and collaborate with everyone in your life. Wunderlist instantly syncs between your phone, tablet and computer, so you can access your lists from anywhere.
Из первых строк описания я уже поняла, зачем нужен Wunderlist, а теперь мне рассказывают, что конкретно можно заносить в списки и как ими пользоваться.
Заметьте, после перечня функций, Wunderlist подробно рассказывает пользователям за что ему дать денег:
7. Список функций
В списке желательно иметь от 3 до 7 функций, и все они должны иметь название и краткое описание. Иногда название фичи выносится заголовком, за которым следует предложение с текстом:
VSCO Journal: Publish original content to your Journal and share with the creative community. Find inspiration on the VSCO Journal, a publication highlighting creatives from around the globe.
NYC Apartments and Real Estate by StreetEasy — приложение, которые мы разрабатывали для компании Zillow. Его основная функция — это поиск недвижимости, потому и в описании на апп сторе слово search встречается чаще всего. Помимо этого, перечисленны такие функции как:
И еще один удачный пример из категории health & fitness:
FitStar Personal Trainer — Burn Calories & Lose Weight with Video Fitness Workouts led by Football Legend Tony Gonzalez (ну оочень длинное название). Основная функция этого приложения — видео тренировки. Но в добавок, перечислены следующие фичи (вкратце):
Описывая функции, нужно соблюдать следующие правила:
Дальше можно поговорить о том, как ваше приложение зарабатывает деньги и зачем людям их отдавать, а можно дать пользователям узнать об этом непосредственно в приложении. Где говорить о деньгах, решать вам, а мы пойдем дальше.
8. Что нового?
Сюда пишем все, что починили или добавили в приложение. Проще всего начинать с глаголов или gerund, хотя можно как угодно.
9. Что можно и чего нельзя делать в описании?
3. Как написать описание к скриншотам?
Скриншоты должны описывать главные функции приложения, и говорить о конкретных use cases. Первый скриншот — самый важный, он должен описывать value proposition. Всего скриншотов должно быть 5.
ShopBob — магазин, потому первый скрин говорит: купи.
Желательно начинать описание скриншота с глагола, а если функционал ограничен, то с существительного.
My Day у нас красивый, и это главное, потому скрин, говорящий о красоте, впереди.
Посмотрим еще на примеры отличных скринов и подписи к ним:
Must-have документация для мобильного разработчика. Часть 1
Во время разработки приложений необходимо учитывать интересы сразу нескольких групп участников: заказчики (бизнес), проектировщики, тестировщики, разработчики и дизайнеры. Однако документация обычно готовится только для заказчиков, а про разработчиков и тестировщиков почему-то постоянно забывают. В нашей первой статье мы расскажем о том, как можно самостоятельно подготовить необходимый комплект документации, утереть нос проектировщикам и получить документацию, которая будет соответствовать коду, а не абстрактным бизнес-фичам.
Это серия статей «Must-have документация для мобильного разработчика»: Часть 1 и Часть 2.
Передаю слово Вячеславу Черникову.
В первой части мы расскажем о том, почему важно уделять внимание техническому проектированию и опишем необходимый минимум документации, которая позволит создать «скелет» проекта на основе пользовательского интерфейса.
Данная статья является сокращенной версией руководства, доступного по ссылке в конце статьи.
Первичная документация
Ключевую идею, с которой мы начнем, можно коротко сформулировать следующим образом:
Мобильные бизнес-приложение — это в первую очередь пользовательский интерфейс для взаимодействия с внешним сервисом.
При разработке технической документации на проект это стоит обязательно учитывать, так как интерфейс нагляден и на его основе проще проводить разделение проекта на разделы. Да и сама модель предметной области очень хорошо описывается интерфейсом — в ней необходимо учитывать в основном те данные (и их производные), которые вводятся пользователем, отображаются на экране и управляют его поведением. Бизнес-сценарии также напрямую завязаны на поведение пользовательского интерфейса.
В то же самое время большинство ТЗ готовится для бизнес-заказчиков и описывают не конкретные экраны или сервисы, а целые бизнес-сценарии и блоки функциональности. В дальнейшем эта документация и спецификации дизайна используются командой разработки. Для кодирования и последующей реализации используются многократные перечитки и пересказы ТЗ.
В следующих главах мы опишем минимально необходимый набор документов, которые позволят команде использовать простые чек-листы для контроля реализации.
Прежде чем мы перейдем к разбору артефактов и извлечению из них полезных данных, давайте рассмотрим весь процесс разработки целиком. Для простоты мы выберем линейный процесс разработки, так как при использовании циклических или спиральных методологий возникают те же самые классы задач, только последовательность их выполнения может отличаться.
Итак, у проекта обычно выделяют следующие производственные классы задач:
Можно выделить и больше, но они по факту будут являться производными от обозначенных.
На этапе аналитики производится поиск решения, описание общих требований к приложению. На выходе с этапа аналитики появляются спецификации, которые являются вводными для этапа проектирования.
Так как наше руководство предназначено в первую очередь для разработчиков, то считаем, что бриф или базовое ТЗ у вас есть.
Дальше начинается самое интересное – проектирование пользовательского интерфейса. Этот этап является ключевым и при правильном подходе очень сильно облегчает и упрощает процесс разработки. Если же данный этап пропущен, то дальше успех проекта будет зависеть только от опыта команды.
На этапе проектирования самым важным является продумывание пользовательского интерфейса и создание схем экранов.
Если начинать сразу с дизайна (вместо схем экранов), то придется постоянно переделывать его (дизайн) для согласования с заказчиком. На этапе проектирования это сильно замедлит процесс. Дизайн фактически является производным от UX и наполняет изначальные схемы эмоциями, выправляет композицию, добавляет анимации и другие аспекты внешнего вида и визуального поведения. Схемы экранов, в свою очередь, создают структуру приложения и моделей данных — какие данные отображать, как они будут сгруппированы, как они будут влиять на поведение интерфейса.
На выходе с этапа проектирования будет получен комплект необходимых спецификаций и ресурсов, которые вместе с ТЗ уйдут разработчику. Этап кодирования разумно начинать с построения фундамента – базовой структуры проекта, в чем нам очень поможет понимание ключевых пользовательских сценариев.
Экраны, данные и логика
Напомним еще раз, что мобильные приложения это в первую очередь пользовательский интерфейс, поэтому и проектирование лучше начать со схем экранов и последовательности переходов между ними. Это необходимо для того, чтобы определить набор шагов, которые предстоит пройти пользователю для получения желаемого результата. Ведь бизнес-приложение создается для определенного набора ключевых сценариев (последовательности действий пользователя), с помощью которых человек может решить свои задачи.
Так как среднее время контакта человека со смартфоном составляет всего несколько минут, то количество шагов в бизнес-приложениях не должно быть большим — для пользователя в первую очередь важно получить результат (выполнить задачу или удовлетворить потребность) за время контакта с устройством. Для сложных приложений с большим количеством функциональных возможностей следует учитывать этот фактор. Хорошим выбором станет разделение приложения на относительно короткие сценарии не более 10 шагов каждый.
Для того, чтобы определить глубину ключевых сценариев, можно использовать карту переходов и состояний, подробнее о которой будет рассказано в следующих разделах. Но для начала требуется привести в порядок структуру интерфейса.
Группировка экранов и сквозное именование
Итак, у нас на руках есть схемы экранов от проектировщиков/дизайнеров и последовательность переходов между ними.
Для того, чтобы разбить приложение на части (разделы предметной области), мы пойдем от экранов. Еще раз напомним, что мобильное приложение это в первую очередь интерфейс взаимодействия с пользователем, поэтому наши экраны и являются прямым отражением доступной ему модели предметной области.
Первым делом необходимо выделить экраны, которые связаны между собой, обычно они должны идти друг за другом в пользовательских сценариях. Например, часто в приложениях можно выделить раздел Account с просмотром и редактированием всей информации, связанной с профилем пользователя.
Если вы опытный программист, то легко справитесь с разделением списка экранов на связанные разделы. В любом случае, потребуется немного практики.
Итак, у нас могут получиться следующие разделы:
Каждый раздел должен иметь название и номер. Названия разделов следует использовать для горизонтального разделения слоя работы с данными, бизнес-логики и пользовательского интерфейса. Это позволит в дальнейшем проще развивать проект.
Например, слой работы с данными (группы методов для различных серверных API) в этом случае разделится на разделы (репозитории, если вам так привычнее), каждый из которых будет обслуживать свой набор экранов:
AccountDataService.cs (или AccountRepository.cs)
В дальнейшем каждый из репозиториев может полностью скрывать всю работу с сервером, дисковым кешем и локальной СУБД. Это позволит на уровне бизнес-логики работать с репозиториями как с черными ящиками.
Дальше предстоит пронумеровать и назвать экраны (страницы, окна). На выходе у нас получится древовидная (хотя и плоская) структура интерфейса без учета последовательности переходов между экранами и их вложенности.
Имена экранов будут использоваться у нас в названиях классов для соответствующих страниц (Page) и ViewModel (или Controller для MVС):
В первую очередь это важно для разработчиков, которые фактически получают готовую структуру проекта:
Как видим, уже вырисовывается скелет проект. Слой DAL можно легко выделить в отдельную библиотеку. Если же у вас используется типовая архитектура или шаблон проекта (Base-классы, NavigationService, и т.д.), то считайте, что костяк приложения у вас уже имеется.
Пример структуры проекта представлен ниже.
UI (User Interface, пользовательский интерфейс)
BL (Business Logic, бизнес-логика)
DAL (Data Access Layer, доступ к данным)
Для того, чтобы дальше реализовывать поведение экранов, нам потребуется дополнительная информация, поэтому продолжим знакомство с необходимыми артефактами.
Таблица экранов
После того, как у нас есть схемы экранов, мы также можем провести их анализ до фактического старта разработки. Следующим полезным артефактом для нас станет таблица экранов, оперировать которой будут не только разработчики, но и тестировщики. В сводной таблице легко собрать воедино всю текстовую информацию. Ключевыми столбцами таблицы для нас станут:
2. Краткое название (Name)
3. Список возможных состояний (States)
4. Поля ввода для валидации (Validation)
5. Описание экрана и его поведения (Behavior)
Как видим, в представленном наборе полей собрана та информация, которая позволит корректно проверить работу каждого экрана в отдельности. Можно также каждому разделу присвоить свой цвет — это упростит работу с картой переходов и состояний.
Дополнительно, в эту таблицу могут быть добавлены следующие столбцы:
6. Список всплывающих уведомлений (alerts, sheets, dialogs)
7. Идентификаторы UI-контролов (например, LoginButton) для написания автоматизированных UI-тестов
8. Используемые модели (Models/Data Objects) данных
9. Используемые на каждом экране методы DAL
10. Используемые стили (Styles)
О каждом экране по столбцам достаточно просто вписывать короткие обозначения, которые в дальнейшем будут использоваться в программном коде и понятны в первую очередь разработчикам. Кроме столбца Behaviour (Описание экрана и его поведение), здесь ограничений лучше не делать.
Отдельно остановимся на состояниях экранов. Большинство современных приложений работает через Интернет, поэтому стоит корректно отображать пользователю информацию о состоянии загрузки:
Хорошей практикой считается, если каждый экран, загружающий данные из сети (или из локальной СУБД) будет корректно отображать пользователю каждое из описанных состояний. Фактически, отдельное состояние описывается своим набором визуальных элементов (тексты, картинки, кнопки, другие элементы), и на уровне программного кода легко управлять переключением из одного состояния в другое. Также можно фиксировать негативные сценарии (ошибка загрузки, пустые данные) для дальнейшего анализа и устранения на стороне сервера или приложения.
Можно взять за правило и на всех экранах, загружающих данные, добавлять переключение состояний. Это упростит взаимодействие пользователя с приложением. Можно также использовать различные анимации или графику в негативных состояниях (ошибки, пустые данные), чтобы сгладить эффект.
Итак, у нас уже есть схемы экранов, список Page и ViewModel, а также детальная информация по каждому экрану. Каркас приложения можно построить, однако сейчас у нас экраны описаны независимо друг от друга и нет четкой и понятной последовательности переходов. Поэтому следующим полезным артефактом для нас станет карта переходов и состояний.
Карта переходов и состояний
Итак, карта переходов начинается с точки старта – момента запуска приложения пользователем. Точек старта может быть несколько, например, один вариант запуска для авторизованного пользователя, второй – для неавторизованного, а третий – из Push-уведомления.
Дальше добавляются прямоугольники для каждого экрана и обозначаются стрелками последовательности переходов. Можно добавить идентификаторы (AutomationId) кнопок или событий, из-за которых произошел переход, и для наглядности еще указать данные, которые будут передаваться на новый экран.
Также у нас уже есть таблица экранов (предыдущая глава), где обозначены возможные состояния каждого из них и которые необходимо отобразить на карте переходов. Это позволит лучше понять возможные прерывания пользовательских сценариев, например, в случае ошибок или пустых данных. Если состояние прерывает (человек не может идти дальше) пользовательский сценарий, то обозначаем его минусом «-», если не прерывает, то плюсом «+». Стрелочки «назад» можно не добавлять.
Как видим, теперь у нас имеется практически вся необходимая для разработки информация в компактном виде. Эти три онлайн-документа (список экранов, таблица экранов, карта переходов) могут обновляться по мере развития проекта.
Для создания описанных выше артефактов нам будет достаточно 3 онлайн-инструментов:
На подготовку каждого из артефактов уходит не больше одного дня, зато в дальнейшем это очень сильно упрощает процесс разработки, тестирования и развития продукта. За время медитативной подготовки документов и схем команда глубже понимает проект целиком и может уже финально оценить сложность и длительность его разработки (цифры для внутреннего использования).
Продолжение следует обязательно прочитать.
Полную версию руководства вы можете найти на Medium «Техническое проектирование мобильных приложений». Пообщаться напрямую с автором и сообществом Xamarin-разработчиков можно в нашем уютном чатике в Telegram.
Во второй части мы расскажем о том, как работать со стилями, фоновой функциональностью и пользовательскими сценариями. Оставайтесь на связи и задавайте свои вопросы в комментариях!
Об авторе
Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.
Другие статьи автора вы можете найти в нашей колонке #xamarincolumn.