Как презентовать новое приложение

Обновлено: 08.01.2025

ОСП №3
ГБПОУ МО «Щёлковский колледж»
Учебная дисциплина
МДК 03.01 «Сопровождение и продвижение
программного обеспечения отраслевой
направленности»
Тема 5. Презентации
программного обеспечения.
Занятие проводит:
преподаватель спецдисциплин
Бойко О.В.

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

В этом занятии мы рассмотрим:
1. Что такое (презентация) демо ?
2. Чем отличается плохое демо от
хорошего ?
3. Из-за чего демонстрация становится
плохой ?
4. Как сделать хорошую
демонстрацию?
5. Заключение

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

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

Такой гигант, как NVIDIA, уже давно использует
ролики для демонстрации своих возможностей

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

Существует много видов демонстрации программных продуктов
Виды презентаций (демок):
- полная версия продукта с триальным
(trial) режимом;
- версия продукта с урезанными
возможностями;
- демонстрация “живого” продукта по
определенному сценарию;
- видео;
- презентация;
- скриншот или картинка.

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

Обычная демка
вряд ли восхитит
и вдохновит когонибудь

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

3. Из-за чего демонстрация
становится плохой ?
Любая мелочь, незначительная
ошибка или просто невнимательность
может привести к плохому демо,
потому что все это портит
впечатление от продукта у
пользователя.

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

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

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

4. Как сделать
хорошее демо
Какие шаги
нужно сделать
при работе над
хорошим демо:

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

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

Здесь демонстрируется несколько типов
графиков и то, как с ними можно работать

Несколько советов для создания хорошего
демо:
1. Выберите 2-3 ключевые возможности продукта для
демо, которые являются полезными для пользователя
(Лучше показать меньше, да лучше).

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

3. Желательно начать презентацию с самой важной
и самой полезной возможности.
Хорошее начало важно в любом деле.

4. Демонстрация продукта не
должна содержать ни багов, ни
падений, ни ошибок в
описании.

5. Действия в перзентации должны быть простыми и
очевидными, чтобы была четкая связь “некие действия —
результат”. Пользователь не должен гадать, какое именно
действие привело к результату.
Чем очевиднее действия в демке, тем понятнее
пользователю продукт.

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

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

8. Демка должна позволить легко повторить все
действия, а при наличии кода — возможность
скопировать его и воспроизвести.
Демку с такой структурой сможет
воспроизвести каждый

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

Текст с описанием на картинке можно заменить
цифровым обозначением

11. Сведите количество кликов на
демке к минимуму, это поможет
удержать внимание пользователя.

12. Демка должна решать какую-либо задачу
пользователя.
Когда демка решает задачу, похожую на задачу аудитории,
пользователи видят, как именно продукт может помочь им.

13. Энтузиазм и немного юмора
— то, что никогда не помешает
любой демке.

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

В своей прошлой статье «Выбор программного продукта. Сбор требований» я рассказал о самом начале сотрудничества бизнес-консультанта с представителями малого и среднего бизнеса. О том, как знакомиться с новой для вас компанией, как правильно строить диалог с владельцем бизнеса или директором компании, как предлагать свои услуги.

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

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

Большинство IT-специалистов идут по привычному пути демонстрации возможности программного обеспечения на основе тестовых примеров.

Это ошибка! Клиенту тесты не нужны, клиенту нужен результат!

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

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

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

Как правильно отвечать на вопросы клиента?

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

Самое главное качество в данном случае – это стрессоустойчивость. Поймите, такие люди встречаются очень часто. Я рассматриваю их как неизбежное зло. Иногда их даже специально приглашают на презентацию в качестве критиков-специалистов. Это может быть собственный системный администратор, маркетолог, бухгалтер или даже приглашенный со стороны человек, которому доверяет ваш клиент. Одни при помощи критики стараются выявить «слабые места» вашего предложения, другие просто слишком консервативны и подсознательно сопротивляются переменам.

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

