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


57

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

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

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


51
Если у вас нет дизайнеров, и это не работа разработчиков, то кто должен это делать? Может быть, уборщик?
GrandmasterB

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

3
Я полагаю, вы действительно имеете в виду "макет?" «Насмешка» это нечто другое .
Роберт Харви

23
Дизайн пользовательского опыта выходит за рамки создания привлекательных вещей. Программисты должны быть очень вовлечены в это.
JeffO

2
Что нелепо, так это реакция ваших коллег. это очень распространено
Клавдиу Крянгэ

Ответы:


74

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

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

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

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


16
И, честно говоря, написать код гораздо проще, если перед вами стоит хотя бы набросок салфетки.
Кэти

9
Пункт 2) ужасно важен, если дело не тривиально!
большие камни

4
Как человек, который работал в UX в течение 3 лет, просто набросок, с которым можно поговорить с людьми (разработчиками, клиентами, конечными пользователями), невероятно полезен и важен. Это сэкономит вам много времени в будущем, когда вам не нужно полностью переделывать сайт, потому что кто-то расстроился!
Гномеджон

39

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

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


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

Это просто сумасшедший разговор ... на самом деле занимаюсь раскадровкой. Путь в старую школу для этих новых парней: P
Мэтью Уайтед

1
«Не делайте макеты, которые выглядят как настоящие экраны» - это очень глубокое понимание.
Эндрю Майерс

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

1
@ Эндрю ... это одна из вещей, которую я узнал, когда я издевался над приложениями в Access и VB. Вы показываете кому-то что-то похожее на скриншот, и они ожидают, что вы можете отправить это :)
Matthew Whited

11

Да, конечно.

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

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


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

10

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

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


5

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

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

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

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


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

@ MatthewWhited Они жалуются на мелочи, когда вы приходите обсуждать пользовательский интерфейс, или они жалуются на них, когда вы предлагаете использовать продукт для выполнения своей задачи? Я скорее ожидаю, что более поздний случай будет более конструктивным, и это хорошо подходит для внутреннего веб-приложения с установленной базой 1.
Евгений Рябцев

3

ВСЕГДА!

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

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

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

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


2

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

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

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

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

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

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

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

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


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

-2

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


1
Макеты предназначены не для создания передового пользовательского интерфейса, а для макета макета и поведения экрана. На самом деле в большинстве случаев они не такие красивые. Я просто не согласен
Kieren Johnstone

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

@KierenJohnstone Я полностью с тобой согласен. Однако сам он говорит, что «UX не так важен». Если он не является достаточно старшим членом команды, его награды не будут соответствовать усилиям (создание макетов). Макеты отличные. Но не в его ситуации.
Кшитий Упадхяй

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

1
Наша команда составляет около 3 человек. Есть один старший член / руководитель группы, и я, и еще один парень, с которым по контракту работали над проектом. Проект был в основном сделан для обсуждения нового экрана с руководителем группы. Также не было предопределенного внешнего вида, поскольку весь смысл нового экрана заключался в том, чтобы улучшить существующий, который было неудобно использовать, поэтому все должно было быть сделано заново.
Константин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.