Как создавать и применять стандарты для разработки пользовательского интерфейса?

Question

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

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

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

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

Благодаря

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Я нашел это 12 Standard Screen Patterns статья очень полезна.

Answer 6

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

Вместо этого я рекомендую выбирать существующие стандарты, такие как The Macintosh Human Interface Guidelines или Windows User Experience Interaction Guidelines. Даже если стандарт ошибочен, редко бывает выгодно отклоняться от широко установленных конвенций.

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

Далее, уполномочьте свою команду QA регистрировать ошибки, когда интерфейс для одного продукта несовместим с другим. Затем разработчик может либо стандартизировать, либо оправдать отклонение, если у него есть причина. Мы делаем это; он работает очень хорошо.

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

Answer 7

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

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

• Всем в команде необходимо иметь в виду seperation of concerns, то есть вещи, которые могут быть разделены, должны быть сохранены таким образом, как можно раньше. Существует так много способов сделать это: например. примените шаблон MVC в своем проекте (что очень просто). Представление и логика должны быть разделены, чтобы изменения одного слоя не влияли на другие.

• Кто-то должен нести ответственность за общий дизайн пользовательского интерфейса, чтобы он был согласован во всем приложении. Предпочтительно, кто-то, кто является графическим дизайнером и имеет некоторое представление об удобстве использования. Дизайн пользовательского интерфейса - это то, что нужно планировать вместе с вариантами использования и постоянно пересматриваться по мере развития. Согласованный пользовательский интерфейс очень важен, и разработчики должны быть на нем.