Инженерный подход к разработке дизайна (ориентированного на ЦА)
Современный продуктовый дизайн полон ограничений и противоречий, которые порой сильно сковывают полет фантазии дизайнера. При разработке дизайна, ориентированного на целевую аудиторию фраза “я художник, я так вижу” перестала быть актуальной уже давно. В этой статье хочу поделится своими мыслями и наблюдениями о системном подходе к работе над любой задачей или процессе внедрения новой функции.
Итак, в чем заключается основная мысль статьи ? При поиске решения творческой задачи всегда нужно отталкиваться от идеального решения. Например в ТРИЗ (Теория Решения Изобретательских Задач) существует метод “ИКР” (идеальный конечный результат), в котором для решения проблемы предлагается придумать лучшую версию этого самого решения, при котором системы нет, но ее функция выполняется. Либо, что еще лучше, придумать условия, при которых функция, над которой мы работаем, не нужна совсем.
Вот например отрывок из книги “Думай как инженер. Как превращать проблемы в возможности”:
“…компьютерные инженеры применяют концепцию под названием «денормализация», суть которой — думать об ограничениях в обратном направлении. «Вы как будто начинаете с идеального мира, — поясняет Нараяна Мурти, основатель фирмы Infosys, занимающейся разработкой программного обеспечения и консалтингом, — и проектируете систему так, будто никаких ограничений нет. А потом, шаг за шагом, начинаете их вводить и идти на компромиссы».
При этом, чтобы достичь поистине выдающихся результатов необходимо соблюдать несколько важных условий. Во-первых творческая задача должна быть четко сформулирована. Это помогает мозгу лучше сочетать разные понятия и комбинировать идеи для поиска решения.
Чем точнее формулировка творческой задачи, тем легче найдется ее решение… Творческая задача — это рисунок на коробке, без которого сложно собрать пазл.
Отрывок из книги “Гибкий ум”. Эстанислао Бахрах
Второй важный момент — это количество идей, которое необходимо придумать для решения задачи. Как и во время любого мозгового штурма — чем больше идей, тем лучше. Нужно отключить внутреннего критика и поработать над количеством идей удовлетворяющих условиям поставленной задачи, а затем из них выбрать самую лучшую.
…нужно производить идеи, не задумываясь о том, плохие они или хорошие, можно ли воплотить их в жизнь, решат ли они проблему. Дайте себе время думать без цензуры. Для этого я всегда советую поставить себе цель по времени и количеству идей. Тем самым вы направляете творческую энергию в нужное русло.
Отрывок из книги “Гибкий ум”. Эстанислао Бахрах
Предлагаю выделить 4 преимущества нашего подхода:
- Качество разработки
Еще на этапе проработки идеи очень полезно рассказать или может показать наброски будущей идеи, так скажем, в максимальной комплектации разработчикам. Это полезно для того, чтобы четко понимать какие проблемы и блокеры с технической стороны будут поджидать вас на пути развития новой функции. Другими словами, будет ли возможен идеальный вариант решения внутри вашей системы или может быть есть какие-то ограничения, с которыми вам придется считаться. Это поможет не тратить время впустую на проработку заведомо не реализуемых идей. - Оптимизация работы над MVP
В современном проектировании очень популярен подход тестирования гипотез через MVP (Minimum Viable Product — минимально жизнеспособный продукт), когда для проверки какой-либо идеи на ценность мы разрабатываем небольшую версию масштабной функции и смотрим насколько она нужна нашим клиентам. Подход и вправду очень крутой потому что позволяет без больших затрат времени и ресурсов проверить идею на прочность. Но способность взглянуть на идею со стороны идеальной реализации решения пользовательской проблемы способно открыть новые, более продуманные и нестандартные варианты этого решения. - Лучшее решение вместо хорошего
Часто при проведении мозгового штурма (индивидуального или коллективного) мы идем на компромисс, останавливаясь на первом же довольно неплохом варианте, которое устраивает нас почти по всем критериям, что не позволяет придумать лучшее решение проблемы. Поиск же идеального решения, даже на первый взгляд не реализуемого, позволяет найти скрытые возможности и выйти на качественно новый уровень поиска ответа на поставленную задачу. - Качество планирования
Даже если размышления из предыдущего пункта не приведут к еще более идеальному варианту решения задачи, то точно дадут возможность лучше распланировать итерации внедрения функции от MVP до полноценной реализации, если тестирование покажет хороший результат. Это можно сделать например через product evolution canvas (канвас эволюции продукта) — это инструмент для планирования релизов продукта или функции от MVP до полноценной версии. Выглядит он так:
Канвас состоит из 3 волн: MVP, Core Product, Full Scale Product. И исходя из нашей идеи начинать проработку лучше с третьей волны — полноценной версии продукта/фичи (Full Scale Product), а уже после нахождения идеального решения начать поиск компромиссов и проработку более упрощенных вариантов, которые не потребуют так много ресурсов для реализации.
В целом подход конечно не нов и практикуется уже достаточно давно. Вот несколько вдохновляющих примеров того, как подобный подход помогает придумывать крутые решения:
Еще один отрывок из книги “думай как инженер”:
“Джон Шепард-Баррон был старомодным шотландцем с пытливым складом ума. Как гласит его история, однажды в середине 1960-х он на несколько минут опоздал в банк — тот закрывался на выходные. Шепард-Баррону срочно нужны были наличные, и он умолял менеджера открыть отделение, но тот отказался.
Будучи инженером до мозга костей, Шепард-Баррон решил, что должен найти способ снимать деньги со счета в любом месте и в любое время. Он работал управляющим директором в фирме, которая занималась печатью банкнот: сначала он отвечал за направление печати, а потом — за перевозки денежных средств на бронеавтомобилях. Его следующим шагом стал поиск возможности автоматической выдачи денег. И он замкнул этот круг, изобретя банкомат. Как ему это удалось? «Я подумал о торговом автомате, который вместо шоколадок выдавал бы деньги», — пояснил Шепард-Баррон
Для инженеров типа Шепарда-Баррона особенно полезно такое эффективное понятие, как конструирование от обратного, то есть способность заранее представить желаемый результат и проектировать, отталкиваясь от него. Тогда озарение на самом деле — итог осознанного, методического планирования, лежащего в основе сочетания идей, опыта и возможностей.
И мой самый любимый и вдохновляющий пример, в котором решение творческой задачи выходит на совершенно новый уровень применяя инженерный подход к разработке новой функции. Пример, в котором проектировщики рассматривая все составляющие и противоречия для идеального решения смогли не только вписать функцию в неблагоприятные условия, но еще и подчинить себе главного противника, чтобы функция работала еще лучше.
Это отрывок из книги “Хороший интерфейс — невидимый интерфейс” Голдена Кришны, в котором описывается пример решения проблемы перегрева автомобилей на раскаленных стоянках. Было несколько довольно неплохих попыток от других автопроизводителей решить данную проблему, но все они (как мы отмечали в 3-ем пункте преимуществ) останавливались на просто хорошем решении вместо лучшего. Например Nissan предложил вручную через мобильное приложение запускать процесс охлаждения автомобиля. Но вот как сам автор видит этот процесс на примере, когда вы оставили машину на парковке, а сами находитесь в прохладном кинотеатре:
- Оставьте машину на парковке и идите в кинотеатр
- Решите вернуться в машину
- За 15 минут до возвращения в машину вспомните, что она, вероятно, нагреется
- Вытащите смартфон
- Активизируйте смартфон
- Нажмите на кнопку, чтобы авторизироваться
- Выйдите из приложения, открытого последним
- Выйдите из группы приложений, открытой последним
- Пролистайте страница значков, чтобы найти нужное приложение
- Ткните пальцем в значок
- Подождите, пока приложение запустится и попробуйте найти действие запускающие охлаждение
- Просмотрите меню и попробуйте нажать Climate
- Ткните в кнопку Turn Climate Control On
- Подождите 15 минут
- Сядьте в прохладную машину
А вот как ту же проблему решили в Mazda 929, где из вышеописанных действий пользователю нужно сделать только первый и последний:
Разумеется, машина нагревается до очень высокой температуры, когда на улице жарко. Mazda установила простой и всем известный прибор для определения жары — термометр. Когда температура достигает определенного предела, датчик подает сигнал, давая системе понять, что машина нагревается.
После получения сигнала небольшие вентиляторы начинают охлаждать машину. Поскольку датчик сообщил, что на улице жарко, можно предположить, что машина находится на солнцепеке, так что Mazda установила на крыше машины солнечные батареи, которые снабжают электроэнергией всю вентиляционную систему. Когда вы возвращаетесь в вашу Mazda929, приятно осознавать, что прохлада в салоне не потребовала ни капли бензина и — что так же важно — ни дюйма интерфейса. Приняв во внимание контекст, создатели 929 использовали источник проблемы — солнце — как ее же решение.
Умно.
Когда датчик температуры обнаруживает, что жара немного спала, солнечная батарея начинает подзаряжать аккумулятор.
Еще умнее.
Отрывок из книги “Хороший интерфейс — невидимый интерфейс”. Голден Кришна
Вместо вывода
Подведем краткий итог всему вышесказанному. Итак, для того чтобы по новому подойти к решению творческой задачи нужно:
- Четко сформулировать цель (поставить задачу)
- Выключить внутреннего цензора
- Найти как можно больше вариантов идеального решения задачи
Спасибо за прочтение !
P.S. Не забывайте подписываться на мой канал в телеграмме, буду публиковать там анонсы новых постов, а также кое-какие мысли на профессиональную тематику.
