Desain antarmukanya dulu, baru hitung harga pengembangan Aplikasinya!

Pernah dapet kerjaan yang walaupun requirementnya sudah diberikan dengan detail, dalam bentuk FSD, tapi belum bisa berasumsi apapun bakal kayak apa nanti aplikasinya.

Di saat itu jadi “gambling” kalau kita buat proposal penawaran dikhawatirkan meleset dari budget dan time yang disepakati karena alasan di atas.

Bila sudah timbul keraguan seperti itu, maka ada baiknya memisahkan penawaran desain antarmuka dengan penawaran development.

Rekrut-lah designer UI/UX yang berpengalaman. Bila kerjaannya desain UI/UX app mobile maka rekrutlah UI/UX designer yang punya pemahaman dan pengalaman soal design pattern mobile, begitu juga dengan web app maupun progressive web app. Jangan sampe kita rekrut UI/UX designer web untuk mobile app, tau-tau yang didesain itu gak sesuai design pattern Android/iOS, yang ada ntar menyulitkan developer mengimplementasikan desain UI/UXnya.

Biarkan desain UI/UXnya clear dan jadi dahulu, sehingga kita tau ekspektasi klien seperti apa dan goal yang harus dicapai developer.

Pakai designer collaborative tool seperti Zeplin, Figma atau Marvelapp.
Tool ini sangat bermanfaat buat presentasikan desain UI/UX sehingga klien maupun developer dapat gambaran sempurna mengenai UI dan UXnya. Tinggalkan cara lama dengan kirim psd apalagi belum dislicing. Pakai tool design collaborative di atas juga sudah bisa export menjadi assets yang dibutuhkan di mobile app secara instant.
Bila desain UI/UX sudah siap 100%, dengan begitu developer dengan sangat yakin dapat menghitung berapa lama dan berapa biaya yang dibutuhkan untuk pengembangan aplikasi tersebut. Dan skup kerjaan dikunci sesuai desain UI/UX yang sudah disiapkan.

Jadi, apabila ada perubahan desain ataupun tambahan desain pada saat pengembangan aplikasi berlangsung, maka ini akan dianggap sebagai tambahan atau di luar skup yang disepakati.

Bila klien menghendaki sekaligus, maka kita selaku developer memberikan masukan mengapa desain antarmuka dibutuhkan di awal agar nantinya tidak ada yang missed antara yang diharapkan klien dengan apa yang dikerjakan developer.

Menghindari tambal sulam di dalam pengembangan Software

Tadi sore ada pertanyaan soal ini:

Terkadang saya masih bertanya-tanya mas bagaimana sebenarnya desain arsitektur software dan juga database yang baik. Setidaknya, ketika ada pengembangan menjadi lebih mudah utk dikembangkan.
Apalagi kaitannya dengan perubahan atau penambahan struktur database yang terkadang menyebabkan perubahan coding (sering sy alami)

Pertanyaan cukup menarik.

Berdasarkan pengalaman, jangan terburu-buru masuk ke tahap development.

Kekeliruan kebanyakan developer, menurut saya, terlalu prematur tahapan rancangan, langsung lompat ke tahap development.

Saya selalu menghindari hal tersebut, alasannya karena rancangan arsitektur yang tidak matang menyebabkan sistem yang akan dibangun ntar jadi tambal sulam

“eh iya ada yang ketinggalan, tambahin dulu deh tabel databasenya”,

“waduh, ternyata di tabel lama sudah ada kolomnya, apa direfactoring aja ya…”, jadinya njelimet.

Pahami “Design thinking“. Yaitu, ajak tim melakukan brainstorming, duduk bareng mendefinisikan masalah dan scope pekerjaan, kemudian di-breakdown menjadi task-task, dan duduk bareng dengan orang-orang yang biasa mendesain rancangan arsitektur software, mendesain rancangan database, dan mendesain rancangan antarmuka, melakukan coret-coret UML-nya (use case dan activity diagram), bikin physical data model database-nya, dan coret-coret wireframe/mockup desainnya.

Setelah itu, diskusikan lagi bareng-bareng lebih lanjut, ajak juga si klien, sambil jelaskan design flow sistemnya seperti apa, biar kelihatan nanti kekeliruan mendesain arsitektur software-nya di mana, pemilihan teknologi, service yang dipakai, database yang dipakai, nanti kelihatan semua yang perlu dikoreksi di mana.

Biasanya nanti ada sanggahan dari klien..

