Dokumentasi Lebih Baik Dan Komunikasi Tim Dengan Dokumen Desain Produk

Diterbitkan: 2022-03-10
Ringkasan cepat Pernahkah Anda kesulitan mendapatkan lampu hijau untuk proposal desain Anda? Apakah Anda merasa proses desain Anda perlu diformalkan? Apakah era COVID19 menjadi tantangan bagi Anda ketika bekerja jarak jauh sebagai desainer? Kemudian lanjutkan membaca untuk mengetahui metodologi untuk mendokumentasikan proses desain Anda di artikel ini.

Proses khas untuk bekerja sebagai desainer produk di perusahaan atau startup mungkin sudah tidak asing lagi bagi Anda: sebuah produk baru sedang dikembangkan untuk memberikan solusi desain. Kemudian Anda mengerjakan beberapa proposal desain dan Anda mengajukannya di depan 1-3 orang untuk mengumpulkan umpan balik.

Terkadang proses ini bekerja dengan baik, tetapi di lain waktu tidak. Misalnya, beberapa orang sibuk memperhatikan untuk menyelesaikan tugas mereka sendiri dan tidak menghabiskan cukup waktu untuk memberikan umpan balik yang jelas dan ringkas untuk proposal desain Anda.

Mungkin juga terjadi bahwa meskipun proses Anda bagus, Anda masih ingin memformalkan proses dengan menuliskan keputusan, melacak iterasi, dan proses desain secara umum, terutama di masa sekarang di mana kita mendapati diri kita bekerja dari jarak jauh karena COVID19.

Mendokumentasikan proses memiliki banyak manfaat. Misalnya, membuat pekerjaan Anda lebih terlihat, menciptakan peluang untuk mendapatkan umpan balik dari lebih banyak orang, meningkatkan komunikasi secara keseluruhan, dan memberikan gambaran yang jelas tentang bagaimana fitur dirancang dengan semua konteks dan pertimbangan di sekitarnya.

Kejatuhan Desainer Pahlawan

Sekitar tahun 2018, saya bekerja sebagai Perancang Produk jarak jauh dari Madrid di sebuah perusahaan yang beroperasi di Amerika Latin, yang dalam proses ini melibatkan tim lain dari Meksiko dan Sao Paulo, Brasil.

Lokasi peta jarak jauh
(Pratinjau besar)

Sebelum saya mulai bekerja di perusahaan ini, saya memiliki banyak pengalaman berbeda dalam karir saya bekerja di lingkungan kecil dan besar dari berbagai sektor seperti media berita, studio desain, jejaring sosial, OS seluler, mendirikan startup e-grocery , dan bahkan melakukan beberapa pertunjukan lepas dengan perusahaan rintisan kecil lainnya.

Selama tahun-tahun itu saya telah mengikuti pendekatan yang sama, Anda membuat beberapa orang duduk di ruangan yang sama, mengajukan solusi Anda, memberikan beberapa layar, mengalir, mendapatkan umpan balik, dan menyajikannya lagi. Setelah beberapa iterasi, pekerjaan Anda akan siap untuk mencapai fase pengembangan.

Namun, pendekatan yang sama ini berhenti bekerja. Tak lama setelah bergabung dengan tim, saya menyadari bahwa hanya menampilkan desain saya di video call saja tidak cukup. Saya membuat banyak proposal, tetapi saya tidak dapat mencapai persetujuan akhir dari pemangku kepentingan dan rekan tim saya. Saya bingung dan terus bertanya pada diri sendiri: Apa yang terjadi? Bukankah saya merancang solusi terbaik? Bukankah saya memberikan pekerjaan yang berkualitas baik? Setiap pertanyaan itu membuatku kehilangan kepercayaan diri. Masalahnya adalah saya perlu menyesuaikan proses saya dengan lingkungan ini.

Lebih banyak setelah melompat! Lanjutkan membaca di bawah ini

Segera setelah saya menyadari bahwa proses saya tidak berhasil, saya mulai membaca banyak artikel tentang cara bekerja sebagai desainer jarak jauh, efek burung camar (ketika seseorang masuk ke pekerjaan Anda, mengkritiknya dengan kasar dan kemudian pergi), bagaimana perusahaan lain mendekati kolaborasi jarak jauh, dan bagaimana mereka memformalkan proses mereka dengan menuliskannya. Setelah membaca semua materi ini, saya bertanya-tanya bagaimana pengembang menghadapi masalah yang sama? Bagaimana mereka berkolaborasi di lingkungan yang jauh dengan cara yang hampir tidak sinkron? Bagaimana mereka mencapai kesepakatan akhir? Saya menemukan bahwa faktanya, komunitas pengembang telah memiliki proses yang bekerja cukup baik untuk mereka: Ini disebut permintaan tarik.

