Содержание
Эта статья впервые появилась в 235-м номере журнала .net - самого продаваемого журнала для веб-дизайнеров и разработчиков.
Вы убедили своего клиента, что он не должен поставлять продукт с функциями, которые их клиенты, вероятно, никогда не будут использовать. Но как тогда получить нужные функции в дорожной карте? Как вы гарантируете, что эти функции сделают продукт более полезным, а не добавляются просто по прихоти?
Продукт, наполненный функциями, которые не приносят ощутимой выгоды для бизнеса и его клиентов, на самом деле не очень хороший продукт. Множество функций, объединенных вместе, равносильно… набору функций. Чтобы сделать хороший продукт, вам нужно «склеить» все функции вместе с чем-то, что что-то значит для тех, кто будет использовать продукт, а также представляет ценность для людей, производящих его. Этот клей, на мой взгляд, должен быть преимуществом, которое продукт дает этим двум очень разным группам людей.
Преимущества, а не особенности
Спросите любого приличного продавца, что они продают, и он, скорее всего, дословно произнесет: «Продавайте выгоды, а не характеристики!» Так почему же, когда мы создаем продукты для Интернета, мы постоянно попадаем в ловушку приоритизации функций и забываем о преимуществах, которые эти функции предоставляют нашим клиентам? Потому что функцию намного легче оценить и создать, чем получить выгоду. Чтобы прояснить преимущества и донести их до людей, нужно время. Иногда выгода становится очевидной только тогда, когда несколько разных функций сгруппированы вместе.
В качестве примера возьмем Basecamp, популярный инструмент для совместной работы над проектами от 37signals. Если вы перечислите его функции, вы получите что-то вроде этого: список дел, обмен сообщениями, календарь, хранилище файлов с дополнительным групповым чатом и письмом. Уберите любую из первых четырех функций, и вы потеряете преимущество - сотрудничество. Некоторые из них не исключают друг друга; например, список дел (Ta-da List) - это отдельный продукт. Но выгода в другом, как и у пользователей.
Если выгода не связана внутренне с функцией или группой функций, для них слишком легко установить приоритет вверх или вниз в соответствии с точкой зрения самого важного или самого громкого человека. Это не имеет большого значения, если у вас есть небольшая, последовательная команда людей, каждый из которых владеет видением, но это не масштабируется на большом проекте с несколькими заинтересованными сторонами. Помощь людям в принятии правильного решения в отношении продукта путем предоставления четких рамок принятия решений может быть очень полезной.
Поэтому нам нужно начать с того, чтобы все функции, которые мы разрабатываем и создаем, неразрывно связаны с теми преимуществами, которые они предоставляют. Но как мы можем это сделать? Нам следует подумать о двух ключевых вещах: выравнивании и отображении.
Согласованность означает, что все, что вы делаете, должно быть напрямую согласовано с видением продукта. Если нет, то зачем вы это делаете? Либо ваше видение неверно, либо вы тратите ресурсы на то, что не принесет вам или вашим клиентам тех преимуществ, которые вы изложили. Вы должны постоянно сверять свои идеи с собранными вами выводами - недостаточно знать, что вы делаете; вам также нужно знать, почему вы это делаете. Более того, каждый в команде должен знать, зачем вы это делаете. Если люди знают, почему, то становится намного проще. Вы можете перестать болтать «а что, если?» И начать говорить о том, что, как вы знаете, является правдой.
Если вы не знаете, что что-то является правдой, у вас есть два варианта: провести небольшое исследование, чтобы проверить свою идею, или оставить ее. Вы всегда можете вернуться к чему-то позже в жизненном цикле продукта. Я лично сторонник парковки как можно больше: чем меньше работы вы возьмете на себя, тем больше у вас шансов вытащить что-то из дверей, и это должно быть вашей основной задачей. Преимущество создания чего-либо в цифровом виде состоит в том, что создавать и поставлять что-либо относительно несложно. Менять просто и мгновенно! В отличие от других отраслей, в которых нужно опасаться изменений.
Может показаться, что я говорю о «бережливом подходе», на самом деле не упомянув об этом; Я не. Я говорю о хорошем дизайне. Я действительно думаю о минимально жизнеспособном продукте (MVP) и других практиках, связанных с бережливым подходом, когда я работаю, но не за счет опыта. Возможно, минимальный жизнеспособный опыт? Это просто здравый смысл: делать меньше, лучше, а не все сразу по посредственным стандартам. Ничто из того, о чем я здесь говорю, не предполагает, что вы должны отгружать полуфабрикат, речь идет о доставке продукта, который попадает в золотую середину. И да, это не новая идея.
Паркуйся и катайся
Представим, что вы припарковали все, что, по вашему мнению, может работать, и собираетесь спроектировать и построить вещи, которые, как вы знаете, попадут в эту золотую середину. Вы можете сопоставить эти функции с преимуществами, которые они принесут вам или вашим клиентам. Но это еще не дает вам законченного продукта.
Вам нужно начать картировать все это, чтобы получить несколько ключевых путешествий, а затем вы можете приступить к их проектированию. (На самом деле вы уже давно занимаетесь дизайном - дизайн больше не сводится к тихому рисованию каркасов.) После этого вы сможете оценить, какое из этих путешествий принесет наибольшую пользу, и расставить приоритеты в своей работе.
Такое группирование объектов означает, что вы можете присвоить им значение. Вы также получаете завершенные задачи или путешествия, которые можно спроектировать от начала до конца.
Несколько лет назад я работал над гибким проектом, и мы этого не сделали. Мы разрабатывали пользовательские истории, которые были расставлены по приоритету с учетом количества усилий, которые они потребовали бы для завершения, как с точки зрения разработки, так и с точки зрения дизайна. Ближе к концу проекта мы начали замечать «трещины», появляющиеся в промежутках между спринтами. Мы вернулись и заделали эти трещины, и все заработало.
Сейчас, оглядываясь назад, я понимаю, что это была не такая большая драма, как казалось в то время. Но было два ценных урока: наброски каркасов - это не то, где начинается или заканчивается дизайн; и когда кажется, что ваш мир рушится, проблема, вероятно, не так велика, как вы думаете. Дизайн начинается задолго до этого, на начальных этапах проекта, и инструменты выбора - это карты опыта и путешествия пользователя. Если вы не участвуете в начальных этапах плана проекта - который, как я уже сказал, является дизайном - и дорожной карты продукта, вы не выполняете свою работу в качестве дизайнера.
Такое согласование и сопоставление функций и преимуществ означает, что вы можете решить, на что вам следует потратить свой бюджет для получения максимально возможной прибыли. Как вы количественно оцените эту отдачу, зависит от вас.
Как дизайнеры, мы обладаем ценными навыками, которые мы можем использовать, чтобы облегчить этот процесс планирования / проектирования. Но было бы глупо думать, что мы можем делать это в полной изоляции. Если вы не эрудированный единорог, не тратите собственные деньги и не определяете свой успех, то сотрудничество и содействие являются ключами к успеху.
Откройте для себя 20 лучших инструментов создания каркасов для дизайнеров в Creative Bloq.
