Проэктирование простых и легких в использовании корпоративных продуктов довольно сложный процесс. Клиенты ожидают увидеть нечто, вроде Facebook или Instagram.
Джон Маэда, бывший президент школы дизайна Род Айленда, определяет «вдумчивое сокращение» как подход к улучшению дизайна. Он говорит, “Простота — это убирание очевидного и добавление смысла”
Почему же дизайнеры, и их команды, так склонны к сложным дизайнам?
Давайте посмотрим, как можно использовать методы в процессе проектирования, чтобы сделать дизайн сложных приложений — простым.
- Продумайте высокоуровневые пользовательские истории что бы заложить начальные точки проэктирования
Быстроразвивающиеся методологии разработки используют концепцию, называемую epic, которая является высокоуровневой пользовательской историей, и которая говорит, что инженер планирует строить. Дальше, в этом посте, я буду использовать «Epic», и «высокоуровневая пользовательская история» как взаимозаменяемые понятия.
Если бы вы проэктировали такие приложения для онлайн платежей, как, Square, Stripe, или Braintree, то вот пример пользовательской истории высокого уровня:
Эта история дает инженеру понять, как функция должна вести себя в целом, но не объясняет, как он должна выглядеть, как ощущаться, или как пользователь должен ее находить.
Внешний вид и чувства определяются позже, на стадии визуального дизайна. А то, как пользователь ее найдет определяется потоком задач.
Рассмотрим поподробнее процесс написания пользовательских историй.
Что такое высокоуровневая пользовательская история?
Пользовательская история высокого уровня описывает 2 вещи:
- Задача, которую кто-то может выполнить
- Чем это приложение может заинтересовать
Если бы мы работали над приложением для онлайн платежей, вот еще немного историй:
- «Пользователь может предложить клиенту скидки, купоны и особые условия, с тем, чтобы он мог выдвинуть на рынок конкретные продукты.»
- «Пользователь может принимать деньги в разных валютах, чтобы клиенты могли знать, сколько денег было переведено на их покупку в местной валюте.»
- «Пользователь может просматривать историю платежей, чтобы отслеживать транзакции.»
Остерегайтесь написания плохих, или слишком больших пользовательских историй — ваше приложение может обрабатывать их без какого — либо вмешательства пользователя. Как правило для них невозможно составить дизайн, но инженеры должны включать их в свой проэкт.
Пример плохой истории пользователя:
» Пользователь может вычислить итог транзакции, что бы понимать сколько денег будет переведено.»
Почему она плохая? Наше приложение автоматически вычисляет стоимость, так что пользователю не приходится использовать калькулятор в приложении или нажимать на кнопку «Рассчитать».
Когда вы что-то покупаете, вам приходится самому что-то добавлять, или спрашивать кого-либо о конечной стоимости? Конечно нет.
Лучший вариант истории:
» Пользователю будет показан итог транзакции, что бы он видел, сколько денег будут переведено.»
Описывая эти высокоуровневые истории для одной функции, вы сможете думать над разными частями приложения, которые эта функция буде затрагивать, что позволит вам спроэктировать стартовую площадку, с которой пользователь будет попадать в поток этой функции.
Но пользовательские истории высокого уровня пока что не объясняют контекст того, как люди будут использовать функцию.
Для этого мы сделаем следующий шаг.
- Разбейте историю пользователя высокого уровня на более мелкие, более конкретные истории пользователей что бы разметить основные направления
Пользовательские истории можно разложить на 2, или больше маленьких истории. Эти маленькие истории представляют контекст и детали о том, как функция будет работать. Это не только поможет вам проэктировать для конкретных случаев использования вместо того, чтобы решать огромную проблему, но также поможет вашим инженерам понять различные части приложения, которые будут затронуты этой функцией.
«Разделите epic на 2 или более истории, чтобы представить подробную информацию о том, как функция работает для пользователя.»
Например, историю пользователя высокого уровня «Пользователь может создавать планы подписки с тем, что бы он мог определять ценовые точки и пакеты для своего бизнеса» можно разделить на такие истории:
- Пользователь может настроить периодичность оплаты в плане подписки (дни, месяцы, годы)
- Пользователь может давать название плану подписки (Бронзовый план, Серебряный план, Золотой план)
- Пользователь может установить цену плана подписки ($99, $199, $299)
Теперь мы знаем, что общая концепция «создания плана подписки» для пользователя охватывает 3 результата:
- Установка периодичности оплаты
- Название плана
- Ввод цены плана
Выполнив эти 3 действия, пользователь успешно создает план подписки.
Если после разбивки epic на небольшие истории, вы получаете слишком много частей, то еще раз подумайте над тем, сколько действий пользователь должен предпринять до того, как получит выгоду от вашего приложения.
«В вашем epic слишком много частей? еще раз подумайте над тем, сколько действий пользователь должен предпринять до того, как получит выгоду от вашего приложения.»
То, что корпоративные приложения пытаются решить сразу много задачь делает их неуклюжими и более громоздкими, чем потребительские приложения, поэтому пользователи начинают предпочитать потребительский опыт в корпоративных приложениях.
Путем уничтожения ненужного, и приоритезации того, что необходимо пользователю для получения выгоды, вы сможете сконцентрироваться на той ценности, которую предлагает ваше приложение и как можно быстрее дать пользователю осознать ее. И об этом мы сейчас поговорим.
- Уничтожьте ненужное, и приоритезируйте пользовательские истории
Вам не нужно проэктировать для всего списка пользовательских историй. Если вы так поступите, то скорее всего получите раздутую функцию, которая выполняет слишком много функций и может подавить пользователя.
Например, предположим, что ваш целевой рынок состоит из бизнеса в Соединенных Штатах. Вы можете сосредоточиться на обработке платежей в американских долларах. Вместо того, чтобы разрабатывать систему для обработки нескольких валют, их курсов обмена, и налогов на многонациональном уровне, вы можете сосредоточиться на вашем целевом рынке.
Это стратегическое решение может сократить время разработки и позволит сосредоточиться на том, что важно для вашей текущей клиентской базы и вашего бизнеса. Вполне разумно это игнорировать до тех пор, пока ваша компания не расширит свой бизнес на международном уровне.
- Преобразуйте пользовательские истории в потоки задачи
Напишите свои пользовательские истории на доске -это легко, и не даст вам остановиться на какой-либо одной идее. Пользовательские истории и потоки задач будут проходить через ряд черновиков. Доска позволит вам быстро менять свои идеи.
Записав истории на доске, вы можете начать собирать основной поток, через который должен пройти пользователь. Здесь начинается поток задач. Поток задач объясняет, как кто-то будет вливаться в поток, а также как он выполняет задачи, точки выхода и точки принятия решений.
Поток задач имеет смысл, поскольку он не только позволяет увидеть общую картину, но также предотвращает создание тупиков. Кроме того, он поможет вашей команде понять ход ваших мыслей.
Вот обычный рабочий сценарий:
Член команды объясняет конкретный поток устно на встрече или через чат. Все члены команды кивают в знак согласия. Через несколько дней, вы и ваши сотрудники понимаете, что говорили о разных вещах.
Потоки задач устраняют этот риск, визуально объясняя ваше видение, для того, чтобы вы, и ваша команда понимали о чем речь. В дополнение к созданию взаимопонимания с вашей командой, диаграмма потока задач описывает сферу действия вашей функции с точки зрения пользователей. Поток задач заставляет вас, и вашу команду, рассмотреть все точки соприкосновения, альтернативные потоки, крайние и угловые случаи.
Что происходит, когда пользователь выходит из потока? Что происходит, когда пользователь возвращается? Что происходит, когда выскакивает ошибка?
Не все конструкции являются линейными и последовательными. Поток задач принимает во внимание несколько переменных. Различные факторы могут влиять на то, как пользователь перемещается по вашему приложению. Конечным результатом является стратегически продуманный план того, как кто-то может использовать ваш продукт.
Что можно из этого вынести
Атаковать проблему в лоб, и начинать рисовать разметку в Photoshop в качестве решения — распространенная ошибка процесса проэктирования. Конечно соблазнительно сразу начать подбирать цвета, выстраивать элементы интерфейса и настраивать типографию.
Прежде, чем что-то проэктировать, добавьте в процесс эти 4 шага:
- Хорошо обдумайте высокоуровневые пользовательские истории, что бы наметить чего кто-либо достигнет, использовав функцию
- Разбейте epic на мелкие, усваиваемые кусочки. Это послужит отправной точкой для увеличения контекста для пользователя, и поможет вашей команде понять ход ваших мыслей.
- Исключите пользовательские истории, несущественные для людей, которые захотят получить пользу от вашего приложения, или выполнить какую-либо задачу не напрягаясь.
- Подойдите к доске и нарисуйте поток задач, собирающий вместе все истории, что бы у вас был гибкий холст для обсуждения идей, изменения потоков и сотрудничества
С помощью пользовательских историй и потоков задач, вы можете предоставить отличные дизайны, которые поднимут ваш продукт на новую высоту.
Как однажды сказал Стив Джобс: «Дизайн — это не только внешний вид, но и то, как продукт работает.».
