Как правильно написать описание программы

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

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

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

Как правильно написать описание группы ВКонтакте.

1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.

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

1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.

7 психологических трюков, которые усилят ваш текст | GeniusMarketing

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

Итак, какие типы документов используются в схеме.

1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).

На рисунке ниже — схема связи между этими документами.

Как это работает?

ТЗ

Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.

ЧТЗ

В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».

Use Case

Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.

Test Case

Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.

Bug Report

Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.

Руководство пользователя/Руководство администратора

Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.

Заключение

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

• документирование
• бизнес-анализ
• управление проектами

Источник: habr.com

НАШ БЛОГ

Актуальные и полезные
статьи и новости
из мира IT.

Как написать описание программы?

Категория: soft
Дата публикации: 2022-03-06

Опубликовано Mikhail_it1

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

«Нас этому не учили!»

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

Советская школа программирования этому учила хорошо: к небольшой программе в несколько сот команд полагались многостраничные документы-руководства (оператора, программиста, пользователя), «Список используемых терминов и сокращений». Эти «бюрократические излишества» теперь не используются. В лучшем случаю, составляется их неэквивалентная замена – документ «Техническое задание» (ТЗ).

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

Как начать?

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

Для начала следует ознакомиться с ГОСТР, ЕСПД (Единой системой программной документации). В оригинале, без интерпретаторов, «цитаторов».

Стандарты определяют положения и основные правила разработки, выполнения всех этапов изготовления программного продукта, его эксплуатации: организационно-методические, формы и содержания, автоматизации и др.

Положения Международного стандарта ISO/IEC и др. носят пока совещательно-рекомендательный характер: они, согласно ФЗ «О стандартизации», становятся обязательны лишь при выполнении международных контрактов по разработке (поставке) ПО.

Что отразить?

Каждый документ имеет:

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

Документ оформляется по стандарту А4 и (или) А3, с нумерацией листов (страниц) над текстом.

Как отразить?

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

В советские времена использовалась схема разработки: ТЗ – Эскизный проект (детали входа-выхода, общее описание модели, метода, алгоритма, программы, плана испытаний) – Технический проект (детализация на уровне, достаточном для программирования) – Рабочий проект (кодирование, тестирование, документирование) – Сопровождение (процесс поиска, исправления скрытых ошибок или «багов» по-современному).

Сейчас чаще используется схема: ТЗ – Программирование и отладка – «Минимальное документирование» – Передача Заказчику.

Тем не менее, показателями качества и профессионализма при разработке программ являются (кроме всего «обыденного», например, времени, трудозатрат и др.) – на стадии:

• ТЗ – определение критериев эффективности и качества программы, структуры «входа-выхода», методов исследования и проектирования, применение разработанных ранее программ, выяснение и классификация требований к программно-техническому обеспечению и вычислительной среде (особенно, выбор языка программирования и ОС), регламентация разработки;
• программирование и отладка – детализация состава и структуры «входа-выхода», метода и алгоритма, среды программирования, структуры программы и конфигурации необходимых средств;
• документирование – разработка программной документации по утвержденным стандартам и правилам ГОСТР;
• передача Заказчику – передача по акту программы и документации к ней, определение (если в ТЗ их нет) условий сопровождения программы и документации, обучения персонала, консалтинга.

Текст передаваемой программы рассчитан на программиста среднего уровня или на уровень ниже, но никак не на «суперпрограммиста». Главные критерии документированности – удобочитаемость (комментированность), структурированность, полнота, наглядность, содержательность, а также наличие атрибутов программы (наименование, разработчик, дата разработки, версия, последняя модификация, используемый режим работы, совместимость и переносимость, контактные данные).

Источник: itcompanion.ru

Как создать идеальное описание приложения для App Store и Google Play

Как правило, приложения выполняют довольно много разных функций от регистрации до terms and conditions. Однако, для описания продукта нам не нужны абсолютно все функции.

Екатерина Абросимова, директор по маркетингу в Yalantis, написала руководство о том, как правильно составлять описание приложения для магазина.

App Definition включает в себя 3 части: название, описание, и скриншоты. Давайте рассмотрим вопрос app definition кратко и более подробно.

Название

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

Описание

1. Первые 1–3 предложения в описании должны максимально четко описывать идею приложения и рассказывать, какую проблему оно решает. Максимальная длина этой части 255 символов.
2. Если у приложения есть особые заслуги (featured on TechCrunch), о них нужно говорить.
3. Основной текст описания может иметь 2–3 абзаца. Здесь мы расписываем характеристики и детали.
4. В конце должен быть список главных функций с их четким описанием.
5. В самый конец описания мы помещаем секцию «что нового?» Исправили баги, добавили фичи, поменяли звездочку на сердечко — все это здесь.

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

Скриншоты

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

А теперь подробнее.

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

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

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

• Grindr — Gay, same sex, bi, social network to chat and meet guys
• Shazam — Discover Music, Artists, Videos Movie Maker

В названии приложения допустимо иметь максимум 25 символов. Если слов будет больше, в поиске их просто не будет видно.

Теперь приступим к составлению описания для апп стора.

2. Как написать описание продукта?

1. Правила

Стараясь описать приложение для апп стора как можно лучше, необходимо соблюдать следующие правила:

• SLAP — Stop, Look, Act, Purchase. Другими словами, захвати внимание пользователя используя односложные предложения с подлежащими и глаголами с самого начала. Передавая смысл просто и ясно, ты подтолкнешь пользователя к действию.
• KISS — Keep it simple stupid. Вырежь все лишние слова, в которых нет никакого смысла. Не используй жаргон, это может отпугнуть.
• WIIFM — What’s in it for me? Что пользователь получит, узнает, ощутит, скачав приложение? Какой у продукта value proposition?

