Здравствуйте, меня зовут Александр Волков, я проектирую интерфейсы в Docsvision. Цель данной статьи — помочь разработчикам сложных программных продуктов.
Ключевое слово — сложный.
Сегодня даже пятиклассник может создать сайт-визитку прямо на своем смартфоне, а при желании можно скачать zip-архив с готовым шаблоном для блога или корпоративного сайта.
Однако если ваше приложение сложнее обычного интернет-магазина, то, вероятно, вам придется самостоятельно выстраивать структуру и определять принципы навигации, наступая на разбросанные повсюду грабли.
И здесь наш опыт может пригодиться.
Опишу один из возможных методов проектирования интерфейсов, который успешно опробован в нашей компании.
Делается это легко и просто (практически полуавтоматически) с помощью программы FlyingLogic. Программа использует Теорию ограничений Голдратта, используется для построения диаграмм, конкурентного анализа и похожа на Excel, но не по цифрам, а по причинам и следствиям.
Очень кратко, если у вас проблемы типа: «Не все люди японцы.
Все японцы?", то FlyingLogic вам понравится.
Здесь надо отметить, что ее написали не мы, а совсем другие талантливые программисты, за что им большое спасибо, ведь она оказалась очень полезной в нашей непростой задача.
Честно признаюсь, что хотя теория и упомянута в заголовке, в тексте вы ее не найдете.
OkGoogle явно знает больше меня об этой и любой другой теории.
Расскажу о практике — построении графа целей, а также о том, как мы принимаем решения при проектировании.
Это был спойлер — кинематографический приём для экономии времени.
Давай начнем! Краткое содержание: 1. В чем проблема 2. Продукт – это не сайт. 3. Скрипты, скрипты.
4. Что делать? 5. Решение 6. Пример 7. Выводы Я постараюсь придерживаться этого плана, пока не увлекусь деталями.
В чем проблема Если вы дочитали до этого места и не убежали смешно, размахивая стопкой бумажных прототипов, то вам интересно, в чем же проблема? В нескольких словах это можно выразить так: нелинейность и разнообразие сценариев.
В современных системах электронного документооборота, которые разрабатывает наша компания, к сожалению, нет простого, понятного, прямого, как бильярдный кий, пути пользователя от главной страницы или лендинга до страницы регистрации или оплаты покупки.
Наоборот: движение документа, как и его жизненный цикл, зачастую извилисто, запутанно и зависит от множества внешних и внутренних параметров.
Среди таких параметров может быть, например, сумма контракта (при превышении определенного порога может потребоваться одобрение не только финансового отдела, но и юридического отдела).
Ход согласования документов зависит от ролевой модели утверждающего, наличия заместителей и (вы не поверите!) даже времени ухода регистратора в отпуск.
Наш эксперт знает об этом больше, чем кто-либо другой.
АндреевВС (Владимир Андреев), поэтому я отсылаю вас к нему и его серия статей .
Словом, сценариев бизнес-процессов может быть много; в каждой организации они свои, и удержать их в уме достаточно сложно.
И проектировщику необходимо не просто помнить о них, а выбрать основные и построить навигационную систему, отвечающую потребностям основной массы пользователей.
Что делать? Нет необходимости вешаться.
Если приложение небольшое, то есть радикальное решение: разбиваем его на небольшие логически последовательные части и привязываем доступ к этим кусочкам к меню на главной странице.
Вуаля! Именно так было спроектировано большинство веб-приложений и сайтов в чудесные 2000-е, когда рутрекер назывался совсем по-другому.
Однако пространство на главной странице не является гибким, и с увеличением количества частей, на которые нужны ссылки, стали появляться чудовищные многоуровневые меню.
Если бы я был присяжным, я бы оправдал пользователя, убившего разработчика такого меню.
Я думаю, вы понимаете, о чем я говорю.
Кроме того, такой подход совершенно не учитывает сценарии работы, и если для сайта это нормально, то для серьёзного бизнес-приложения это путь в никуда.
Сценарии Небольшое отступление.
Как учесть сценарии в дизайне? В самом общем случае это выглядит так:
- Получите список этих самых сценариев от бизнес-аналитиков.
И описание, если повезет.
- Глядя на этот список, нарисуйте набор экранов, стараясь повторить конкретный сценарий с минимальным количеством переходов и щелчков мышью.
- Используя эти экраны, создайте прототип для данного сценария, протестируйте его (при необходимости), исправьте все недостатки и повторите процесс для другого сценария.
- Затем наступает этап объединения этих атомарных кусочков в единое приложение.
И здесь живут драконы.
Дело в том, что скрипты начинают конкурировать друг с другом за место на экране и внимание пользователя.
Иногда их совершенно невозможно совместить.
Возникают хаос и энтропия.
Или хотя бы иметь какой-то критерий отбора.
Было бы лучше, если бы это происходило автоматически.
Нужна программа! Решение Как вы уже догадались, программа называется FlyingLogic и с нашей задачей она справляется отлично.
И не только с ней! Загрузите бесплатную 30-дневную пробную версию Здесь .
Вы можете прочитать о ней Здесь .
Для тех, кто любит не читать, а заглядывать через плечо, вот 13-минутный фильм.
видео о принципах работы (я обычно включаю двойную скорость, поэтому это занимает всего 6 минут).
Влад Головач в своей статье на Medium посчитал главным недостатком программы невозможность сортировки элементов и перемещения их по экрану.
Как ни парадоксально, но именно в этом для нас заключается его главное преимущество, потому что.
позволяет организовать автоматическое ранжирование.
Да и не только! Пример В качестве быстрого примера давайте спроектируем структуру абстрактного приложения.
Это таск-менеджер, в нем вы можете создавать задачи (делать) для себя или подчиненных и контролировать процесс их выполнения.
Мы будем вести разработку модно, исходя из целей пользователя.
Поясню, что под структурой подразумевается базовый скелет приложения и движение по нему, то есть принципы навигации.
Но только.
Если вас интересует внешний вид и расположение элементов управления, то Dribbble и Behance к вашим услугам.
Пара определений Актеры — это роли или любые другие системы, которые взаимодействуют с приложением.
Скрипт — это последовательность элементарных взаимодействий между приложением и актором для достижения своих целей.
Рисунок 1. Как связаны сценарии, действующие лица и цели
Сначала мы составляем списки действующих лиц и их целей.
Сразу хочу подчеркнуть, что эти списки неполные, но для нас это не имеет значения, нам нужно проиллюстрировать подход. В реальной разработке, конечно, списки должны быть максимально полными (см.
рисунок 5), чтобы не пропустить возможный сценарий.
Действующими лицами нашего приложения являются:
- Руководитель
- Исполнитель
- Контроллер
- Коллега
- мировоззрение
- Организуйте вещи
- Сделайте планирование проще
- Не пропускайте сроки
- Разгрузите голову
- Дайте ощущение контроля
- Взаимодействуйте с коллегами
- Снять ответственность
Составим список таких возможных элементарных действий:
- Добавить новую задачу
- Добавить повторяющуюся задачу (шаблон)
- Выполнить задачу
- Запланируйте задачу на определенный день
- Отклонить задачу
- Разделить задачу (создать подзадачу)
- Оценить нагрузку на день/неделю
- Просмотр уведомлений
- Найти запись
- Изменить запись
- Лист задач фильтра
- Сортировать лист
- Выберите задачу для выполнения (что делать дальше)
- Планируйте свой день
- Делегировать задачу
- Прокомментируйте задачу
- Оцените статус проекта
- Разрешение конфликтов
- Проверить прогресс
- и т. д.
Дальнейшая работа происходит внутри FlyingLogic. Мы создаем 3 типа объектов: действующие лица, действия и цели.
Мы начинаем связывать действующих лиц с действиями, пытаясь достичь выбранной цели.
Вполне возможно добавлять действия на лету.
Например, мы задаемся вопросом: как исполнителю достичь цели «Разгрузить голову»? Очевидно, вспомнив какую-то задачу, он должен немедленно добавить ее в приложение (или добавить и назначить срок выполнения).
Это освободит его мысли для предстоящей работы и цель будет достигнута, не так ли? Соединяем узлы «Исполнитель» -> «Добавить» -> «Разгрузить голову».
Когда узлы соединяются, происходит волшебство — они автоматически выстраиваются в некую иерархию, похожую на ту, что показана на картинке.
Внизу — действующие лица, вверху — их цели.
Движение по графику происходит снизу вверх.
Рис.
2 Так выглядит график целей в окне FlyingLogic Прелесть в том, что как только вы добавляете соединение или узел, граф перестраивается в соответствии с новой конфигурацией.
Давайте порассуждать Глядя на эту диаграмму, вскоре становится ясно, что:
- Чем меньше действий между действующим лицом и целью, тем быстрее и легче она достигается! Мы должны найти самые короткие сценарии, только тогда приложение будет успешным.
Такова жизнь, вода ищет дырку.
- Чем больше входных данных имеет действие, тем более «популярным» оно является.
Именно на эти действия нужно обратить особое внимание при разработке.
Они повлияют на большинство ваших пользователей.
- (Примечание: На самом деле это не совсем так.
Что делать, если вход всего один, но этим действием пользуются 90% пользователей? Ответ: Присвойте веса соединениям, в программе есть такая возможность.
)
- Сумма входных и выходных данных определяет вес действия в сценариях (это упрощенный подход. См.
предыдущее примечание).
Мы видим, что «Уведомления» и «Добавить» имеют больше всего входных данных (6).
Это говорит о том, что данные действия очень распространены, то есть они должны быть доступны всегда.
Похоже на правду, правда? Кроме того, через эти действия пролегают кратчайшие пути к достижению целей «Разгрузить голову», «Не пропустить сроки» и т. д. А это уже важно! Почему? Потому что, зная это, мы решили разместить счетчик уведомлений и кнопку добавления новых задач прямо на верхнюю панель, чтобы мы всегда могли их видеть.
Конечно, для опытного дизайнера это и так очевидно, но теперь у нас есть повод! С другой стороны: «Расписание», «Завершить», «Утвердить», «Делегировать», «Разделить», «Комментировать» имеют входные данные только из действий «Найти» и «Фильтр».
Что это значит, вы уже догадались? Пока не выбрана конкретная задача, эти действия не нужны (а вызывающие их элементы управления будут загромождать интерфейс и голову пользователя).
Поэтому лент в нашем приложении не будет. Кнопки действий появятся только после выбора задачи.
Строго говоря, этот метод не защищает от ошибок.
Например, в нашем графе элементарное действие «Найти задачу» имеет наибольший вес (12).
Исходя из этого, необходимо обязательно предусмотреть форму поиска в каждом представлении/экране приложения.
Казалось бы, что.
Однако это не так.
Опыт показывает, что люди не ищут задачи, а просматривают списки.
Если вы знаете, что искать, то вы явно помните задачу.
А если ты помнишь задание, то зачем его искать? Поэтому наши экраны должны содержать списки, а форму поиска можно спрятать за иконкой.
Конечно, поиск все равно нужен, если нужно искать по атрибутам (найти все задачи от Васи Пупкина со сроком выполнения в неделю, например).
Загвоздка в следующем: формулировка неточная.
Если заменить «Найти задачу» на «Выбрать задачу для выполнения», то все становится на свои места и в нашем приложении на первый план выходят списки.
Просто потому, что выбор подразумевает определенный набор, список.
Мы почти закончили.
Тогда есть простор для творчества.
Во-первых, вы можете сразу же легко разбить свое приложение на слои или представления.
Например, как я это сделал: 
Рис.
3 узла группировки Поскольку движение идет снизу вверх, получается, что главный экран будет своего рода дашбордом со списком задач и быстрым способом их фильтрации.
Далее вам понадобится возможность просмотреть подробную информацию о задаче и принять решение по ней (второй уровень) – это можно сделать, открыв всплывающее окно, открыв гармошку или показав детали на отдельной панели.
Эта панель должна содержать кнопки «Завершить» и других действий.
Вот как это получается из нашего графика! Счетчик уведомлений и кнопка добавления задач, как мы уже говорили, будут на каждом экране (дополнительный уровень).
Во-вторых, чтобы определить, что именно должен содержать каждый уровень/тип, необходимо разложить его на составляющие.
Давайте возьмем в качестве примера первый уровень и попробуем его декомпозировать.
Найти (выбрать) задачу можно:
- Просто взгляд из общего списка
- Применяя фильтры
- Поиск
- Заглядывая в историю
- Получение уведомления о новой задаче
- Календарь
- Через поле ввода
- Через шаблон
- Копирование другой работы
- Перетаскивание писем из почты
- Отправив электронное письмо на специальный адрес
- Через панель фильтров (создайте свой или примените существующий фильтр)
- Через контексты (важность, проект, срок, тег и т. д.)
В-третьих, с помощью графика очень легко выделить отдельные сценарии, оценить их приоритет и сгруппировать.
Вы можете экспериментировать! Если вы решили, что ваш инструментарий должен работать по методологии GTD, то вы можете построить график для таких сценариев, просто взглянув на рабочий процесс GTD: 
Рис.
4 Рабочий процесс GTD А затем на основе графика определить порядок и состав экранов.
Так причем здесь автоматизация, спросите вы? Автоматизация заключается в том, что мы получаем все скрипты на одном листе.
Мы получаем разбивку экрана, подходящую для всех сценариев.
И после разложения состав этих экранов.
Кроме того, программа отлично подходит для экспериментов со стилем «если, то…».
Собственно, для этого он и создан.
Например, если вы добавите, удалите или сгруппируете узлы, они чудесным образом перестроятся в новую структуру.
Это увлекательный и очень затягивающий процесс, когда вы завязываете узлы, спонтанно вставляете новые и придумываете их на ходу, без скучного планирования и совещаний.
Попробуйте и вы оцените экономию времени на написании и чтении скриптов.
Иметь картинку перед глазами дорогого стоит, поверьте.
Кроме того, метод позволяет отсекать ложные сценарии, ведущие, например, к цели организации, а вовсе не к цели пользователя.
Теория утверждает, что это совершенно разные цели.
Окей, Гугл.
Что дальше? Следующим шагом могла бы стать замена элементарных действий на графе кварками кнопок, контролов и элементов управления.
Таким образом, дизайнер получит элементы, из которых должен состоять экран, и сможет смоделировать их взаимодействие.
Вы можете попробовать оптимизировать экраны, проанализировав совпадения элементов управления в разных сценариях.
А можно пойти другим путем и присвоить связям веса, добавить условия выполнения элементарных действий, сложную логику и побочные эффекты.
Честно говоря, мы еще не зашли так далеко; эта неизведанная территория все еще ждет своих исследователей-Колумбов.
Поделитесь своим опытом и мы обязательно подружимся с вами.
А может, предложим деньги и интересную, интересную работу.
Особенно если вы считаете, что поддержка Word в Git гораздо важнее, чем проверка орфографии, а для прототипирования нужны SublimeText и Gulp (а не Axure или, помилуй Бог, Photoshop).
выводы В целом, вот и все.
Суть в том, что метод вполне рабочий и мы опробовали его в боевых условиях, на реальных, живых интерфейсах.
Его изложение было намеренно предельно упрощено – это облегчает понимание концепции.
Имейте в виду, что мы не использовали множество интересных функций FlyingLogic, таких как встроенная нечеткая логика, предварительное условие, ветвление, условные переходы, группировка, веса соединений, побочные эффекты, желательные и нежелательные эффекты и многое другое.
Они представляют большой практический интерес для дальнейшего развития этого подхода.
Основная сила проявляется, конечно, именно в сложных, запутанных сценариях, когда нужно иметь все перед глазами, разложенное по полочкам.
Когда важно не упустить ни одной мелочи: принцип «Чепуха, раковая опухоль очень маленькая…» не работает ни в медицине, ни в дизайне.
Например, вы можете оценить вероятность достижения целей актером, сравнить вклад разных сценариев в общий результат (а значит, и удовлетворенность пользователей) в зависимости от различных условий.
Играть с ползунками уверенности одно удовольствие, меняя значение в одном углу диаграммы, вы видите, как рассчитываются значения в зависимых узлах в противоположном углу.
На картинке ниже — список покупок Чака Норриса на День Благодарения в Wallmart. К нашей теме это не имеет никакого отношения, за исключением того, что именно так выглядят списки, с которыми работают аналитики и разработчики в Docsvision. Больно – это наша профессия, мы просто знаем, что упорство от упрямства отличает только одно – наличие успеха в конце концов.
Рис.
5 Список покупок Чака Норриса Надеюсь, этот пост мотивирует вас не бояться экспериментировать и придумывать новые интерфейсы для SD, ERP-систем, мобильных банков и других SAP. На всякий случай еще раз вставлю ссылки на ЛетающаяЛогика и пару видео: « Итак, вы думаете, что умеете думать? " И " Модели принятия решений с летающей логикой для таких людей, как я, которые любят эффективные сокращения и всегда читают с конца.
Ах да, чуть не забыл.
Убийца графа — дворецкий! Теги: #интерфейсы #навигация #flyinglogic
-
«Ксенофобия В Японии — Обычное Дело»
19 Oct, 24 -
Снимаем «Матрицу» Дома На 15 Камер Gopro.
19 Oct, 24
