Интерфейс — это вся видимая пользователю часть сервиса, с которой он взаимодействует, решая свои задачи.
Проектирование интерфейсов — это всегда поиск наиболее эффективного решения, которое основано на понимании задач, мотиваций и обстоятельств пользователей и в то же время учитывает цели, возможности и ограничения со стороны бизнеса и технологий.
Результатом проектирования являются макеты и сопроводительные материалы, которые можно передать команде разработки.
- Глубинное исследование всего, что окружает продукт
- Решение, которое учитывает интересы бизнеса и клиента
- Финальный дизайн и поддержка внедрения на этапе разработки
Создать сервис с нуля
Создать принципиально новый интерфейс существующего сервиса
Добавить в сервис новые функции и возможности для пользователя
Исправить локальные проблемы и интерфейсные ошибки
Детально изучаем сам сервис и все, что его окружает: поведение пользователей и сценарии их взаимодействия с сервисом, прямых и косвенных конкурентов, возможные риски и ограничения, релевантные технологии и тренды индустрии.
Моделирование и анализ бизнес-процессов как инструмент выявления требований к отчетности
Источники информации: бриф заказчика, конкурентный анализ, интервью с экспертами в предметной области, кабинетное и полевое обследование, юзабилити-тесты и эксперименты.
Моделируем
Разделяем модели пользователей, описываем их различия в целях, ожиданиях и контекстах использования сервиса.
Формулируем требования к каждому разделу сервиса: на какие вопросы пользователи должны получить ответы, необходимые функции, технологические и бизнес-требования.
Синтезируем
Строим Customer Journey Map: схематично визуализируем логику взаимодействия пользователей с сервисом при решении разных задач.
Описываем User Stories: детализируем в текстовом формате, как пользователь закрывает свои потребности через интерфейс сервиса, и как интерфейс реагирует на действия пользователя.
Детализируем
На основе зафиксированных ожиданий и адаптированных визуальных паттернов из брендбука компании разрабатываем визуальную концепцию сервиса — несколько ключевых экранов, иллюстрирующих, как будет выглядеть интерфейс продукта, и объяснение заложенных в концепцию принципов.
Итеративно детализируем пользовательские сценарии и презентуем заказчику. Собираем обратную связь и вносим корректировки.
Систематизируем дизайн-макеты, используя библиотеки стилей и компонентов — это помогает ускорить дизайн-процесс и упростить разработку продукта.
Источник: www.markswebb.ru
Роль бизнес-процессов в проектировании интерфейсов
Проектирование интерфейсов в создании программного обеспечения для организаций, довольно интересная деятельность, сталкиваешься с разными задачами. Но, с чего необходимо начинать для того, чтобы разработать качественный интерфейс программного продукта? С разговора с заказчиком? Да, но полную информацию при общении с руководителем организации не всегда удается получить.
Дизайнер бизнес-процессов
Проектирование интерфейсов в программных продуктах, которые разрабатываются для автоматизации бизнеса, необходимо начинать с анализа деятельности, а еще глубже с анализа бизнес-процессов и только точное понимание бизнес-процесса дает возможность видеть цели, которые должен выполнять программный продукт. Понимание целей приводит к ясному и логическому проектированию интерфейса.
Для автоматизации бизнеса необходимо иметь его описание, описанием бизнеса занимаются не автоматизаторы, программисты или проектировщики, описанием бизнес-процессов занимаются бизнес аналитики и менеджеры, автоматизировать можно только ту деятельность, которая прошла логических контроль с их стороны. Внедрение компьютерных технологий поверх неверно организованных бизнес-процессов только вредит, если автоматизировать «бардак» в результате получится «автоматизированный бардак».
А каким же образом бизнес-процессы связаны с интерфейсами? Интерфейс является механизмом взаимодействия пользователя с программным продуктом, что бы интерфейс отобразить на экране, необходимо провести предпроектный анализ, который выделит суть и цели программного продукта, исходя из целей и бизнес-процессов полученных в предпроектном анализе, можно проектировать интерфейс.
Итак, при разработке проекта получается следующая цепочка:
Для раскрытия темы давайте, рассмотрим одну из ее частей – анализ и исследование, именно в этой части разработки программного продукта необходимо выяснить, для чего данный продукт нужен.
Автоматизация бизнес-процессов подразумевает под собой разработку ПО по уже описанным бизнес-процессам, но как поступить, если бизнес-процессы в организации не описаны, в данном случае не следует догадываться, каким образом работает компания и заниматься самодеятельностью не подготовившись должным образом, иначе это влетит в затягивание сроков разработки, не установленным расходам и выяснением отношений с заказчиком.
Поступить можно двумя путями, если объем бизнес-процессов довольно сложен, организация крупный заказчик, есть смысл обратится к сторонней организации за помощью в описании бизнес-процессов. Они опишут структуру организации, бизнес-процессы, сделают их коррекцию, создадут пакет должностных инструкций для сотрудников компании, а также видение и стратегию организации на будущее.
После необходимо понять какая деятельность будет автоматизироваться? Чтобы ответить на этот вопрос нужно понять, что именно не устраивает в текущей работе организации. Такими параметрами могут стать: время выполнения процесса, стоимость выполнения процесса, качество (количество ошибок и сбоев). Выделенные бизнес-процессы необходимо детально описать, сделав акцент на информации (используемые документы, отчеты), которая необходима для осуществления какого-либо действия процесса или является результатом его выполнения.
Если система бизнес-процессов не так сложна или вы автоматизируете один из процессов, его можно описать самостоятельно.
Каким образом это можно сделать? Изначально проводится опрос участников процесса и делаются заметки на бумаге. Необходимо выяснить всех участников процесса, исполнителей, передаваемую информацию, входы и выходы процесса и ответственных. Если процессов много, рекомендуется использовать специальное ПО для бизнес-моделирования, это существенно облегчит хранение процессов и вычисление пересечения данных между собой, позволит проводить анализ результатов бизнес-процессов. Примером данных систем являются: Business Studio, Aris, AllFusion Process Modeler, ELMA.
Если бизнес-процесс не является сложным, можно обойтись просто графическим отображением, для этого можно использовать специализированное программное обеспечение, такое как: BizAgi Process Modeler, Bonita Open Solution, ActiveBPEL Engine и др. или же графические редактор для создания блок-схем: Microsoft Visio, OpenOffice.org Draw, yEd Graph Editor. Какой бы инструмент не использовался главное это достижение цели в данном случае описанный бизнес-процесс.
При создании графической блок-схемы для себя, можно разрабатывать ее в свободной форме, главное что-бы процесс был понятен самому себе, но если со схемой работает не один человек и схем много, иногда складывается необходимость в использовании целой методологии.
Методологии описания бизнес-процессов появились уже давно, и если вы преследуете цель полноценного описания бизнес-процессов в организации, можно обратиться к одной из них.
Я перечислю основные методологии, которые используются сейчас: ARIS, DFD, IDEF0, IDEF3, BPMN, EPC, FlowChart, и др. Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели. Для каждого объекта и связей характерны ряд параметров, или атрибутов, отражающих определённые характеристики реального объекта (номер объекта, название, описание, длительность выполнения (для функций), стоимость и др.).
Для описания сложных бизнес-процессов с различными уровнями вложенности рекомендуется использовать несколько нотаций: нотацию IDEF0 целесообразно использовать для описания процессов верхнего уровня (она отображает структуру и функции системы, использует потоки информации и материальные объекты), а нотации FlowChart, EPC для моделирования процедур нижнего операционного уровня.
Пример использования нотации IDEF0:
Пример использования нотации EPC:
Пример использования нотации Cross Functional Flowchart:
Какие бы методологии в описании вы не использовали главное добиться полного понимания бизнес-процесса, таким образом, вы перейдете к следующему этапу — формированию требований к программному продукту и выявлению задач выполняемых с помощью ПО.
Дальнейший процесс проектирования будет складываться из создания черновых интерфейсов и прототипов ПО, основываясь на данных полученных из бизнес-процесса. Разработка черновых прототипов программы позволит лучше увидеть функциональность проектируемого интерфейса.
Понимание целей и задач разрабатываемого ПО является начальным этапом работы для проектировщика интерфейсов, а описание бизнес-процессов послужит хорошим инструментом для достижения положительных результатов в проектировании.
Список целей и задач, а также подключение маркетологов к разработке интерфейса расставят приоритеты между элементами информации предлагаемой пользователю, упростят работу с ПО, и повысят эффективность конечной эргономики программного продукта.
- интерфейсы
- проектирование интерфейсов
- бизнес-процессы
Источник: habr.com
«Интерфейсная революция» в ECM-системах
