Mockups: Pengodean vs Menggambar?

9

Ini bukan tentang desain web tetapi tentang desain antarmuka secara umum. Apakah lebih baik untuk memberi kode Antarmuka Maket atau "menggambar" mereka dalam program grafis, seperti GIMP, Photoshop, dll?

website-design  interface-design  design-process 
— Christopher
sumber
3
Saya selalu diberi tahu "sketsa antarmuka Anda, jika Anda melakukannya di photoshop atau apa pun orang akan berpikir Anda lebih jauh dari Anda sebenarnya. Biarkan maket Anda terlihat samar, hanya turunkan dasar-dasarnya sehingga klien Anda tahu apa yang diharapkan dan kemudian memperluas di UI Anda nanti. "
— Hanna
1
Itu sepenuhnya tergantung pada proyek. Tidak ada jawaban 'terbaik' universal.
— DA01

Jawaban:

14

Tanyakan pada diri Anda pertanyaan-pertanyaan ini:

  • Berapa banyak tata letak / opsi UI yang dapat Anda jelajahi dalam 30 menit dengan coding? Berapa banyak yang bisa Anda jelajahi dengan membuat sketsa?

  • Seberapa sering Anda mendapatkan desain UI tepat pada percobaan pertama? Jika tidak terlalu sering, seberapa cepat / mudah mengubah sketsa versus maket kode?

  • Bisakah Anda secara instan mengidentifikasi warna hanya dengan melihat kode hex / rgb (bukan hanya dugaan kasar, tetapi warna / warna yang tepat)? Ketika Anda menggambarkan warna dalam pikiran Anda, dapatkah Anda segera menerjemahkannya ke hex? Seberapa cepat Anda bisa memilih skema warna dengan mengetikkan kode hex dibandingkan menggunakan color picker nyata?

Fakta bahwa Anda mengajukan pertanyaan ini memberi tahu saya bahwa Anda kemungkinan besar adalah seorang programmer, bukan seorang desainer, melalui pelatihan. Jika Anda seorang desainer, maka akan sama absurdnya dengan mengembangkan aplikasi tanpa merencanakan struktur kelas, desain basis data, arsitektur aplikasi, dll. Dan langsung beralih ke pengkodean — dan jika Anda adalah pengembang yang berpengalaman, maka Anda tahu masalah apa yang menyebabkan pengembangan bottom-up semacam ini.

Demikian pula, jika Anda langsung melompat ke kode tanpa benar-benar merancang UI Anda terlebih dahulu, maka hasilnya tidak akan cantik, jika hanya karena tidak praktis untuk menyempurnakan desain yang baik dengan pengkodean secara membabi buta.

— Lèse majesté
sumber
OP dapat berbicara tentang menggunakan editor kode WYSIWYG, dengan itu Anda dapat memilih warna atau bahkan "menggambar" objek ...
— jackJoe
2
Sebenarnya, coding tanpa mendesain UI terlebih dahulu adalah teknik yang cukup valid. Itu, tentu saja, jika "coding" tidak berarti bagian UI atau UX :). Sebagian besar API dan pustaka dirancang sebenarnya tanpa memperhitungkan UI - itu tidak praktis.
— thebodzio
1
@lese, Anda melempar metode air terjun. Yang mungkin OK, tetapi tren hari ini adalah untuk menjadi gesit, di mana sangat mungkin bahwa Anda bekerja dalam kode dari hari pertama.
— DA01
@ DA01: Anda mengerjakan kode sejak hari pertama, tetapi Anda masih menerapkan metodologi top-down. Tidak ada yang gesit yang mengatakan Anda tidak dapat merencanakan arsitektur data Anda atau mendefinisikan UI-terlebih dahulu sebelum pengkodean (yang saya pikir sebagian besar perusahaan gesit lebih suka daripada UML, diagram kelas, dll.).
— Lèse majesté
2
@thebodzio: Ya, tentu saja, untuk itulah pemisahan kekhawatiran itu. Tapi saya tidak mengacu pada pengkodean backend. Ketika saya mengatakan coding dalam hal merancang bagian dari pertanyaan (bukan analogi pemrograman yang saya gunakan untuk menggambarkan hal ini - saya tahu, sedikit membingungkan), maksud saya coding mockup (CSS + HTML atau apa pun bahasa UI Anda mungkin ).
— Lèse majesté
5

