Процесс разработки пользовательского интерфейса. Тестирование прототипа

Межсистемная согласованность-

Понятие ментальной модели. Различие ментальных моделей пользователя и разработчика ПО.

Ментальные модели формируются на основании человеческого восприятия. Ментальная модель — это интуитивное понимание принципов работы объекта или системы, основанное на прошлом опыте человека, имеющейся информации и здравом смысле.

4)понятие метафоры - Метафора продолжает быть средством описания новых понятий в компьютерных науках. Сравнительно свежим примером служит появления чисто метафорического английского названия новой дисциплины «DataMining», смысл которого по-русски можно передать термином «интеллектуальный поиск и анализ данных». По нашему мнению метафора в компьютерных науках носит универсальный характер и присутствует практически во всех его областях. В последние десятилетия метафора стала предметом изучения специалистов по человеко- компьютерному интерфейсу, визуальным коммуникациям и компьютерной визуализации. В настоящее время очень много работ посвящено проблеме метафоры в компьютерных науках и человеко-компьютерном взаимодействии. Эти работы рассматривают проблемы использования метафор в визуальных системах и содержат рекомендации по их проектированию. Кроме того, опубликованы фундаментальные исследования в области метафоры интерфейса и визуальной метафоры, например, работы А. Блэквэлла

Процесс пользовательского интерфейса. Предварительная работа при создании пользовательского интерфейса

 

 

Процесс пользовательского интерфейса. Первоначальное проектирование

Стадии проектирования, как и вообще весь процесс создания интерфейса, очень похожи на стадии в процессе разработки информационной системы в целом.

6. 1. Анализ деятельности пользователей. Это пред проектная стадия, на которой определяются задачи, процедуры, уточняется характер производства, контингент пользователей и т.п.

6.2. Формализация результатов анализа в виде схем и диаграмм бизнес-процессов и сценариев выполнения каждой задачи.

6.3. Проектирование интерфейса для обеспечения каждого сценария и процесса. Синтез решения в виде прототипа интерфейса.

6.4. Тестирование с пользователями прототипа или готового интерфейса. Синтез решения (рисование экранных форм) часто занимает гораздо меньшее время, нежели этап анализа

 

Процесс разработки пользовательского интерфейса. Создание прототипа на высоком уровне

Прототипирование — процесс создания (с применением определенных методов или технологий) какого-то физического объекта для конкретных целей.

Под интерфейсом понимается любой экранный информационный или интерактивный интерфейс. Таковыми являются:

· сайты,

· мобильные приложения,

· приложения для стационарных компьютеров,

· презентационные панели (включая touch),

· информационные стационарные экраны.

Этапы разработки

Полный цикл разработки интерфейса включает следующие этапы:

1. Исследование

2. Пользовательские сценарии

3. Структура интерфейса

4. Прототипирование интерфейса

5. Определение стилистики

6. Дизайн концепция

7. Оформление всех экранов

8. Анимация интерфейса

9. Подготовка материалов для разработчиков

 

Процесс разработки пользовательского интерфейса. Создание прототипа на низком уровне

 

процесс разработки пользовательского интерфейса. Тестирование прототипа

Тестирование прототипа поможет обмануть время и устранить глобальные проблемы в самом начале разработки.

Бумажный прототип
На бумаге идеально тестировать концепты, когда есть доступ к целевой аудитории и несколько человек для проведения исследования. Лучше всего тестировать сложные сценарии с множеством экранов, миллионом кнопок — в общем, что-то такое, что можно аналогично протестировать только на готовом продукте.

Интерактивные прототипы в мелкой детализации
С помощью интерактивных прототипов хорошо тестировать логику, особенно простую, а также ожидания пользователей. Конечно, можно взяться и за сложную навигацию, но придется потрудиться с количеством и качеством экранов. Респондент зачастую не воспринимает интерактивный прототип как прототип, поэтому ему приходится постоянно об этом напоминать.

Тестирование цветного прототипа в программах типа Axure
Тут всё достаточно просто. Дизайнер делает красивый интерфейс, в котором вы размечаете области, при взаимодействии с которыми должно что-то происходить

Тестирование на BigData
Это путь Яндекса и больших компаний: придумать быстрое решение, выпустить бета-версию, сделать пререлиз, пустить миллионный суточный трафик и смотреть, как всё работает

