Post #37

Про концепции. Заметка №2 Добавлю сразу пару слов что такое концепции в том смысле, как я их делаю. Итак, концепты легко попутать с макетами интерфейса. Но фрейминг и задачи у них принципиально иные (поэтому, в частности, концепты категорически нельзя показывать без комментариев, либо передавать разработчикам на оценивание/валидацию). Я бы сформулировал концепцию так: концепция — это коммуникативный инструмент, визуализирующий продуктовые гипотезы и варианты их решения для последующего обсуждения. Когда продукта еще нет, но есть много рассуждений, возникает проблема в том, что люди не понимают друг друга — особенно представители бизнеса, которые способны мыслить на разных уровнях абстракции, причём больше с позиций целей и задач, чем реализации. И даже если используются общие термины, каждый вкладывает в них своё. Именно поэтому часто нужен концепт — для облегчения обсуждений будущего продукта. Причём независимо от того, есть ли конкурентные аналоги (ибо нам нужно отстраиваться от них, а не думать аналогиями), или это инновационный продукт. Концепция — далеко не всегда ваерфрейм (если только участники продуктовой команды уже не знакомы с подобными подходами). Она обладает дизайном, а контент в ней реалистичен — ибо стейкхолдеры могут легко отвлекаться на заглушки или же видеть что-то своё за квадратами. При этом там нет никаких ветвистых сценариев, а многие функциональности замылены — ибо их ещё никто не определял. На мой взгляд лучший способ подачи концепта — презентация. Ибо обязательным составом концепции являются: * Схемы основных воркфлоу * Ключевые идеи и принципы продукта * Ну и сами мокапы Как следует из определения, концепция — не совсем предложение, как делать продукт. Визуализация макетов нужна лишь для облегчения коммуникции, но при этом любой автор и пользователь концепции должен исходить, что это в высокой степени материал на выброс, это в первую очередь для обсуждения проблемы, и только потом её решения. Разумеется, в условиях ограниченных ресурсов нужно постараться, чтобы концепт был максимально полезным и с позиций решения проблем. Но first things first. Именно поэтому в концепт обязательно включение принципов/идей — почему мы считаем что наше понимание проблемы таково, а виденье её решений — вот такое. Просто картинки, ввиду размытости их интерпретаций на ранних этапах — не облегчат понимание, а испортят его ровно в тот момент, когда концепт «пойдёт по рукам». Если концепт всем понравился — это должно настораживать, мигом идём валидировать с внешним миром. Также концепт не должен содержать никакого маркетинга — это не инструмент продажи (хотя, честно уж скажу, что этот элемент есть — но не стоит рисовать космос и звездолеты, ибо это внутренний инструмент, и любой программный архитектор быстро поставит на место). Если концепт вызвал бурную и подробную критику, обозначил противоречия во взглядах стейкхолдеров, сгенерировал кучу предложений — это очень хорошо. Выбрасываем его, делаем следующую итерацию. В каком-то смысле концепт — это визуализация тех саымх «правильных вопросов, содержащих большую часть ответа» (см. историю выше и рассказ Роберта Шекли). Но бывает что он не вызывает никакого отклика. Это значит что концептуализатор и стейкхолдеры не синхронизированы в плане ожиданий. Об этом потом.