Что делать, если вам задают вопрос, ответа на который вы не знаете? Я считаю, что лучшее решение – это честно ответить: «не знаю». Вы уже продемонстрировали свою компетентность, сумели ответить на большинство сложных вопросов, пояснили клиенту все преимущества и особенности работы с новым программным продуктом. А потому в каком-то конкретном случае признаться в том, что вы также знаете далеко не все на свете, будет наилучшим решением. Ведь если в ситуации, где вы «плаваете», попытаться выкрутиться, клиент это обязательно заметит. При личном общении подобные нюансы видны практически всегда. И такую попытку сохранить лицо» могут принять за неискренность и упрямство. Таким образом, вы покажете себя недостаточно честным, а также сложным в общении человеком, который не способен признать отсутствие знаний или свою неправоту. Также очень часто ваши попытки выкрутиться выглядят, скорее, как проявление зашоренной веры в определенный программный продукт. А потому я советую всегда быть честным и не скрывать того факта, что вы не готовы ответить на конкретный вопрос. Клиент должен видеть, что вы с ним всегда предельно откровенны, и тогда он будет вам доверять.

Помните: вы сейчас – продавец!

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

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

Помните: вы продаете не программу, а решение проблемы. И всегда исходите из этого.

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

К вопросу о цене

«Сколько это будет стоить», «какова цена ваших услуг» — вопросы, которые вы услышите обязательно. С другой стороны:

1. Вы продаете не программный продукт, а свои услуги бизнес-консультанта. А потому говорить следует как о программе, так и о возможном последующем сотрудничестве.
2. До того, как у вас появится инструмент для «точной диагностики», вы не не сможете назвать цену. Просто потому что любые предварительные расчеты могут оказаться ошибочными. Завышать стоимость заранее – испугать клиента слишком большими суммами. Пытаться посчитать сумму на основе тех данных, которые уже у меня есть – скорей всего, обмануть себя. Ведь если вы озвучите определенную стоимость работы, менять ее в процессе будет сложно, не говоря уже о том, что такое поведение снижает к вам доверие клиента. А без доверия работа бизнес-консультанта в малом и среднем бизнесе невозможна.

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

Мои услуги ограничены определенными сроками! Я решаю проблему клиента и ухожу.

Таким образом, уже в момент предложения услуг я обозначаю тот факт, что через какое-то время обязательно будет финал сотрудничества. Это может быть полгода, может быть – 1,5 года. Но финал обязательно будет.

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

Но вернемся к вопросу цены. Назвать общую стоимость и даже наметить этапы работ в начале сотрудничества не реально. Для этого у вас просто недостаточно данных. Я нашел такой выход: предлагаю работать поэтапно, и обсуждать каждый из этих этапов отдельно. И первым из них называю работу с программным продуктом. Я его выбираю, произвожу перенос остатков, т.е. готовлю к внедрению. Этот этап посчитать не сложно. Сумма и сроки чаще всего оказываются совсем небольшими. Клиент видит вполне демократичную стоимость работы и возможность уже в ближайшей перспективе получить что-то конкретное за свои деньги. Чаще всего, это предложение встречает понимание и, как следствие, одобрение.

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

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

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

Брифы и техзадания: обойдемся без них!

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

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

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

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

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

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

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

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

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

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

Вместо послесловия

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

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

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

Особенностью отечественного программирования является то, что автор 90% времени тратит на создание прекрасной программы, и только 10% на то, чтобы правильно ее преподнести. Такой подход не всегда приносит желаемые плоды, ведь встречают все-таки по одежке.

• Как представить свою программу
• Как описать программу
• Как создать свою обучающую программу

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

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

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

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

У разработчиков, как и у писателей, бывает ступор, когда хочешь что-то написать, но не знаешь что.

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

Для чего это нужно:

• Улучшить навыки программирования.
• Опробовать новые технологии.
• Наполнить портфолио.
• Использовать как примеры, создавая собственные уроки.
• Их легко выполнить, а также можно добавлять новые фичи.

Это не просто список проектов. Здесь есть детальное описание каждого задания, чтобы помочь вам начать разработку с нуля.

