UI/UX дизайн похож на водопад, как вы думаете, каким должен быть правильный процесс?

UI/UX дизайн похож на водопад, как вы думаете, каким должен быть правильный процесс?
UI/UX дизайн похож на водопад, как вы думаете, каким должен быть правильный процесс? - linkedinsalesnavigator @ Unsplash

В настоящее время я работаю Fullstack разработчиком, наш фронтенд строится на React.

Наш текущий процесс включает в себя:

  1. Клиент / владелец продукта описывает функцию дизайнеру UI / UX.
  2. Дизайнер создает красивый шаблон в Figma или любом другом UI инструменте, например, так
  3. Дизайн передается нам, разработчикам, для реализации.
  4. Код пишется, затем проверяется, любые различия между дизайном и продуктом отмечаются как ошибки

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

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

Поэтому я спрашиваю, как правильно поступить? Должны ли мы (как разработчики) скрежетать зубами и создавать компонент? Должны ли мы отправить дизайн обратно? Или попытаться подобрать существующий компонент и уменьшить несоответствия между созданным компонентом и дизайном?

То, что вы описываете, не похоже на водопад - это водопад

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

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

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


LetsCodeIt, 1 января 2023 г., 01:06

Похожие посты

Есть ли лучшее название для "яда Agile"?Agile планирование спринтов для кросс-функциональных команд (UX, UI, Dev)Насколько разработчики должны быть озабочены бюджетом?Как фронтенд-разработчику в Agile точно измерить смету без дизайна?С точки зрения программной инженерии, может ли GitHub быть Agile?Должно ли преднамеренное отсутствие значения быть представлено соглашением о значении или явным флагом?Управление и редактирование нескольких строк на странице CRUD - ключевой аспект эффективного управления пользователями и книгамиПроблемы с использованием двух столбцов для emailАльтернативы к двум столбцам для email: один столбец или хеширование данныхВ заключение, выбор подхода при использовании двух столбцов для emailКакова техническая причина того, что многие сайты социальных сетей не позволяют редактировать текст?Дистанционное образование в области компьютерных наук - HCI