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

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

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

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

• Схема решения одинаковая для всех видов дизайна — продуктов, графики, интерфейса, навигации, программ, бизнеса. Эти этапы пригодятся и в обычной жизни:
• Анализ. Первым делом нужно понять задачу, а точнее — проблемную ситуацию. Например, «я хочу есть» — первоначальная формулировка. Полезное действие — поесть. Противоречие — в холодильнике пусто. Вред — голод и лень.
• Модель. На основе связей и условий задачи нужно найти смысловой образ решения. Моделей решения может быть несколько: «сходить за едой самому», «сходить куда-нибудь поесть», «пусть кто-нибудь принесёт мне еду».
• Решение. Модель решения воплощается в конкретную форму: «зайти на сайт Ми Пьяче и заказать пиццу».

Анализ задачи

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

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

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

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

• В семье

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

  Полезное действие: утренний кофе; вред: рассыпанные частицы кофе. Анализ переводит ситуацию из области сложных психологических противоречий в техническую задачу покупки автомобильного пылесоса.

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

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

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

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

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

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

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

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

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

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

• — Мы не любим пошлые советские свадьбы с выкупами, столами буквой «П» и песней «Свадебные цветы». Это пытка для всех: гости фотографируются среди шариков в обшарпанном подъезде, катаются на микроавтобусе, слушают тамаду в кафтане. Кусаем каравай, бьём бокалы, собираем деньги в ползунки — бессмысленная чушь. Нет радостных воспоминаний, нет красивых фотографий, нет истории, которой хотелось бы поделиться. Упущенный шанс сделать праздник. Мы хотим, чтобы больше людей женились красиво. Чтобы свадьбы были о влюблённых, а не о суевериях и амбициях родителей. К счастью, мы не одиноки, поэтому в феврале 2013 года мы открыли свой свадебный салон в Москве. Обращение соавторов на главной странице сайта «Мэри Трюфель»

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

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

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

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

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

• Работа с почтовыми сообщениями
  • Проверка наличия новых сообщений
    • Ручная проверка
    • Индикация новой почты
  • Просмотр входящей корреспонденции
    • Просмотр множества писем, выбор
    • Чтение отдельного сообщения
  • Работа с вложенными документами
    • Просмотр вложенных документов
      • в т. ч. просмотр альбомов фотографий, архивов
    • Сохранение вложенных документов
    • Печать вложенных документов
  • Ответ на сообщение
    • Работа с цитатами
  • Пересылка сообщения
  • Пометка сообщений (важность и напоминания, пометка о прочтении, защита от удаления, спам/не спам)

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

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

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

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

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

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

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

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

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

  С каналами, маржинальность которых в норме либо договоры по которым были утверждены контролёром или аудитором (в статусах «в норме» и «утверждён» ниже) менеджеру ничего не нужно делать, но важно их просто увидеть. Он просматривает информацию о них и жмёт кнопку «Просмотрено».

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

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

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

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

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

Пользователи чекинятся в заведении, потому что завидуют чужому мэрству

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

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

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

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

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

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

• Бесплатные автомобили

  В прошлом таксопарки содержали свои автомобили и автомастерские. Теперь таксокорпорации Убер, Яндекс и Гетт не владеют собственными автомобилями, а используют автомобили водителей, таксопарков и компаний-партнёров.

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

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

• Прибауточный ресурс

  Шеф-повар, журналист и автор Алексей Зимин постоянно использует в своих рецептах и книгах смешные заголовки с культурными отсылками: «Вок в помощь», «Паровое дело», «Горе от умами», «Овощи в себе», «Дорога блинная», «Тихий удон», «Вечно пряные».

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

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

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

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

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

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

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

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

Синтаксический анализ — это просто более общее и красивое название сценариев использования продукта (по-английски use cases). Ну должен же я поумничать. Если серьёзно, то взаимодействие в системах не обязательно связано с пользователями или даже с использованием: например, взаимодействие программных интерфейсов или нежелательные столкновения сотрудников тоже можно описать формальным языком. Соответственно, синтаксический анализ пригодится для сложных многопользовательских сервисов, систем документооборота, сложных АПИ. Например, в бюро так описывали взаимодействие Бюробиллинга и Бюрокассы — веб-сервисов для существующих и будущих продуктов бюро.