Saya akan memilih "menggambar" terlebih dahulu. Dalam GUI, tata letak / presentasi yang tepat adalah kuncinya dan membutuhkan sarana visual untuk dirancang. Merancang GUI secara visual memungkinkan Anda dengan cepat mengubah desain Anda tanpa harus "membayangkan" setiap perubahan, "menerjemahkannya ke kode" dan akhirnya mengujinya. Cara lain juga mungkin, tetapi jarang lebih baik (misalnya proyek sangat kecil, seperti hanya beberapa tombol dan Anda terbiasa dan terbiasa bekerja di tingkat "kode"; selama desain beberapa pola mungkin muncul, itu bisa saja digunakan kembali dengan sedikit modifikasi).

Jika Anda mendesain untuk widget alat tertentu, Anda juga dapat menggunakan beberapa aplikasi "perancang GUI" jika tersedia. Ini akan mempercepat lebih banyak proses desain GUI, karena keduanya menunjukkan persis bagaimana desain GUI akan terlihat seperti dalam menjalankan program dan dapat mengekspor siap untuk menggunakan deskripsi GUI di tingkat presentasi.

— thebodzio
sumber
2
"dan Anda terbiasa dan terbiasa bekerja di" level "kode" -> Penting bahwa tim UI / UX dapat bekerja di level kode. Setiap desainer tidak harus menjadi seorang pembuat kode, tetapi tim harus mampu membangun semua yang mereka desain dan memahami teknik sebanyak desain visual.
— DA01
Saya bisa setuju selama yang Anda maksud adalah tim secara keseluruhan. Saya berpikir bahwa, ketika Anda hanya mendesain UI / UX, bukan mengkodekannya, pengetahuan tentang cara kerja kode sebenarnya dapat menghambat Anda, karena Anda akan cenderung menghindari beberapa solusi potensial hanya karena Anda akan menganggapnya "terlalu sulit untuk melaksanakan". Ini berarti bahwa desain Anda dapat dilucuti dari beberapa ide cemerlang, karena "pemikiran toolkit" akan mengunci bagian dari imajinasi Anda. Kemudian lagi ... itu hanya satu sisi pisau :) Selain itu, pertanyaannya adalah tentang "mock-up" saja.
— thebodzio
1
Saya sering mendengar argumen 'menahan Anda', tetapi mendapati itu hanya datang dari desainer visual yang keras kepala menentang pembelajaran kode lapisan presentasi. Orang-orang ini juga cenderung melayang ke arah melakukan segala sesuatu di Flash. :) Saya ingin menyarankan bahwa tidak ada bedanya dengan desain cetak. Mengetahui cara kerja pencetakan tidak 'menahan Anda' sebagai desainer cetak. Sebaliknya, itu mencegah Anda membuat file yang akan mencekik RIP, atau menyebabkan printer berteriak pada Anda untuk cakupan tinta 300%. Ini hanya tentang memahami medium dan kendala terkaitnya.
— DA01
1
WYSIWYG bukan untuk memfasilitasi 'pemikiran visual'. Ini untuk membiarkan orang yang tidak ingin mempelajari sesuatu yang pincang. ;) Adapun kendala, mereka mendefinisikan media. Seorang arsitek yang dapat menggambar gambar-gambar hebat, tetapi tidak memahami dasar-dasar beban dan bentang sangat ditahan ... karena tidak ada yang mereka gambar yang dapat dibuat.
— DA01
1
(dan banyak pendapat saya telah dibentuk bekerja baik dengan atau di tim UX yang tidak tahu bagaimana membangun apa pun yang mereka buat. Mereka tidak berinovasi sebagian besar waktu ... melainkan merancang hanya setengah dipikirkan solusi yang tidak praktis dalam hal implementasi, jadwal, pengguna, atau anggaran [yang semuanya merupakan kendala tambahan, alih-alih menjadi 'tembok' yang membantu menentukan solusi desain]) PS: diskusi yang baik!
— DA01
3

