Чаще всего люди ищут решение задачи интуитивно. «Попробуем так, теперь эдак» — примитивный линейный перебор. «Посмотрим, что можно сделать с тем, что у нас есть» или «что я могу использовать?» — поиск подсказки в материалах задачи. «Избежим прошлых ошибок» — если на чём‑то сильно обжёгся раньше. «Так, что это напоминает?» — обращение к памяти и личным наблюдениям. «А чего, собственно, я хочу?» — анализ цели, чтобы освободиться от стереотипов.

Всё это рабочие методы. Но что если я попробовал их все, а решение до сих пор не найдено? Где именно я сдался раньше времени? Где недожал?

Я не могу предложить универсальный алгоритм творчества, гарантированно приводящий к результату. Я предлагаю универсальную схему решения задачи, которая используется в нашем дизайнерском бюро около семи лет. Недавно я узнал, что эта схема в общих чертах совпадает со схемой, описанной немецким гештальт‑психологом Карлом Дункером в 1935 году.

Наша схема решения задачи — не алгоритм, а три очевидных этапа. В ней нет секретов и открытий. Польза этой схемы в том, чтобы всегда знать, где ты находишься. Ведь если искать решение хаотично, то подвергаешь сомнению сразу все параметры задачи: постановку, цель, средства; мечешься между разными направлениями решения и разными постановками задачи. А если у тебя есть план и ты уверен в результатах предыдущего этапа, то это придаёт сил и уверенности в выбранном пути.

Схема решения одинаковая для всех видов дизайна — продуктов, графики, интерфейса, навигации, программ, бизнеса. Эти этапы пригодятся и в обычной жизни:

Изначально у дизайнера, предпринимателя, менеджера, редактора, программиста или любого другого человека есть размытое эмоциональное желание или дискомфорт от текущей ситуации:

Задача этапа анализа — осмыслить ситуацию и её взаимосвязи, и в несколько итераций переформулировать смутное желание в конкретную цель.

Полезное действие. В западном мире любят говорить не «проблема», а «задача». И это правильно: нужно концентрироваться на цели, а не на возникшей проблеме. Слишком часто люди думают только о проблеме, а от проблемы, как известно, легче всего уйти. Помните наш пример о бревне на дороге?

Первым делом нужно как можно точнее сформулировать полезное действие. Что является желаемым благом в текущей ситуации? Затем — вредный фактор. Чего хочется избежать? Точное определение иногда даже само по себе приводит к решению задачи, а неверное — сбивает с курса.

Полезное действие можно и нужно отделять от способа его достижения в конкретной системе, конструкции или продукте. Если перед дизайнером стоит задача улучшить зубную щётку, он будет думать об углах наклона усиков и пупырышках на ручке. А если сформулировать полезное действие зубной щётки — чистка зубов, то это открывает простор для возможных новых решений: возможно, чистка жидкостью, вибрацией или даже предохранение от налёта.

Проблемная ситуация может быть настолько запутанной или сложной, что сходу даже сложно понять, к чему стремиться. Полезных и вредных факторов слишком много. Что изобразить в логотипе страховой компании? Какие функции реализовать в новом сервисе, а от каких отказаться?

Обычно у продукта есть главная функция, но это не значит, что она одна. В автомобиле можно не только перемещаться, можно спать, есть, хранить вещи. Разные люди хотят разного — спортивного характера, статуса, роскоши, заработка. В этой многомерности и заключается сложность творчества и предпринимательства.

Матрица системы. В сложных многомерных ситуациях я рекомендую построить «матрицу системы». Это инструмент подробного анализа иерархии систем, связанных с задачей, их предыдущего и будущего развития.

Напомним, что направление вверх и вниз — это движение к надсистемам и подсистемам. Влево и вправо — в прошлое и будущее каждой из подсистем:

Если разложить по уровням сложную систему, гораздо легче определить для каждого уровня главное благо и вред. Появляется целая шкала полезного действия. Глядя на такую схему, проще выбрать уровень, на котором нужно искать решение в первую очередь. По умолчанию — это уровень, который непосредственно связан с проблемой.