В описании каждого проекта вы найдёте:

1. Постановку задачи.
2. Описание возможностей, которые должны быть реализованы (это скорее подсказка, чем жёсткое условие. Вы можете добавлять собственные функции, если хотите).
3. Список дополнительных фич, реализация которых поможет прокачать ваш проект и мозги.
4. Ссылки на ресурсы, которые помогут вам выполнить проект.

Все проекты разделены на три уровня сложности:

1. Начальный — для новичков, которые как правило сосредоточены на разработке пользовательских приложений.
2. Средний — более опытные разработчики, которые уже знакомы с UI/UX, умеют пользоваться инструментами разработки и внедрять API сервисы в свои приложения.
3. Продвинутый — те, кто прошёл две предыдущие стадии и хочет улучшить навыки изучив новые техники, например внедрение бэкенд приложений и баз данных.

Далее представлены по 5 проектов для каждого уровня (всего 15). На данный момент мы собрали более 30 проектов, их можно найти на GitHub. В дальнейшем мы планируем пополнить этот список.

Уров е нь: 1 — Начальный

Описание: создаёт и хранит напоминания

Возможности

• Создать запись.
• Редактировать запись.
• Удалить запись.
• При закрытии окна, записи сохраняются. Открыв приложение, сохранённые записи восстанавливаются.

Дополнительные фичи

• Пользователь может создавать и редактировать записи в формате Markdown. При сохранении данные конвертируются в HTML.
• Пользователь может посмотреть дату создания записи.

Ссылки и ресурсы

Пример проекта

Уровень: 1 — Начальный

Описание: вам необходимо создать мигающую гирлянду. Задача — нарисовать ряд из семи разноцветных кружков (огоньков), интенсивность каждого огонька будет меняться в зависимости от таймера. Когда текущий огонёк становится ярче, предыдущий тускнеет, возвращаясь к исходной интенсивности.

Проще говоря, симуляция новогодней гирлянды.

Возможности

• Кнопка для запуска/остановки мигания.
• Можно менять интервал мигания.

Дополнительные фичи

• Выбор цвета каждого огонька.
• Выбор уровня яркости.
• Изменение размера любого огонька.
• Выбор количества рядов (от 1 до 7).

Ссылки и ресурсы

Пример проекта

Уровень: 1 — Начальный

Описание: для веб-разработчика важно понимать основы работы с изображениями, потому что UI/UX современных приложений во многом на них опирается.

В приложении вы реализуете возможность вращения изображения. На экране отображается 4 копии одного изображения, представленного в матрице 2 на 2. Используя стрелки вверх, вниз, влево и вправо рядом с каждым изображением, пользователь может повернуть их вертикально или горизонтально.

Допускается использовать только чистый HTML, CSS, и Javascript. Сторонние библиотеки не допускаются.

Возможности

• Отображение 4 копий одного изображения в матрицы 2 на 2.
• Рядом с каждой копией есть стрелочки вверх, вниз, влево и вправо, с помощью которых пользователь может вращать каждое изображение.

Дополнительные фичи

Ссылки и ресурсы

Пример проекта

Уровень: 1 — Начальный

Описание: тест, в котором можно проверить свои знания, отвечая на вопросы.

Создайте приложение для других разработчиков, в котором они смогут проверить свои знания HTML, CSS, JavaScript, Python, PHP и т.д.

Возможности

Дополнительные фичи

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

Ссылки и ресурсы

Пример проекта

Уровень: 1 — Начальный

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

Возможности

Дополнительные фичи

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

Ссылки и ресурсы

Пример проекта

Не пропустите 5 приложений среднего уровня сложности во второй части.

Читайте также:

  
• Приложение ленд ровер remote не запускает двигатель
  
• Как работать с приложением лайм такси
  
• Бизнес аккаунт в whatsapp что это
  
• Как изменить цвет сообщений в вайбере
  
• Ошибка при запуске приложения 0xc00000116 windows 7 как исправить