Должен ли разработчик делать макеты пользовательского интерфейса, если в проекте нет дизайнеров?

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

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

Один из моих коллег говорит, что это нелепо и это не моя работа.

Я очень часто работаю в таких проектах, и ответ - ДА, и как можно раньше.

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

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

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

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

Я настоятельно рекомендую вам не делать макеты, которые выглядят как настоящие экраны. Если вы поделитесь ими с конечными пользователями, которые часто фокусируются на вещах, которые не имеют значения, таких как цвета и темы. То, что я рекомендую вам делать, это либо создавать рисованные на бумаге, либо наброски на доске. Или, если вы хотите, чтобы они в компьютере использовали что-то вроде Pencil Project или Visio ( вот несколько трафаретов Visio от Jonathan Abbett, которые выглядят от руки).

Да, конечно.

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

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

При разработке «нового экрана» вы хотите сначала обсудить грубую идею пользовательского интерфейса с пользователем и / или вашими коллегами. Вы не можете обсуждать это с пользователем «в коде» или «в UML», который просто не работает (он даже не будет работать между программистами). И вы должны ожидать, что вам нужно выбросить свои первые два или три эскиза или, по крайней мере, сильно изменить элементы пользовательского интерфейса.

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

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

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

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

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

ВСЕГДА!

Я работаю в небольшой компании, и я единственный «мягкий» айтишник. Я делаю все требования, дизайн, кодирование, тестирование (хотя кто-то всегда проверяет мое тестирование), дизайн базы данных и т. Д.

НИКОГДА НЕ РЕДАЙТЕ УГЛЫ НА ШАГИ ДИЗАЙНА - ваши конечные пользователи будут вам благодарны. Вы будете благодарить себя тоже, потому что вы БУДЕТЕ в конечном итоге вновь работать его , чтобы конечные пользователи счастливы. Даже если ваш макет представляет собой не что иное, как нарисованный от руки лист бумаги, он дает им представление о том, чего ожидать. Потратив 10 минут на то, чтобы что-то набросать, можно сэкономить неделю на работе (уже там, сделал это)

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

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

Давайте посмотрим на это в более общем виде:

• Является ли создание черновиков хорошей идеей?
• Кто должен создавать проекты?

Является ли создание черновиков хорошей идеей?

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

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

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

Кто должен создавать проекты?

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

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