Например, чтобы выбрать ассортимент и дизайнеров свадебных платьев для свадебного салона «Мэри Трюфель», логично решать задачу на уровне самих платьев — одного из элементов свадьбы:

На уровне свадебных платьев «Мэри Трюфель» выбирает своей главной ценностью хороший вкус. И матрица заодно даёт представление о потенциальном расширении бизнеса: платьями для подружек невесты, костюмами для женихов, услугами ателье, оформления и организации свадеб.

Но свадебные платья — высококонкурентный бизнес, свадебных салонов и платьев очень много, а вкус — размытое понятие. Поэтому чтобы отстраниться от конкурентов, придётся выйти в надсистему — на уровень свадьбы:

А на уровне свадьбы гораздо легче сделать яркое заявление, выделяющее среди других салонов:

Если система сложная, схема станет навигатором для поиска решения задачи. Не получилось на этом уровне — рассмотрим решение в надсистеме или подсистеме.

Функциональная иерархия. Если на выбранном для решения задачи уровне системы — например программного продукта, — выполняется много функций, полезное действие имеет смысл представить в виде дерева.

Функциональная иерархия описывает возможности продукта для решения задач пользователей. На верхних уровнях иерархии находятся макрозадачи пользователей, а на нижних — элементарные операции. В функциональной иерархии принципиально не используются терминология и описание конкретной реализации дизайна или пользовательского интерфейса. Помните принцип отделения полезного действия от системы?

Цель написания функциональной иерархии во время анализа — изучить предметную область и проблемную ситуацию, выбрать задачи пользователей, покрываемые продуктом. На её основе могут быть составлены базовые сценарии работы с продуктом и структура будущего продукта.

Степень детализации функциональной иерархии выбирается так, чтобы не упустить важные частные задачи пользователей, но при этом не описывать конкретные интерфейсные решения. Ниже фрагмент функциональной иерархии почтового клиента:

Правильно составленная функциональная иерархия напоминает хорошую инструкцию пользователя — какие полезные функции и сценарии есть в системе?

Кстати, майндмепы, или интеллект‑карты,— графический аналог функциональной иерархии.

Структурные и инфологические схемы. Если в системе много физических или информационных объектов — станций метро, автобусных остановок, зон погрузки, продуктов в линейке, элементов интерфейса, типов данных — понять систему помогут структурные схемы:

Синтаксический анализ и сценарии. Функциональная иерархия полезна, когда в системе много «глаголов» — полезных действий. Структурные и инфологические схемы — когда много «существительных» — элементов и объектов. Но если в системе много и того, и другого, чтобы её осмыслить, не обойтись без формального описания её элементов, связей, событий и состояний.

Идея синтаксического анализа системы в аналогии с языком. Ведь язык отражает сложный мир вокруг человека, значит можно выделить в системе стандартные элементы — «члены предложения» и описать её связи и события обычными предложениями.

В наших предложениях будут субъекты — действующие лица, подлежащие. Например, в задании на разработку системы контроля маржинальности телекоммуникакционного оператора мы выделили субъекты: менеджер, контролёр, аудитор.

Субъекты имеют дело с объектами — дополнениями. В той же системе это: филиал, канал, доходный договор, расходный договор, а также связанные с ними параметры: плановые и фактические начисления, маржинальность.

У объектов бывают разные состояния — определения. Например, канал может быть: в норме, низкомаржинальный, на проверке у контролёра.

Когда определены действующие лица, объекты и состояния, можно написать сценарии — предложения, описывающие связи между объектами, действия субъектов над объектами, изменения состояний объектов, например:

Используемый системными аналитиками универсальный язык моделирования Ю‑эм‑эль — это способ синтаксического описания систем в графической форме.

Другой пример применения синтаксического анализа — правила редактуры текста элементов пользовательского интерфейса. Идею о том, что интерфейс подчиняется синтаксису языка, я сформулировал в 2007 году. Тогда же мы задались целью систематизировать знания о синтаксисе в приложении к интерфейсу. Оказалось, что элементам интерфейса в интерфейсе соответствуют члены предложения. Например, обычные кнопки могут выражать сказуемые и подлежащие, чекбоксы и радиокнопки — дополнения, определения и обстоятельства.

