Проектирование вычислительных систем охватывает широкий спектр проектных действий — от проектирования аппаратных средств до проектирования интерфейса пользователя. Организации-разработчики часто нанимают специалистов для проектирования аппаратных средств и очень редко для проектирования интерфейсов. Виды интерфейсов: текстовый и графический. Графические интерфейсы обладают рядом преимуществ: − Их относительно просто изучить и использовать. Пользователи, не имеющие опыта работы с компьютером, могут легко и быстро научиться работать с графическим интерфейсом. 75
− Каждая программа выполняется в своем окне (экране). Можно переключаться из одной программы в другую, не теряя при этом данные, полученные в ходе выполнения программ. − Режим полноэкранного отображения окон дает возможность прямого доступа к любому месту экрана. На схеме изображен итерационный процесс проектирования пользовательского интерфейса. Наиболее эффективным подходом к проектированию интерфейса пользователя является разработка с применением моделирования пользовательских функций. Рисунок 51 – Процесс проектирования интерфейса пользователя Таблица 5 — Принципы проектирования интерфейсов
Лекция 5. Проектирование пользовательских интерфейсов
| Принцип | Описание | |||||
| Учёт знаний пользователя | Необходимо | использовать | термины и | |||
| понятия, взятые из опыта будущих | ||||||
| пользователей | системы, | а | объекты, | |||
| управляемые системой, должны быть | ||||||
| напрямую связаны с рабочей средой | ||||||
| пользователя. | ||||||
| Согласованность | Команды | и | меню | системы | должны быть | |
| одного | формата, | параметры | должны | |||
| передаваться во все команды одинаково и | |||||||||
| пунктуация команд должна быть схожей. | |||||||||
| Удобно, когда для всех типов объектов | |||||||||
| системы | поддерживаются | одинаковые | |||||||
| методы. | |||||||||
| Минимум | Одно и тоже действие в различных | ||||||||
| неожиданностей | ситуациях должно приводить к аналогичной | ||||||||
| реакции. | |||||||||
| Способность | к | В интерфейсах должны быть средства | |||||||
| восстановлению | предотвращающие ошибки пользователя, а | ||||||||
| также позволяющие корректно восстановить | |||||||||
| информацию | после | ошибок. | Это | ||||||
| подтверждение | деструктивных | действий и | |||||||
| возможность отмены действий. | |||||||||
| Руководство пользователя | Интерфейс | должен | предоставлять | ||||||
| необходимую информацию в случае ошибок | |||||||||
| пользователя | и | поддержать | средства | ||||||
| контекстно-зависимой справки. | |||||||||
| Учёт | разнородности | В интерфейсе должны быть средства для | |||||||
| пользователей | удобного взаимодействия с пользователями, | ||||||||
| имеющими разный уровень квалификации и | |||||||||
| различные возможности. | |||||||||
Разработчиками интерфейсов предусмотрены 5 основных стилей взаимодействия пользователя с системой. Таблица 6 – Стили взаимодействия с пользователем 1. Непосредственное манипулирование
2. Выбор из меню 3. Заполнение форм 4. Командный язык 5. Естественный язык Таблица 7 — Преимущества и недостатки стилей взаимодействия
| Стиль взаимодействия | Основные | Основные | Примеры приложений | ||||
| преимущества | недостатки | ||||||
| Прямое | Быстрое | и | Сложная | Видеоигры; | системы | ||
| манипулирование | интуитивно | реализация. | автоматического | ||||
| понятное | Подходит | проектирования | |||||
| взаимодействиеЛе | только там, | где | |||||
| гок в изучении | есть | ||||||
| зрительный | |||||||
| образ | задач | и | |||||
| объекта | |||||||
| Выбор из меню | Сокращение | Медленный | Главным | образом | |||
| количества | вариант | для | системы | общего | |||
| ошибок | опытных | назначения | |||||
| пользователя. | пользователей. | ||||||
| Может | быть | ||||||
| сложным, | если | ||||||
| меню | состоит | ||||||
| из | большого | ||||||
| количества | |||||||
| вложенных | |||||||
| пунктов | |||||||
| Заполнение форм | Ввод | с | Занимает | Системы | управления | ||
| клавиатуры | пространство | запасами; | обработка | ||||
| минимальный | на экране | финансовой информации | ||||
| Командный язык | Простой | ввод | Труден | в | Операционные | |
| данных. | изучении. | системы; | библиотечные | |||
| системы | ||||||
| Естественный язык | Легок | в | Сложно | Системы | расписания; | |
| изучении, | предотвратить | системы | хранения | |||
| мощный и гибкий. | ошибки ввода | данных WWW | ||||
| Подходит | Требует | |||||
| неопытным | большого | |||||
| пользователям. | ручного набора | |||||
| Легок | в | |||||
| настройке | ||||||
Модель с разделенными интерфейсом командного языка и графическим интерфейсом лежит в основе некоторых операционных систем, в частности Linux. Рисунок 52 — Модель с разделенными интерфейсом
С помощью визуальных средств информацию можно представлять графически, например в виде графиков и диаграмм
| Представлен | ПО для |
| ие данных | представления |
| данных |
| 70 | |||||||
| 60 | |||||||
| 50 | |||||||
| 40 | Доход | ||||||
| 30 | |||||||
| 20 | |||||||
| 10 | |||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| кв | кв | кв | кв | кв | кв | кв | кв |
1 кв 
2 кв 
3 кв 
4 кв
Дисплей Рисунок 53 – Модель представления информации Принимая решение по представлению данных, разработчик должен учитывать ряд факторов: − Что нужно пользователю: точные значения данных или соотношения между значениями? − Насколько быстро будут происходить изменения значений данных? Нужно ли немедленно показывать пользователю изменение значений? − Должен ли пользователь предпринимать какие-либо действия в ответ на изменение данных? − Нужно ли пользователю взаимодействовать с отображаемой информацией посредством интерфейса с прямым манипулированием?
− Информация должна отображаться в текстовом (описательно) или числовом формате? Важны ли относительные значения элементов данных? Альтернативы Часто визуальное представление информации нагляднее, чем табличный аналог
| Янв | Фев | МартАпр | Май | Июль |
| 2842 | 2851 | 3164 2789 | 1273 | 2835 |
| 3500 | ||||
| 3000 | ||||
| 2500 | ||||
| 2000 | ||||
| 1500 | Продажи | |||
| 1000 | ||||
| 500 | ||||
| Фев | Март | Апр | Май Июнь | |
| Янв |
Использование в интерфейсах цвета: − Используйте ограниченное количество цветов − Используйте разные цвета для показа изменений в состоянии системы − Для помощи пользователю используйте цветовое кодирование − Используйте цветовое кодирование продуманно и последовательно − Осторожно используйте дополняющие цвета
Рисунок 54 — Пример неправильного использования цветов Средства поддержки пользователя Одним из основных аспектов проектирования пользователя является справочная система . Справочную систему приложения составляют: − сообщения, генерируемые системой в ответ на действия пользователя; − диалоговая справочная система; − документация, поставляемая с системой. Таблица 8 — Факторы проектирования текстовых сообщений
| Фактор | Описание |
| Справочная система должна знать, что делает | |
| пользователь, и реагировать на его действия | |
| сообщениями соответствующего содержания |
82
| Профессиональ- | Сообщения должны содержать сведения, | ||||
| ный | уровень | соответствующие профессиональному уровню | |||
| пользователя | пользователей. | ||||
| Опыт пользователя | Если пользователи хорошо знакомы с системой, | ||||
| им не нужны длинные и подробные сообщения. В | |||||
| то же время начинающим пользователям такие | |||||
| сообщения покажутся сложными, мало понятными | |||||
| и слишком краткими. | |||||
| Фактор | Описание | ||||
| Сообщения должны иметь положительный, а не | |||||
| отрицательный | оттенок. | Всегда | следует | ||
| Стиль сообщений | использовать активный, а не пассивный тон | ||||
| обращения. Не должно быть оскорблений или | |||||
| попыток пошутить | |||||
| Разработчик сообщений должен быть знаком с | |||||
| Культура | культурой той | страны, где | продается | система. | |
| Сообщение, вполне уместное в культуре одной | |||||
| страны, может оказаться неприемлемым в другой | |||||
| Таблица 9 — Факторы проектирования текстовых сообщений | |||||
| Фактор | Описание | ||||
| Справочная система должна знать, что делает | |||||
| пользователь, и реагировать на его действия | |||||
| сообщениями соответствующего содержания | |||||
| Профессиональный | Сообщения должны содержать сведения, | ||||
| уровень пользователя | соответствующие профессиональному уровню | ||||
| пользователей. | |||||
| Опыт пользователя | Если пользователи хорошо знакомы с системой, им | ||||
| не нужны длинные и подробные сообщения. В то | |||||
| же время начинающим пользователям такие | |
| сообщения покажутся сложными, мало понятными | |
| и слишком краткими. | |
| Фактор | Описание |
| Сообщения должны иметь положительный, а не | |
| отрицательный оттенок. Всегда следует | |
| Стиль сообщений | использовать активный, а не пассивный тон |
| обращения. Не должно быть оскорблений или | |
| попыток пошутить | |
| Разработчик сообщений должен быть знаком с | |
| Культура | культурой той страны, где продается система. |
| Сообщение, вполне уместное в культуре одной | |
| страны, может оказаться неприемлемым в другой |
Первое впечатление пользователя о системе основано на сообщениях об ошибках , они должны: − Быть последовательными и конструктивными − Быть вежливыми, краткими, не содержать оскорблений. − Не содержать звуковых сигналов, которые могут сбить с толку посетителей. Желательно: − Связать сообщение с контекстно-зависимой справкой. − Включить в сообщение варианты исправления ошибки.
| Это сообщение скорректировано | Это сообщение лучше: | |
| плохо: | − | Оно доброжелательно |
| − Оно обвиняет пользователя в | − | В нем используются |
| совершении ошибки. | медицинские термины. | |
| − Не рассчитано на уровень | − | Предполагается простой способ |
| знаний пользователя. | исправления ошибки | |
− Не предполагаются способы исправления ошибки. В связи с тем, что справочная система имеет иерархическую структуру, где на верхних уровнях иерархии содержится более полная информация, а на нижних – более подробная, может возникнуть следующая ситуация: пользователь заходит в систему получив сообщение об ошибке и затем перемещается в системе по ссылкам. Через некоторое время он запутывается и ему необходимо начинать все сначала. Чтобы таких ситуаций не возникало информацию удобно отображать в нескольких окнах. 85
Рисунок 55 — Пример справочной системы Тексты справочной системы должны быть: − Написаны совместно с создателями приложения. − Продуманы так, чтобы его можно было прочитать в окне малого размера(только необходимая информация). − Адаптированы к неопытному пользователю. Документация пользователя должна содержать 5 документов: − Функциональное описание , в котором кратко представлены функциональные возможности системы. Прочитав функциональное описание, пользователь должен определить, та ли это система, которая ему нужна. − Документ по инсталляции системы , в котором содержится информация по установке системы. 86
− Вводное руководство , представляющее неформальное введение в систему, описывающее ее «повседневное» использование. − Справочное руководство , в котором описаны возможности системы и их использование, представлен список сообщений об ошибках и возможные причины их появления, рассмотрены способы восстановления системы после выявления ошибок. − Руководство администратора , необходимое для некоторых типов программных систем. В нем дано описание сообщений, генерируемых системой при взаимодействии с другими системами, и описаны способы реагирования на эти сообщения. Рисунок 56 — Документация пользователя Вместе с перечисленными руководствами необходимо предоставлять другую удобную в работе документацию. Для опытных пользователей системы удобны разного вида предметные указатели, которые помогают быстро просмотреть список возможностей системы и способы их использования. Оценивание интерфейса
Это часть общего процесса тестирования и аттестации систем ПО, в котором оценивается удобство использования и степень соответствия интерфейса требованиям пользователя. Таблица 10 — Показатели удобства использования.
| ПОКАЗАТЕЛЬ | ОПИСАНИЕ |
| Количество времени обучения, необходимое для | |
| Изучаемость | |
| начала продуктивной работы. | |
| Скорость реакции системы на действия пользователя. | |
| Скорость работы | |
| Устойчивость системы к ошибкам пользователя. | |
| Устойчивость | |
| Способность системы восстанавливаться после | |
| Восстанавливаемость | |
| ошибок пользователя. | |
| Способность системы “подстраиваться” к разным | |
| Адаптируемость | |
| стилям работы пользователя. |
Существуют простые и не дорогостоящие методики оценивания, позволяющие выявить отдельные дефекты в интерфейсах. − Анкеты, в которых пользователи оценивают интерфейс. Эти сведения дают возможность разработчикам зафиксировать, пользователи с каким уровнем знаний имеют проблемы с интерфейсом. − Наблюдения за работой пользователей. Позволяют
| отслеживать, какие используются сервисы, | совершаемые |
ошибки, как пользователи взаимодействуют с системой. − Видеонаблюдения типичного использования системы. Может оказаться полезным для обнаружения проблем, но для уточнения используются другие методы оценивания.
Источник: studfile.net
Проектирование интерфейсов без купюр
Проектирование интерфейсов как оно есть. Процесс, особенности и нюансы.
Уже больше года я работаю в команде Tele2, где занимаюсь интерфейсами. У меня есть свой продукт, программа лояльности “Больше”: web версия и теперь уже отдельный блок в приложении Мой Tele2. Основная работа связана с интеграциями и разработкой различного функционала: от системы управления контента (CMS, читай административная панель), до эксклюзивных партнерств и механик.
Довольно часто появляются задачи, связанные с проектированием интерфейса, с тем, что именно увидит пользователь и с чем потом будет взаимодействовать, решая свои задачи. Вот, решили поиск запустить, как он должен выглядеть и работать? А вот, фильтры обновить надо, почему?
Сегодня хочу поговорить о самой сути проектирования и поделиться опытом того, как это работает у нас.
Проектирование интерфейсов: это основа
Давайте представим себе скелет рыбы. Они все разные, ну пусть будет такой.
Скелет и кости устроены таким образом, чтобы держать мышцы рыб и обеспечивать движение плавников. Распределение нагрузки на костяной каркас рыбы позволяет ей плавать, как ни в чем не бывало, кушать водоросли и наслаждаться жизнью. За нее уже все продумала и спроектировала сама природа так, чтобы ее вид мог выживать и развиваться.
С проектированием веб интерфейсов дела обстоят немного сложнее, так как за нас никто не поработает и только нам решать конкретные задачи пользователей. Ключевое слово здесь “задачи”, так как именно они лежат в основе здорового проектирования. Попробую сформулировать, что такое проектирование интерфейсов в двух словах.
Проектирование интерфейсов – это процесс решения конкретных задач пользователя через взаимодействие с цифровыми продуктами с учетом возможностей, требований и ограничений (бизнеса, технологии).
Кто занимается проектированием
Есть соблазн сказать, что вот же, есть ux/ui дизайнеры, обратился к ним за помощью, а потом получай результат. Но тут не так все просто. Ключ в информации и понимании полного контекста задач. Ты, как продакт, видишь (должен видеть) всю картину в целом, от задач пользователей до бизнес требований, от ближайших фич до стратегии развития всего продукта. Чем плотнее ты работаешь с дизайнером, тем более полным будет решение при проектировании.
В крупных компаниях, где разные продукты тесно связаны друг с другом, необходимо учитывать полную картину взаимодействия. Для этих целей используются общие встречи по проектированию (у нас в Tele2 они называются дизайн-сессиями). На таких встречах присутствует вся команда: отряд продактов по разным направлениям и дизайнеры.
Продакт вместе с дизайнером готовит варианты решения задач и презентует их всей команде. На таких встречах можно собрать полезные комментарии от коллег и скорректировать свое решение. Зачастую ты просто можешь пропустить что-то важное (технические ограничения, элементы фирменного стиля, аналитика, необходимость доп.интеграции и прочее). Дизайн-сессия позволяет закрывать большую часть вопросов до выхода интерфейса в продуктив (когда уже увидят реальные пользователи) и является неотъемлемой частью проектирования.
Откуда начинается проектирование
Как вы могли уже догадаться, начинается оно с задач, которые должен решать интерфейс. На практике вытащить их из заказчиков не так то и просто.
Во-первых задач может быть несколько. То есть, один думает, что мы решаем эту задачу, другой думает про другую. Как тут быть? Приоритезировать задачи с учетом ценности, которую они принесут твоему продукту.
Во-вторых они могут быть неясно сформулированы. “Хотим, чтобы фильтры в каталоге были более понятные” или “Сделайте корзину более заметной”. Что с этим делать? Помогать заказчикам переформулировать задачи. Конкретизировать их до конкретных ценностей, а лучше метрик:
“Хотим, чтобы фильтры в каталоге были более понятные” – “Хотим увеличить CTR фильтров ”
“Сделайте корзину более заметной” – “Необходимо увеличить кол-во заказов с корзины”
Для фильтрации задач используйте бриф с основными вопросами, которые помогут заказчику сформулировать задачу более четко и понятно. Здесь вам и контекст, и смысл, и ожидания. Про бриф я рассказывал более подробно здесь и даже предложил свой пример, который можно брать в работу.
Задачи вытащили, идем дальше
Благо теперь у вас есть задача, а это, скажу я вам, уже 50% успеха (правда, просто поверьте). Переходим непосредственно к проектированию. Относительно недавно на работе с товарищем завязалась беседа, по-поводу того, как ставить задачи дизайнерам и оказалось, что существует принципиально два разных подхода:
- Ставятся задачи, которые должен решить интерфейс. Дизайнер предлагает решения. После идет обсуждение и развитие этих решений вместе с продактом.
- Сразу предлагаются решения в виде мокапов, набросков от продакта. Далее вместе с дизайнером предлагается их развитие.
Каждый подход по-своему хорош, но и не лишен недостатков.
Первый (решение дизайнера) дает в полной мере свободу творчества. Продакт менеджер не вовлекается в подбор решений, а работает с тем, что ему предложили. Классно, что можешь довериться дизайнеру и посмотреть его варианты. Не классно, что твои ожидания могут не оправдаться и придется потратить немало времени на обновление решения.
Второй подход (решение продакта) подразумевает, что сам продакт ищет решение, смотрит примеры интерфейсов на рынке и проектирует до уровня набросков, а дальше уже вместе с дизайнером занимается развитием. Классно, что твои ожидания уже сформированы и есть на что опираться для развития. Не классно, что своим решением ты можешь сразу ограничить дизайнера и не увидеть альтернатив.
Оба подхода имеют право на существование. У нас в команде, например, я топлю за второй подход, а мой коллега за первый, поэтому наши дизайн-сессии становятся еще ценнее из-за разных точек зрения.
Не забудь про сценарии
Проектирование интерефейсов, это про взаимодействие. Ты думаешь о том, как пользователь будет взаимодействовать с твоим продуктом и решать определенные задачи.
У тебя есть решение, но какие контекстные сценарии оно затрагивает? В каких ситуациях человек, например, возьмет телефон в руки, зайдет в приложение и начнет наполнять корзину товарами? Держать всю цепочку шагов в голове проблематично, да и не нужно, просто нарисуйте процесс.
Сфокусируйтесь на основном сценарии, в котором будет использоваться ваше решение. Подумайте, какие барьеры и на каких этапах могут возникать. Порой достаточно ограничиться только средой вашего продукта для того, чтобы набросать взаимодействия с конкретным решением.
Например для задачи с корзиной: пользователь просматривает каталог товаров и может накидать себе в корзину разных товаров.
Ориентируясь на сценарии пользователя, сделайте апгрейт своего решения, если необходимо. После этого презентуйте финальный вариант команде на дизайн-сессии.
Если вам жалко кота Тома в мультфильме “Том и Джери” и вы хотите знать, когда появятся материалы в блоге, то подписывайтесь на наш telegram канал! Кстати, в канале есть материалы, которые не выходят на сайте, так что заглянуть точно стоит Продолжаем читать…
Проверка решения
Наше решение прошло ревью всей команды, учтены комментарии и готовы эскизы, осталось только в спринт положить и вот оно! Не спешите тратить ресурс разработки. Кто как не пользователь скажет будет ли работать то, что вы предложите или нет.
Проектирование интерфейсов без пользовательского фидбека невозможно. Проверьте свое решение с помощью прототипов, mvp, опросов и прочего.
Чтобы не разрабатывать то, что никому не нужно, как можно раньше покажите пользователям решение и соберите данные о том, нужно ли оно вообще. Так вы обезопасите себя от потерь ресурсов и волос на голове, когда “пилили, пилили, а оно не нужно”. Про проверку гипотез и решений рекомендую почитать в этом материале.
Пользователь проголосовал, значит делаем
Провели эксперименты, проверили гипотезы и пользовательские метрики показывают, что решение себя оправдало. Значит берем в работу. Добиваем финальный дизайн, кладем в спринт и выкатываем на прод всем пользователям.
Теперь и пользователь счастлив и вы, потому что метрики, на которые вы закладывались с решением, растут. У фильтров повысился CTR, а через корзину кол-во заказов увеличилось на 10%. Проектирование интерфейсов выполнено на славу.
Принципы хорошего интерфейса
На последок хочу поделиться с вами основными, на мой взгляд, принципами хорошего интерфейса.
- Ясность и понятность. Пользователю не нужна инструкция, чтобы решить свою задачу через интерфейс.
- Ничего лишнего, только необходимые для решения задачи элементы интерфейса.
- Фокусировка. Есть основные элементы интерфейса, есть дополнительные, расставьте четкие визуальные акценты для решения задачи пользователя.
- Привычки против моды. Отдавайте предпочтение уже знакомым пользователю элементам интерфейса, нежели создавайте “шедевры”, которыми не будут пользоваться.
- Группировка. Объединяйте информацию в смысловые блоки, ну заставляйте пользователя вчитываться в каждую букву, чтобы понять суть.
- Единообразие. Если в одном разделе сайта кнопки выглядят определенным образом, то и в других частях, они должны выглядеть также.
- Эволюция. Интерфейсы не стоят на месте, они должны развиваться, иначе пользователь быстро потеряет к ним интерес. Следите за трендами и старайтесь идти в ногу со временем.
Используйте эти принципы как чек-лист при проектировании, спрашивайте себя, а правда ли это решение понятно пользователю? Или, не забыл ли я расставить акценты на важных элементах?
Итоги
Проектирование интерфейсов, это очень интересный процесс. Тебе приходится решать ряд задач и учитывать кучу ограничений, но вы только представьте себе какой кайф ты испытываешь, когда видишь, что твоими решениям пользуются люди. Проектируйте с чувством, проектируйте с удовольствием и делайте счастливыми своих пользователей.
- Как проводить исследование пользователей
- Бэклог продукта
Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.
Ахахаххаха, просто божественный ролик про фанатов футбола, которые пропускают ключевые моменты матча во время разных ситуаций. Эта игра актеров и сама идея просто великолепны, браво Heineken, браво режиссеры!
Источник: www.alexcouncil.com
Прорисовка интерфейсов или как можно использовать UX/UI при проектировании в 1С
Любой аналитик или разработчик, работающий с 1С, сталкивался так или иначе с таким сказочным персонажем, как разработка интерфейсов 1С. Систему прототипирования в 1С можно сравнить с популярным мемом из кинофильма «ДМБ»:
-Вот и я не вижу. А он есть.
Так и с прорисовкой интерфейса в 1С, она тоже есть, но на нее никто не обращает внимание.
Разработчики обычно «рисуют» напрямую в конфигураторе или 1C:EDT. А что насчет бизнес-аналитиков, консультантов и руководителей проектов? Какие инструменты чаще всего используются для того, чтобы показать заказчику наглядный вариант будущей системы (формы документов, справочников и рабочих мест), и какие инструменты можно использовать для оптимизации процесса прототипирования мы рассмотрим в данной статье.
Что такое дизайн интерфейса?
Начать хотелось бы с основ, а именно с того, что такое дизайн интерфейса. Как ни крути, но разработка интерфейсов 1С непосредственно относится к дизайну и прототипированию систем. Пора перейти от стадии «депрессии» к стадии «принятия» и начать использовать практики из других областей разработки.
Итак, дизайн интерфейса – это процесс создания внешнего вида сайтов, приложений, компьютерных программ так, чтобы они были удобны и интуитивно понятны.
В рамках данной статьи – это процесс рисования или прототипирования форм будущих объектов в 1С (примечание: прототипирование, прорисовка интерфейса, разработка интерфейса, создание макета – это синонимы).
Во всем ИТ мире дизайн интерфейсов имеет две специализации: UI и UX-дизайн.
- User Experience (UX) – пользовательский опыт. Цель UX-дизайнера — сделать так, чтобы пользователь быстро и легко получил от программы то, зачем он её использует;
- User Interface (UI) – пользовательский интерфейс. Цель UI-дизайнера — создать эстетичный дизайн интерфейса продукта.
В среде 1С никакой подобной закрепленной специализации разработки интерфейса нет, технологии UX/UI используются аналитиками крайне редко. Это является проблемой, так как возможности для прототипирования интерфейса есть, и они могут сделать работу аналитика и пользователя удобнее и быстрее. Вопрос: как? Ответ очевиден: понятный интерфейс делает процесс согласования новых форм объекта быстрее. Пользователь принимает непосредственное участие в проектировании, снижает уровень недопонимания, уменьшается вероятность переделок и не нужно тратить много времени на обучение.
Типичные требования к качественному UX/UI-дизайну:
- Ясность – понятный интерфейс без двусмысленностей;
- Лаконичность – интерфейс не перегружен составными элементами;
- Узнаваемость – элементы дизайна легко распознать, даже если пользователь видит ваш макет впервые;
- Отзывчивость – хороший интерфейс реагирует на действия пользователя мгновенно. Он должен понимать, что происходит на экране прямо сейчас;
- Постоянство – соблюдение постоянства для всего документа или макета;
- Эстетика – интерфейс должен быть визуально привлекательным, чтобы пользователю было приятно работать;
- Эффективность – качественный интерфейс экономит время пользователя и доставляет его в нужную точку с минимальными усилиями;
Снисходительность –даже при самом продуманном интерфейсе ни один пользователь не застрахован от ошибки, не стоит забывать об этом.
Этап создания макетов интерфейсов давно используется в других областях разработки. Например, в web, где есть полноценная методология ведения проектов и соответствующий инструментарий.
Методология основывается на предоставлении пользователю возможности взаимодействовать с прототипом еще до начала разработки первой версии. На этом этапе можно выявить до 80% всех неудобных мест будущего решения. На этом этапе пользователь может сам лично пощупать интерфейс, что неминуемо ускоряет сдачу результата заказчику.
Классический ситуация, когда заказчик, консультант и разработчик говорят на разных языках, и в итоге получается результат, которым все недовольны.
Сейчас большинство проектов ведется в удаленном формате и согласовывать требования становится сложнее, поэтому нужно двигаться в направлении развития прототипирования при разработке интерфейсов в 1С и вовлекать заказчика в разработку.
Как сейчас рисуется интерфейс на проектах?
За свой опыт я не видел, чтобы кто-то из аналитиков или консультантов использовал для рисования прототипов, макетов, версий документов какой-то специальный софт. Обычно это делается в «Пейнт» путем составления аппликаций из различных скриншотов.
Занятие веселое ровно в первые 5 минут и ровно до первой демонстрации заказчику, после чего нужно все переделать, сделать новые скриншоты и составить новый макет. Такое творчество не для слабонервных. Некоторые из нас используют для этих целей Excel, либо обычное рисование от руки на клочках бумаги. В 21 веке, Карл!
Можно, конечно же, последовать примеру разработчиков и напрямую рисовать прототипы в конфигураторе, но:
- это не сделаешь быстро, и сам заказчик уже не сможет протестировать макет;
- потребуется установка, лицензии 1С и хорошие ресурсы компьютера.
Нужен специальный инструмент для бизнес-аналитика, консультанта или руководителя проектов. Ведь, как правило, именно этими людьми происходит обсуждение и согласование целей, задач и ожидаемых результатов проекта вместе с заказчиком.
Сама фирма 1С не предоставляет стандартов использования инструментов формализации бизнес-процессов и уж тем более правил рисования макетов и прототипов.
Подпишитесь на дайджест!
Подпишитесь на дайджест, и получайте ежемесячно подборку полезных статей.
Как это должно и может работать. Обзор инструментов проектирования.
Опыт показывает, что для комфортной и качественной разработки интерфейсов на базе 1С не хватает:
- Инструмента, в котором необходимый вариант будущей формы можно сделать быстро и вместе с заказчиком;
- Регламентации по созданию интерфейсных форм с учётом особенностей платформы 1С;
- Соответствующих учебных материалов.
Ниже представлены сервисы, которые можно использовать для прототипирования интерфейсов на базе 1С.
1С-Maker — 1cmaker.com
Сервис создан одинесниками для одинесников.
- Не нужно уметь программировать;
- Заказчик и исполнитель видит результат в реальном времени (упрощение согласования). Тут же формируются требования в реальном времени. Даже не зарегистрированный пользователь может посмотреть макет;
- Есть возможность комментировать и описывать элементы, их назначения и возможности, это поможет точнее составить ТЗ, сэкономить своё время и время программиста;
- Создатели посчитали, что в среднем, на корректировку до желаемого состояния уходит 3-3,5 итерации, 1CMaker помогает это время сократить в 2 раза;
- В бесплатном режиме вполне удобно работать. Есть встроенные элементы для составления макета, их немного, но они есть.
Эскиз — https://t.me/sketch1c
Проект в стадии разработки. Есть телеграм канал, где автор выкладывает прогресс по инструменту. Есть «сырая» версия продукта, которую можно попробовать.
Сервис позволяет сделать прототип внутри 1С, на борту довольно большой инструментарий и возможности.
Скачать и ознакомиться можно по ссылке.
Сервисы, зарекомендовавшие себя в web-разработке
Все сервисы, представленные ниже могут использоваться для создания макетов. Можно загружать шаблоны, макеты библиотек и строить по ним интерфейс, формы и все, что душе угодно. Да, эти инструменты заточены больше под web-разработку, но это не отменяет возможность их адаптации под интерфейсные нужды при работе с 1С. Рассмотрим на примере несколько сервисов.
На самом деле их гораздо больше и функционал у них схож. В web-среде есть «золотая» тройка: Figma, Adobe XD и Sketch. О первых двух поговорим, последний работает только на MacOS
Figma
- Доступна версия для Windows;
- Работа прямо из браузера — в ней доступны все инструменты и возможности;
- Наличие бесплатного тарифа, но для полноценной работы нужна подписка;
- Есть командный режим работы, несколько человек могут онлайн работать с одним документом (например, заказчик и консультант), тут же можно общаться внутри проекта. Есть инструменты коммуникации, которые позволяют, не прерывая работы, обсуждать все текущие вопросы в Figma. Наличие отдельного канала связи позволяет не отвлекаться на сторонние коммуникации вроде телефона или скайпа;
- Собственное облачное хранилище (в бесплатной версии история хранится 30 дней);
- Режим презентации макета;
- Нет русского языка;
- Легко экспортировать в самые разные форматы.
AdobeXD
- Большая экосистема взаимосвязанных продуктов от Adobe;
- Возможность работы с рабочего стола или браузера;
- Есть русский язык;
- Совместная работа в реальном времени;
- Простота в использовании, если вы знакомы с другими продуктами Adobe;
- Девиз Adobe «Плати или умри».
Отдельная номинация:
Draw IO – легкий сервис, в котором можно нарисовать какую угодно диаграмму и не только:
- Настолько дешево, что аж бесплатно;
- Небольшой набор инструментов;
- Есть возможность совместной работы;
- Есть как браузерная, так и десктопная версия;
- Есть русская версия.
Другие популярные сервисы:
- Axure RP;
- И многие другие.
- С каждым годом проблема разработки интерфейса в среде 1С становится актуальнее;
- Софт, который подходит для проектирования дизайна форм 1С, преимущественно платный, но все же он есть;
- Есть возможность адаптировать софт из других областей разработки. Не нужно заново придумывать велосипед;
- Фирма 1С пока не хочет заниматься вопросами дизайна форм, текущие справочные материалы бесполезны;
- Уже прямо сейчас каждый может выбрать для себя сервис и использовать его;
- Использование технологий проектирования — это еще один шаг к развитию ведения проектов, который может повысить эффективность и презентабельность перед клиентом.
Рассказать друзьям
Предыдущая
Производители фискальных накопителей для онлайн-касс изготовят более двух миллионов устройств
Противостояние бухгалтерских гениев и ИТ- умов!
Комментарии ( 66,’PROPERTY_OBJECT_ID’ => $ElementID, ‘ACTIVE’=>’Y’,), array(), false, array(‘ID’, ‘NAME’) ); echo $cnt; ?>)
IncludeComponent( «scoder:scoder.comments», «coments», Array( «AJAX_MODE» => «Y», «AJAX_OPTION_ADDITIONAL» => «», «AJAX_OPTION_HISTORY» => «N», «AJAX_OPTION_JUMP» => «N», «AJAX_OPTION_STYLE» => «N», «CACHE_TIME» => «36000000», «CACHE_TYPE» => «A», «COMPOSITE_FRAME_MODE» => «A», «COMPOSITE_FRAME_TYPE» => «AUTO», «CUSTOM_TITLE_DATE_ACTIVE_FROM» => «», «CUSTOM_TITLE_DATE_ACTIVE_TO» => «», «CUSTOM_TITLE_DETAIL_PICTURE» => «», «CUSTOM_TITLE_DETAIL_TEXT» => «», «CUSTOM_TITLE_IBLOCK_SECTION» => «», «CUSTOM_TITLE_NAME» => «Ваше имя», «CUSTOM_TITLE_PREVIEW_PICTURE» => «», «CUSTOM_TITLE_PREVIEW_TEXT» => «», «CUSTOM_TITLE_TAGS» => «», «DEFAULT_INPUT_SIZE» => «30», «DETAIL_TEXT_USE_HTML_EDITOR» => «N», «DIF_LEVEL_COMMENTS_SPACE_PX» => «50», «DISPLAY_BOTTOM_PAGER» => «Y», «DISPLAY_TOP_PAGER» => «N», «ELEMENT_ASSOC» => «PROPERTY_ID», «ELEMENT_ASSOC_PROPERTY» => «300», «GROUPS» => array(«2»), «MAX_FILE_SIZE» => «0», «MAX_LEVELS» => «100000», «MAX_USER_ENTRIES» => «100000», «NEWS_COUNT» => «50», «OBJECT_ID» => $ElementID, «OBJECT_TYPE» => $arParams[«IBLOCK_ID»], «PAGER_BASE_LINK_ENABLE» => «N», «PAGER_DESC_NUMBERING» => «N», «PAGER_DESC_NUMBERING_CACHE_TIME» => «36000», «PAGER_SHOW_ALL» => «N», «PAGER_SHOW_ALWAYS» => «N», «PAGER_TEMPLATE» => «.default», «PAGER_TITLE» => «Комментарии», «PREVIEW_TEXT_USE_HTML_EDITOR» => «N», «PROPERTY_CODES» => array(«300″,»NAME»), «PROPERTY_CODES_ANSWERE» => array(«300″,»NAME»), «PROPERTY_CODES_ANSWERE_REQUIRED» => array(«300″,»NAME»), «PROPERTY_CODES_REQUIRED» => array(«300″,»NAME»), «RESIZE_IMAGES» => «N», «SC_HIDE_TREE» => «N», «STATUS_NEW» => «ANY», «USER_MESSAGE_ADD» => «Ваш комментарий отправлен», «USE_CAPTCHA» => «N», ) );?>
Источник: is1c.ru