Какие принципы проектирования пользовательского интерфейса, такие как “разделение задач”, я могу использовать, чтобы убедить разработчиков в том, что пользователn

Question

Закрытый.Этот вопрос должен быть более сосредоточенный.В настоящее время он не принимает ответы.

---

Хотите улучшить этот вопрос? Обновите вопрос таким образом, чтобы он фокусировался только на одной проблеме, выполнив редактирую этот пост.

Закрытый 5 лет назад.

Недавно у меня была большая дискуссия с командой, связанная с дизайном пользовательского интерфейса для нашего недавнего программного проекта.

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

Команда дизайнеров разработала дизайн, с которым я не могу согласиться и считаю, что это противоречит основным правилам дизайна.

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

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

Я обобщил принцип проектирования пользовательского интерфейса следующим образом: "один пользовательский интерфейс не должен содержать двух совершенно разных вещей".Хотя они и утверждали это, они хотят приложить такие усилия и все побочные (например, больше пользовательского интерфейса, больше ситуаций для решения пользовательского интерфейса, больше усилий по разработке / тестированию / сопровождению по сравнению с дизайном пользовательского интерфейса, который разделяет две разные вещи), чтобы пользователь получил простое в использовании программное обеспечение с хорошим юзабилити.Конечно, я полностью не согласен с таким заявлением, как может программное обеспечение, не хорошее во всех остальных аспектах, быть хорошим для пользователя?И измерять нечего, так как у команды дизайнеров еще нет полноценного дизайна.

И все заканчивается тем, что я не могу убедить команду.Все по-прежнему кажется объективным.

Это заставило меня задуматься, есть ли какое-либо хорошее руководство по дизайну пользовательского интерфейса / лучшая практика / принцип, который охватывает нашу ситуацию (чтобы разделить различные проблемы, подробно описать потребности в сценарии отладки / запуска и необходимость в сценарии управления версиями, не объединяя их в одном специальном пользовательском интерфейсе, диалоговом окне или мастере и т.д...)

Я был бы признателен за любые комментарии и предложения, связанные со всей проблемой в целом, а не только с приведенным выше вопросом.также я отвечу на все, что я здесь не очень хорошо выразил.

Пожалуйста, не закрывайте это :) это действительно большая проблема для меня как менеджера разработчиков.

Answer 1

Я согласен с @JanNeilson в том, что принципы дизайна не помогут вам убедить разработчиков изменить дизайн пользовательского интерфейса.

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

Юзабилити-тестирование может быть формальным процессом, когда вы приводите клиентов в лабораторию, просите их выполнить определенные задачи с помощью вашего программного обеспечения и записываете видео с пользователем и экраном.

Важный: Обязательно сообщите тестируемым пользователям, что вы их не тестируете;что вы просите их помочь вам протестировать программное обеспечение.Объясните, что вы не обидитесь, если им не понравится программное обеспечение.Вы хотите честной реакции.Периодически просите их сказать, о чем они думают, т.е.чтобы "думать вслух", пока они решают, что делать.Не отвечайте на их практические вопросы, пока они окончательно не застрянут.

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

Делайте заметки во время или сразу после каждого теста.Вы можете попросить разработчиков посмотреть записанное видео позже (отредактируйте ожидающие части, чтобы разработчики посмотрели все) или посмотреть видео из другой комнаты во время теста.Или без видео, вы можете приводить в комнату для просмотра по одному разработчику за раз, но попросите их сидеть сложа руки.Разработчик не должен отвечать на вопросы пользователя, предварительно не сказав: "Мне жаль, что я создал такой паршивый пользовательский интерфейс".

Если ваше программное обеспечение не готово к такому тестированию, вы можете провести юзабилити-тестирование с помощью бумажного макета.

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

Поиск в Интернете позволяет найти множество статей и книг.Вот очень хорошая статья для начала:http://alistapart.com/article/usability-testing-demystified

Первый абзац из Википедия о юзабилити-тестировании говорит:

Тестирование юзабилити это метод, используемый в дизайне взаимодействия, ориентированном на пользователя , для оценки продукта путем тестирования его на пользователях.Это можно рассматривать как незаменимая практика юзабилити, поскольку это дает непосредственную информацию о том, как реальные пользователи используют систему.Это контрастирует с методами проверки удобства использования, когда эксперты используют различные методы для оценки пользовательского интерфейса без привлечения пользователей.

Я добавил курсив.Другими словами, вы невозможно добиться хорошего удобства использования без юзабилити-тестирования. Напротив, привлечение экспертов для оценки пользовательского интерфейса с использованием принципов и опыта может помочь, но не является существенным.

Answer 2

В этом вопросе вы затрагиваете несколько различных аспектов;Я собираюсь сосредоточиться на управлении ПОТОК.

Вместо того чтобы рассуждать об общих чертах, таких как "разделение проблем", я рассматриваю специфические проблемы, связанные с конкретным дизайном пользовательского интерфейса, как с точки зрения UX, так и с более абстрактными или общими понятиями.Для этого вам понадобится макет пользовательского интерфейса.И перед созданием макета пользовательского интерфейса вам понадобится базовый набор описаний назначения пользовательского интерфейса, который будет управлять макетами пользовательского интерфейса.Как только у вас появятся макеты пользовательского интерфейса, вы сможете обсудить варианты использования пользовательского интерфейса и подчеркнуть, почему проблемы с UX вызывают беспокойство из-за разделение забот или другие конкретные принципы.

По моему опыту, спорить об общих чертах неэффективно, потому что тем, кто это понимает, не нужно это слышать, а тем, кто этого не понимает, нужен макет, чтобы иметь достаточный контекст для понимания.

Если вас беспокоят ресурсы, необходимые для создания макета пользовательского интерфейса, вы можете подумать о сокращении времени, например: "потратьте 3 часа на то, чтобы составить макет пользовательского интерфейса на бумаге, и давайте рассмотрим".