Текстовые формулы систем, которые мы рассматривали в советах о создании работоспособных систем — тоже пример синтаксического анализа:

В формуле описывается не вся сложная система целиком, а главный принцип её действия.

Анализ ресурсов. Ничто так не помогает дизайнеру решить задачу, как заданный себе вопрос: а что у нас есть? Что я могу использовать?

Обезьяна берёт палку, чтобы достать банан. Оружейный конструктор использует пороховые газы после выстрела, чтобы перезарядить автомат. Предприниматель устраивает учебный класс с кофе‑баром на базе офиса своей компании. Программист использует готовую библиотеку, чтобы не писать код заново. Дизайнер логотипа использует букву в названии продукта, похожую на нужный объект.

Чтобы решить задачу эффективно, нужно на этапе анализа произвести «инвентаризацию» ресурсов, то есть аккуратно собрать и выписать, что у нас есть.

Работающая система потребляет ресурсы — энергетические, материальные и информационные. Эти ресурсы уже находятся в системе и их лучше использовать для решения текущей задачи в первую очередь. Какой у нас источник энергии? Какие у наших пользователей мотивы? Какой материал у нас всегда в запасе? Какая у нас есть информация?

Внешние ресурсы находятся снаружи, их тоже можно использовать. Какую функцию телефона можно использовать в приложении, чтобы не писать свою? Где взять готовую картинку? Кто подбросит меня до работы? А что если все едущие на работу будут подбрасывать по пути остальных в нашем сервисе?

Лучший вид ресурсов — это бесплатные или копеечные: воздух, вода, отходы, остатки, обрезки, не пошедшие в дело, статистика пользователей, история посещений и покупок.

Отдельный вид информационных ресурсов — культурные зацепки в голове аудитории. Мемы, визуальные образы, поговорки, цитаты из фильмов и литературы можно использовать для решения задачи — часто совершенно бесплатно.

В наше время не требуется большая эрудиция, чтобы использовать такие ресурсы в дизайне. Поиск по картинкам, поговоркам и цитатам — рутинный этап любого проекта:

Мудборды и культурный поиск в графическом дизайне — это тоже анализ ресурсов для решения задачи.

Поиск клише и существующих решений поможет понять, в каком виде потребители привыкли получать полезное действие в продуктах, подобных вашему. Потом это пригодится, чтобы проверять решение по параметру «образование», чтобы он был понятен и близок пользователям психологически и культурно.

Короткий путь. Формулировка полезного действия и анализ ресурсов обязательны в любой задаче. Но если каждый раз строить матрицу системы, функциональную иерархию, структурную схему и проводить синтаксический разбор, только анализ растянется на недели.

Хорошая новость в том, что у проектировщика нет необходимости использовать сразу все инструменты. Ниже несколько ориентиров выбора инструментов в бюро:

Матрица системы — очень трудоёмкий инструмент. Построение матрицы продукта или компании занимает несколько дней, в которые мы проводим сессии с клиентом. Поэтому матрицу системы имеет смысл использовать в редких случаях, когда нужно посмотреть на бизнес глобально, понять его пользу и сильные стороны, увидеть просчёты и возможности на всех уровнях. Как ни странно, чаще всего этот инструмент мы применяем в графическом дизайне — при создании логотипа и фирменного стиля, чтобы лицо компании выглядело осмысленно и последовательно со всех точек зрения. Другой пример — когда компании нужно сделать резкий рывок в развитии, сохранив при этом свою суть и не потеряв наработанное.

Функциональная иерархия полезна для ускоренного анализа многофункционального, как правило, уже существующего продукта. В бюро бывает так: приходит клиент с большим продуктом. Вроде понятно, что нужно начать с малого, но продукт настолько большой, что невозможно понять, за что хвататься. Только на экскурсию по продукту уйдёт несколько дней. А функциональная иерархия, составленная в разговоре с клиентом, помогает быстро понять, а что, собственно, делает этот продукт? (Вот что надо было использовать тогда с футболистами, Миша).

