Чи повинен розробник робити макети інтерфейсу користувача, якщо в проекті немає дизайнерів?

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

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

Один із моїх колег каже, що це нерозумно, і це не моя робота.

Я дуже часто працюю над такими проектами, і відповідь - це ДА, і якомога раніше.

Людям набагато легше критикувати покращення якоїсь чернетки, ніж придумати рішення з нуля. Тож я починаю розробляти проект рано з двох причин:

• Дайте експертам питання, як можна подати інформацію.
• Покажіть моє сучасне розуміння проблеми та інформаційних структур.

У рідкісних випадках також було приємно мати деякі докази того, що я насправді довів те, про що ми домовились ...

Макети є фантастичними, і немає причин, що розробник не повинен їх робити. (Це може бути зручно навіть для розробника, щоб зробити грубі проекти компонування інтерфейсу, навіть якщо у вас є дизайнери інтерфейсу користувача.)

Я дуже рекомендую вам не робити макети, схожі на фактичні екрани. Якщо ви ділитесь ними з кінцевими користувачами, які часто зосереджуються на речах, не важливих як кольори та теми. Що я вам рекомендую - це створити намальовані рукою на папері або ескізи на дошці. Або якщо ви хочете, щоб вони в комп'ютері використовували щось на кшталт Pencil Project або Visio ( ось кілька трафаретів Visio від Jonathan Abbett, які виглядають ручно.)

Так, абсолютно.

Не дозволяйте, щоб хтось інший розповів вам, як робити свою роботу. І ви маєте рацію, це дуже схоже на те, щоб зробити UML для вашої моделі даних. Якщо припустити, що ви розробник, ваша робота - постачати якісне програмне забезпечення. Якщо макети допоможуть вам це зробити, то це частина вашої роботи.

Робіть макети з низькою вірністю - не робіть їх схожими на справжні екрани. Ви витратите занадто багато часу на коригування шрифтів, пікселів та меж, і ваші користувачі будуть нав’язуватися над такими деталями, а не зосереджуватись на функціональності. Щось на зразок бальзаміка для цього чудово підходить, немає жодних сумнівів у інших подібних інструментах. З макетом в руці стає набагато простіше обговорити особливості проекту з вашими користувачами та з іншими членами команди розробників.

Створюючи "новий екран", ви хочете спочатку обговорити грубу ідею інтерфейсу користувача з користувачем та / або вашими колегами. Ви не можете обговорювати це з користувачем "в коді" або "в UML", який просто не працює (він навіть не працюватиме між програмістами). І ви повинні сподіватися, що вам потрібно відкинути свої перші два-три сцени або принаймні сильно переставити елементи інтерфейсу.

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

Не обов'язково. Є щонайменше дві причини, через які макети можуть не принести користі.

По-перше, якщо є добре налагоджені галузеві практики щодо того, щоб робити те, що ви збираєтеся робити, ви можете просто продовжувати робити саме це. Ви не будете підштовхувати мистецтво дизайну інтерфейсу, але це так само добре.

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

Маючи досить гнучку веб-структуру, для "просто іншого екрану інтерфейсу користувача, як і попередні N екранів", ви можете почати з працюючого прототипу та переставляти його по ходу. Зробіть макет і обговоріть з колегами в будь-який час, коли ви збираєтеся зробити щось фантазійне.

ВЖЕ!

Я працюю в невеликій компанії, і я єдина «м'яка» ІТ-людина. Я виконую всі вимоги, дизайн, кодування, тестування (хоча хтось завжди перевіряє моє тестування), дизайн бази даних тощо.

НІКОЛИ НЕ РІЗНАЙТЕ КОРОНИ НА КРАЇНІ ДИЗАЙНУ - ваші кінцеві користувачі будуть вам вдячні. Ви будете дякувати себе теж, тому що ви БУДЕТЕ в кінцевому підсумку знову працювати, щоб це зробити кінцевих користувачів щасливими. Навіть якщо ваш макет - це не що інше, як накреслений рукою аркуш паперу, він дає їм уявлення, чого чекати. Витрачавши 10 хвилин на те, щоб виписати щось, ви можете заощадити час роботи в тиждень (був там, зробив це)

Це також допомагає вам у кодуванні. Це дає вам можливість подумати про те, що вам потрібно зробити, найефективніший спосіб її виконання та будь-які перешкоди, які можуть бути на шляху.

Наприклад, ви можете виявити, що "простий" звіт, який вам потрібно створити, складніше, ніж ви думали раніше, тому що ви не фіксуєте якусь дату в таблиці xyz. Це також розширює ваш кругозір і показує, що ваша команда, начальство або навіть можуть бути використані для потенційних майбутніх кар'єрних можливостей, які ви робите більше, ніж голий мінімум, і можете вийти за рамки "це не моя робота" (<--- серйозно, НЕ бути тим хлопцем, ми всі його ненавидимо) або це дає вам шанс на додаткове навчання.

Давайте розглянемо це в більш загальному вигляді:

• Чи є створення чернеток гарною ідеєю?
• Хто повинен створювати чернетки?

Чи є створення чернеток гарною ідеєю?

Створення чернетки переважно передбачає 2 переваги. По-перше, це забезпечує фокус, що призводить до прискорення фактично виконаної роботи. По-друге, це набагато простіше обговорити напрямок роботи до завершення роботи.

Мінусом створення чернетки є те, що він використовує час. Мало сенсу витрачати 2 години на створення продуманої чернетки на те, на що потрібно 4 години.

У вашому випадку рівень макету повинен враховувати передбачуваний обсяг роботи, який входить у проект, та користь проекту. Залежно від них, ваш макет може бути десь між 10-секундними написаннями на пост-це та повністю інтерактивним веб-сайтом. Для дуже великих і дорогих проектів не рідкість цілі команди тижнями працювати над чернетками та створювати чернетки проекту, виконуючи це.

Хто повинен створювати чернетки?

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

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