tarik-permintaan
(Pratinjau besar)

Permintaan tarik memungkinkan Anda memperkenalkan perubahan dalam basis kode yang lebih besar dengan mendokumentasikannya dan memvalidasi keputusan Anda dengan umpan balik orang lain. Dengan cara ini, perubahan yang Anda perkenalkan berpadu sempurna dengan semua standar dan koneksi yang sudah ada pada kode. Inilah yang harus saya capai, tetapi tentu saja dalam pendekatan desain-fashion. Izinkan saya memperkenalkan Anda pada Dokumen Desain Produk.

Dokumen Desain Produk

Dokumen Desain Produk (PDD) , adalah dokumen yang mengubah masalah yang ingin Anda pecahkan, konteksnya, dan solusi akhir menjadi pendekatan berbasis iterasi atau tahap.

Ini berarti Anda dapat mendokumentasikan seluruh proses desain Anda ke dalam satu dokumen yang dapat dibagikan dengan siapa pun di perusahaan Anda dan dokumen tersebut akan berfungsi sebagai basis pengetahuan untuk keputusan produk yang Anda buat. Kedengarannya keren, ya? Mari kita menggali detailnya.

Konsep Keseluruhan

Sebuah PDD dapat dijelaskan dalam 4 konsep utama: Metadata, Konteks, Tahapan , dan Umpan Balik .

konsep
(Pratinjau besar)
  • Metadata hanyalah informasi yang berguna tentang dokumen seperti judul, tanggal, status, dan sebagainya.

  • Konteks adalah apa yang orang lain perlu baca, untuk memahami proposal desain yang Anda buat, pikirkan seperti deskripsi, masalah, abstrak, atau tujuan dari apa yang perlu Anda capai.

  • Tahapan adalah iterasi yang berbeda dari desain Anda, biasanya mulai berfokus pada solusi yang lebih luas dan di setiap tahap berfokus pada detail yang lebih spesifik. Setiap tahap didasarkan pada sebelumnya dan alamat umpan balik yang diterima. Ini adalah cara terstruktur untuk mencapai titik akhir di mana masalah yang diselesaikan tidak dapat muncul lagi.

  • Umpan balik mengacu pada semua pendapat, komentar, permintaan, dan rekomendasi yang Anda kumpulkan dari orang lain. Anda dapat mengumpulkan umpan balik dari pemangku kepentingan atau anggota tim Anda.

Dengan empat konsep ini, Anda dapat membuat variasi PDD yang berbeda untuk memenuhi kebutuhan Anda, setiap perusahaan/proyek berbeda dan apa yang berhasil untuk saya, tidak harus bekerja dengan cara yang sama untuk Anda. Tetapi jika Anda membahas 4 konsep utama ini di PDD Anda, kemungkinan besar itu akan berhasil di hampir semua situasi.

Contoh Struktur

Setelah memahami konsep utama, saya akan berbagi dengan Anda struktur yang telah saya gunakan selama saya di perusahaan itu. Ini memiliki bagian berikut:

dokter
(Pratinjau besar)
  • Judul harus ringkas, jelas dan mudah dibedakan dari judul PDD lain yang sudah Anda miliki.
  • Status menunjukkan di tahap mana dokumen Anda sekarang:
    • Minuman
      Masih bekerja untuk mendefinisikan Konteks. Tidak siap untuk umpan balik.
    • S30, S60, S90
      Tahapan yang berbeda (30%, 60%, 90%) dari solusi Anda (detail lebih lanjut tentang tahapan nanti).
    • Menyelesaikan
      Semua Umpan Balik telah ditangani dan tidak ada poin yang hilang. PDD selesai.
  • Abstrak adalah deskripsi masalah yang perlu Anda rancang, biasanya menautkan ke bacaan terkait lainnya yang mungkin Anda miliki.
  • Sasaran adalah poin kunci yang perlu menjadi fokus solusi Anda, ini adalah daftar periksa yang akan terus Anda tinjau untuk memastikan Anda berada di jalur yang benar.
  • S30 (atau Tahap 30% ) adalah proposal pertama yang Anda buat berdasarkan abstrak dan tujuan, dengan fokus pada solusi yang lebih luas daripada detail, mungkin dengan menyediakan kerangka gambar fidelitas rendah atau teknik serupa. Ini adalah tahap di mana solusi yang diusulkan dapat mengambil pendekatan yang sama sekali berbeda dan umpan balik utama diharapkan terjadi.
  • S60 (atau Tahap 60% ) adalah solusi Anda pada 60% kelengkapan dan menerapkan umpan balik dari S30. Ini memiliki detail yang lebih sedikit daripada S90, tetapi dengan jelas menunjukkan maksud dari solusi Anda. Anda menyediakan kerangka gambar fidelitas tinggi dengan lebih banyak kasus yang terlibat dan beberapa definisi aliran. Anda mungkin menerima semacam umpan balik yang sebagian besar berfokus pada kasus yang terlewat dan skenario kecil yang tidak terduga.
  • S90 (atau Tahap 90% ) adalah tahap yang memiliki solusi pada 90% kelengkapan dan menerapkan umpan balik dari S60. Tahap ini difokuskan pada detail terbaik dari desain Anda, termasuk semua skenario yang berbeda, kasus sudut, desain visual, dan bahkan prototipe. Ini diharapkan memiliki semacam umpan balik kecil.