Структурные схемы продуктов, сайтов, интерфейсов и архитектуры программ — довольно популярный инструмент. Многие дизайнеры интерфейсов составляют подробные карты сайтов и приложений с уменьшенными схемами экранов. Как ни странно, в бюро этот инструмент почти не применяется. Дело в том, что если для осмысления и проектирования продукта нужна структурная схема, значит, проект получается слишком монструозным для одной итерации. Даже работа над большими продуктами, такими как «Система Главбух» была построена так, чтобы структура экранов легко умещалась в голове. Это хорошо и для управления большим проектом, и для поддержки платформы, и для пользовательского интерфейса. Соответственно, структурная схема вам понадобится, если от сложности в проекте никуда не деться: при проектировании микросхемы, навигации в общественном транспорте, операционной системы или логистической схемы.

После этапа анализа мы поняли, чего хотим — сформулировали полезное действие. Разобрались в системе — осмыслили проблемную ситуацию. И знаем, что у нас есть — проанализировали ресурсы.

Вполне возможно, решение уже нашлось. Бывает, хорошее понимание проблемы сразу приводит к решению.

Если решения ещё нет, цель этого этапа — найти идею, образ, принцип, схему решения. С одной стороны, этот этап можно считать частью постановки задачи. Мы всегда включаем первоначальную модель решения в документ «понимание задачи», который утверждаем с клиентом до начала работы. Слишком рискованно брать деньги и начинать работу с клиентом, ещё не зная, что будешь делать.

С другой стороны, модель решения — это уже поиск решения задачи, дизайн смысла. Первоначальная модель может преобразоваться несколько раз.

Вторая модель решения имела техническое воплощение — это правильный ответ.

Поиск модели решения начинается с точной формулировки противоречия. «Хочу есть, но в холодильнике пусто» — это первоначальная формулировка проблемы. Хочу есть, но в холодильнике пусто → в доме нет еды → я не хочу выходить из дома. Сформулировать вредный фактор помогает приём — задавать подряд вопрос «почему», пока ответ не станет очевидным.

Cложно сформулировать противоречие, когда системы ещё нет. Например, перед бюро появилась задача «создать электронную книгу бюро». Нам помогли вопросы: что плохого и хорошего в бумажных книгах? Что плохого и хорошего в существующих электронных книгах? Одно из ключевых противоречий, которые мы сформулировали и разрешили в дизайне книги — «должна быть сплошная прокрутка, но книга должна быть поделена на адресуемые развороты, как бумажная листаемая книга». Другое противоречие: «книга должна быть доступна максимальному количеству людей, как сайт, но должна быть лёгкой и управляемой, как приложение». Эти противоречия предопределили почти всё в дизайне наших электронных книг.

Когда противоречие сформулировано, нужно понять, как его разрешать. Дизайнеру придётся выбрать путь: капитуляция, грубая сила, компромисс или изобретательность. Других путей просто нет. Конечно, мы выбираем изобретательность. Тогда противоречие нужно обострить: я поем, не выходя из дома. Электронная книга будет непрерывно и прокручиваться, при этом поделена и привязана к разворотам.

Дальше нужно понять, как решать задачу: в существующей системе или создавая новую систему. Создание новой системы связано с большими расходами времени, денег и интеллектуальных ресурсов, порождает и заставляет решать новые сопутствующие задачи. Поэтому в первую очередь нужно искать решение без выхода в надсистему, которое меняет только проблемную часть и не затрагивает остальную систему.

Но если старая система себя изжила, не справляется со своими задачами или её просто не существует, очевидно, что нужно создавать новую.

Если мы создаём новую систему, в модели решения должна создаваться или достраиваться полная формула системы.

Если задача решается в существующей системе, нужно развивать формулу — перейти от простой формулы к сложной, динамизировать, добавить эффекты, перейти к самоуправлению, например:

Возможно, придётся выйти в надсистему или подсистему — создать би‑ или полисистему, решить задачу в подсистеме.

Модель решения — это полезное действие и явно сформулированный способ его достижения. Лучше всего, если модель сформулирована одной фразой или абзацем — так видны все достоинства и недостатки решения.

В такой модели решения не хватает полезного действия — ради чего создавать сайт? Добавим пользу:

Здесь есть полезное действие, но непонятно, почему решение «создать сайт» — это вообще решение. Кроме того, полезное действие направлено не во внешний мир, а только на интересы компании. Вывернем наизнанку:

Модель решения — ключевой элемент бюрошного «понимания задачи» перед стартом проекта. Ниже примеры наших неудачных и удачных формулировок:

Обратите внимание на последнюю модель решения. На самом деле это не одно решение, а целых четыре, да ещё и для трёх разных журналов. Модель решения порождает новую задачу: как решить все эти задачи одновременно в трёх журналах, а в идеале — во всех 140 журналах издательского дома? Модель решения: чтобы упростить и сделать возможным обновление сразу трёх журналов, сначала будет разработан конструктор форматов — серый каркас без логотипа и характерных элементов. Для каждого журнала будет создана «шкурка» оформления, которая будет надеваться на каркас.

Эта модель решения воплотилась в «Универсальный журнал Актиона‑МЦФЭР».

Модель решения — это уже дизайн. Это эскиз идеи, структуры решения. Но на этом этапе не стоит переживать, что модель решения некрасивая или странная.

Оцените модель решения — действительно ли решение достигнет полезное действие без компромиссов, будет почти бесплатно, а не погасит проблему заливкой денег и ресурсов. Неважно, насколько необычно решение, важно, удовлетворяет ли оно этим критериям.

Модель решения — это только идея решения. На последнем этапе модель решения получает конкретную практическую форму.

Это самая трудная часть решения задачи, за которую клиенты и платят деньги дизайнерам. Нужно создать рабочую конструкцию, найти форму, проработать детали. Как правило, на этапе решения происходит ещё один титанический сдвиг. Реальность всегда сопротивляется воплощению идеи: получается некрасиво, не круто, не стыкуется, не работает, жрёт память, разваливается при взлёте. Практическая реализация постоянно создаёт новые противоречия и ставит новые задачи.

К сожалению, рецепта нет. На этапе решения нужны настойчивость и уверенность. У меня есть поучительная история.

В начале 2011 года мы работали над проектом сервиса авиабилетов. Перед бюро стояла задача придумать название, логотип и интерфейс сервиса.

С названием всё прошло на отлично. Мы придумали название One Two Trip, по‑русски «Раз‑два‑трип». Клиенту понравилось, и он даже выкупил у киберсквотеров домен в зоне .com

Когда дело дошло до логотипа, дело застопорилось. На уровне идеи всё было хорошо — название означает простое и быстрое отправление в путешествие: раз — откуда, два — куда и — в путь. Получилась модель логотипа, но знак никак не выходил:

Я начал сомневаться в выбранном пути. И тут клиент пишет: у меня есть логотип. Оказывается, он одновременно работал с дизайнером Андреем Зубриловым. Андрей выдал отличный знак:

Я был ошарашен. С одной стороны, я кусал локти, что Андрей нашёл решение раньше нас. Но ещё больше меня удивило то, что он сделал за нас последний шаг, который мы не дожали — придал конструкции со стрелкой понятную и узнаваемую форму минимальными средствами.

Для меня это был отличный урок. Если у тебя нет сомнений в модели решения — нужно переть до конца. Таких ошибок мы стараемся не повторять.

Рецепта поиска окончательного решения у меня нет. Но я могу дать несколько советов. Используйте в своём поиске:

Если всё хорошо — поздравляю. У вас есть решение! Если оно окажется успешным, не забудьте придумать, где ещё его можно использовать.

Напоследок несколько важных слов об аналитическом подходе к решению дизайнерских задач. Ради чего столько усилий?

Дизайнер должен быть изобретательным — это значит, что он должен находить настоящее решение задачи, а не бесполезный компромисс. Дизайнер не обязан быть изобретателем, ведь чаще всего решение его проблемы уже где‑то существует.

Но в мире полно идей, решений, устройств, приспособлений, типовых элементов и конструкций. Как вспомнить именно то, что нужно? Что делать, если решение существует, но дизайнер о нём не знает?

