Sebenarnya Apa itu "Deliverable"?

"Deliverable". Sebuah konsep sederhana yang mudah untuk dipahami (sesuatu yang kamu "sampaikan"P), namun sulit untuk dijelaskan dengan benar.

Salah satu cara untuk menjelaskan deliverable bisa jadi seperti potongan pekerjaan atau sebuah artifak yang merupakan gabungan dari pekerjaan kelompok yang lebih besar. Contohnya: sebuah sitemap, model navigasi, dan pencarian definisi. Semuanya berada dalam satu payung dari "arsitektur informasi". Untuk memformalkan deliverable ini bisa jadi ada sebuah dokumen yang mangandung semua dokumen tersebut dan sebuah lembar cover dengan bebera informasi versi.

Lebih lanjtu lagi, artefak dan deliverable bisa jadi berdiri sendiri maupun saling menggantikan. Sebuah bingkai gambar, sebagai contoh, bisa digunakan sebagai deliverable dalam sebuah proyek untuk menunjukkan seorang manajer bahwa kamu melakukan peningkatan, menyediakan pengembang informasi mengenai struktur yang dibutuhkan, atau mengumpulna pembayran dari klien.

Hal penting yang perlu diambil adalah bahwa deliverable bukanlah sesuatu yang perlu dilakukan demi output. Namun, untuk menyediakan kejelasan yang lebih besar atau membawa proyek mendekat ke keadaan yang diinginkan. Jadi, penting untuk berpikir secara kritis mengenai kenapa kamu membuat sebuah deliverable dan pada tingkat formalitas apa karena di sana terdapat potensi untuk membuang waktu yang sangat banyak!

Siapa Penontonmu?

Deliverable memiliki penonton, dan terkadang ada kelebihan seperti yang ditunjukkan oleh Diagram Venn di bawah. Memahami bahwa penonton adalah tahap pertama yang penting untuk memahami kebutuhan deliverable dan tingkat formalitas yang mungkin dibutuhkan.

Manajer Produk

Umumnya, manajer produk atau manajer internal manapun akan sangat tertarik pada frasa penemuan dan definisi. Ini adalah kebutuhan dan proses bisnis sedang diiris-iris dan produk sedang di definisikan. Maka, jika mereka meminta beberapa perwakilan dari tampilan lini produk nantinya. Akan jadi lebih baik untuk memberikan sketsa tangan dari beberapa layout, ketimbang menghabiskan waktu mengetik prototipe untuk contoh.

Pengembang

Pengembang ditugasi dengan program yang telah ditemukan, didefinisikan dan di desain ke perwakilan akhir melalui kode. Di sini ada banyak salah intepretasi mengenai maket. Layout apapun yang disampaikan ke tim pengembang harus sempurna dan spesifikasinya perlu dibuat, karena kebanyakan pengembang akan membuat persis seperti yang kamu minta, terutama jika mereka adalah sebuah outsourced tim!

Klien

Dalam kasus klien, deliverable mungkin perlu untuk dipoles dan disajikan sebagai alat pemasaran (untuk menunjukkan sebarapa bagus agensinya). Terkadang kamu akan menggunakan deliverables untuk mempengaruhi stakeholder eksternal, atau dalam bagian rapat perjanjian kontraktual saat kamu bekerja dengan "milestone payment structure".

Di Jenis Lingkungan Apa Kamu Bekerja?

Penonton tidak hanya memainkan bagian besar dari bagaimana sebuah deliverable harus dibuat. Namun juga struktur dari organisasinya. Tidak ada yang tetap konstan, bahkan dalam struktur yang sama (seperti perusahaan konsultasi); deliverable bisa berganti dari proyek ke proyek. Deskripsi berikut adalah generalisasi, tapi bagus sebagai titik awal jika kamu memiliki kesulitan dalam mencincang jenis keluaran apa yang akan diperlukan.

Gigs Konsultasi dan Agensi Digital

Deliverable lebih sering jadi bagian penting dalam lingkungan ini semenjak tujuan bukan hanya untuk membuat proyek terlaksana namun juga mendidik klien dan memastikan bahwa mereka kagum dengan deliverable. Secara efektif, dia akan memastikan kembali pada klien bahwa mereka telah membuat pilihan yang tepat kepadamu ketimbang kompetitormu.

Ini penting dalam tahap tender ketika beberapa konsultan berkompetisi untuk pekerjaan yang sama. Namun, tetap ingat ada beberapa hal lain yang klien pikirkan saat melakukan seleksi seperti biaya, sumber daya dan lain-lain.

Hackathon

Deliverable dalam "hackathon" dibuat dengan tujuan untuk ditampilan pada panel juri. Di sana bisa ada slight deck, dan kamu bisa menampilkan beberapa storyboard dan product roadmaps. Segala yang akan memicu emosi, mengkomunikasikan resolusi masalah dan resolusi terhadapnya. Dan mendemonstrasikan visi yang jelas selangkah lebih maju! Ini mungkin bukan kasus dari sebuah prototipe yang telah dikembangkan penuh, kecuali kamu mempunyai anggota di tim yang mampu melakukannya.

