UI /UX в гибкой среде разработки

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

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

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

Как я могу избежать этого? Какие-либо предложения? Каковы некоторые лучшие практики?

11 голосов | спросил Mark 7 +04002014-10-07T22:09:42+04:00312014bEurope/MoscowTue, 07 Oct 2014 22:09:42 +0400 2014, 22:09:42

5 ответов


8

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

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

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

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

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

Вот ссылка, чтобы вы начали.

Вам нужно упростить, чтобы пройти.

Удачи вам. Если у вас есть шанс, напишите комментарий, я бы хотел услышать, как это получается.

ответил Johnny UX 8 +04002014-10-08T01:29:32+04:00312014bEurope/MoscowWed, 08 Oct 2014 01:29:32 +0400 2014, 01:29:32
16

В режиме Agile

Из различных связанных с Agile концепций я хотел бы выделить два:

  • Он предназначен для борьбы с волатильностью требований (часто развивающимися или изменяющимися требованиями или их приоритетом).
  • Это увеличивает время выхода на рынок .

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

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

О требованиях к проектированию

Гистограмма, показывающая растущую стоимость изменений по мере развития процесса разработки

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

Это то, о чем свидетельствует каждый разработчик программного обеспечения /UX - чем больше требований вы знаете до процесса проектирования, тем более прочным будет дизайн.

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

3 стратегии дизайна

В основном есть 3 подхода к проектированию (UX или программное обеспечение):

  • Throwaway (революционный)
    • Если у вас мало понимания проблемы и требований (высокий уровень неопределенности)
    • Вы разрабатываете быстрый, быстрый тест и, в основном, для изучения того, что работает, а что нет.
    • Обычно супер-быстрый процесс, но проекты, скорее всего, будут отброшены (что приведет к перепроектированию или переработке).
  • Эволюционная
    • Когда у вас есть некоторое понимание проблемы /требований, но оно неполное и может измениться.
    • Вы строите проект шаг за шагом, учитывая новые знания на каждой итерации.
    • Конструкции обычно служат основой для следующей итерации.
    • С каждой итерацией предыдущий дизайн часто требует пересмотров - иногда драматических.
    • Опасность состоит в том, что плохие проекты могут сохраняться.
  • Инкрементальный
    • Когда у вас есть четкое понимание проблемы и требований.
    • Вы разрабатываете для удовлетворения всех требований.
    • Этот процесс может быть длинным.

Когда Agile великолепно

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

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

Когда Agile является катастрофой

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

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

Предложения

Начнем с того, что ваши сверстники пытаются съесть пирог и оставить его в целости - вы не можете попросить произвести оптимальные проекты, если вам не пришло время изучить все требования. Концепция just-enough-now-iterate-later является ключом к Agile.

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

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

ответил Izhaki 8 +04002014-10-08T00:10:19+04:00312014bEurope/MoscowWed, 08 Oct 2014 00:10:19 +0400 2014, 00:10:19
2

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

Для некоторых примеров этого просмотрите страницу Google Material Design , а также Atlassian Design Guidelines . Он обеспечивает как высокоуровневый подход к дизайну, так и компоненты и правила пользовательского интерфейса низкого уровня, которые помогают людям разрабатывать приложения, используя их стиль и шаблоны. В отличие от руководства по стилю Apple и Windows эти документы являются живыми, а также более интерактивными, поэтому он захватывает все основные элементы дизайна в одном месте.

ответил Michael Lai 8 +04002014-10-08T00:53:48+04:00312014bEurope/MoscowWed, 08 Oct 2014 00:53:48 +0400 2014, 00:53:48
0

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

ответил PhillipW 8 +04002014-10-08T02:19:25+04:00312014bEurope/MoscowWed, 08 Oct 2014 02:19:25 +0400 2014, 02:19:25
0

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

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

Поговорите с разработчиками, поймите технические ограничения. Технология, особенно на предприятии, имеет множество ограничений и обычно конкретные методы решения проблем.

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

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

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

Удачи, держись! К.

ответил Ken 8 +04002014-10-08T04:27:37+04:00312014bEurope/MoscowWed, 08 Oct 2014 04:27:37 +0400 2014, 04:27:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132