В этой главе: Достаточно простого дизайна
- Вы узнаете несколько важных советов, как ускорить разработку нужных компонентов.
- Получите инструменты, которые помогут вам понять, стоит ли создавать функционал.
- Поймете, как отличить необходимые функции от полезных.
Извините, но я все равно не собираюсь учить вас, как стать блестящим дизайнером. Вместо этого я собираюсь научить вас кое-чему не менее важному: когда не стоит заниматься дизайном. Если в предыдущей главе речь шла об основах, которые вам необходимо знать, чтобы что-то спроектировать, то в этой главе мы расскажем о том, как понять, когда вообще не стоит начинать процесс проектирования.
Помните, что важно знать, как что-то проектировать, но не менее важно знать, когда не стоит ничего проектировать. Избегать лишней работы - это не значит лениться. Это разумно. Это означает, что у вас будет больше времени для качественной дизайнерской работы над важными вещами.
Видите ли, прелесть методологии Lean в том, что она заставляет вас избавиться от многих старых, укоренившихся привычек, которые замедляли вашу работу и заставляли проектировать то, что так и не было создано, или создавать то, что так и не было использовано.
Lean UX часто заключается в достаточном количестве дизайна. Пожалуйста, обратите внимание, что слово “достаточный” здесь очень важно. "Достаточный дизайн" не означает "дрянной дизайн" или "сложный в использовании дизайн". "Достаточный дизайн" означает выполнение того, что вам нужно, чтобы научиться тому, чему вы хотите научиться.
Создавайте необходимый, а не аккуратный дизайн
Дизайнеры разрабатывают дизайн. Это прямо указано в названии должности. Проблема в том, что мы можем перестараться с дизайном. Мы можем потратить много времени, сосредоточившись на деталях, видении и множестве других вещей, которые напрямую не связаны с решением проблемы.
Послушайте, я только что объяснил, что вам нужно выяснить, как вы собираетесь тестировать, чтобы понять, действительно ли изменение дизайна принесло ощутимые изменения в ваш бизнес. Теперь давайте поговорим о том, как убедиться, что вы вносите только те изменения в дизайн, которые приносят ощутимые изменения в ваш бизнес.
Это две разные вещи. Серьезно.
Независимо от того, являетесь ли вы опытным дизайнером или кем-то, кому просто нужно знать дизайн в достаточной степени, чтобы представить свой продукт вниманию пользователей, вам придется перестать думать о дизайне в первую очередь как о способе сделать вещи красивыми, крутыми или интересными. Ваша цель при создании такого дизайна - сделать все простым, очевидным и полезным.
Для этого нужно исключить все, что не является необходимым для подтверждения вашей гипотезы или изменения ключевых показателей.
Эту концепцию сложно понять, поэтому давайте рассмотрим несколько примеров, как хороших, так и плохих. Вы что-нибудь покупали на Amazon в последнее время? О, подождите. Вы человек, так что, вероятно, так оно и есть.
Вы обратили внимание на все то, что есть на страницах с товарами? Этого очень много. Здесь есть рекомендации, обзоры и другие места, где можно купить, описания, рейтинги и... около миллиона других вещей. Также здесь продается по паре версий практически каждого продукта, известного человечеству.
Из-за того, как Amazon создает свой продукт, у меня есть достаточно высокая уверенность в том, что каждая из этих особенностей помогает ему продавать больше товаров. Я также знаю, потому что был рядом в то время, что у Amazon не было большинства из этих функций, когда она начинала продавать книги в доисторическую эпоху Интернета.
В этом-то и дело. На то, чтобы представить, спроектировать, создать и протестировать каждый из этих элементов, ушло очень много времени. Если вы решите создать страницу с товаром, на которой будут все эти материалы, вам лучше быть независимым и состоятельным, потому что это займет некоторое время.
Что Вам Следует Сделать Вместо Этого
Давайте представим, что вы собираетесь что-то продать. Что вам нужно, чтобы подтвердить, можете ли вы продать эту вещь?
Что ж, вам нужно все это:
- Причины, по которым человек может захотеть купить эту вещь
- Способ, которым люди могут указать, что они хотят купить эту вещь
- Достаточное количество людей, чтобы провести эксперимент и увидеть, сколько людей на самом деле хотят купить эту вещь.
Было бы здорово, если бы люди могли также прокомментировать то, что они купили? Конечно! Заставит ли это людей покупать эту вещь, если они не планировали покупать ее ранее? Вряд ли. Как насчет оценок за товар? Это существенно повлияет на количество людей, которые его покупают? Трудно сказать. А что, если бы вы показали людям больше товаров для покупки? Это могло бы увеличить количество их покупок.
Какие-либо из этих вещей абсолютно необходимы, чтобы проверить, будут ли люди покупать что-то у вас? Неа.
Видите ли, сначала вам нужно спроектировать и изготовить то, что абсолютно необходимо. В этом случае дайте людям то, что они, возможно, захотят купить, и дайте им возможность это приобрести. Другие вещи приятно иметь, но они не являются абсолютно необходимыми для подтверждения вашего предположения.
Они также мешают вам выпускать необходимые товары и заставляют людей покупать их у вас.
Когда вы разрабатываете новую функцию, например, страницу товара, на которой люди могут что-то покупать, постарайтесь сократить ее до самых необходимых частей. Возможно, для вас комментарии абсолютно необходимы, потому что вся ваша модель основана на личных рекомендациях о товарах. Возможно, рейтинги являются решающим элементом, потому что ваша идея заключается в том, что профессиональные рейтинги повышают желание совершать покупки.
Как бы то ни было, вам нужно сначала найти, спроектировать и создать все, что абсолютно необходимо, и не более того. Потому что, если с необходимым ничего не получится, есть большая вероятность, что использование того, что приятно иметь, не спасет ситуацию.
Вот еще один пример
Я поговорил с несколькими людьми из компании, у которой был довольно успешный продукт. Они хотели добавить в свой продукт новую функцию. Они потратили много времени на обсуждение того, как будет работать эта функция, что она будет делать для пользователей, как пользователи будут с ней взаимодействовать, и на все другие разговоры, которые вы обычно слышите о новых интересных функциях.
Затем они перешли к ключевому вопросу: как пользователи получат доступ к этой функции?
Они решили, что эта функция достаточно важна для того, чтобы включить ее в свою основную навигацию. К сожалению, не нашлось ни одного места, где их новая функция подходила бы наилучшим образом.
Они решили, что им нужно будет полностью изменить дизайн основной навигации для продукта. Это, конечно, означало, что все остальные небольшие изменения, которые они сохранили для основной навигации, должны были быть учтены в этом редизайне. Кроме того, им пришлось бы полностью изменить визуальный дизайн основной навигации. О, и если бы они делали полный визуальный редизайн навигации, очевидно, им пришлось бы обновить визуальный дизайн остальной части приложения, чтобы он соответствовал.
Я уже упоминал, что, когда они наконец запустили новую функцию, пользователям было на нее наплевать? Не удалось изменить ни один показатель, и в итоге компания полностью отменила ее.
Что они Должны Были Сделать
Они должны были сделать что-нибудь другое. Весь этот опыт был невероятно дорогостоящим и деморализующим, и я хотел бы сказать, что это единственный раз, когда я видел, как это происходит, но это было бы ложью.
Самое важное, что им не удалось сделать, - это проверить саму функцию, прежде чем изменять весь сайт, чтобы адаптировать ее.
Они могли бы сделать это несколькими способами:
- Они могли бы провести дополнительную проверку клиентов, прежде чем создавать функцию, чтобы посмотреть, решит ли она реальную проблему клиентов.
- Они могли бы добавить эту функцию и напрямую рекламировать ее небольшому проценту своих пользователей, а также прямо попросить их опробовать ее и оставить отзыв.
- Они могли бы добавить доступ к этой функции из какого-нибудь места, которое не являлось основной навигацией, но все еще было доступно пользователям, и протестировать ее там.
- Они могли бы просто внести небольшие изменения в текущую основную навигацию, чтобы привести функцию в соответствие с идеей о том, что они вернутся и улучшат отображение в основной навигации позже, если эта функция будет пользоваться успехом.
- Они могли бы использовать то, что я называю функциональной заглушкой. Это следующее.
Создайте заглушку функционального объекта
Ладно, этот последний пример меня расстроил. Давайте посмотрим на хороший пример правильного дизайна. Это, пожалуй, самый часто используемый прием в арсенале Lean UX. Это замечательно, потому что позволяет протестировать функцию, не создавая вообще ничего! Что может быть быстрее этого?
Я часто консультируюсь с компаниями, которые рассматривают возможность продажи определенного товара, пакета или функции. Например, я разговаривал с компанией, которая хотела начать взимать плату за определенные функции в своем бесплатном продукте.
Когда мы поговорили, они сразу же начали обсуждать такие вещи, как то, следует ли им взимать единовременную плату или подписку, следует ли им разрешить бесплатную пробную версию и какие платежи они должны принимать. Они сказали мне, что хотят, чтобы я спланировал процесс оплаты таким образом, чтобы пользователи с большей вероятностью покупали обновление.
Я остановился и задал вопрос, который, на мой взгляд, является достаточно важным: Есть ли у вас какие-либо доказательства того, что кто-то вообще купит эту штуку?
Причина, по которой я задал этот вопрос, заключалась в том, что все вопросы, на которые они пытались ответить, сложно решить, спроектировать и создать. Несмотря на огромное количество товаров, которые покупаются и продаются в Интернете, крупные потоки платежей по-прежнему могут быть сложными. Кроме того, знаете ли вы, что интеграция с платежными системами является основной причиной синдрома ярости разработчиков, который я только что полностью выдумал? Правдивая история.
Первым шагом было проверить, хочет ли кто-нибудь платить за какую-либо часть бесплатной системы компании. Вот дизайн, который вам нужен для проверки этого предположения: кнопка с надписью "Обновить" и статическая страница с ценой и несколькими функциями, которые вы можете предложить при обновлении.
Вам также нужен серверный интерфейс для подсчета количества людей, которые нажимают на эту кнопку, и способ A / B-тестирования того, как изменение цены и выгод влияет на конверсию. Это гораздо проще создать, чем целую платежную систему и поток платежей. Кроме того, у вас действительно должна быть возможность проводить A / B-тестирование такого рода материалов в любом случае.
Какое это имеет отношение к дизайну?
Ладно, я признаю это. Не похоже, что это имеет какое-то отношение к отличному дизайну. Это больше похоже на избегание дизайна. Но важная составляющая отличного дизайна - это тратить время на то, что важно, а не на то, что не сработает.
Если хотите, можете рассматривать это как планирование эксперимента. Ваша задача - разработать наилучший из возможных экспериментов, чтобы подтвердить или опровергнуть вашу гипотезу.
Возможно, ваша гипотеза заключается в том, что людям понравится ваша новая функция или они будут готовы платить за определенные компоненты вашей системы. Что бы это ни было, приложите как можно меньше усилий, чтобы выяснить, так ли это на самом деле, потому что вам придется проделать чертовски много работы, как только вы поймете, что люди отчаянно хотят того, что вы продаете.
Создайте функцию "Волшебник страны Оз"
В качестве консультанта я сотрудничал с компанией Food on the Table. В настоящее время в Food on the Table есть продукт, который помогает людям планировать свое питание с учетом того, что продается в местном продуктовом магазине. На момент написания этой статьи у них была информация о ежедневных распродажах буквально из тысяч продуктовых магазинов по всей территории Соединенных Штатов.
Это отличная идея. Кроме того, реализовать ее - огромная заноза в заднице. В конце концов, у вас должен быть какой-то способ собрать всю эту информацию из всех этих продуктовых магазинов, чтобы поделиться ею с пользователями. У вас также должен быть простой в использовании интерфейс для сбора информации от людей о том, где они делают покупки и какие блюда им нравятся.
Поэтому они этого не сделали. По крайней мере, сначала они этого не делали. Вместо этого они решили, что им нужно больше узнать о том, как люди совершают покупки и заинтересуют ли их продукты, которые они хотят создать.
Вместо того чтобы выполнять всю проектную и инженерную работу по созданию продукта для всех сразу, они привлекли нескольких потенциальных клиентов и выполнили всю работу вручную. Верно. Вместо того чтобы потратить первые несколько недель на сбор данных о продажах и создание пользовательского интерфейса, они отправились в магазин, получили рекламные проспекты и пообщались с потенциальными пользователями, чтобы помочь им спланировать прием пищи. Дизайн и разработка не требовались вообще.
Оказалось, что людям понравилась эта идея, и именно тогда они решили пойти дальше и начать проектировать и строить. Но если бы людям не понравилась эта идея, даже если бы кто-то в буквальном смысле сидел с ними и помогал бесплатно готовить, был бы какой-то смысл в создании остального продукта? Скорее всего, нет.
Мы называем это функцией "Волшебник страны Оз" или иногда консьерж-сервисом, и множество компаний постоянно пользуются ею. Вот еще несколько примеров отличных функций "Волшебника страны Оз".:
- Используйте краудсорсинг или что-то вроде Mechanical Turk для сбора данных, а не для написания кода для их сбора.
- Самостоятельно упаковывайте и отправляйте продукты, а не интегрируйтесь с центром распространения.
- Утверждайте заказы вручную, а не пытайтесь создать целую систему обнаружения мошенничества, чтобы убедиться, что у вас есть действительные заказы. Опять же, это дает вам возможность полностью отказаться от проектирования, потому что избежать ненужного проектирования - один из лучших способов сэкономить время во всей вселенной.
Решайте только важные проблемы
Сначала позвольте мне рассказать вам историю об очень маленькой ошибке, с которой мы столкнулись в Food on the Table, и которая оказала значительное влияние на показатели.
Как я упоминал ранее, Food on the Table позволяет пользователям составлять планы питания на основе того, что продается в местных продуктовых магазинах. Там была кнопка с призывом к действию, которая позволяла пользователю добавить блюдо в свой план питания.
Когда компания протестировала эту кнопку на месте, все сработало идеально. Пользователи нажимали на кнопку, и блюдо добавлялось. Срабатывало каждый раз.
Проблема возникала, когда пользователи с более медленным подключением или на более медленных компьютерах нажимали на кнопку. Во многих из этих случаев, когда пользователи нажимали на кнопку, задержка составляла до нескольких секунд. Это означало, что пользователь нажимал на кнопку, но ничего не происходило. Затем она нажимала на кнопку еще несколько раз, надеясь, что что-то произойдет. Когда нажатие кнопки регистрируется в пользовательском интерфейсе, пользователь несколько раз добавляет блюдо в свой план питания, что явно не входило в ее намерения.
Мы быстро обнаружили эту ошибку в ходе наблюдательного тестирования. Это происходило с достаточным количеством людей, и мы были уверены, что это негативно влияет на ключевые показатели, особенно для новых пользователей.
Затем нам нужно было придумать, как это исправить. Именно здесь возникла концепция “минимального использования дизайна”.
Теперь, как вы можете себе представить, существует множество способов устранить эту проблему. Немедленным инженерным решением могло бы стать уменьшение задержки нажатия кнопки, чтобы нажатие кнопки записывалось быстрее. Любой, кто когда-либо писал какой-либо код, поймет, что это потенциально очень сложная проблема.
Другой подход может заключаться в том, чтобы просто отразить в пользовательском интерфейсе внесенные пользователем изменения, не дожидаясь ответа от сервера. Это, конечно, чревато опасностями, поскольку может привести к тому, что то, что видит пользователь, не будет синхронизировано с тем, что находится в базе данных.
Я мог бы предложить вам пять или шесть других возможных решений, но самое простое, к которому мы пришли, - это просто показывать индикатор рабочего состояния на выключенной кнопке до завершения процесса. Поскольку ожидание никогда не превышало нескольких секунд, люди были вполне довольны тем, что их выбор был записан.
Почему я рассказываю эту историю? Важно понимать, что в данном конкретном случае это решение сработало по многим причинам. Например, пользователи, как правило, добавляли в свои планы питания только три-пять приемов пищи одновременно. Ожидание добавления каждого из них в течение нескольких секунд существенно не повлияло на общее время выполнения задания. Если бы это было задание, которое им приходилось повторять сотни раз, трехсекундная пауза стала бы проблемой.
Об этом важно помнить. Если все пойдет хорошо, то в течение срока службы вашего продукта вы внесете гораздо больше мелких, повторяющихся изменений, чем крупных, радикальных. Важно иметь процесс определения минимально возможного изменения, которое вы можете внести в соответствии с вашей ситуацией.
Как Вы можете Сделать Это Прямо сейчас
Найдите ошибку, которую вы хотите исправить. Это не ошибка типа опечатки. Что-то, что явно влияет на ваши показатели, но может не иметь абсолютно очевидного решения. Это может быть ошибка взаимодействия с пользователем, например, “Никто не знает, как предоставить общий доступ к файлу”, или техническая ошибка, например, “Загрузка фотографии профиля занимает пять минут”.
Первый шаг - определить, стоит ли ее вообще исправлять. Для этого попробуйте ответить на следующие вопросы:
- Кого затрагивает эта проблема?
- Как часто она затрагивает их?
- Какой ключевой показатель она потенциально может повредить?
Если это в значительной степени влияет на важных пользователей и негативно влияет на ключевые показатели, это, безусловно, стоит исправить. Если это два из трех возможных вариантов, то, вероятно, все равно стоит исправить. Дело в том, что не все ошибки нужно исправлять, но слишком много серьезных ошибок могут создать крайне негативный опыт для ваших пользователей.
Следующий шаг - найти ключевую проблему, которую они создают для пользователей. Проблема не обязательно заключается в том, что приложение ведет себя не так, как ожидалось. Это должно мешать людям успешно использовать ваш продукт.
Лучший способ по-настоящему понять проблему - это, конечно, увидеть ее в действии. Попросите реальных пользователей показать вам проблему на их компьютерах или устройствах. Поймите, в чем заключается ошибка, когда люди с ней сталкиваются и что это мешает им делать.
Теперь — и это самая сложная часть проектирования — вам нужно решить реальную проблему, вызванную ошибкой. Здесь вам нужно провести мозговой штурм с несколькими различными решениями. Выбранное вами решение должно удовлетворять двум важным правилам:
1. Это должно решить проблему, с которой сталкиваются пользователи.
2. Это должно быть лучшее решение, требующее наименьшего количества времени.
Я почти слышу, как некоторые из вас говорят: “Но иногда то, что занимает очень мало времени сейчас, может стоить времени в будущем!” Это и верно, и неуместно. Старайтесь не решать проблемы, которых у вас еще нет. Если вы будете слишком долго решать эту проблему, ваша компания может не дожить до решения следующей.
Вот почему в моем примере мы решили просто показать пользователю, что его нажатие кнопки было принято, а не реализовывать более дорогостоящее решение, позволяющее значительно ускорить обращение к серверу.
Мы не стали делать ничего сложного, потому что в этом не было необходимости. Мы могли бы решить главную проблему пользователей — они нажимали на кнопку слишком много раз, потому что не знали, сработает ли она с первого раза, — просто сообщив им, что это сработало с первого раза.
Это может показаться длительным процессом для того, что кажется таким простым, как исправление ошибки. И, конечно, я никоим образом не призываю вас делать это при исправлении опечаток. Но всякий раз, когда существует несколько подходов к исправлению ошибки, некоторые из них будут работать быстрее, чем другие. Потратив немного времени на поиск более быстрого способа решения проблемы, вы в конечном итоге сэкономите свое время.
Еще одна вещь, которую, как вы, возможно, заметили, я не советовал вам делать, - это тщательное редактирование и тестирование исправленной ошибки пользователями. Существует множество изменений в дизайне, когда это необходимо. Этот тип исправления ошибок пользовательского интерфейса, при условии, что проблема пользователя достаточно хорошо понята заранее, как правило, не требует создания прототипов или тестирования юзабилити.
Перестаньте беспокоиться о подстаканниках
У каждого стартапа, с которым я когда-либо общался, слишком мало ресурсов. Программисты, деньги, маркетинг...как ни крути, у стартапов их не хватает.
Когда у вас недостаточно ресурсов, расстановка приоритетов становится еще более важной. Вы не можете позволить себе роскошь воплощать в жизнь каждую вашу замечательную идею. Вам нужно выбирать, и жизнь вашей компании зависит от разумного выбора.
Почему так много стартапов так усердно работают не над тем, что нужно?
Под “неправильным материалом” я, конечно же, подразумеваю материал, который не влияет на ключевые показатели — проекты, которые не превращают людей в новых пользователей, не увеличивают доход или не способствуют удержанию персонала. И это особенно проблематично для новых стартапов, поскольку им часто не хватает действительно важных функций, которые бы определяли все эти ключевые показатели.
Это похоже на то, как если бы у них был автомобиль без тормозов, и они беспокоились о создании идеального подстаканника.
По некоторым причинам, когда вы находитесь в процессе выбора функций для своего продукта, бывает очень трудно отличить тормоза от подставок для стаканов. Как вы это делаете?
Для начала вам нужно задать два простых вопроса (и ответить на них):
- Какую проблему это решает?
- Насколько важна эта проблема по сравнению с другими проблемами, которые мне предстоит решить?
Чтобы точно ответить на эти вопросы, полезно определить некоторые вещи, над которыми часто работают и которые просто не приносят большой отдачи. Итак, как выглядит проект подстаканника? Часто он выглядит следующим образом.
Визуальный дизайн
Визуальный дизайн может быть невероятно важен, но в 9 случаях из 10 это подстаканник. Очевидно, что цвета, шрифты и верстка могут влиять на такие вещи, как конверсия, но, как правило, это скорее оптимизация конверсии, чем драйвер конверсии.
Например, тот факт, что вы вообще разрешаете пользователям покупать товары на вашем сайте, оказывает гораздо большее влияние на доход, чем цвет кнопки "Купить". Возможно, это крайний пример, но я видел, что слишком много компаний тратят время на споры о визуальном оформлении невероятно важных функций, что в конечном итоге приводит к задержке их выпуска.
Продолжайте. Сделайте свой сайт красивым. Некоторые из этих визуальных улучшений могут даже повлиять на ключевые показатели. Но каждый раз, когда вы откладываете выпуск новой функции, чтобы убедиться, что у вас получился правильный градиент, спрашивайте себя: “Я изменил дизайн подстаканника или увеличил турбонаддув двигателя?”
Особенности удержания
Удержание - это очень важный показатель. Вам обязательно следует подумать о том, как удержать своих пользователей, как только они у вас появятся.
Слишком многие люди начинают беспокоиться о том, что у них есть отличные возможности для удержания, задолго до того, как у них появятся пользователи, которых нужно удержать. 100%-ное удержание - это замечательно, но если ваши показатели привлечения и активации слишком низкие, вы можете сохранить одного по-настоящему счастливого пользователя до тех пор, пока не обанкротитесь.
Прежде чем тратить много времени на разработку вознаграждений для суперпользователей, спросите себя, готовы ли вы к этому. Помните, что отличный дизайн подстаканников может сделать людей, у которых уже есть автомобиль, невероятно счастливыми, но сначала вы должны убедить их купить его, а никто никогда не покупал junker для подстаканников.
Анимация
Я не противник анимации. На самом деле, иногда отличная анимация или другие подобные детали в дизайне могут сделать функцию замечательной. Иногда хорошо продуманная анимация может уменьшить путаницу и сделать функцию простой в использовании.
Проблема в том, что вы должны понять, сделает ли добавляемая вами анимация вашу функцию значительно более удобной для использования или просто немного круче.
Как правило, если вам приходится выбирать между "полезным" и "крутым", выбирайте "полезное" в первую очередь. Я не говорю, что вы не должны пытаться сделать свой продукт "крутым". Вам обязательно нужно это сделать.
Но на создание правильной анимации может потребоваться непропорционально много времени и ресурсов, и, если только она не добавляет чего-то действительно важного в ваш интерфейс, вам, возможно, лучше отложить ее на потом.
“Но подождите”, - кричит легион дизайнеров. “Мы не должны выбирать между полезным и крутым! Apple не выбирает между полезным и крутым! Они просто выпускают идеальные продукты!”
Это приятно. Когда у вас больше денег, чем у большинства правительств развитых стран, у вас меньше ограничений в ресурсах, чем обычно бывает у стартапов. Стартапы каждый день делают выбор между полезным и крутым, и я изучил достаточно показателей, чтобы знать, что многие классные, но непригодные для использования продукты используются ровно один раз, а затем сразу же отбрасываются, потому что они слишком запутанные.
Может показаться, что это противоречит моей точке зрения о том, что сначала нужно привлечь пользователей, а потом беспокоиться об удержании, но я хотел бы отметить, что есть существенная разница между решением проблем долгосрочного удержания и тем, чтобы сбить с толку новых пользователей настолько сильно, что они никогда не вернутся.
Прежде чем тратить много времени на то, чтобы ваша анимация без проблем работала в любом браузере, спросите себя, действительно ли отдача, которую вы получаете, стоит затраченных усилий или вы просто создаете анимированный подстаканник.
Ваша Фича Здесь
Я не могу назвать все проекты, которые могли бы стать подстаканниками. Это всего лишь несколько примеров, которые я неоднократно видел.
И, честно говоря, подстаканник для одного продукта может быть функцией другого продукта. Единственное, что имеет значение, - это то, насколько сильно предлагаемые вами изменения могут повлиять на ключевые показатели.
Как бизнес, вы должны решать проблемы, которые имеют наибольшие шансы обеспечить ваше выживание. Проекты с подстаканниками - это отвлекающие факторы, которые отнимают у вас слишком много времени, и от вас зависит, чтобы каждый проект, за который вы беретесь, приносил вам достойную отдачу.
Если вы хотите идентифицировать подстаканники, обязательно задавайте себе вопрос, какую проблему решает та или иная функция и насколько важна эта проблема по сравнению со всеми другими проблемами, которые вы могли бы решить. Подстаканники решают проблему, куда поставить напиток. Тормоза решают проблему, как уберечь вас от столкновения со стеной.
Конечно, если бы у меня был выбор, я бы предпочел, чтобы вы построили мне машину, которая ездит сама по себе. Тогда я смогу держать свой напиток обеими руками.