Gigs Pekerja Lepas

Dalam pengalaman saya, gigs pekerja lepas (terutama yang online) lebih sering dalam lingkup yang sangat kecil. Biasanya berupa "Maket dibutuhkan untuk aplikasi X" atau "Laporan kegunaan untuk situs X". Deliverable ini digunakan untuk menandai penyelesaian ketimbang perkembangan dan sering dikaitkan dengan pembayaran puncak.

Start Up

Deliverable start berfokus disekitar penemuan, validasi dan defnisi, sebagai wirausaha yang berusaha meretakkan pasar. Desain juga penting dan deliverable di dalam fase perbaikan proyek akan berputar di sekitar pemikiran ide dan pembuatan perubahan seiring dengan umpan balik dari pengguna dan stakeholder awal.

Tim Produk

"Tim Produk" yang saya acu adalah sebuah perusahaan yang memiliki satu atau lebih produk digital dan pegawai internal. Tim ini biasanya menggunakan deliverable di akhir proses. Mereka mungkin lebih rendah dalam kesetiaan, kecuali ketika manajer produk butuh untuk mengkomunikasikan paket informasi ke eksekutif. Tiap deliverable cenderung berarah ke fase berbeda dari proses UX.

Deliverable dalam Proses UX

Deliverable bisa juga ada di beberapa fase dalam proses desain UX:

• Penemuan
• Definisi
• Desain
• Perbaikan

Seperti yang kamu lihat, sebelumnya di dalam proses terdapat lebih banyak deliverable seiringi projek dimulai secara luas dan terdapat kerja ekstra dihabiskan dalam perencenaan dan mencoba mengidentifikasi hal yang tepat untuk dikerjakan. Model ini mungkin paling dapat diterapkan pada tim produk dan terdapat banyak penyebrangan posisi selama dua fase pertama. Pendesain UX, Manajer Produk, dan Analis Bisnis bisa jadi berkolaborasi dalam peta perjalanan pelanggan, sebagai contoh.

Kenapa Mebuat Deliverable?

Kenapa membuat deliverable, seperti didaftar di atas, dia kontekstual. Alasannya tergantung kedudukan, jenis organisasi, penonton, dan banyak faktor lainnya. Berikut adalah lima alasan paling umum untuk membuat deliverable:

1. Untuk memenuhi kewajiban kontraktual.
2. Untuk menandai perkembangan
3. Untuk mempengaruhi orang.
4. Untuk membuat hal lebih jelas dan memindahkan proyek lebih dekat ke tujuan.
5. Untuk membuat proses yang tidak terlihat menjadi lebih terlihat dengan beberapa output.

Pendekatan pribadi saya adalah untuk menjaga bagian depan dan tengah dari proses saya di deliverable seperti persona, prototipe, dan wawancara pengguna. Saya menyimpan yang kurang biasa disekitarnya seperti; grup fokus dan domain model.

Saya juga suka menelusuri deliverables yang belum pernah saya dengar sebelumnya. Ada banyak metode berbeda di luar sana. Ini bisa memberimu perspektif yang lebih luas dan membuatmu menjadi desainer yang lebih baik dalam menambah beberapa deliverable ke alur kerjamu.

Kesimpulan

Baik itu sudah mencakup hal-hal mengenai deliverable! Berikut beberapa detil untuk diingat:

• Artefak biasanya sejumlah diagram yang dimasukkan dalam sebuah payung yang lebih besar. Namun, sebuah artefak bisa juga berdiri sebagai deliverable sendiri (seperti sebuah prototipe interaktif).
• Artefak dan deliverable ada sebuah cara untuk mengkomunikasikan desain dengan stakeholder internal dan eksternal, dan mengelaborasikn visi. Mereka mengkomunikasikan solusi potensian untuk tantang dan masalah yang dihadapi desainer tiap hari.
• Deliverable harus tidak dibuat demi output, tapi sebagai sebuah cara untuk membuat produk akhir dan mencapai tujuan yang ditentukan.
• Fase dari proyek bisa jadi indikator yang baik mengenai kapan harus menggunakan tiap deliverable, tapi jika ragu kamu harus mengacu kembali ke cakupan proyek dan berhati-hati terhadap beberapa deliverable yang paling sering digunakan dari yang lainnya!
• Deliverable disesuaikan terhadap stakeholder tertentu (biasanya manajemen, pengembang, dan klien eksternal). Mereka bisa digunakan untuk grup tersebut, tapi tingkat relevansinya bisa berbeda-beda.
• Desainer perlu memberi petunjuk dengan orang yang bekerja sama. Baik itu pengembang, agensi kolaboratif, maupun stakeholder lainnya.
• Kejelasan adalah hal penting. Kita menggunakan banyak diagram atau deliverable untuk menyalurkan ide.
• Deliverable bisa jadi puncak untuk menandai perkembangan. Tapi lebih utamanya, mereka harus menjadi cara untuk menyalurkan sebuah ide konsep.