Помоги проекту - поделись книгой:
5. Перечень этапов разработки мобильного приложения.
Поскольку разработка мобильного приложения может быть довольно длительным проектом, советую в договоре описать этапы работы и сроки выполнения каждого этапа. Это позволит более эффективно придерживаться сроков выполнения договора.
6. Соглашение о неконкуренции.
Соглашение о неконкуренции должно идти в договоре отдельным пунктом. Например, вы можете указать, что разработчик не может использовать идеи и технологии из вашего мобильного приложения в других приложениях.
Вы не можете заставить разработчика не использовать ваши идеи, но можете дополнительно прописать запрет на использование созданного кода для вашего мобильного приложения в других проектах. По закону разработчик и так не имеет права этого делать, но многие из разработчиков об этом даже не догадываются. Отдельный пункт в договоре напомнит им о том, как это важно.
7. Условия нераспространения информации.
Обязательно оговорите условия нераспространения информации о вашем приложении. Обычно оно называется Non-Disclosure Agreement, что переводится как «договор о конфиденциальности», или «договор о неразглашении информации», в числе которых персональные данные, коммерческая тайна, условия сотрудничества и т. д. Такое соглашение гарантирует, что разработчик не будет рассказывать о своей работе, а также делиться вашими секретами и технологиями со всеми подряд. Важно также, что этот пункт действует и после завершения договора, то есть бессрочно.
8. Результат сотрудничества.
В договоре должна быть указана конкретная сумма и конкретный результат труда, который вы получите за эти деньги. Иначе вы рискуете попасть в постоянное «Доплатите, пожалуйста, и мы все доделаем». Если же исполнитель ошибся суммой, а такое также случается, то всегда можно внести изменения в договор на взаимовыгодных условиях.
Часто заключают договор с использованием почасовой оплаты. В таком случае убедитесь, что есть отдельный пункт, обеспечивающий прозрачный контроль за затраченным разработчиком временем при создании приложения. К примеру, контроль можно осуществлять через сторонний сервис, постоянно следящий за тем, что делает разработчик за своим компьютером, или же видео выполнения работы.
9. Условия оплаты.
Предоплата в разработке программных продуктов – дело естественное, и этого не нужно бояться. На самых ранних этапах разработчики выполняют множество задач, которые остаются за кадром. Об этой работе вы обычно даже не подозреваете, но и она должна быть оплачена. Предоплата позволяет исполнителям качественно работать с самого начала.
Если рассчитываетесь по безналичному расчету, то обычно с подтверждением оплаты проблем не возникает. Если платите наличными, советую получить от разработчика документ, подтверждающий факт оплаты. Документ требуйте в момент оплаты, а не когда-нибудь «завтра». Также на документе должны стоять печать и подпись от компании разработчика.
10. Акт выполненных работ.
Для каждого разработчика наличие акта выполненных работ очень важно. Это документ необходим при налоговых проверках в качестве подтверждения, что все работы по контракту были выполнены и договор считается закрытым. Ни в коем разе не подписывайте акт выполненных работ до того, как все работы будут выполнены, но и не вздумайте шантажировать им разработчика, чтобы он делал то, о чем вы не договаривались. Вам еще наверняка пригодятся его услуги, не нужно портить отношения.
Соглашение с пользователями
Чем точнее в документе учтена специфика сервиса, тем меньше вероятность того, что у вас не найдется адекватного решения при возникновении конфликтной ситуации.
Одного договора с разработчиком недостаточно. Вам также понадобится заключить письменные договоренности с каждым пользователем мобильного приложения. К счастью, для этого вам не нужно заключать отдельные договоры с каждым из них на бумаге. Вы заключите договоры в электронной форме. Для этого вам необходимо разместить текст договоров в самом мобильном приложении, дать возможность прочитать его каждому пользователю и выполнить действие, подтверждающее согласие с принятием условий договора.
Самые важные договоренности желательно показывать пользователю либо при регистрации учетной записи для пользования приложением, либо сразу после первого запуска. Некоторые используют сообщение о том, что при дальнейшем использовании приложения, пользователь автоматически соглашается с договором. Часто приложением невозможно пользоваться, пока пользователь не сделает пометку о том, что согласен с условиями соглашения, и это правильно.
Пользовательское соглашение, или, как его еще называют, лицензионное соглашение с конечным пользователем (end-user license agreement (EULA)), – это договор, регулирующий отношения между вами, правообладателем приложения и пользователем приложения. Он касается только условий использования мобильного приложения. Похожие соглашения есть практически в любом онлайн-сервисе и приложении для обычного компьютера. В народе их еще называют «лицензией». Имейте в виду, что из-за неверно написанного соглашения вам могут отказать в публикации приложения в магазине приложений.
Одним из самых важных пунктов лицензионного соглашения является отказ от ответственности (Disclaimer). В информационных технологиях его обычно добавляют в любое приложение и сервис, чтобы тем самым обезопасить себя от любых негативных последствий, возникших у пользователя при использовании программы. Это делается для предотвращения проблем у владельца приложения. Те, кто наперед продумывают все юридические последствия, абсолютно правы.
Почитайте соглашения, подписываемые крупными компаниями с пользователями их мобильных приложений. Компании нередко виноваты в ненадлежащей работе своих программ, но вообще не несут никакой ответственности перед пользователями. Берите с них пример, иначе пользователи начнут винить вас не только в каждой вашей ошибке, но и в своих собственных.
Менее важные договоренности, чем пользовательское соглашение, обычно становятся видимыми только после перехода по ссылке или нажатия на кнопку и содержат пункт о том, что если кто-то пользуется мобильным приложением, то автоматически соглашается с данными договорами. К таким договорам относятся публичная оферта и сообщение о конфиденциальности.
Оферта регулирует ваши отношения с пользователем по части оказания услуг и поставки товара, то есть условия купли-продажи. Информация о конфиденциальности описывает, какие данные собираются и как они будут использоваться. Так, например, если приложение собирает личные данные (имейл, имя, телефон и др.), то, скорее всего, вы должны будете уведомить об этом Роскомнадзор, в противном случае рискуете быть оштрафованными. Довольно часто, мобильные приложения отсылают собираемую информацию третьим сторонам, о чем можно найти отдельный пункт либо в лицензионном соглашении, либо в соглашении о конфиденциальности.
Техническое задание
Техническое задание должно обеспечить полное понимание системы для любого человека, прочитавшего этот документ.
Техническое задание пришло к нам из производства. Когда требуется создать какую-то деталь или устройство, то еще до его создания необходимо иметь ясное представление о том, как должен выглядеть результат работы, какие функции будет выполнять устройство, из каких материалов состоять и т. д. Производство немыслимо без технического задания (далее – ТЗ), так как значительно облегчает появление новых гаджетов, вещей и программ.
Никто не спорит, что при производстве вещей все нужно продумывать заранее, создавать чертежи и описывать результат. При производстве интеллектуального продукта, люди не до конца осознают, что его произвести еще сложнее, и все, что относится к производству материальному, также характерно и при производстве интеллектуальном. Также из-за безграмотности некоторых разработчиков появились идеи, что ТЗ не нужно или же это пустая трата денег и времени.
Часто заказчики сами создают ТЗ, не понимая, что у них для этого недостаточно опыта и знаний. Представьте, что вы составляете ТЗ не на разработку мобильного приложения, а на смартфон. Что вы можете в нем прописать, не будучи специалистом? Только то, что знаете как пользователь. Что знает пользователь? Только то, что может пощупать и опробовать лично, часто даже не подозревая, что другие люди могут пользоваться той же моделью смартфона иначе и для других целей. Я уже не говорю о нехватке специальных знаний в дизайне интерфейса и программировании.
Для разработки ТЗ заказчик может или самостоятельно изучить специфические вопросы, касающиеся разработки приложения, или воспользоваться помощью специалистов. Идеально, если ТЗ разрабатывается теми, кто на его основе будет создавать мобильное приложение. Обратившись к сторонней компании только за созданием ТЗ, вы вполне можете получить раздутый проект как по финансовой, так и по материальной части, не гарантирующий успеха. Составителю выгодно написать в ТЗ как можно больше ненужного и потратить на его создание как можно больше времени, потому что от этого зависит размер его дохода. Самостоятельно разработчик также не может создать ТЗ, даже имея на руках бриф или пожелания заказчика. Поэтому ТЗ всегда создается обеими сторонами, но главным остается разработчик. Именно он направляет заказчика, задает ему правильные вопросы для получения правильных ответов.
Есть заказчики, требующие создать вначале договор с прикрепленным к нему ТЗ, а затем говорящими: «Только тогда мы подумаем над тем, заказывать ли у вас». Дескать, иначе они не смогут понять уровень профессионализма разработчика или сразу хотят увидеть, что он способен предложить. Частично это правда, и по ТЗ действительно можно судить о разработчике, но ТЗ не создается на коленке за несколько часов. Это сложная работа, требующая участия многих специалистов и отнимающая много времени. Разработка ТЗ должна оплачиваться, иначе оно не будет качественным. При заказе и составления ТЗ, и разработки мобильного приложения стоимость составления ТЗ будет ниже, чем для тех, кто заказывает только одно ТЗ. Это связано с затратами времени специалистов: если они тратят его как на ТЗ, так и на производство приложения, то это окупается, в отличие от написания ТЗ без продолжения работы.
Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.
Как и договор, ТЗ в процессе работы над приложением может изменяться. Не стоит относиться к договоренностям так, будто они высечены на камне – эти времена давно прошли. Действуйте гибко. Если выгодно изменить договор, в том числе техническое задание, – меняйте. Жизнь часто вносит коррективы, и лучше вовремя приспосабливаться к происходящему.
Из-за отсутствия единых стандартов каждая компания делает ТЗ по-своему. С одной стороны, это дает невиданную гибкость, а с другой, ведет к полной неразберихе, и если заказчик захочет передать свой проект другому разработчику, то не исключено, что придется менять ТЗ. Ниже я расскажу только о самых важных частях технического задания.
1. Назначение, цели, задачи и результат.
Понятно и доступно опишите, зачем вам мобильное приложение и какие задачи оно должно решать. Обычно кратко описывают каждую большую задачу, а детализацию делают в описании подзадач.
2. Целевая аудитория.
Максимально подробно опишите будущих пользователей приложения. Многие создают собирательные образы наиболее распространенных типов пользователей, а некоторые даже описывают, как будет себя вести каждая из этих личностей, создавая так называемые user story, или истории пользователей.
3. Структура.
Описать структуру приложения, включающую все разделы, их названия, элементы каждого раздела и порядок их размещения. Необходимость каждого элемента и порядок его размещения должны быть обоснованы.
4. Макеты экранов (страниц).
В общем виде отображаются самые важные элементы каждого экрана, начиная с главного. Это можно сделать как на бумаге, так и в специализированном приложении или онлайн-сервисе.
5. Функционал.
Описать все функции: как они будут реализованы, как будут работать и зачем они нужны.
6. Дизайн.
Привести примеры понравившихся приложений, описать пожелания по оформлению.
Некоторые заказчики требуют описывать как можно больше деталей. Их можно понять, ведь они пытаются не только внести ясность, но и обезопасить себя от недобросовестных исполнителей. Однако разработчику чрезмерная детализация всегда добавляет проблем, потому что не все можно предсказать наперед и увидеть, как одно будет сочетаться с другим. Возможно, наоборот, не будет, поэтому иногда требуется создать прототип приложения. Конечно, это значительно усложняет разработку. Хорошие разработчики составляют ТЗ в меру детально, чтобы у них была возможность оперативно вносить изменения в конечный результат.
Глава 7
Разработка мобильного приложения
Начало
Информация, ведущая к обязательному изменению проекта, поступит к автору этого проекта тогда и только тогда, когда чертежи уже выполнены.
Создание нового мобильного приложения в каждой компании начинается по-разному. У всех компаний, серьезно относящихся к своим обязательствам перед заказчиком, есть одно общее правило при разработке приложений: вначале оно проектируется. Это обязательный этап создания любого мобильного приложения сложнее калькулятора.
В рамках этого этапа создается проект конкретного приложения, по которому происходит вся работа над ним в компании-разработчике. Проект дает ответы на все вопросы, которые могут возникнуть у разработчика (какую технологию использовать, как взаимодействуют разные части приложения, сколько времени потратить, в каком порядке выполнять работу). К примеру, если приложение будет многоязычным, то необходимо детально разобрать механизм реализации многоязычности именно на стадии проектирования, чтобы можно было заложить весь необходимый функционал.
Техническое задание описывает только то, как должно выглядеть приложение и что оно должно делать, но не объясняет разработчику, как необходимо разрабатывать приложение – это объясняет описание проекта.
У каждой компании собственный подход к проектированию. Некоторые ограничиваются только макетом интерфейса, другие детально описывают все что смогут, третьи ко всему вышеуказанному создают прототип. Поскольку проектирование может занимать довольно много времени и не может выполняться бесплатно, то в каждом отдельном случае все решается индивидуально.
Сделать приложение сегодня не проблема, проблема заключается в том, чтобы сделать все, как хочет заказчик и в оговоренные сроки. Если приложение – это простой калькулятор, то его может сделать один студент или даже школьник. Если приложение требует вовлеченности нескольких специалистов, то правильно организовать работу не так легко.
Как организовать сотрудников так, чтобы они одновременно работали над приложением и после этого не приходилось все переделывать заново? Нужно ясное видение того, что должен делать каждый из них, когда, в каком объеме и как совместить затем работу с работой другого специалиста. Для этого необходимо управление проектами.
Вы ведь не думаете, что компания-разработчик будет заниматься только одним вашим приложением? Они откажутся от всех существующих клиентов, всех доработок и подработок, а также от всех новых клиентов в вашу пользу? Нет, так не бывает. Компания обычно ведет несколько проектов разной сложности. Каждый из сотрудников компании должен иметь возможность с легкостью переключаться между совершенно разными задачами и выполнять их в срок. Для этого компании нанимают отдельного сотрудника, менеджера по проектам, который только тем и занимается, что организовывает совместную работу.
Без проекта разработчики не будут точно знать, что им и как делать. Если вам встретится разработчик, утверждающий, что «им это не нужно» или «это пустая трата денег», сразу с ним прощайтесь. Можно ли создать автомобиль, самолет или даже смартфон без проекта и продумывания всех этапов работы и взаимодействия специалистов? Конечно, нельзя. В этом плане разработка мобильного приложения не исключение.
Обратите внимание на то, что говорит разработчик, чтобы понять его профессиональный уровень. Нельзя путать проектирование с созданием макета интерфейса или прототипированием. Некоторые разработчики полагают, что это одно и то же. На самом деле макет может быть частью проектирования, но не может быть самим проектированием. Проектирование – более широкое понятие, включающее в себя детальное описание будущего мобильного приложения, зарисовки интерфейса и другую информацию, помогающую в работе над приложением.
С точки зрения заказчика, логично все детально описать, упорядочить и продумать в виде проекта и только после этого приступать к работе. Например, как это делают при постройке дома: нужно заранее утрясти все проблемы и обговорить все с заказчиком и только после этого начинать что-то делать. В материальном мире такой подход действительно всегда срабатывает. С разработкой мобильного приложения так не получится. Она скорее напоминает квантовую механику, где один электрон одновременно может быть в двух местах. Я хочу сказать, что при разработке приложений невозможно наперед все предсказать и описать. Это и есть основной камень преткновения между заказчиками и разработчиками.
Создание практически любого приложения начинается с чистого листа. Разработчик может использовать готовые элементы из прошлых работ, но их очень мало и они редко подходят для других типов проектов (если только речь не идет о сотнях похожих приложений, как у нас было с салонами красоты). Весь программный код, дизайн, звуки – все создается заново. Отчасти поэтому сложно не только определить сроки выполнения заказа, но и установить цены за работу. Разработчик, даже несмотря на детальное ТЗ, все еще плохо представляет, какими способами получится все это реализовать и что получится на выходе. Многие из пунктов ТЗ и договора заказчик обязательно будет трактовать так, как ему выгодно или захочется, что в результате приведет к изменениям в приложении.
Использовать чужой код или изображения для упрощения работы можно только с разрешения автора, и хотя во многих случаях его легко получить, лучше этого не делать. Достаточно посмотреть в интернете, сколько сайтов выглядят слишком похоже, используя одинаковые изображения. Экономия копеечная, поэтому лучше дизайн делать полностью уникальным.
«А как же фреймворки, библиотеки и готовые куски кода из прошлых работ?» – спросит опытный заказчик. А так, что это все равно придется приспосабливать под нужды нового проекта. Да, готовый код облегчает разработку, но вы не сможете использовать фреймворк без тщательной подгонки под проект, то есть разработчику все равно придется изрядно потрудиться.
Разработка мобильного приложения не линейный процесс. Часто приходится возвращаться к предыдущим этапам работы, что-то доделывать и переделывать. Иногда потому, что так захотел заказчик, иногда потому, что так лучше, иногда из-за найденных ошибок. Все это неотъемлемая часть процесса разработки любого программного обеспечения. Это значит, что, если вы заставите разработчика предсказывать все нюансы и тонкости будущего приложения на бумаге в виде проекта, это выльется в пустую потерю времени и денег и растянет проектирование на неопределенный срок.
Другая крайность – описание проекта слишком обобщенно. С одной стороны, как уже было сказано, это позволяет разработчику гибко подходить к разработке, а заказчику постоянно вносить предложения по ее улучшению, с другой – это сильно затягивает процесс работы, потому что все постоянно будет переделываться, а затем будет переделываться переделанное. Не будет никаких границ, никакой ясности, что негативно отразится на результате. С точки зрения многих разработчиков, это рай, потому что можно хоть до смерти программировать одно приложение, зарабатывая деньги, а с точки зрения заказчиков, это ад, потому что приложение никогда не появится на свет.
Избежать обеих крайностей помогает следование гибкой методологии разработки (Agile), позволяющей подстраиваться под проект, сохраняя его целостность и имея явные ограничения в виде сроков и сложности кода. Обычно проект разбивается на этапы, каждый из которых является самодостаточным и законченным проектом, в то же время оставаясь частью большего проекта.
В самом начале достаточно подробно, как отдельный проект, описывается только первый этап разработки приложения. После этого начинается разработка. Результат показывается заказчику, а затем обсуждается дальнейшая работа и корректируются как второй этап разработки приложения, так и проект разработки приложения в целом. Таким образом, проект имеет явные и четкие ограничения. Разработчик может довольно точно определить стоимость и срок реализации каждого отдельного этапа, что значительно облегчает его сотрудничество с заказчиком, да и заказчику так спокойнее.
На этапе проектирования разработчику важно понимать и учесть в договоре, что заказчик наверняка захочет что-то усовершенствовать. Нужно предусмотреть возможность улучшений в некоторых местах реализации проекта, потому что для разработчика это дополнительный расход времени, а для заказчика – денег. Даже если разработчик об этом ничего не говорит, имейте в виду, что при вашем желании что-то существенно доделать или переделать срок работы может растянутся, а стоимость – вырасти.
Многие используют user story, тщательно разбирая поведение пользователя, порядок его действий, перемещений и функции, которыми он будет пользоваться. Для этого создаются несколько выдуманных пользователей, каждый из которых хочет решить конкретные проблемы. Разработчики продумывают весь путь пользователя от загрузки приложения до решения своих проблем и пытаются понять, как его можно улучшить с точки зрения простоты для пользователя и реализации целей заказчика. Лучше сразу подключать к работе заказчика или его представителя, отлично знающего целевую аудиторию и результат, которого заказчик ожидает от выпуска приложения. Также необходимо подключать разных специалистов, в том числе программиста и дизайнера.
В результате описания проекта должна появиться навигационная карта, из которой будет понятно, как пользователь будет перемещаться в приложении и, возможно, за его границами, используя другие приложения. В результате пользователь должен добраться куда хочет, но управлять этим процессом и ненавязчиво подталкивать его в нужном направлении должны вы. С этой целью можно одни элементы делать большими и видимыми, другие – менее видимыми, а третьи – вообще прятать.
Нейминг
Придумать удачное название – не пара пустяков: это адский труд.
Правильно назвать приложение важнее, чем правильно назвать ребенка. Ребенок в любое время может изменить свое имя, причем не один раз, и это только поможет ему эффективнее достигать поставленных целей. Смена названия приложения – это гарантированная «смерть». Его нужно с самого начала правильно назвать, ведь другой попытки не будет. Отчасти из-за этого создание любого продукта сегодня часто начинается с выбора названия.
До момента установки люди видят только название и краткое описание мобильного приложения. Название они видят в первую очередь, что в значительной мере влияет на их первое впечатление о программе, которое, как известно, крайне трудно изменить. Название приложения можно услышать от знакомого, прочитать в новостях, найти в магазине приложений. Именно по названию люди идентифицируют программы и отличают приложение от остальных.
Так почему практически все заказчики халатно относятся к процессу выбора названия приложения? Думаю, причины две. Первая причина: они уверены, что уже придумали самое лучшее название на свете. Ведь оно им очень нравится – так почему бы не считать его самым лучшим? Вторая причина: им кажется, что название никогда не поздно придумать – подумать денек, и найдется. Уверен, что если бы такие заказчики хоть раз имели дело с профессионалами нейминга, они бы относились к поиску названия более серьезно.
Конечно, вы можете самостоятельно придумать название для своего приложения, при условии, что сможете выделить этому процессу достаточно времени. Для начала купите хорошую книгу по неймингу и внимательно ее почитайте. Книг о нейминге мало, все они написаны специалистами, выбрать легко. Статьи из интернета мало чем помогут – их как раз пишут неспециалисты, а в этом вопросе доверять любителям не стоит.
Лучше всего подобрать название совместно со своей целевой аудиторией. Это одновременно и способ выбрать название, которое гарантированно нравится людям, и способ попиарить приложение на этапе разработки. Объявите о конкурсе с призом, который ценен для будущих пользователей приложения. Установите правила конкурса, сроки и требования к названию. Чем больше людей из целевой аудитории примут участие, тем большее количество вариантов названий вы получите. Останется только выбрать самое подходящее.
Одной из проблем с подбором названий для мобильных приложений является ограниченное количество символов, видимых на экранах пользователей. Так как экраны смартфонов небольшого размера, то длинные названия при показе в магазине приложений попросту обрезаются. Перед поиском названия для своего приложения посмотрите на названия приложений конкурентов и то, как они обрезаются в магазине приложений, обратите внимание на короткие названия, узнайте, как их придумали и что они значат. Ваше название должно быть коротким, но понятным для пользователя.
Естественно, название должно иметь прямое отношение к ценности, которую от него получает пользователь. Например, это может быть основная функция или проблема, которую решает приложение. Названием может служить краткое описание того, что делает приложение или образ, с которым оно ассоциируется. Понятное, но уникальное и выделяющееся в ряду названий других приложений – вот ваша цель.
Желательно, но не обязательно, чтобы название включало одно из популярных ключевых слов, которое пользователи используют при поиске в поисковых системах. Так оно будет лучше отображаться в поисковых системах и магазине приложений.
Не используйте бессмысленный набор букв для названия или же аббревиатуры. Такое себе могут позволить те, у кого есть миллионные инвестиции. Они с легкостью раскручивают узнаваемость своего бренда за счет огромной рекламы. Если вы не можете себе этого позволить, то подбирайте название так, чтобы оно рекламировало приложение, а не звучало для людей как абракадабра.
Хорошо, если название будет с капелькой юмора, но он должен быть понятен целевой аудитории. Смешное название выбрать очень трудно, поэтому неудивительно, что таких названий мало.
Не стоит называть приложение тем же именем, что и ваша компания или давать ему свою фамилию, если вы частный предприниматель. Так делают только те, кто уже очень известен, и раскрученное имя помогает продавать. Если же вы мало известны, то придумайте интересное название, привлекающее внимание больше, чем «Иванов» или «Попов».
Варианты названия сразу же ищите в поисковой системе: может быть, кто-то их уже использует? Также ищите его в магазинах приложений. Если название свободно – можно использовать. Если приложение станет популярным, рано или поздно вы задумаетесь о регистрации торгового знака, тогда придется проверять, не зарегистрировал ли кто-то такое же или очень похожее имя официально. Желательно проверить это как можно быстрее.
Источниками идеи для названия могут стать приложения конкурентов, сайты и книги по тематике приложения, обсуждения целевой аудитории на форумах и блогах.
Записывайте идеи. Сделайте список всех идей, оставьте его на неделю-другую, а потом просмотрите свежим взглядом. Я уверен, вы удивитесь тому, как сразу не увидели, что некоторые названия абсолютно бессмысленны или глупы. Отбросьте их, обдумайте оставшиеся названия еще раз и удалите те, которые посчитаете бесперспективными. В результате у вас останется мало подходящих названий, из которых вы выберете лучшее.
Обязательно проверьте, что означает ваше название на других языках. Может быть, это что-то отвратительное, противоположное по смыслу или может вызывать неприятные ассоциации у части людей? Проверять все названия таким образом нет смысла, поэтому проверяйте только самые лучшие варианты, которые вышли в финал отбора. Как и в случае с доменными именами, название мобильного приложения нужно проверить на уникальность и наличие, ведь если то, которое вам подходит, занято, то второе такое же точно дать нельзя.
Пользовательский интерфейс
Поделиться книгой: