Макети: Кодування проти малювання?

Мова йде не про веб-дизайн, а про дизайн інтерфейсу взагалі. Краще кодувати інтерфейсні макети або "малювати" їх у графічній програмі, наприклад GIMP, Photoshop тощо?

Задайте собі ці питання:

• Скільки макетів / варіантів інтерфейсу можна вивчити за 30 хвилин, кодуючи? Скільки ви можете дослідити, замальовуючи?

• Як часто ви отримуєте дизайн інтерфейсу точно під час першої спроби? Якщо не дуже часто, наскільки швидко / легко змінити ескіз проти кодованого макету?

• Чи можете ви миттєво визначити колір, просто подивившись на його шістнадцятковий / rgb-код (не лише здогадку про бальний парк, а точний відтінок / колір)? Коли ви малюєте кольором у своїй свідомості, чи можете ви негайно перевести це на шестигранний? Наскільки швидко ви можете вибрати колірну гамму, ввівши шістнадцяткові коди порівняно з реальним кольором?

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

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

Я б голосував за "малювання" першим. У графічному інтерфейсі ключовим є правильний макет / презентація, який вимагає розробити наочні засоби. Проектування графічного інтерфейсу дозволяє візуально змінювати дизайн, не потребуючи "уявляти" кожну зміну, "переводити її в код" і, нарешті, перевіряти її. Інший спосіб також можливий, але він рідко кращий (наприклад, проект надзвичайно малий, як-от пара кнопок, і ви знайомі і звикли працювати на рівні «коду»; під час проектування можуть з’явитися деякі шаблони, які можуть бути просто повторне використання з незначною модифікацією).

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

Для дизайну інтерфейсу у мене є три етапи з різними цілями:

1. Ескіз. По-перше, ви хочете скласти основне уявлення про те, які елементи будуть і як вони впишуться разом. Будь-яка дрібна деталь чи естетичний перфекціонізм на цьому етапі - це відволікання. Я використовую дошку та ручку для стирання жиру, тому неможливо відволіктися на занадто багато деталей та легко писати набори різних ідей та починати заново в будь-який час. Я чув про людей, які лише ескізують невеликі нотатки після публікації або користуються лише їх рукою (наприклад, лівою рукою, якщо ти правою рукою), щоб змусити себе взагалі не звертати ніякої уваги на естетику та зосереджуватись на 100% на ідею та функцію. (зображення не моє, від Frank Prendegast )

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

3. (3!) Реалізація. Нарешті, ви реалізуєте річ і прагнете зробити це таким чином, що дозволяє отримувати більше відгуків рано та часто.

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

Це запитання дещо розпливчасте і як таке відповіді.

Крім того, проекти будуть різко відрізнятися, як і команди.

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

Взагалі кажучи, я б сказав, що це тип робочого процесу, на який слід прагнути:

1. Ескіз. Олівець + папір. Дошки. Ітерація. Працюйте з якомога більше членів команди.
2. макет з низьким рівнем фантастики. Може бути PSD, може бути visio. Може бути папір. Користувач тестує їх.
3. Приступайте до побудови прототипів. Саме тут ви хочете почати робити якомога більше робочого коду. Переходьте до Photoshop, як вам потрібно, і отримайте речі з нього в код якомога швидше. Продовжуйте тестування / ітерацію користувача.

Для мене працює створення макетів за допомогою програми, яка підкреслює не створення макетів, ідеальних для пікселів. Для мене це макет Balsamiq, який ви можете перевірити за посиланням http://www.balsamiq.com/products/mockups