Модель решения

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

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

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

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

• Карл Дункер называл модель решения «функциональным значением» или «функциональным смыслом». У любого конечного решения есть «функциональный смысл», благодаря которому это решение сработало или сработает аналогичное. Одна из задач в экспериментах Дункера — об облучении опухоли рентгеном. Нужно найти способ воздействовать на опухоль лучами так, чтобы не разрушить здоровые ткани. Люди предлагали варианты, которые складывались в три группы:
• исключить контакт между лучами и здоровой тканью (пропустить лучи через естественные отверстия, защитный барьер, открытая операция);
• уменьшить мощность лучей по пути, увеличить на опухоли (сконцентрировать несколько слабых лучей на опухоли);
• уменьшить чувствительность тканей (какой-нибудь инъекцией).

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

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

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

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

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

• Ничего нового

  Модель решения: вызвать еду на дом.

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

• Новая книга

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

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

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

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

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

• Плохо

  Создать сайт с продуктами компании

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

• Так себе

  Повысить продажи компании, создав сайт с продуктами

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

• Хорошо

  Упростить клиентам компании покупку продуктов, создав сайт с каталогом и простой формой заказа

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

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

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

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

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

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

Решение

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

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

• На пути к запуску

  Начало 2004 года, когда Спейс Икс собиралась запустить ракету, наступило и прошло… Наконец, осенью 2004 года двигатели стали работать стабильно и удовлетворять всем поставленным требованиям. Это означало, что Мюллер с командой могли вздохнуть свободно, а все остальные сотрудники Спейс Икс — приготовиться к страданиям… Посыпались серьёзные проблемы. Бортовая электроника, то есть системы навигации, коммуникации и общего управления ракетой, оказалась сущим кошмаром. По неизвестным причинам не удавалось выполнить банальные на первый взгляд задачи — например, заставить главный компьютер ракеты воспринимать флеш-память. Программное обеспечение, необходимое для управления ракетой, тоже стало настоящей обузой.

  Эшли Вэнс. Илон Маск: Тесла, Спейс Икс и дорога в будущее. Олимп-Бизнес, 2015

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

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

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

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

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

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

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

• Рецепта поиска окончательного решения у меня нет. Но я могу дать несколько советов. Используйте в своём поиске:
• Ресурсы. Чемодан «Раз-два-трипа» — банальный образ путешествия, лежащий на поверхности. Видеозаписи трёхдневных учебных курсов помогли нам запустить девятимесячную Школу дизайнеров, а затем Школы редакторов и менеджеров.
• Воспоминания, наблюдения и опыт из других областей. Моя история личного знакомства с чайным мастером Андреем показала мне собственные человеческие слабости, которые можно использовать в интернет-магазинах.
• Спецэффекты. Может быть, вам нужно «сделать в шутку», использовать плацебо или щётку? Изучайте знания о мире и человеке.
• То, что уже хорошо работает в вашей системе. Если в вашей системе хорошо работают дедлайны, сделайте десять дедлайнов. Если в одном вашем журнале хорошо сработали форматы, используйте их в других журналах.

• Когда кажется, что решение найдено, становится очень радостно. Но не забудьте критически проверить своё решение, задав себе вопросы:
• А почему оно будет работать? Полноценная ли формула у вашего решения?
• Не потеряет ли система целостность из-за вашего решения? А хорошо ли само решение интегрировано в систему? Узнают и доберутся ли пользователи до новой функции? Видно ли кнопочку?
• Похоже ли ваше решение на хорошее по духу? Хорошее решение всегда выглядит элегантно, потому что достигается бесплатно или минимальными затратами.
• Поймут и примут ли люди ваше решение? Помните об образовании в работоспособных системах.

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

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

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

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

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

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

Работоспособный дизайн — чтобы правильно прицелиться.

P. S.

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

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

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

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

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

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

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

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

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

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

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