Misal “saya gak pengen flownya seperti itu, pengennya seperti ini”, nah ini jangan langsung manut, ajak orang UX, kasih tau UX jaman now untuk software yang dibangun kayak gimana, UX di software/aplikasinya seperti apa.

Paling mudah sih, kasih pembanding, pembanding dengan software serupa yang sudah ada di dunia ini, jadi si klien bisa percaya kalau usulan dia keliru.

Dan terkadang ada sanggahan lagi dari klien terkait teknologi, “wah, pake teknologi itu biayanya mahal ya, uang kami tidak cukup”, nah, untuk kasus yang kayak gini, kasih alternatif teknologi yang gratis misalnya atau yang lebih murah lagi, sambil kasih tau apa kekurangannya jika ada.

Kalau misal nanti ketemu kendala, “wah teknologi yang dipakai kalau yang handal sih X, tapi masalahnya belum punya pengalaman soal itu”, nah yang kayak gini harus pandai memposisikan diri “mau rekrut personil yang ahli di teknologi tersebut” atau “alokasikan waktu dengan tim buat mempelajari” (masing-masing ada resikonya)

Pentingnya memahami penamaan “assets” di dalam desain

Apa itu “aset desain” atau Design Assets ?
Aset desain adalah resources tertentu di dalam UI/UX yang digunakan ke dalam proses pengembangan perangkat lunak atau aplikasi.

Apa saja yang termasuk “aset desain”?

Yang termasuk di dalam UI aset desain adalah color palettes(codes/hexa/rgb), styles (tema), icons (icon yang akan dipasang), fonts (font yang digunakan), images (gambar, baik itu background komponen desain, background halaman, banner, gambar header, footer, dsb), animation (animasi transisi halaman), audio (suara ketika klik tombol, dsb), video (video panduan penggunaan software, video iklan) dan setiap elemen yang digunakan untuk memvisualisasikan aplikasi atau software.

Dalam pembahasan kali ini difokuskan mengenai masalah penamaan file, karena ada beberapa kasus di mana designer tidak memberikan nama yang pas untuk assets desain yang ia desain. Alhasil, untuk tracing assets design (misal: icon) ataupun memanggil assetsnya di codingan menjadi membingungkan.

Ditambah lagi, ada beberapa assets design yang nama filenya sama dengan assets design yang lain. Tentu ini akan membuat frustasi developer yang menggunakannya.

Penamaan file di dalam assets design itu sangat penting, itu akan memudahkan designer maupun developer yang akan memindahkan desain ke dalam codingan.

Umumnya, penamaan assets design itu menggunakan prefix, sama halnya dengan penamaan tabel di database, menggunakan prefix atau suffix:
Contoh
ic_email => menandakan ini icon untuk email.
bg_email => menandakan ini background untuk halaman email.
ic_email_selected => menandakan ini icon email ketika dipilih.
ic_email_pressed => menandakan ini icon email ketika ditekan.

Ya, menggunakan prefix ic_ untuk icon, bg_ untuk background, suffix _selected untuk icon yg dipilih, suffix _pressed untuk icon yang ditekan, dan lain sebagainya.

Dan ada pula yang ditaruh ke dalam sub folder tertentu untuk background di dalam folder tersendiri, untuk icon di dalam folder tersendiri, dan lain-lain.

Dengan begitu, manajemen assets design jadi tertata dengan baik 

Pentingnya bagi seorang designer mobile app. memahami “design pattern” dan guidelines desain aplikasi

Waaah…. desainer baru…. begitu dilihat pengalamannya ternyata basic-nya adalah desainer web yang sudah bekerja selama 5 tahun lebih.

Tiba-tiba kebutuhan akan aplikasi mobile begitu tinggi, alhasil beberapa desainer web beralih profesi mengerjakan desain-desain antarmuka aplikasi mobile.

Nah, ada kesalahan fatal yang terjadi, menyebabkan potensi kesalahan di dalam pengembangan, ntah itu timeline menjadi tambah panjang, developer yang menjadi sulit mengimplementasikan desain yang diberikan, dan sebagainya.

Siapapun yang menjadi desainer aplikasi mobile, dimohon jangan samain seperti mendesain website yah..hehe
Desain aplikasi platform apapun itu, baik itu iOS, Android, Windows Phone, Blackberry, ada prinsip-prinsip desain yang harus dipahami, ada guidelines yang harus dipatuhi. Setiap OS mobile punya pattern desain sendiri yang mesti diikuti. Tidak bisa “semau gue, menurut gue itu keren”.

