RSS

Tag Archives: wireframe

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 πŸ™‚

 
Leave a comment

Posted by on November 2, 2015 in Android, Design

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , ,

Seputar Manajemen Proyek (bag.1)

Q : Jika misal klien kita sebuah perusahaan, nah masalah tarifnya gimana? Tarifnya menyesuaikan besarnya company gak? Misal perusahaannya itu perusahaan baru dan yang lagi berkembang skala nasional, kan income mereka juga beda gitu. Gimana mas?

A : masalah tarif proyek TI itu ada beberapa pertimbangan :

  • Ketersediaan infrastruktur untuk lingkungan implementasi.
  • banyaknya personil yang terlibat dalam pengembangan sistemnya + beban job descnya (manajerial & staff teknis & staf pendukung).
  • milestone pekerjaan systemnya (apa saja yang dikerjakan dan berapa lama waktunya (timelineny).. nah ini ada penjelasannya lagi).
  • Teknologi yang dipakai.

Dan itupun tidak menyesuaikan besarnya perusahaan kok.

Q : oh, brarti menentukan harga memang tahapnya banyak juga ya…hehe…oh, trus klo kliennya personal/individu gimana, mas? Kan tarifnya mesti beda sama klien company ya?

A : Banyak.. dan semuanya tertulis. Jadi pihak vendor dan pihak client jelas. Tetapi terkadang juga sulit diterapkan hal tersebut, apalagi dari clientnya yg “kotor”, itu yg gawat, biasanya mereka memang mengadakan apa gitu (tender), buat menghabiskan anggaran belanja saja, tanpa keperluan dan tujuan yang jelas, akhirnya useless. Hehehe..tetapi tidak semua begitu. Hanya sedikit. Dan kalau bisa ya mending dihindari. πŸ˜€
Kalau clientnya personil, liat skala pengerjaannya juga, apakah besar atau kecil? Jika kecil, tidak serumit seperti yang dijelaskan di atas.

Biasanya meliputi hal berikut :

  1. biaya hosting, domain, dll (adakah?)
  2. Milestone pekerjaan perangkat lunaknya
  3. Teknologi yang dipakai, biasanya semakin baru maka semakin bagus
  4. Tidak dikenai pajak, karena ratenya rendah πŸ˜€

Walau personil/pribadi atau proyek bersama, keduanya mesti ada kontrak tertulis, dan jangan lupa, kasih aturan, terutama menghindari client yang hobi telat bayar, kalo telat = denda. Haha πŸ˜€

modelnya ada 3 loh :

  1. Tender (jadi si client sudah punya harga, sudah menentukan jumlah personil yang harus disediakan)
  2. Dari permintaan (permintaan client ke kita, via pribadi atau via vendor)
  3. Dari penawaran (kita yang menawarkan diri ke client)

nah, untuk no.1 ada tata urutannya. Biasanya sebagai berikut :

  1. Opening project (meeting internal) dgn client, rapat, dengerin user stories – ini siapin analyst dan team dokumentasi (buat nyatet+dokumentasiin) dan PM.
  2. Breakdown keperluan app yg mau dibuat.
  3. Dokumentasi dibuat secara rapi sesuai format, terus diperiksa oleh client apakah sudah benar dan sesuai belum.
  4. Kalo no.3 sudah, tinggal system architecture (db+server), system analyst yg kerja.
  5. Kerjaan si no.4 dikasih ke pimpinan developer (lead programmer atau supervisor) dan dijelaskan jg ke designer UInya.
  6. Rapat lagi ke programmer, jelasin job descnya, negosiasi harga, blablabla..ini agak panjang jg.
  7. Masuk masa implementasi.
  8. PM control pekerjaan beserta analyst bantu ngarahin biar kerjaan programmer terarah.
  9. Closing project, dokumentasi akhir, dll.

Q : Oya satu lagi, cuma pengen tau pembagian gaji tiap orang. Misal : utk proyek diatas PM dapet berapa trus analyst berapa, programmer, dst…itu juga masih kurang tau aku πŸ™‚

