Использовать плохой интерфейс для полного редизайна или добавить хороший пользовательский интерфейс в небольших шагах?

Я начал работать в качестве дизайнера UI /UX для крупной компании с большим веб-сайтом.

Поскольку разработчики заняты разработкой бэкэнд-функций, ресурсы сейчас ограничены.

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

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

12 голосов | спросил Pectoralis Major 11 J000000Tuesday17 2017, 16:41:43

4 ответа


10

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

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

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

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

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

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

ответил Nick Groeneveld 11 J000000Tuesday17 2017, 17:02:25
2

Честно говоря, я не уверен, что вы имеете в виду, но что бы это ни было, ответ будет всегда: сделать это правильно

На самом деле нет ни одного сценария, в котором что-то не так помогает кому-либо. И вся идея UX - это УЛУЧШЕНИЕ опыта и процессов. И это включает в себя сохранение времени разработки.

Вы говорите, что ресурсы ограничены. Если вы ошиблись, вы увеличите потребность в дополнительных ресурсах, оставив только 2 пути:

  1. тратить больше времени /ресурсов на решение чего-то, чего никогда не было.
  2. Запустить что-то неполное или неправильное

Как вы можете видеть, это потерять ситуацию .

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

Прочтите пункт 1 на на этой странице (выдержка ниже)

  

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

Заключительная мысль:

как вы делаете что-то неправильно по назначению? . Одна вещь - это не попробовать что-то, что, по нашему мнению, будет работать, но это не так. Мы все это пережили (следовательно, почему мы так много тестируем). Другой вариант - сделать это неправильно с целью . Лично мне нужно много думать о том, как делать что-то неправильно. Я полагаю, что это было бы что-то вроде теории , и опыт говорит мне, что вещи должны быть похожими на X. Тогда сделайте что-нибудь еще случайным образом , но даже тогда было бы трудно понять (концептуально говоря, это как сказать : «Я буду разбирать то, что знаю» )

ответил Devin 11 J000000Tuesday17 2017, 18:27:53
1

Убедитесь, что ваше определение Good (new) UI выровнено с текущими потребностями клиентов. Это может дать вам рычаги управления, чтобы двигаться вперед и выделять больше ресурсов на новый дизайн (и разработку).

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

Вы говорите, что ресурсы для развития ограничены; можно ли так же сказать для исследований и тестирования?

Если вы можете потратить 20% на создание корпуса для нового дизайна, вы можете получить больше рычагов для продвижения вперед. В то же время платные клиенты будут иметь внимание руководства.

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

ответил Mike M 11 J000000Tuesday17 2017, 17:16:30
1

В настоящее время я поддерживаю поддержку около 50 веб-приложений.

Вы должны пойти с небольшими поэтапными изменениями.

Причины:

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

И я согласен с ответом Майка М, ваши изменения могут быть не такими, о чем попросил клиент, если они нарушают ЛЮБЫЕ старые вещи, вся ваша команда берет ненужную вину.

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

ответил luisluix 11 J000000Tuesday17 2017, 22:47:05

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

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

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