Seorang designer antarmuka aplikasi mobile mesti mendalami pengetahuan seputar perangkat OS platform tersebut, mindset-nya juga harus diubah. Sama seperti pada waktu seorang designer web mendapatkan job dari perusahaan ternama (pernah saya alami di BNI, Jakarta), mereka (BNI…yg saya tau) punya guidelines terhadap website mereka. Misal : Warna tema website mereka.. di guidelines-nya dijelasin hexa codenya apa, logo web-nya pakai yang mana, resolusi “width height“-nya berapa, ukuran hurufnya berapa, pake typeface apa, dan sebagainya..maka terjadilah konsistensi desain di web yang dimiliki perusahaan ternama tersebut.

Begitu juga dengann platform mobile. Antarmuka di aplikasi mobile punya konsistensi, ketika mendesain layout, peletakan menu slalu di sebelah mana, icon aplikasi bentuknya seperti apa, di hape layar kecil resolusinya berapa, di hape layar besar resolusinya berapa, kalo bikin tab taruh di mana, default typeface pake apa, dan sebagainya.

Saya rasa tantangan yg mereka (designer web) hadapi ketika menjadi designer apps adalah bagaimana caranya agar menguasai design interaksi dan UX-nya.

Untuk mengubah sebuah tampilan website menjadi tampilan aplikasi yg mungil, layar terbatas, jangkauan pengguna ketika menyentuh layar bagaimana, dan hal-hal lain yang perlu diperhatikan… bukanlah sebuah pekerjaan yang mudah. Sebagai contoh : ketika mengatur ukuran huruf yang nyaman dibaca pengguna aplikasi, mengatur komponen apa aja yang dapat dijangkau pengguna aplikasi ketika menyentuh layar, dan dari langkah tersebut, desainer masih dibuat pusing lagi ketika menguji hasil karya antar mukanya.

Si desainer sudah merasa yakin mendesain aplikasi di hape layar besar (di atas 5 inch), ternyata di hape layar kecil membuat pengguna kurang nyaman, terkadang mengalami masalah komponen layout-nya oversize di hape layar kecil, terkadang ukuran hurufnya kegedean diterapkan di hape layar kecil, dan masih banyak lagi masalah-masalah yang mungkin terjadi. Dan akhirnya si desainer aplikasi  mencoba mengatur ulang layout-nya.

Dengan kata lain, mau tidak mau si desainer harus menyiapkan beberapa layout design untuk beberapa jenis ukuran layar smartphone maupun tablet (dari ldpi, mdpi, hdpi, xhdpi, sampai dengan xxhdpi).

Seperti yang sudah saya jelaskan, masing-masing perangkat mobile, baik itu smartphone maupun tablet punya UX berbeda. Apalagi beda platform, tentu User Experience di tiap platform berbeda. Pengguna device Android sudah terbiasa melihat menu dengan slide ke kanan atau tap pada pojok kiri dan kanan, sedangkan pengguna device iOS terbiasa dengan menu slide di bawah ke atas, dan berbeda lagi dengan pengguna WindowsPhone, menu disajikan per tab dengan label yang besar di atasnya, tidak ada menu pojok seperti di Android ataupun menu bawah seperti di iOS. Setiap platform punya guidelines-nya bagaimana meletakkan komponen design, seperti yang saya sampaikan yaitu menu, slide menu, tombol, tab, tabel, dan komponen lainnya.

Biasanya, seorang desainer itu melakukan coret2 dulu di wireframe (wireframing), diskusikan dengan tim (ntah dengan desainer web ataupun aplikasi mobile yang lain ataupun dengan developer dan system analyst) apa yang telah di-wireframing sudah pas atau belum, kemudian periksa guidelines di docs platform tersebut apakah sudah sesuai pattern OS tersebut atau belum, kemudian UX-nya bagaimana.. apakah sudah sesuai dengan kebiasaan pengguna di platform tersebut atau belum, setelah itu baru memulai perbaiki designnya agar menjadi tampilan antarmuka aplikasi yang ideal yang siap diimplementasikan ke dalam aplikasi.

Bagi teman-teman yang belum mengetahui guidelines atau panduan mendesain di masing-masing platform mobile, bisa merujuk ke link berikut ini :
Semua udah ditulis lengkap, resmi dan terstruktur, tinggal kitanya mau belajar dengan tekun atau tidak.
iOS : https://developer.apple.com/…/UserExp…/Conceptual/MobileHIG/
Android : http://developer.android.com/de…/get-started/principles.html
WP : https://dev.windows.com/en-us/design

Sekian 🙂