A : Lebih detailnya malah bisa berlembar-lembar hahaha. Intinya masih sama dengan yang diajarkan di RPL, walau sebenernya ada beberapa yg “basi” sudah ditinggalkan, kayak model “waterfall” dan masalah user testing.

  • PM tanggung jawab 100% kegiatan
  • Analysis itu component pekerjaannya 20% dari seluruh kegiatan,
  • Dokumentasi+testing itu 20% juga dari seluruh kegiatan
  • Programmingnya 60% dari seluruh kegiatan (makanya kerjaan programmer itu banyak daripada analyst LOL)

Tapi kenapa dari setiap personil, bobot pekerjaan sedikit, namun gajinya lebih besar? Ya, sebagai contoh Analyst terhadap Programmer, terlihat karena tanggungjawab, tingkat pemahaman serta tingkat stressnya lebih tinggi daripada programmer πŸ˜€

Nah, masalah hitung menghitung masing-masing personil+job desc-nya. Tergantung kesepakatan dan kebijakan si PM (project manager) dan si pemilik vendor dan bagian keuangannya. Ada beberapa perusahaan, yang mewajibkan setiap investasi harga proyek dari client itu 25%-nya masuk ke kas perusahaan. Jadi misal, kalo 25% dari harga proyek itu sudah PASTI masuk kas perusahaan, maka yg didapet personil adalah 75% dari harga proyek. Kenapa? demi kemajuan perusahaanlah πŸ˜€ dan juga penggajian karyawannya. Nah, harga personilnya di-breakdown lagi.

Ini personilnya ada yang outsourcing atau dari pegawai sendiri? πŸ˜€ Sayangnya kalo pegawai sendiri itu hitungannya gaji.. jadi agak sedikit rugi, namun untungnya pas tutup buku akhir tahun biasanya.

Sedangkan outsourcing, itu dibagi lagi, apanya? dia posisinya apa? analyst, bisa dapet sekitar 15%-20% dari harga proyek, kalo programmer (total loh..jadi kalo ada 6 ya dibagi 6 aja) itu sekitar 30%-40%. Tapi masing-masing punya kebijakan berbeda-beda.

Q : Ada tips-tipsnya gak mas mengenai proyek agar aplikasi yang kita kembangkan mendekati keinginan user?

A :

tipsnya :
punya “koneksi” + “komunikasi” yang bagus, mas πŸ™‚ Dan dengan koneksi dan komunikasi yang bagus, tentunya kita dapat memahami bagian “user stories” dengan baik, mulai dari bagian manajerial sampai ke teknisnya. Semua itu kita bagi menjadi bagian kerangka acuan kerja, timeline, wireframe kemudian milestone dan kemudian kita bagi lagi menjadi lebih spesifik menjadi tasks yang akan dikerjakan oleh programmer.

Untuk masalah koneksi, sedia link di mana-mana, bahkan di luar kota sekalipun, artinya mas wajib punya relasi dan partner yang bener-bener se-visi. Agak susah memang, itu dari pengalaman soalnya. Kalau sudah bagus koneksinya, biasanya akan dapat rekomendasi dari mana-mana : “eh, dia itu bagus loh..buat ngerjain ini, coba contact dia” dan “blablabla..” spt itu πŸ™‚

Apalagi urusan SDM, karena koneksi yang kita maksud di sini adalah ketersediaan SDM, jika salah pilih, gk akan maksimal hasilnya.

Masalah investasi, ada tolak ukur sendiri-sendiri c..jadi tepat jg mengukur apa saja beban personil dan berapa besar biayanya.

Jangan jg “membodohi” personil, apalagi urusan investasi ini.

Mengenai masalah teknologi yg dipakai, hmm..kebanyakan pakai framework c mas, lebih enak buat pelebaran dan bongkar pasang, kalopun pake CMS juga bisa. πŸ™‚

Nah urusan timeline (waktu), ada banyak hal yg harus diperhatikan dan sepakati bersama dengan si Client.
Jangan sampai salah satunya melanggar atau mengulur waktu, dan konsistensi ini perlu ada perjanjian di atas kertas.

Dan bagi temen-temen yang butuh template dokumen business plan, kerangka acuan kerja, dan lain-lain untuk startup ataupun proyek, bisa mampir ke link : <a href=”http://www.businessinsider.com/document-center”>ini</a&gt; πŸ˜€

 
1 Comment

Posted by on December 19, 2011 in Hilarious

 

Tags: , , , , , , , , , , , , ,