Для этого и нужен аналитический подход. Если дизайнер проанализирует задачу, определит вред и полезное действие, сформулирует противоречие, то в конце концов он сформулирует конкретные требования к идеальному решению. А ведь найти существующее решение по конкретным критериям гораздо проще, чем перебирать весь опыт человечества на заданную тему. Да и ответ может лежать в соседней области.

И нет ничего стыдного, если правильным решением дизайнерской задачи окажется банальный пылесос или привычная кнопка. Главное — уметь перевести учебную, бытовую, жизненную, профессиональную проблему в формат чёткой цели. Именно в этом состоит подход работоспособного дизайна, который проповедует бюро.

Дорогие друзья! Первый совет о работоспособном дизайне я написал 2 февраля 2015 года. С тех пор в течение трёх лет каждые две недели (с некоторыми пропусками), я публиковал большой совет‑лекцию. Целый год заняли советы только об одной закономерности дизайна — повышении управляемости. Для сравнения — советы‑рукопись книги «Типографика и вёрстка» были написаны за 11 месяцев.

Поделиться своими знаниями о «дизайне всего» я мечтал десять лет. Советы под рубрикой «Решение задач» я писал по плану, который подготовил заранее. И вот сегодня я написал последний совет.

Тема работоспособного дизайна объединяет наши дизайнерские дисциплины и преподавателей — Бирмана, Ильяхова, Нозика, Товеровского, Синельникова, Беляева и Куличевского. Это дизайн всего: систем, интерфейсов, текста, отношений и процессов. Священным дизайнерским граалем я это не называю из природной скромности и потому, что грааль — призрачная мечта, а дизайн работоспособных систем бюро практикует ежедневно. Эти советы — плод наших многолетних наблюдений, выводов, обобщений и открытий.

Мой план состоял из трёх больших частей: разрешение противоречий, создание работоспособных систем, эволюция работоспособных систем. Этапы решения задач — это эпилог, подведение итогов.

Многое я понял и узнал, пока писал эти советы. У меня самого в голове разложились по полочкам пути разрешения противоречий, осознались понятия целостности и образования в системах, родилась идея свойств работоспособных систем FIRE, оформились стратегии редизайна существующих продуктов.

Я отдаю себе отчёт, что мои советы‑лекции о работоспособном дизайне непонятны и неинтересны большей части дизайнеров, в отличие, скажем, от лекций по типографике и вёрстке. В первую очередь я виню себя как автора — ведь это моя задача заинтересовать аудиторию. Вторая причина в том, что я пишу об универсальных принципах дизайна, в моих примерах встречается то веб‑дизайн, то техника, то промдизайн, то бизнес и организационные решения. Каждый человек занимается своим делом, и ему трудно понять, зачем изучать смежные дисциплины, которые не имеют к нему прямого отношения.

Третья причина заключается в том, что только небольшая часть аудитории действительно занимается решением задач. Много дизайнеров и менеджеров просто «пилят сайты», «рисуют иконки», «оптимизируют ключевые слова», «печатают буклетики» и «ведут СММ», даже не задумываясь, почему клиент об этом попросил и зачем это нужно. Это связано с профессиональной специализацией и с тем, что дизайнеры в больших компаниях чаще всего ничего не решают.

Я считаю своей аудиторией менеджеров продуктов, технических директоров, арт‑директоров, ведущих дизайнеров и разработчиков и тех, кто мечтает ими стать. Я верю, что самых востребованных специалистов отличает не гениальность, а мультидисциплинарный, системный и эрудированный подход. А этому вполне можно научиться и научить.

Наверняка многие из вас уже догадались, что мои советы — рукопись будущей бюрошной книги. Если эта книга выйдет, она будет называться «Работоспособный дизайн». В ней знания будут оформлены в структурированном, лёгком для поиска виде.

Скорее всего, книга выйдет просто потому, что я верю, что она должна выйти. Хватило же мне силы воли на три года, несмотря на постоянные шуточки Сергея Короля. Но мне очень придаст вдохновения и желания ускориться ваша поддержка. Если вы хотите эту книгу, оставьте, пожалуйста, свой адрес электронной почты ниже.

И мы напишем вам, когда будут новости.