Описание желательно писать от второго лица, с точки зрения того, как пользователь будет использовать продукт.

Для того, чтобы составить дельное описание, нужно четко ответить на следующий вопрос.

2. Какие функции выполняет ваше приложение?

Как правило, приложения выполняют довольно много разных функций от регистрации до terms and conditions. Однако, для описания продукта нам не нужны абсолютно все функции. Достаточно выделить несколько основных, и одну самую важную. Важная функция — это ваше value proposition, конкурентное преимущество и позиционирование вашего продукта на рынке.

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

Для нашего My Day, самая важная функция — countdown clock with reminder. Другие функции, перечисленные в описании, это обои, праздники, виджет, настройки цвета и стиля, и единицы времени, которые аппа способна высчитывать. Мы позиционируем My Day как красивый и удобный продукт, и в этом его ценность.

3. Из чего состоит описание?

Повествование о приложении для апп сторов можно разделить на 5 частей:

1. 255 символов
2. Ревью и награды (если есть)
3. 2–3 абзаца основного текста
4. Спиcок функций
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. Ревью и награды

Если вам удалось получить ревью от уважаемого источника, цитату из него нужно вставить в описание приложения.

• Quip — Docs, Chat, Spreadsheets: ** Featured in MIT Technology Review’s 10 Breakthrough Technologies 2014**
• Wish — Shopping made fun: «Love, love this app. It’s a fun app that u can wish on things u love and want. Highly recommend it to frndz 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 подробно рассказывает пользователям за что ему дать денег:

  Wunderlist is free to download and use. Wunderlist Pro upgrades your experience and gives you unlimited access to Files, Assigning and Subtasks to help you accomplish even more for $4.99 a month or $49.99 a year through an auto-renewing subscription.

  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 встречается чаще всего. Помимо этого, перечисленны такие функции как:

  • ability to view, save and share for-sale and rental listings
  • email and call agents directly from the app
  • tap into the database for all kinds of market- and property-level facts and history

  И еще один удачный пример из категории health Lose Weight with Video Fitness Workouts led by Football Legend Tony Gonzalez (ну оочень длинное название). Основная функция этого приложения — видео тренировки. Но в добавок, перечислены следующие фичи (вкратце):

  • HD videos with legend
  • Challenges (setting personal goals)
  • Apple TV
  • Custom audio tracker
  • Track progress
  • Connect FitBit, Jawbone UO, MyFitnessPal
  • Integrated with Health app

  Описывая функции, нужно соблюдать следующие правила:

  1. Не делай описание функций слишком длинным.
  2. Помести две наиболее важные функции в начале, а третью самую важную в конце.
  3. Здесь никто ничего не читает.
  4. Здесь никто ничего не читает.
  5. Каждая новая функция должна начинаться с нового слова, и желательно, чтобы первое слово во всем списке относилось к одной части речи (глаголы, прилагательные, существительные).
  6. Третья самая важная функция.

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

  8. Что нового?

  Сюда пишем все, что починили или добавили в приложение. Проще всего начинать с глаголов или gerund, хотя можно как угодно.

  • Now supporting iOS 9
  • Likes: See who liked your post
  • Now you can book up to 4 hotels at once on the app
  • Fixed a bug affecting some iPhone 6 and 6 Plus readers

  9. Что можно и чего нельзя делать в описании?

  • Value proposition в сжатом виде
  • Фраза «ideal for»
  • Убеждение: «Free forever!»
  • From the creators of…
  • Злоупотрелять ключевыми словами в описании (слишком много ключевиков и отсутствие связи с контекстом описания негативно воспринимается пользователями)
  • Допускать грамматические ошибки и опечатки
  • Говорить техническим языком
  • Писать что-то вроде: Наш продукт был сделан в Нью-Йорке разработчиком Сидоровым.
  • Врать (в ответ получим плохие отзывы)
  • Писать запутанно и абстрактно
  • Гиперболизировать (использовать словечки типо revolutionize, revolutionary, game changing, disruptive, если это не правда на самом деле)

  3. Как написать описание к скриншотам?

  • четко
  • информативно
  • коротко

  Скриншоты должны описывать главные функции приложения, и говорить о конкретных use cases. Первый скриншот — самый важный, он должен описывать value proposition. Всего скриншотов должно быть 5.

  • Shop the latest fashions and get trend updates and styling tips
  • Dresses to denim, shoes to swimwear, find what you’re shopping for now
  • Shop the latest styles first and create a personalized boutique of favorites
  • See all gorgeous details up close
  • The designers to put on your radar now

  ShopBob — магазин, потому первый скрин говорит: купи.

  Желательно начинать описание скриншота с глагола, а если функционал ограничен, то с существительного.

  • Beautiful countdown
  • Event with a personal touch
  • Many countdown styles
  • Lots of wallpapers
  • Use it as a widget!

  My Day у нас красивый, и это главное, потому скрин, говорящий о красоте, впереди.

  Посмотрим еще на примеры отличных скринов и подписи к ним:

  

  

  

  4. Где брать ключевики?

  • из головы
  • из Google Trends
  • из Google AdWords Keyword Planner
  • и вот еще полезный список App Store Statistics

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

  5. Что еще почитать на тему App Definition?

  • Apple Guidelines
  • Google Guidelines
  • Ideal For Statement
  • Value Proposition
  • Value Propositions That Work
  • Useful Value Propositions Examples

  А для пущего понимания, как продать приложение людям, обязательно послушайте этот подкаст:

  И читайте Пола Грема:

  Источник: apptractor.ru