Бытует мнение, что для начала работы над интерфейсом требуются некоторый набор пользовательских историй. Мнение это настолько укоренилось, что регулярно порождает проблемы при передаче артефактов от дизайна в разработку. На самом деле, это лишь малая часть из того, что нужно знать для разработки интерфейса. Получить действительно исчерпывающую документацию для работы, дизайнеру, как и разработчику, получается крайне редко. Каким должен быть базовый или минимальный набор вводной информации, чтобы дизайнер смог приступить к работе?
По моему опыту, если обобщить, требования можно разделить на шесть частей:
- Перечень типов сущностей. Как правило, они состоят из набора полей с различными типами данных, требующих своего набора контролов и паттернов работы с ними.
- Взаимосвязи сущностей и их подчинённость. Эта информация помогает выстроить информационную архитектуру. Проще говоря, разработать требования к навигации внутри приложения.
- Жизненный цикл сущностей. Это знание описывает как информация попадает в приложение, как меняется и что должно получиться в результате.
- Статусная модель сущностей. Информация об этом позволит дизайнеру понять как сущности могут влиять на друг друга в процессе изменения значений в полях. Поле со статусом — устоявшийся паттерн. Сама модель может быть в виде списков, графов, классификаторов. Статусная модель, а также само значение этого поля для каждой сущности, может изменяться руками пользователя, по какому-то алгоритму внутри приложения, через интеграцию с другими приложениями или сервисами.
- Требования к пользователю. В прикладных приложениях, как правило, описывается существующими бизнес-процессами, технологическими картами или, на худой конец, должностными инструкциями. Про это как раз и пишутся, так называемые пользовательские истории.
- Требования к выводу. Это может быть интерфейсным решением, интеграцией или иным результатом. Во всех случаях, это приводит к осознанным действиям пользователя в реальном мире.
В больших командах, на первые четыре вопроса может ответить системный аналитик, на последний вопрос, как правило отвечает владелец продукта или, как сейчас модно, продуктовый менеджер. Предпоследний вопрос потребует от дизайнера погружения в предметную область. Нередко, дизайнеру приходится добывать вышеуказанные требования самостоятельно, что больше похоже на детективное расследование, чем на анализ и разработку.
Можно начать работу с неполных требований, однако очень высок риск получить дорогие доработки позднее. Сначала получить дорогие доработки на этапе дизайна, а потом и на всех остальных. Суетливый и несистемный подход в решении дизайн-задач почти всегда наносит ощутимый материальный ущерб.
В чём может выражаться ущерб? Конечно, в затрачиваемом времени работников, то есть в прямых денежных потерях, прежде всего. Потери будут происходить от доработок основных сценариев работы с приложением, постановок задач на разработку, доработок программных компонент, их тестирования, обновления документации и локализации, обновления информации на всех линиях техподдержки, а также промо-материалах на различных носителях. Тогда выдвигается гипотеза, что потерь можно избежать, например, ничего не делая. Зачастую, надо отметить, так и бывает, поэтому говорить про хороший и продуманный дизайн в этих случаях вообще не приходится. Потери считают потом, по стоимости линий технической поддержки, текучке персонала, штрафам и прочему неприятному.
У дизайнера, при таком подходе, жизнь становится примерно в три раза активнее: теперь он или она будет готовить три пакета документации: как понял задачу дизайнер, как надо показать менеджменту и как может реализовать разработка. Ведь работа дизайнера — это не показывать макеты, продавать и проводить опросы. Результат работы дизайнера — это часть документации на разработку, которая содержит описание множества дополнительных состояний и требований от коллег по обе стороны конвейерной, если можно так сказать, ленты.
В самых причудливых формах, когда менеджмент придерживается правила «в любой непонятной ситуации расширяй штат», команда дизайнеров разрастается бесконтрольно, а продуктовая линейка выглядит и работает совершенно по-разному. Я же соглашусь с великим полководцем Александром Васильевичем Суворовым, который говорил, что воевать нужно не числом, а умением. Менять нужно подход к решению дизайн-задач.
Про причудливые формы в управлении дизайнерами и борьбу с бардаком можно почитать в заметке «Суетливый дизайн»
Про оправдания работы без требований и спецификаций можно почитать в заметке «Дизайн на основе данных (Data Driven Design)»
Наверное, вопрос про устройства — один из самых важных вопросов, который должен задавать себе дизайнер интерфейса перед началом работы. Устройства определяют контекст, скорость ввода и вывода, а также объёмы обрабатываемой человеком информации.
Так, перед разработкой интерфейса для телевизора, пожалуй, стоит изучить типовые планировки квартир, а не писать пользовательские истории вида «я как пользователь дивана хочу засыпать под телепередачу». Смотрим планировку, смотрим контекст: кухня, гостиная, спальня, детская. Как предприимчивый и хитрый дизайнер, я бы ещё посмотрел фотографии квартир, выставленных на продажу на вторичном рынке недвижимости. Далее изучаем интерфейс устройства: пульты, голосовой ввод, экраны, углы обзора и прочее. Делаем выводы о размерах гарнитуры шрифта и контролах, требованиях к цветопередаче, контрастности и сопровождающих их настройках. На сегодняшний день, мне неизвестны приложения популярных видеохостингов, которые решили эту задачу достойно. К телевизору надо подходить, чтобы понять, что же там написано, в каком состоянии интерфейс и что требуется от пользователя. Цитируя нашего современника «Это фиаско, братан!».
Современный человек окружён множеством устройств. Нужно трезво оценивать свои возможности по обучению пользователя чему-то новому. Возможно, стоит творчески позаимствовать существующие решения и, тем самым, сэкономить калории на построении новых нейронных связей в голове пользователей. Вдохновляться можно интерфейсами приложений, развивающихся постепенно, с устоявшимися паттернами. Что-то меняющееся в угоду метрикам, не подойдёт. Метрики задают люди за них отчитывающиеся, люди на этих рабочих местах меняются, а значит это подвижная история, которая никогда не будет иметь фундамента.
Что же тогда считать фундаментом? Как было сказано выше, конечно, устройства ввода. А также особенности работы, например, требуется постоянное подключение к сети, а значит возникает зависимость пользователя от сторонних провайдеров. Мне приходилось сталкиваться с гибридными вариантами, когда необходимо обеспечить оффлайн режим и уметь синхронизироваться. Онлайн-сервисы подразумевают совместную работу, а это тянет за собой целый пласт логики, с которой нужно определиться на ранней стадии, перед разработкой интерфейса, о чём мы говорили в начале этой заметки. Из вышеперечисленного возникает важная задача по обработке ошибок, которой зачастую пренебрегают. Комбинации из этих вопросов не всегда по силам решить даже опытным специалистам, поскольку всё упирается в бюджеты и сроки. Однако, это не означает, что задача нерешаемая. Некоторые штуки делаются постепенно, не сразу. Посмотрите на опыт старших товарищей, на программное обеспечение развивающееся постепенно, скорректируйте планы, выделите главное, не пренебрегайте критически важными вопросами. Например, определите, где вы можете потерять пользовательские данные и придумайте как можно сгладить и локализовать проблему имеющимися у вас инструментами. Ограничения просто необходимы, это нормально.
Мой опыт по большей части лежит в разработке узкоспециализированного программного обеспечения, поэтому погружение в предметную область стоит в приоритете. Если сроки и бюджеты позволяют, то необходимо кроме изучения бизнес-процессов, с которыми связана программа, также уделить внимание документообороту, изучению должностных инструкций будущих пользователей программы (поможет лучше разобраться в ролевой модели и управлении доступами), почитать законодательство, попросить аналитику и конкурентный анализ от коллег (поможет понять на что стоит обратить внимание и как позиционируется продукт).
Когда поймём какие задачи нам нужно решать и зачем, сможем двигаться дальше. У нас есть перечень типов сущностей, их взаимосвязи и подчинённость, жизненный цикл, статусная модель, требования к пользователю, требования к выводу, общие представления о пользователе и окружающем чего мире.
Пора обсудить всё с инженерами. Цель — прийти к соглашению об используемых технологиях, их возможностях и ограничениях. На основе полученных знаний выбираем инструменты, проще говоря, на чём и как будем собирать интерфейс. Избежать этого разговора, как-то заболтать и зарегулировать этот процесс легко не получится. Инженер и дизайнер как две половинки. Если между ними пропасть, то это половинки одной жопы.
Далее, согласно приоритетам в реализации задач можно составить план разработки и развития интерфейса продукта, а значит можно понять в какой последовательности нам потребуется разрабатывать и дорабатывать интерфейсные решения. Наглядными примерами являются инструменты навигации и компонент таблицы, которые могут развиваться итеративно. На больших продуктах почти все дизайнеры и разработчики интерфейса сталкиваются с такими задачами.
Отметим также важность «продуктового ландшафта». В моём мире, перед релизом продукта, есть пилотные запуски, внедрения, техническая поддержка и её стоимость, масштабирование, интеграторы, сторонние вендоры и прочее. В конце мы отдельно поговорим про этот самый «продуктовый ландшафт» и его место в голове и рабочем процессе дизайнера.
«Если бы всё было так просто!» — скажут менеджеры проектов, дизайнеры и лидеры команд разработки. Конечно, даже в рамках одного продукта могут быть разные команды, разные методологии, разные подходы. Дизайнер может редуцировать подходы в решении дизайн-задач, ни одна методология или должностная инструкция вам этого не запретит, иногда в этом и суть нашей работы.
При анализе минимального набора требований, ограничений реального мира, отсортированных по приоритету задач, возможностей и ограничений технологий можно описать типовые подходы к решениям в дизайне интерфейсов.
В работе дизайнера интерфейсов есть три обязательных части: информационная архитектура, работа с данными, стилизация и брендирование. Последняя часть наиболее заметна, но наименее затратна. Что касается первых двух, то они должны помочь перечислить минимальный набор необходимых инструментов. Под инструментами я понимаю контролы, методические рекомендации по их использованию, устоявшиеся паттерны построения интерфейсных решений и прочее.
Про цвет, форму, сетки, буквы и прочее подробно и в доступном виде написано в книгах, рассказывают на курсах, пишут в статьях и преподают дисциплины в различных профильных учебных заведениях. В этом деле я вам ничего нового и умного рассказать, наверное, не смогу.
Теперь, после анализа, у нас есть некоторые наработки и предложения типовых решений. Давайте посмотрим на них в разрезе времени: что нам нужно для первоочередных задач, а что можно отложить. Это большая и утомительная работа: сверять план развития компонентной базы и паттернов построения интерфейсов с постоянно меняющимся беклогом разработки. Однако, лучше выделить одного дизайнера методиста в отделе дизайна, чем постоянно держать всю продуктовую команду в стрессе и режиме тушения пожара перед планированием спринтов.
Атомарные компоненты и их ограниченный набор важен в том случае, если ваша разработка не пишет свою библиотеку, а использует готовые решения и не может сойтись на чём-то одном. Это нормально, нужно принимать это как явление природы. Чем проще набор атомарных контролов, тем больше шансов, что их приведут к одному виду и логике работы. Если вы думаете, что эта проблема решена, то посмотрите на выпадающие списки (также известные как select) в разных фреймворках для веб-приложений.
Со сложными компонентами также нужно держать себя в руках и не плодить разное поведение для решения аналогичных задач. Рекомендую развивать версии отдельных сложных компонент и обязательно учитывать обратную совместимость. Отклонения от типовых решений должны проходить отбор внутри дизайна. Дизайнеру нужно приложить усилия, чтобы обосновать дополнительные затраты на разработку чего-то нового или хорошо забытого старого, поскольку в нормальной разработке новый компонент — это дополнительный релизный цикл.
Скорость и снижение стоимости появляется с унификацией. Если бы каждый производитель всё делал по-своему, то, например, о гражданской авиации, заправочных станциях, бытовой технике и электронике, медицине и прочих благах можно было бы и не мечтать.
Конечно, это связано с некоторым самоотречением, но будем честны, не всегда перед нами стоит цель изобрести что-то новое. Что-то умное в дизайне не всегда революционное и шатающее привычные устои, иногда совсем наоборот.
Форма не должна господствовать над функцией. Дизайн интерфейса — это не графический дизайн, не статичная история. Красота достигается через очевидность и простоту решения, то есть как-то иначе интерфейс было бы делать глупо. Также глупо нагружать интерфейс дополнительными смыслами, это даже звучит тошнотно. Вот смотрите: премиальный календарь, чувственный браузер, выгодный менеджер паролей. Давайте сделаем так, чтобы люди со слабым зрением, уставшие люди, пожилые, очень занятые, с разной подготовкой и финансовыми возможностями смогли комфортно работать с вашим программным обеспечением на разных устройствах. А пока, к сожалению, у нас беспощадно-загадочные маркетплейсы и геймификация вместо, простите, действительно хорошо сделанной работы.
При разработке интерфейса узкоспециализированного программного обеспечения, так исторически сложилось, во главу угла ставят задачу сделать как можно раньше и соответствовать программам и методикам испытаний. Тем не менее, если в результате возникает потребность продукт продать, он начинает обрастать рядом дополнительных требований: удобство работы, скорость работы в приложении или временные затраты на выполнение операций, стоимость обучения, стоимость поддержки и доработок, прочность интерфейсных решений, узнаваемость.
Комбинации бывают разные, но метриками это определённо считать можно. Все из них прекрасно ложатся в дизайн-задачи. Так стоимость поддержки можно снизить документацией, обработкой ошибок, системным подходом к сбору информации о неисправностях: коды ошибок, информация об окружении, информации о событиях и действиях, приведших к ошибке и др. На вопрос каким образом дизайнер относится к документации ответ очевиден: всё в интерфейсе имеет название и нуждается в текстовом описании, интерфейс локализуется, ссылки на документацию и справочная информация должны сопровождать пользователя на протяжении работы с приложением. Стоимость обучения можно снизить, если изучить опыт работы пользователей в смежном программном обеспечении и ориентироваться в общей подготовке своих пользователей. Например, посмотрите какие сложности вызывают вопросы информационной безопасности внутри больших компаний, несмотря на обучение, политики безопасности, программно-аппаратные комплексы, специалистов и так далее. Всё равно их взламывают зачастую из-за человеческого фактора: фишинг, телефонные истории и примитивные пароли.
Метриками можно «обмазать» любой интерфейс, всё зависит от того есть ли у вас желание оптимизировать свою работу, помочь коллегам, научиться чему-нибудь новому. Важно не позволять в угоду метрикам уродовать пользовательский опыт и своё ментальное здоровье.
Поскольку не слежу за трендами и новыми словами для продаж времени консультантов, то использовал такое словосочетание. Как можно ещё описать ямы с пользователями, попавшими в ловушку непродуманного взаимодействия, горы из нескольких линий техподдержки, лес с брошенными в нём специалистами внутренней автоматизации, крепости специалистов по информационной безопасности и образовавшиеся овраги в результате специфических интеграций?
Проекты имеют жизненные циклы, включающие в себя пилотные запуски, внедрения с особенностями интеграции, особенности обслуживания и техподдержки, вовлечение сторонних интеграторов и вендоров. Всё это определяется параметрами договоров и бюджетами. На вашего пользователя всё это также оказывает влияние. Коридорные исследования, документация, правильный интерфейсный текст, красивый и уникальный дизайн выглядит в этом ландшафте как мыльные пузыри и примерно также влияют на его формирование.
Дизайнеру в этих случаях полезно перестать «щекотать» пиксели, перестать слушать истории про «кабинетный» дизайн и походы в народ. Нужно уделить время изучению ландшафта, это позволит связать истории от посадочных страниц до техподдержки. Нанести на карту не только пользователей, но и своих коллег, участвующих в работе над продуктом. Понять кто, когда, как и в какие сроки привлекается к работе и решению проблем пользователя. Поверьте, вам откроется новый дивный мир, который перевернёт приоритеты в ваших дизайн-задачах, а также позволит доступно объяснить коллегам на что стоит обратить внимание.
15 октября, 2023
Пётр Лутов
Дизайн в разработке программного обеспечения