Дизайнер компании Canonical отмечает постепенное улучшение удобства использования свободного ПО и ПО, разрабатываемого на добровольных началах в целом. Помимо улучшения как такового, в наличии имеются и качественные изменения в приоритетах, которые нелишне взять на заметку при разработке интерфейса пользователя (UI). Рассмотрены причины отставания от проприетарного ПО, и способы решения этих проблем.

1. Слабые стимулы к удобству. Для коммерческого ПО финансовое положение поставщика зависит от этого напрямую, через количество пользователей и объём продаж им. Для свободного ПО мотивация как будто не связана с количеством пользователей.
   Что делать: организаторы могут обратить больше внимания на мотивацию к интерфейсу пользователя. Устроители наград могут выделять отдельную номинацию для разработчиков за хороший дизайн, система вознаграждений может позволять людям направлять средства разработчикам за именно хороший дизайн, система разделения версий может различать версии ПО и условия их поставки не только по функционалу, обеспечиваемому этим ПО, но и по удобству использования.
2. Хороших дизайнеров мало. Мало хороших разработчиков, и мало хороших дизайнеров. Тем реже случаи, когда это совмещается в одном. Некоторые, конечно, заняты на такой работе, но уже совсем редко бывает, что это на общественных началах.
   Что делать: выпускайте больше хороших обучающих материалов, помогайте тем сообществам, которые объединяют дизайнеров и программистов, ведите работу над проектами свободного ПО с разделением труда на программистов, дизайнеров и т. д.
3. Часто мы не замечаем их предложений по дизайну. мы часто говорим друг другу "покажи исходник", а дизайнеру мы отвечаем "присылай исправление". Но, как правило, дизайнер - не программист, и сам работающий код написать не может.
   Что с этим делать: главе проекта рекомендуется наладить взаимодействие со всеми, кто заинтересован, уже на стадии выработки интерфейса пользователя. Публиковать наравне с остальной проектной документацией описания и характеристики интерфейса пользователя для обсуждения его, например, в онлайн-дневниках, системах запросов на улучшение ПО, и повысить приоритет таких запросов до уровня сообщений об ошибках в такого рода системах.
4. Удобство субъективно. Мы можем более точно судить о скорости и полезности ПО, чем об удобстве. Чтобы оценить удобство, нужны подробные тесты использования. Но мало кто из пользователей поступает настолько тщательно, и дизайнеры таким образом остаются без результатов таких тестов. А ведь на такие запросы нужно проводить работы по дизайну — и снова проводить тесты.
   Что делать: поощряйте мелкомасштабные тесты пользователей на общественных началах, внедряйте и развивайте ПО, способствующее этому: снимки экранов, видеозапись и т. д. Направляйте разработку таким образом, чтобы пользовательские тесты оказывались важнее, при этом в требованиях к разработке выделяйте преимущественно те моменты, которые трудно уловить пользователю.
5. Код, а потом дизайн. ПО получается намного более удобным, когда сначала сделан хотя бы набросок. Изменения, вносимые в интерфейс пользователя, могут затрагивать реализацию различных частей кода, таких как многопоточность, способ хранения рабочих данных и т. д. Однако, часто мы просто пишем код, оставляя удобство для пользователя "на потом".
   Однако по мере роста объёма кода, выправлять дизайн становится всё сложнее. Особенно пикантно когда после это происходит выхода версии 1.0 - уже было набравшая вес база пользователей смотрит на это "как баран на новые ворота" и отворачивается в сторону конкурентов.
   Что делать: объединяйте "по два" дизайнеров с теми программистами, когда они собираются сделать что-то новое, с тем, чтобы сначала было решено по дизайну.
6. Разнобой. Случается, что дизайнеры работают над проектом "каждый помаленьку". Полученные "винегреты" показывают, что качество такого дизайна обратно пропорционально количеству дизайнеров.
   Что делать: Выделять ведущего дизайнера интерфейса пользователя, принимающего вклад всех остальных, и решающего с программистами, что именно можно воплотить.
