Концепция приложения. Брифинг

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

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

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

О приложении

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

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

— приложение делает.

а/ продает что-то в физическом/виртуальном мире? (Aviasales)

б/ приложение самоценно и поставляет какой-то контент? (Instagram)

в/ (посередине) приложение поставляет некий медиа-контент? (Apple Music)

— структура приложения: здесь важно ответить на вопрос “Какой сценарий является целевым — то есть как пользователю как можно скорее попасть на основной сценарий?

— конкуренты:

а/ от кого отстроиться?

б/ к кому стать ближе («мимикрировать» — а если точнее, создать приложение, для которого нет сверхзадачи отличаться чем-то, а важно использовать правильные сложившиеся паттерны)? Попытка сломать паттерн становится иногда причиной сложностей для продукта. Пример — Hipmunk

— масштабируемость. Планируется ли расширять приложение далее для внедрения других продуктов?

— платформы. Какие платформы планируется использовать и какие из них являются приоритетными?

О концепции:

— задача концепции: визуальная, функциональная? Раскрою: что именно мы хотим проверить и утвердить в рамках этапа концепции — визуальную составляющую или пользовательский опыт? Или и то и другое?

— как мы будем оценивать концепцию? Для этого надо обратиться к блоку “О продукте” и держать его в голове.

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

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

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

б/ субъективные. В определенных регионах не использовать определенные знаки и цвета. Будьте внимательны в этом вопросе и проявите толику терпения в изучении. Рекомендую полистать замечательную книгу Шона Адамса и Терри Ли Стоуна “Дизайн и цвет. Практикум”.

— стилистика бренда:

— есть ли брендбук? Это очень важная составляющая, по сути это голос, которым говорят продукты компании. Если продукт это модель, то брендбук это наряд, в который он/она одеваются. Приведу пример: мы как люди обладаем 2 руками и 2 ногами. Еще головой. И вот теперь представьте себе разницу между одной фигурой, одетой во все темное и мрачное. И второй — одетой в теплое и яркое. Разница очевидна.

— если нет — определить цветовую схему. Удачный пример и возможность для этого — это цветовой круг Иоханнеса Иттена. Если хотите проще и быстрее — вот еще два прекрасных гайда: How to design a strong visual identity for digital products и How to Choose Colors for Mobile App Design (5 Principles)

Отдельный блок — это “целевой сценарий” и критерии его проектирования.

• концентрация пользы — отношение полезной к условно неполезной площади экрана. Чем выше, тем лучше. Но! В разумных пределах — потому что важно иметь ввиду…
• плотность логики. Это второй параметр, который служит ограничителем в “концентрации пользы”. То есть нужно устоять перед желанием напичкать все в один экран. Важно раскрывать логику постепенно.
• привычность. Уже упоминавшийся параметр, но здесь сфокусирую на нем еще раз внимание аудитории. Если целевая аудитория привычно использует Facebook (например, и да — признана в России экстремистской организацией) — не стоит пытаться пересаживать его что-то другое с точки зрения паттернов.
• предусмотрительность. Это способность интерфейса предугадывать действия пользователя, идти “на шаг впереди”. Пример тому — агрегаторы билетов, которые предзаполняют формы, как бы предугадывая ваш следующий шаг.
• открытость. Не прятать информацию и логику за непонятными символами и копирайтом.
• разборчивость и эргономичность. Способность интерфейса быть разборчивым и одновременно эргономичным. Удачные примеры — это приложения для заказа такси, еды и тому подобного. Мы такие действия часто осуществляем на ходу — и здесь важно давать пользователю возможность не путаться и осуществлять целевое действие без ошибок.

С точки зрения концепции супер-правильно было бы включать ее тестирование на представителях целевой аудитории. Очень полезно выйти из своей скорлупы и услышать отклик реальных потенциальных пользователей.

Что еще почитать:

• Фундамент для создания дизайн-концепции интерфейса: большая идея, мудборд и референсы (by red_mad_robot) — вот тут кладезь всяких хинтов о том как именно проектируется концепция.

Как Создать Концепцию Программного Продукта и Что Это Такое?

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

Намного хуже, если вы потратили несколько десятков тысяч долларов, несколько месяцев, а продукт оказался провальным, к примеру для скрипта криптовалюной биржи. Это очень печально, хотя возникает достаточно часто в стартап индустрии. Чтобы избежать риска и выпустить полностью успешный проект, еще до начала программной разработки стоит проверить концепцию (proof of concept, POC).

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

Что такое концепция программного продукта?

Концепция ПО это тестирование готового продукта на основе прототипа. Таким образом данный этап является первой фазой в процессе проектирования приложения. Он объясняет как проект должен работать на основе детального описания требований и спецификации. Доказательством является полное удовлетворение тех функций которые необходимо реализовать.

Такой подход позволяет легче нанять разработчиков для стартапа в будущем. Для того чтобы подтвердить концепцию в программной разработке необходимо сформулировать основные задачи и выполнить следующие этапы: 1.Определить цели проекта и методы их реализации. 2.Получить обратную связь от пользователей и клиентов. 3.Скоректировать идею и приступить к реализации.

Цели проекта и методы их реализации

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

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

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

Обратная связь от пользователей и клиентов

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

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

Корректировка идеи и реализация

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

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

Выводы

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

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

Оцените (330 оценки — 4.3 из 5)

При подготовке материала использовались источники:
https://vc.ru/u/23101-dmitry-moroz/574408-koncepciya-prilozheniya-brifing
https://merehead.com/ru/blog/proof-concept-software-development/