Untuk desain UI saya memiliki tiga tahap dengan tujuan yang berbeda:

  1. Membuat sketsa. Pertama, Anda ingin mendapatkan ide dasar dari elemen apa yang akan ada dan bagaimana mereka akan cocok bersama. Setiap detail halus atau perfeksionisme estetika pada tahap ini adalah gangguan. Saya menggunakan papan tulis dan pulpen yang bisa dihapus sehingga tidak mungkin teralihkan oleh terlalu banyak detail dan mudah untuk mencoret-coret banyak ide yang berbeda dan mulai lagi kapan saja. Saya pernah mendengar tentang orang yang hanya membuat sketsa pada kertas post-it kecil atau hanya menggunakan tangan mereka (misalnya tangan kiri jika Anda kidal) untuk memaksa diri mereka sendiri untuk tidak memperhatikan estetika dan fokus 100% pada ide dan fungsi. (gambar bukan milikku, dari Frank Prendegast )

Foto bingkai foto papan tulis

  1. (2!) Mensimulasikan.Kedua, Anda ingin melihat ke bawah dan mendapatkan umpan balik, mencari tahu sebanyak mungkin tentang intuisi orang-orang dan tanggapan tanpa kompromi sebelum Anda memulai pekerjaan implementasi yang memakan waktu. Ini harus dalam apa pun yang Anda kerjakan paling efisien karena jika Anda melakukannya dengan benar, Anda harus sering 'kembali ke papan gambar', mencari kritik dan bertujuan mengidentifikasi sebanyak mungkin masalah tak terduga sedini mungkin. Jika Anda adalah mesin pengkodean gila dan ini adalah pekerjaan yang paling nyaman bagi Anda, maka pengkodean baik-baik saja, tetapi kebanyakan orang akan bekerja lebih cepat dalam hal-hal seperti Fireworks, Photoshop, perangkat lunak wireframing khusus, atau mungkin pembangun antarmuka berbasis-UI seperti Flash Catalyst (baik jika produk akhir bukan Flash, tujuannya adalah untuk mendapatkan umpan balik yang baik sebelum Anda memulai implementasi).

  2. (3!) Pelaksana. Akhirnya, Anda menerapkan hal itu dan bertujuan melakukannya dengan cara yang memungkinkan Anda mendapatkan lebih banyak umpan balik lebih awal dan sering.

Ketiga bagian dari siklus proyek ini memiliki tujuan yang berbeda, jadi jika ini adalah proyek besar, masuk akal untuk menggunakan alat yang paling cocok untuk pekerjaan di setiap tahap.

— user56reinstatemonica8
sumber
2

Pertanyaan ini agak kabur dan, karena itu, seperti jawabannya.

Selain itu, proyek akan sangat bervariasi, seperti halnya tim.

Konon, tidak ada yang 'terbaik'. Ini tentang menggunakan semua alat dalam alur kerja yang paling masuk akal untuk Anda dan tim Anda.

Secara umum, saya akan mengatakan ini adalah jenis alur kerja yang harus Anda tuju:

  1. Sketsa. Pensil + kertas. Papan tulis. Pengulangan. Bekerjalah dengan sebanyak mungkin anggota tim.
  2. mock-up rendah fi. Bisa jadi PSD, bisa berupa visio. Bisa jadi kertas. Pengguna menguji ini.
  3. Dapatkan untuk membuat prototipe. Di sinilah Anda ingin mulai melakukan sebanyak yang Anda bisa dalam kode kerja. Langsung ke Photoshop yang Anda butuhkan dan dapatkan barang-barang itu ke dalam kode secepat mungkin. Lanjutkan pengujian / iterasi pengguna.
— DA01
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.