Anda mungkin bertanya pada diri sendiri, apakah saya harus mengikuti urutan dan tahapan penamaan konvensi yang sama? Yah, tidak. Anda dapat mengganti nama panggung dari S30, S60 dan S90 menjadi hanya: Eksplorasi, Proposal, Solusi.

Anda juga dapat mengubah urutan sehingga pekerjaan yang paling halus (S90, Solution) berada di bagian atas dokumen dan alur pembacaan beralih dari tahap akhir ke tahap awal (S30, Eksplorasi).

Template

Mulailah dengan cepat dengan salah satu template yang disediakan untuk platform penulisan yang paling umum. Ingat: Konvensi penamaan bagian benar-benar dapat disesuaikan. Jika Anda tidak menyukai Abstract , gunakan saja Brief , About atau apapun yang sesuai dengan kebutuhan Anda. Konsep utama yang perlu Anda pertahankan adalah tentang membuat iterasi yang berbeda untuk fokus pada setiap tahap, Anda cukup mengganti nama S30 oleh Eksplorasi, S60 oleh Proposal, dan S90 oleh Solusi.

  • Kertas
  • Gagasan
  • Google Dokumen
  • Contoh kehidupan nyata

Manfaat Utama Menggunakan PDD

  1. Setiap keputusan didokumentasikan.
    Artinya, bahkan ketika Anda meninggalkan perusahaan/proyek Anda (dan itu akan terjadi cepat atau lambat), semua pengetahuan yang dihasilkan akan melekat di perusahaan selamanya, sehingga orang lain dapat melihatnya dan beralih dari tempat Anda pergi.

  2. Meningkatkan komunikasi.
    Mendapatkan orang yang berbeda dari tim Anda di PDD untuk memberikan umpan balik membantu semua orang tetap di halaman yang sama dan menyadari keputusan yang dibuat.

  3. Membatasi perubahan tanpa akhir dari pemangku kepentingan.
    Setiap tahap berfokus pada sudut masalah yang berbeda, mulai dari solusi yang lebih luas ke solusi yang sempit. Hal ini memungkinkan orang untuk fokus pada satu masalah pada satu waktu, membantu mereka dalam tahap penutupan.

  4. Produk ini dibangun secara kolaboratif.
    Alih-alih pemangku kepentingan menentukan solusi spesifik, kami membiarkan tim engineering, desain, dan tim lain terlibat dengan solusi yang menjadikan mereka bagian darinya.

Catatan Akhir

Menutup cerita tentang perusahaan jarak jauh ini, saya harus bekerja di sana selama beberapa bulan lagi dan saya dapat mengimplementasikan Dokumen Desain Produk setidaknya pada 5 proyek berbeda. Frustrasi saya berkurang banyak dan saya dapat mencapai konsensus pada proposal desain saya sehingga produk terus berkembang. Sejak itu, perusahaan telah berkembang pesat dan beberapa pekerjaan yang saya lakukan selama waktu saya masih digunakan.

PS: Saya mulai menulis artikel ini pada tahun 2019, kemudian pada tahun 2021 saya melihat bahwa Abstrak sedang membuat produk untuk mendokumentasikan proses desain, jadi saya memutuskan untuk kembali ke jalur dan menyelesaikannya. Sepertinya itu masih topik yang cukup relevan.

Bibliografi

  • Cara Menjalankan Latihan Desain di Tim Jarak Jauh oleh Hannah Hearth
  • Hindari Efek Camar: Kerangka 30/60/90 Untuk Umpan Balik oleh Lauren Moon
  • Bagaimana Anda mendesain dokumen desain? oleh John Saito
  • Kekuatan dokumen desain oleh Brendan Fagan
  • Memperkenalkan Notebook oleh Matt Colyer