Тестирование имеющегося продукта
Тестирование схожего продукта, что уже у вас есть, или есть у ваших конкурентов отлично подходит тем, кто хочет сделать «идеально, как у конкурента».

 

Какие бывают прототипы?

Горизонтальный прототип (Horizontalprototype).
Когда люди говорят "прототип ПО", они обычно имеют в виду именно горизонтальный прототип. предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом или моделью. Горизонтальным прототип называется потому, что в нем не реализуются все слои архитектуры и нюансы системы, но воплощаются некоторые особенности интерфейса пользователя.

Горизонтальный прототип, подобно кинофильму, создает видимость функциональности, не обеспечивая ее действительного воплощения. Горизонтальные прототипы демонстрируют функциональные возможности, которые будут доступны пользователю, внешний вид пользовательского интерфейса (цвета, планировку, графику, элементы управления) и структуру доступа к информации (структуру навигации). Но полезной работы он не выполняет! С другой стороны, зачастую имитации достоточно, чтобы пользователи могли решить, нет ли каких то упущений, неверных или ненужныъ функций.

Вертикальный прототип (verticalprototype).
Вертикальный прототип, также называемый структурным прототипом (structuralprototype) или проверкой концепции, воплощает срез функциональности приложения от интерфейса пользователя до сервисных функций. Вертикальный прототип действует как настоящая система, поскольку затрагивает все уровни ее реализации. Разрабатывайте такой прототип всякий раз, когда сомневаетесь в осуществимости и стабильности предполагаемого подхода к архитектуре системы или когда хотите оптимизировать алгоритмы, оценить предполагаемую схему базы данных или проверить критически важные временные требования.

Одноразовые прототипы.
Прежде чем создать прототип, примите четкое и ясное решение, прекратите ли вы работать с ним после оценки или сделаете его частью выпускаемого продукта. Создайте одноразовый прототип (throwawayprototype), или исследовательский прототип (exploratoryprototype), чтобы ответить на вопросы, разрешить неясности и улучшить требования.

Но при этом стройте его как можно более быстро и дешево. Иначе потом сложно будет с ним расстаться. И никогда, никогда (!) не кладите одноразовый прототип в основу архитектуры кода - так как для "дешевой" реализации прототипа разработчики используют крайне неоптимальные методы. В этом и заключается главная ловушка таких прототипов, жаль отказаться, а применить нельзя. Или показали пользователям, а те думают, что код уже практически написан. А ведь это не так, для этого есть...

Эволюционные прототипы.
В отличие от одноразового прототипа, эволюционный прототип (evolutionprototype) представляет собой прочный архитектурный "фундамент"для постепенного создания окончательного продукта - по мере прояснения требований. Эволюционное прототипирование - один из компонентов модели спирального цикла разработки ПО.

В отличие от одноразовых прототипов, создаваемых "быстро и начерно", для построения эволюционного прототипа необходимо с самого начала использовать отличный и качественный код. Соответственно, на него уйдет больше времени. При создании такого прототипа ни в коем случае не стоит экономить на качестве. Окончательный продукт в данном случае - кульминация серии эволюционных прототипов.

Бумажные и электронные прототипы.
Не всегда для разрешения неопределенностей в требованиях нужен прототип в виде исполняемого кода. Бумажный прототип (paperprototype), иногда его называют низкокачественным прототипом - это дешевый, быстрый и низкотехнологичныйспособ выяснить, как может выглядеть некий фрагмент системы. Он помогает установить, действительно ли пользователи и разработчики одинаково понимают требования. Похожий метод, называемый методом раскадровки (storyboard), показывает предлагаемый интерфейс пользователя, без привлечения пользователей к работе с ним.

Вот такие бывают прототипы. Конечно, на одном только создании прототипа дело не заканчивается, его еще надо оценить, а тут есть свои ловушки и подводные камни... Но тем не менее - чем раньше вы получите feed-back от конечного пользователя, тем больше у вас шансов сделать именно такую систему, которая ему и нужна.
Пользователь может прочитать ТЗ и сделать свои выводы, а разработчики свои. Чтобы не получилось в итоге "ой, как неудобно с этим работать", очень полезно использовать прототипы. Особенно, если у вас не итеративная модель разработки и Заказчик свой продукт увидит не скоро...