А. Г. |
Тот, кто лишь прошаривает память в поисках «решения Карл Дункер. О решении задач. 1935, пер. на англ. 1945 Чаще всего люди ищут решение задачи интуитивно. «Попробуем так, теперь эдак» — примитивный линейный перебор. «Посмотрим, что можно сделать с тем, что у нас есть» или «что я могу использовать?» — поиск подсказки в материалах задачи. «Избежим прошлых ошибок» — если на Всё это рабочие методы. Но что если я попробовал их все, а решение до сих пор не найдено? Где именно я сдался раньше времени? Где недожал? |
|
|||||||||||||||||||
Я не могу предложить универсальный алгоритм творчества, гарантированно приводящий к результату. Я предлагаю универсальную схему решения задачи, которая используется в нашем дизайнерском бюро около семи лет. Недавно я узнал, что эта схема в общих чертах совпадает со схемой, описанной немецким Наша схема решения задачи — не алгоритм, а три очевидных этапа. В ней нет секретов и открытий. Польза этой схемы в том, чтобы всегда знать, где ты находишься. Ведь если искать решение хаотично, то подвергаешь сомнению сразу все параметры задачи: постановку, цель, средства; мечешься между разными направлениями решения и разными постановками задачи. А если у тебя есть план и ты уверен в результатах предыдущего этапа, то это придаёт сил и уверенности в выбранном пути.
Анализ задачи
Задача этапа анализа — осмыслить ситуацию и её взаимосвязи, и в несколько итераций переформулировать смутное желание в конкретную цель. Полезное действие. В западном мире любят говорить не «проблема», а «задача». И это правильно: нужно концентрироваться на цели, а не на возникшей проблеме. Слишком часто люди думают только о проблеме, а от проблемы, как известно, легче всего уйти. Помните наш пример о бревне на дороге? Первым делом нужно как можно точнее сформулировать полезное действие. Что является желаемым благом в текущей ситуации? Затем — вредный фактор. Чего хочется избежать? Точное определение иногда даже само по себе приводит к решению задачи, а неверное — сбивает с курса.
Полезное действие можно и нужно отделять от способа его достижения в конкретной системе, конструкции или продукте. Если перед дизайнером стоит задача улучшить зубную щётку, он будет думать об углах наклона усиков и пупырышках на ручке. А если сформулировать полезное действие зубной щётки — чистка зубов, то это открывает простор для возможных новых решений: возможно, чистка жидкостью, вибрацией или даже предохранение от налёта. Проблемная ситуация может быть настолько запутанной или сложной, что сходу даже сложно понять, к чему стремиться. Полезных и вредных факторов слишком много. Что изобразить в логотипе страховой компании? Какие функции реализовать в новом сервисе, а от каких отказаться? Обычно у продукта есть главная функция, но это не значит, что она одна. В автомобиле можно не только перемещаться, можно спать, есть, хранить вещи. Разные люди хотят разного — спортивного характера, статуса, роскоши, заработка. В этой многомерности и заключается сложность творчества и предпринимательства. |
Первое упоминание бюрошного подхода в совете о логотипе «Изюма» | |||||||||||||||||||
Матрица системы. В сложных многомерных ситуациях я рекомендую построить «матрицу системы». Это инструмент подробного анализа иерархии систем, связанных с задачей, их предыдущего и будущего развития. Напомним, что направление вверх и вниз — это движение к надсистемам и подсистемам. Влево и вправо — в прошлое и будущее каждой из подсистем: |
О матрице системы | |||||||||||||||||||
![]() |
||||||||||||||||||||
Матрицу системы хорошо заполнять вместе со всеми ответственными за проект — предпринимателем, клиентом, менеджером продукта, проектировщиком, ведущим дизайнером. Это внутренний инструмент для осмысления и озарения — уделяйте внимание содержанию, не беспокойтесь об оформлении. Матрица свадебного салона «Мэри Трюфель»
|
||||||||||||||||||||
Если разложить по уровням сложную систему, гораздо легче определить для каждого уровня главное благо и вред. Появляется целая шкала полезного действия. Глядя на такую схему, проще выбрать уровень, на котором нужно искать решение в первую очередь. По умолчанию — это уровень, который непосредственно связан с проблемой. Например, чтобы выбрать ассортимент и дизайнеров свадебных платьев для свадебного салона «Мэри Трюфель», логично решать задачу на уровне самих платьев — одного из элементов свадьбы: |
||||||||||||||||||||
![]() |
||||||||||||||||||||
Оранжевым обозначены элементы, которые «не закрываются» свадебным салоном. Это потенциальные возможности для себя или конкурентов. На жёлтом фоне — полезное действие, связанное с уровнем. Матрица свадебного салона «Мэри Трюфель»
|
||||||||||||||||||||
На уровне свадебных платьев «Мэри Трюфель» выбирает своей главной ценностью хороший вкус. И матрица заодно даёт представление о потенциальном расширении бизнеса: платьями для подружек невесты, костюмами для женихов, услугами ателье, оформления и организации свадеб. Но свадебные платья — высококонкурентный бизнес, свадебных салонов и платьев очень много, а вкус — размытое понятие. Поэтому чтобы отстраниться от конкурентов, придётся выйти в надсистему — на уровень свадьбы: |
||||||||||||||||||||
![]() |
||||||||||||||||||||
А на уровне свадьбы гораздо легче сделать яркое заявление, выделяющее среди других салонов:
Если система сложная, схема станет навигатором для поиска решения задачи. Не получилось на этом уровне — рассмотрим решение в надсистеме или подсистеме. Функциональная иерархия. Если на выбранном для решения задачи уровне системы — например программного продукта, — выполняется много функций, полезное действие имеет смысл представить в виде дерева. Функциональная иерархия описывает возможности продукта для решения задач пользователей. На верхних уровнях иерархии находятся макрозадачи пользователей, а на нижних — элементарные операции. В функциональной иерархии принципиально не используются терминология и описание конкретной реализации дизайна или пользовательского интерфейса. Помните принцип отделения полезного действия от системы? Цель написания функциональной иерархии во время анализа — изучить предметную область и проблемную ситуацию, выбрать задачи пользователей, покрываемые продуктом. На её основе могут быть составлены базовые сценарии работы с продуктом и структура будущего продукта. Степень детализации функциональной иерархии выбирается так, чтобы не упустить важные частные задачи пользователей, но при этом не описывать конкретные интерфейсные решения. Ниже фрагмент функциональной иерархии почтового клиента:
Правильно составленная функциональная иерархия напоминает хорошую инструкцию пользователя — какие полезные функции и сценарии есть в системе? Кстати, майндмепы, или Структурные и инфологические схемы. Если в системе много физических или информационных объектов — станций метро, автобусных остановок, зон погрузки, продуктов в линейке, элементов интерфейса, типов данных — понять систему помогут структурные схемы: |
||||||||||||||||||||
![]() |
||||||||||||||||||||
Схемы пользовательского интерфейса, электрического прибора, структуры базы данных и станций Московского метро отображают «существительные» системы
|
||||||||||||||||||||
Синтаксический анализ и сценарии. Функциональная иерархия полезна, когда в системе много «глаголов» — полезных действий. Структурные и инфологические схемы — когда много «существительных» — элементов и объектов. Но если в системе много и того, и другого, чтобы её осмыслить, не обойтись без формального описания её элементов, связей, событий и состояний. Идея синтаксического анализа системы в аналогии с языком. Ведь язык отражает сложный мир вокруг человека, значит можно выделить в системе стандартные элементы — «члены предложения» и описать её связи и события обычными предложениями. В наших предложениях будут субъекты — действующие лица, подлежащие. Например, в задании на разработку системы контроля маржинальности телекоммуникакционного оператора мы выделили субъекты: менеджер, контролёр, аудитор. Субъекты имеют дело с объектами — дополнениями. В той же системе это: филиал, канал, доходный договор, расходный договор, а также связанные с ними параметры: плановые и фактические начисления, маржинальность. У объектов бывают разные состояния — определения. Например, канал может быть: в норме, низкомаржинальный, на проверке у контролёра. Когда определены действующие лица, объекты и состояния, можно написать сценарии — предложения, описывающие связи между объектами, действия субъектов над объектами, изменения состояний объектов, например:
Используемый системными аналитиками универсальный язык моделирования |
||||||||||||||||||||
Другой пример применения синтаксического анализа — правила редактуры текста элементов пользовательского интерфейса. Идею о том, что интерфейс подчиняется синтаксису языка, я сформулировал в 2007 году. Тогда же мы задались целью систематизировать знания о синтаксисе в приложении к интерфейсу. Оказалось, что элементам интерфейса в интерфейсе соответствуют члены предложения. Например, обычные кнопки могут выражать сказуемые и подлежащие, чекбоксы и радиокнопки — дополнения, определения и обстоятельства. Текстовые формулы систем, которые мы рассматривали в советах о создании работоспособных систем — тоже пример синтаксического анализа: Пользователи чекинятся в заведении, потому что завидуют чужому мэрству В формуле описывается не вся сложная система целиком, а главный принцип её действия. Анализ ресурсов. Ничто так не помогает дизайнеру решить задачу, как заданный себе вопрос: а что у нас есть? Что я могу использовать? Обезьяна берёт палку, чтобы достать банан. Оружейный конструктор использует пороховые газы после выстрела, чтобы перезарядить автомат. Предприниматель устраивает учебный класс с Чтобы решить задачу эффективно, нужно на этапе анализа произвести «инвентаризацию» ресурсов, то есть аккуратно собрать и выписать, что у нас есть. |
Илья Бирман. Пользовательский интерфейс. Глава «Синтаксис» | |||||||||||||||||||
Работающая система потребляет ресурсы — энергетические, материальные и информационные. Эти ресурсы уже находятся в системе и их лучше использовать для решения текущей задачи в первую очередь. Какой у нас источник энергии? Какие у наших пользователей мотивы? Какой материал у нас всегда в запасе? Какая у нас есть информация? Внешние ресурсы находятся снаружи, их тоже можно использовать. Какую функцию телефона можно использовать в приложении, чтобы не писать свою? Где взять готовую картинку? Кто подбросит меня до работы? А что если все едущие на работу будут подбрасывать по пути остальных в нашем сервисе?
Лучший вид ресурсов — это бесплатные или копеечные: воздух, вода, отходы, остатки, обрезки, не пошедшие в дело, статистика пользователей, история посещений и покупок. Отдельный вид информационных ресурсов — культурные зацепки в голове аудитории. Мемы, визуальные образы, поговорки, цитаты из фильмов и литературы можно использовать для решения задачи — часто совершенно бесплатно.
В наше время не требуется большая эрудиция, чтобы использовать такие ресурсы в дизайне. Поиск по картинкам, поговоркам и цитатам — рутинный этап любого проекта: |
Подробнее: Дизайн должен быть бесплатным | |||||||||||||||||||
![]() |
||||||||||||||||||||
Поиск образов, связанных со свадьбами, вскрыл проблему пошлых штампов — которые нельзя использовать и нельзя не использовать. Мэри Трюфель
|
||||||||||||||||||||
Мудборды и культурный поиск в графическом дизайне — это тоже анализ ресурсов для решения задачи. Поиск клише и существующих решений поможет понять, в каком виде потребители привыкли получать полезное действие в продуктах, подобных вашему. Потом это пригодится, чтобы проверять решение по параметру «образование», чтобы он был понятен и близок пользователям психологически и культурно. Короткий путь. Формулировка полезного действия и анализ ресурсов обязательны в любой задаче. Но если каждый раз строить матрицу системы, функциональную иерархию, структурную схему и проводить синтаксический разбор, только анализ растянется на недели. Хорошая новость в том, что у проектировщика нет необходимости использовать сразу все инструменты. Ниже несколько ориентиров выбора инструментов в бюро: Матрица системы — очень трудоёмкий инструмент. Построение матрицы продукта или компании занимает несколько дней, в которые мы проводим сессии с клиентом. Поэтому матрицу системы имеет смысл использовать в редких случаях, когда нужно посмотреть на бизнес глобально, понять его пользу и сильные стороны, увидеть просчёты и возможности на всех уровнях. Как ни странно, чаще всего этот инструмент мы применяем в графическом дизайне — при создании логотипа и фирменного стиля, чтобы лицо компании выглядело осмысленно и последовательно со всех точек зрения. Другой пример — когда компании нужно сделать резкий рывок в развитии, сохранив при этом свою суть и не потеряв наработанное. Функциональная иерархия полезна для ускоренного анализа многофункционального, как правило, уже существующего продукта. В бюро бывает так: приходит клиент с большим продуктом. Вроде понятно, что нужно начать с малого, но продукт настолько большой, что невозможно понять, за что хвататься. Только на экскурсию по продукту уйдёт несколько дней. А функциональная иерархия, составленная в разговоре с клиентом, помогает быстро понять, а что, собственно, делает этот продукт? (Вот что надо было использовать тогда с футболистами, Миша). Структурные схемы продуктов, сайтов, интерфейсов и архитектуры программ — довольно популярный инструмент. Многие дизайнеры интерфейсов составляют подробные карты сайтов и приложений с уменьшенными схемами экранов. Как ни странно, в бюро этот инструмент почти не применяется. Дело в том, что если для осмысления и проектирования продукта нужна структурная схема, значит, проект получается слишком монструозным для одной итерации. Даже работа над большими продуктами, такими как «Система Главбух» была построена так, чтобы структура экранов легко умещалась в голове. Это хорошо и для управления большим проектом, и для поддержки платформы, и для пользовательского интерфейса. Соответственно, структурная схема вам понадобится, если от сложности в проекте никуда не деться: при проектировании микросхемы, навигации в общественном транспорте, операционной системы или логистической схемы. Синтаксический анализ — это просто более общее и красивое название сценариев использования продукта ( Модель решенияПосле этапа анализа мы поняли, чего хотим — сформулировали полезное действие. Разобрались в системе — осмыслили проблемную ситуацию. И знаем, что у нас есть — проанализировали ресурсы. Вполне возможно, решение уже нашлось. Бывает, хорошее понимание проблемы сразу приводит к решению. Если решения ещё нет, цель этого этапа — найти идею, образ, принцип, схему решения. С одной стороны, этот этап можно считать частью постановки задачи. Мы всегда включаем первоначальную модель решения в документ «понимание задачи», который утверждаем с клиентом до начала работы. Слишком рискованно брать деньги и начинать работу с клиентом, ещё не зная, что будешь делать. С другой стороны, модель решения — это уже поиск решения задачи, дизайн смысла. Первоначальная модель может преобразоваться несколько раз.
Вторая модель решения имела техническое воплощение — это правильный ответ. |
||||||||||||||||||||
Поиск модели решения начинается с точной формулировки противоречия. «Хочу есть, но в холодильнике пусто» — это первоначальная формулировка проблемы. Хочу есть, но Cложно сформулировать противоречие, когда системы ещё нет. Например, перед бюро появилась задача «создать электронную книгу бюро». Нам помогли вопросы: что плохого и хорошего в бумажных книгах? Что плохого и хорошего в существующих электронных книгах? Одно из ключевых противоречий, которые мы сформулировали и разрешили в дизайне книги — «должна быть сплошная прокрутка, но книга должна быть поделена на адресуемые развороты, как бумажная листаемая книга». Другое противоречие: «книга должна быть доступна максимальному количеству людей, как сайт, но должна быть лёгкой и управляемой, как приложение». Эти противоречия предопределили почти всё в дизайне наших электронных книг. Когда противоречие сформулировано, нужно понять, как его разрешать. Дизайнеру придётся выбрать путь: капитуляция, грубая сила, компромисс или изобретательность. Других путей просто нет. Конечно, мы выбираем изобретательность. Тогда противоречие нужно обострить: я поем, не выходя из дома. Электронная книга будет непрерывно и прокручиваться, при этом поделена и привязана к разворотам. Дальше нужно понять, как решать задачу: в существующей системе или создавая новую систему. Создание новой системы связано с большими расходами времени, денег и интеллектуальных ресурсов, порождает и заставляет решать новые сопутствующие задачи. Поэтому в первую очередь нужно искать решение без выхода в надсистему, которое меняет только проблемную часть и не затрагивает остальную систему.
Но если старая система себя изжила, не справляется со своими задачами или её просто не существует, очевидно, что нужно создавать новую.
Если мы создаём новую систему, в модели решения должна создаваться или достраиваться полная формула системы.
Если задача решается в существующей системе, нужно развивать формулу — перейти от простой формулы к сложной, динамизировать, добавить эффекты, перейти к самоуправлению, например:
Возможно, придётся выйти в надсистему или подсистему — создать би- или полисистему, решить задачу в подсистеме. Модель решения — это полезное действие и явно сформулированный способ его достижения. Лучше всего, если модель сформулирована одной фразой или абзацем — так видны все достоинства и недостатки решения.
В такой модели решения не хватает полезного действия — ради чего создавать сайт? Добавим пользу:
Здесь есть полезное действие, но непонятно, почему решение «создать сайт» — это вообще решение. Кроме того, полезное действие направлено не во внешний мир, а только на интересы компании. Вывернем наизнанку:
Модель решения — ключевой элемент бюрошного «понимания задачи» перед стартом проекта. Ниже примеры наших неудачных и удачных формулировок:
Обратите внимание на последнюю модель решения. На самом деле это не одно решение, а целых четыре, да ещё и для трёх разных журналов. Модель решения порождает новую задачу: как решить все эти задачи одновременно в трёх журналах, а в идеале — во всех 140 журналах издательского дома? Модель решения: чтобы упростить и сделать возможным обновление сразу трёх журналов, сначала будет разработан конструктор форматов — серый каркас без логотипа и характерных элементов. Для каждого журнала будет создана «шкурка» оформления, которая будет надеваться на каркас. Эта модель решения воплотилась в «Универсальный журнал Модель решения — это уже дизайн. Это эскиз идеи, структуры решения. Но на этом этапе не стоит переживать, что модель решения некрасивая или странная. |
||||||||||||||||||||
|
||||||||||||||||||||
Оцените модель решения — действительно ли решение достигнет полезное действие без компромиссов, будет почти бесплатно, а не погасит проблему заливкой денег и ресурсов. Неважно, насколько необычно решение, важно, удовлетворяет ли оно этим критериям. Если модель решает задачу по смыслу, этого достаточно, чтобы быть в ней уверенным. Окончательную форму решение получит на следующем этапе. РешениеМодель решения — это только идея решения. На последнем этапе модель решения получает конкретную практическую форму. Это самая трудная часть решения задачи, за которую клиенты и платят деньги дизайнерам. Нужно создать рабочую конструкцию, найти форму, проработать детали. Как правило, на этапе решения происходит ещё один титанический сдвиг. Реальность всегда сопротивляется воплощению идеи: получается некрасиво, не круто, не стыкуется, не работает, жрёт память, разваливается при взлёте. Практическая реализация постоянно создаёт новые противоречия и ставит новые задачи.
К сожалению, рецепта нет. На этапе решения нужны настойчивость и уверенность. У меня есть поучительная история. В начале 2011 года мы работали над проектом сервиса авиабилетов. Перед бюро стояла задача придумать название, логотип и интерфейс сервиса. С названием всё прошло на отлично. Мы придумали название One Two Trip, Когда дело дошло до логотипа, дело застопорилось. На уровне идеи всё было хорошо — название означает простое и быстрое отправление в путешествие: раз — откуда, два — куда и — в путь. Получилась модель логотипа, но знак никак не выходил: ![]() Я начал сомневаться в выбранном пути. И тут клиент пишет: у меня есть логотип. Оказывается, он одновременно работал с дизайнером Андреем Зубриловым. Андрей выдал отличный знак: ![]() Я был ошарашен. С одной стороны, я кусал локти, что Андрей нашёл решение раньше нас. Но ещё больше меня удивило то, что он сделал за нас последний шаг, который мы не дожали — придал конструкции со стрелкой понятную и узнаваемую форму минимальными средствами. Для меня это был отличный урок. Если у тебя нет сомнений в модели решения — нужно переть до конца. Таких ошибок мы стараемся не повторять. |
||||||||||||||||||||
|
||||||||||||||||||||
Если всё хорошо — поздравляю. У вас есть решение! Если оно окажется успешным, не забудьте придумать, где ещё его можно использовать. Напоследок несколько важных слов об аналитическом подходе к решению дизайнерских задач. Ради чего столько усилий? Дизайнер должен быть изобретательным — это значит, что он должен находить настоящее решение задачи, а не бесполезный компромисс. Дизайнер не обязан быть изобретателем, ведь чаще всего решение его проблемы уже Но в мире полно идей, решений, устройств, приспособлений, типовых элементов и конструкций. Как вспомнить именно то, что нужно? Что делать, если решение существует, но дизайнер о нём не знает? Для этого и нужен аналитический подход. Если дизайнер проанализирует задачу, определит вред и полезное действие, сформулирует противоречие, то в конце концов он сформулирует конкретные требования к идеальному решению. А ведь найти существующее решение по конкретным критериям гораздо проще, чем перебирать весь опыт человечества на заданную тему. Да и ответ может лежать в соседней области. И нет ничего стыдного, если правильным решением дизайнерской задачи окажется банальный пылесос или привычная кнопка. Главное — уметь перевести учебную, бытовую, жизненную, профессиональную проблему в формат чёткой цели. Именно в этом состоит подход работоспособного дизайна, который проповедует бюро. Работоспособный дизайн — чтобы правильно прицелиться. P. S.Дорогие друзья! Первый совет о работоспособном дизайне я написал 2 февраля 2015 года. С тех пор в течение трёх лет каждые две недели (с некоторыми пропусками), я публиковал большой Поделиться своими знаниями о «дизайне всего» я мечтал десять лет. Советы под рубрикой «Решение задач» я писал по плану, который подготовил заранее. И вот сегодня я написал последний совет. Тема работоспособного дизайна объединяет наши дизайнерские дисциплины и преподавателей — Бирмана, Ильяхова, Нозика, Товеровского, Синельникова, Беляева и Куличевского. Это дизайн всего: систем, интерфейсов, текста, отношений и процессов. Священным дизайнерским граалем я это не называю из природной скромности и потому, что грааль — призрачная мечта, а дизайн работоспособных систем бюро практикует ежедневно. Эти советы — плод наших многолетних наблюдений, выводов, обобщений и открытий. Мой план состоял из трёх больших частей: разрешение противоречий, создание работоспособных систем, эволюция работоспособных систем. Этапы решения задач — это эпилог, подведение итогов. Многое я понял и узнал, пока писал эти советы. У меня самого в голове разложились по полочкам пути разрешения противоречий, осознались понятия целостности и образования в системах, родилась идея свойств работоспособных систем FIRE, оформились стратегии редизайна существующих продуктов. Я отдаю себе отчёт, что мои Третья причина заключается в том, что только небольшая часть аудитории действительно занимается решением задач. Много дизайнеров и менеджеров просто «пилят сайты», «рисуют иконки», «оптимизируют ключевые слова», «печатают буклетики» и «ведут СММ», даже не задумываясь, почему клиент об этом попросил и зачем это нужно. Это связано с профессиональной специализацией и с тем, что дизайнеры в больших компаниях чаще всего ничего не решают. Я считаю своей аудиторией менеджеров продуктов, технических директоров, Наверняка многие из вас уже догадались, что мои советы — рукопись будущей бюрошной книги. Если эта книга выйдет, она будет называться «Работоспособный дизайн». В ней знания будут оформлены в структурированном, лёгком для поиска виде. Скорее всего, книга выйдет просто потому, что я верю, что она должна выйти. Хватило же мне силы воли на три года, несмотря на постоянные шуточки Сергея Короля. Но мне очень придаст вдохновения и желания ускориться ваша поддержка. Если вы хотите эту книгу, оставьте, пожалуйста, свой адрес электронной почты ниже. И мы напишем вам, когда будут новости. |
P. S. Это был понедельничный совет о решении дизайнерских задач. Хотите знать всё о дизайне продуктов, работоспособных системах, полезном действии, разрешении противоречий, законах, приёмах и формулах? Присылайте вопросы. |