7. "Остатки прежней роскоши". Часто разработчики пытаются имитировать проверенные временем дизайны. Но далеко не всегда можно точно полагаться на то, что интерфейс пользователя от Apple или Microsoft заведомо хорош. Случается разработчики свободного ПО не предлагают своё видение того, каким должен быть интерфейс пользователя, а повторяют ошибки предшественников.
   Что делать: поддерживать эксперименты в области дизайна, и по мере их успешности обновлять проектную документацию для направления дизайнеров в нужное русло.
8. Делаем "под себя". Разработчики часто пишут для себя, то есть, полагаясь в разработке в основном на собственные нужды. При этом не берутся в расчёт нужные пользователям с первых шагов вещи, такие, как первоначальная установка и настройка, и импорт настроек из конкурирующего ПО.
   Что делать. Сила, как известно - в простоте, поэтому в удобстве использования давайте лучше относиться к простым дизайнам, а к сложным - наоборот. И предлагайте работать с вашим ПО тем , кто вас окружает - друзьям и семьям.
9. "Крошки на столе". Вполне возможно, что прелесть вашего ПО будет сложно разглядеть за теми оставшимися мелочами, которые мешают работать с ним неподготовленному пользователю, ведь "хороших танцоров" среди них действительно немного, и понятно почему им нередко "что-то мешает".
   Что делать. Планируя работу над ошибками в ПО, отдавайте себе отчёт в том, сколько длится каждая её часть. Ведь многие досадные ошибки в интерфейсе пользователя могут быть исправлены раньше других, потому лучше бы их поставить в расписание выполнения работ пораньше.
10. Многовариантность для удобства избранных. Случается, что разработчики реагируют на запросы пользователей тем, что предлагают им в настройках изменить поведение ПО для какого-то случая. В коммерческом ПО разработчики продолжают работать над проектом по какому-то одному из вариантов, даже когда они не согласны с его выбором.
    Что делать: Проявлять твёрдость в руководстве проектом, вводить в обиход простоту. Также можно распределять многовариантность по веткам в системе контроля версий.
11. "15 минут славы". Понятно, что каждый доброволец хочет занять место на экране пользователя, чтобы как будто сказать "вот это - делал я". В итоге интерфейс пользователя загромождён элементами, которые, может быть, и утратили свою актуальность, да вот только гневать не хотелось бы таких авторов.
    Что делать: использовать другие возможности, например, блоги. Регулярно пересматривать изменения в коде, затрагивающие дизайн, и пересматривать существующий код на тему нужности каждого элемента.
12. Затруднённость командного взаимодействие на удалёнке. Как правило, разработка свободного ПО очень разнесена территориально. В основном мы взаимодействуем текстовыми способами: почта, чаты и т. д. Но интерфейс пользователя включает и поведение ПО, и графику, поэтому возможны недопонимания.
    Что делать. Развивайте и внедряйте средства мультимедиа-общения: voip, видеочаты, "виртуальные планшеты" и т. д. И, по возможности, чаще встречайтесь лично.
13. Часто мы пишем ПО, а к нему отдельно - графический интерфейс. Это, конечно, хорошо для повторного использования того же кода, модульности, но в графическом ПО, например, индикатор хода выполнения процесса имеет решающее значение. Хотя и понятно, что для терминалов это нехарактерно.
    Что делать: сначала подумайте, как будет выглядеть и вести себя графический интерфейс, а уже потом решайте, как "расслаивать" ПО для отделения его кода от общего.
14. Разнесённые "по углам" команды разработчиков. Что бы вы ни делали на компьютере, как правило, используются целые разные наборы ПО. И в отличие от коммерческого ПО, команды, которые их разрабатывают, не настолько сильно связаны друг с другом. У них разные подходы к разработке и выпуску релизов, это часто затрудняет внесение дизайнерами улучшений интерфейса пользователя, ведь он затрагивает сразу несколько таких подсистем. Например, чтобы посмотреть и напечатать веб-страницу, человек в той или иной мере использует порядка десятка элементов интерфейса ПО из разных подсистем.
    Что делать. Задача поставщикам ПО: координировать работу таких команд, если, конечно, они могут позволить себе содержать штат разработчиков на всех уровнях стека ПО. При этом вовлекать в эту координацию вклад и со стороны.

В ближайшие месяцы Matthew Paul Thomas покажет примеры решения таких проблем.