Cara Design Sprint Membantu Rancangan Software Kamu

Design Sprint? Pernah dengar makhluk tersebut?

“Uh, kalau ‘Sprint’-nya sih saya sering dengar dari Scrum”

Iya. Nampaknya perancang Design Sprint, Jake Knapp, dapat inspirasi nama ‘Sprint’ dari Scrum.

Karena memang secara konsep mirip.

Sprint di Scrum, adalah rentang waktu singkat untuk fokus menggubah rancangan, menjadi potongan software¹ yang cukup berkualitas untuk digunakan pengguna.

Sprint di Design Sprint, adalah rentang waktu singkat untuk fokus mengideasi dan memvalidasi rancangan terbaik dari potongan software².

Persamaan:

• sama-sama singkat,
• sama-sama fokus,
• sama-sama bicara tentang potongan kecil dari software,
• sama-sama berada di dalam keluarga besar agile—yang berarti membuat bisnis lebih tangkas melayani pelanggan.

Perbedaan 1, keluaran: Sprint di Scrum keluarannya potongan software yang berkerja, Sprint di Design Sprint keluarannya rancangan yang sudah divalidasi nilai manfaatnya oleh responden dari pengguna.

Perbedaan 2, masukan: Sprint di Scrum masukannya rancangan software. Sprint di Design Sprint masukannya bisa 0 atau bisa masalah besar bersama—ini karena proses ideasi sudah berada dalam Sprint.

Dari perbedaan tersebut, bisa dinilai kalau Scrum dan Design Sprint adalah dua makhluk berbeda, yang menyelesaikan masalah yang berbeda.

Jadi Apa Itu Design Sprint?

Design Sprint adalah rangkaian proses singkat (lima hari), yang membantu sekumpulan orang bisa menghasilkan rancangan software terbaik (baca: tervalidasi) guna menyelesaikan masalah bersama.

Saya baru kenal Design Sprint tahun 2014, di meet-up Scrum di bilangan Slipi. Salah satu peserta berbagi tentang eksperimen Design Sprint di kantornya.

Perjumpaan pertama, belum begitu berkesan.

Tahun lalu saya melatih sebuah klien. Melihat kondisi internal di sana, saya pikir Design Sprint bisa jadi solusi. Alhasil, jadi baca-baca lagi, dan di situlah saya mulai jatuh cinta dengan Design Sprint—dan Design Thinking pada umumnya.

Berikut hasil rangkuman hasil riset saya tahun lalu: (klik gambar untuk memperbesar) 

Persiapan

Ada sekelompok orang yang tepat—maksudnya cukup mewakili pihak-pihak yang penting. Contoh: (Designer, CEO, Product Manager, User Expert, Software Developer, dll). Ada fasilitator. Pastikan jadwal mereka kosong lima hari ke depan. Pastikan logistik untuk Design Sprint terpenuhi (kertas, pulpen, spidol, post-it, dll)

Hari Pertama: Understanding

Sekelompok orang berembuk menentukan masalah bersama. Kondisi internal dan eksternal juga dibahas habis di sini. Brainstorming pertama lalu juga dimulai di hari pertama ini, setelah masalah bersama ditentukan. Pertanyaan pembukanya adalah “How Might We”. Gaya brainstormingnya, present-and-discuss. Tujuan brainstorming “how-might-we” tersebut bukan menyepakati solusi, melainkan metrik apa yang perlu diukur, untuk memonitor posisi tim dalam memecahkan masalah bersama.

Hari Kedua: Diverging

Tujuan di hari ini adalah menghasilkan sebanyak mungkin opsi solusi, untuk memecahkan satu masalah bersama. Hari kedua ini akan sunyi. Masing-masing peserta akan menghabiskan banyak waktu untuk berkontemplasi dan menggambar. Keluaran dari hari ini adalah sebanyak mungkin story board.

Hari Ketiga: Deciding

Tujuan di hari ini adalah menemukan satu atau lebih story board, yang ingin diuji nilai manfaatnya ke pengguna di hari kelima. Proses awalnya adalah voting, lalu dilanjutkan dengan penggabungan ide-ide yang serupa atau komplementer. Lalu diakhir dengan memilih—baik dengan voting ataupun tidak—satu atau lebih story board untuk divalidasi.

Hari Keempat: Prototyping

Tujuan di hari ini adalah membuat versi prototype dari story board yang sudah dipilih kemarin. Prototype bisa dibuat dengan software sederhana seperti Keynote atau Power Point. Prototype menggunakan program asli baru dilakukan, jika prototype ala wireframe dinilai kurang bisa menggambarkan manfaat software.

Hari Kelima: Validating

Tujuan di hari ini adalah mendapatkan pembelajaran penting dari pengguna terhadap prototype yang dibuat kemarin. Informasi penting tersebut umumnya berupa

• angka metrik yang ditentukan di hari pertama &
• masukan-masukan lain dari pengguna.

Di hari ini memang diundang responden yang dinilai bisa mewakili persona pengguna software. Temuan dari hari kelima ini bisa jadi arahan masalah bersama dari Design Sprint di iterasi berikutnya.

Keluaran Design Sprint

Kalau sudah sampai di penghujung Sprint, bisa dibilang pasti didapat pelajaran yang bisa diambil. Bisa dalam bentuk rancangan-rancangan dengan respon yang positif, ataupun yang ternyata negatif.

Dengan Design Sprint, setiap pihak bisa menilai secara (lumayan valid) manfaat bisnis dari rancangan kecil software, bahkan tanpa menulis satu baris kodepun.

Bagi saya, bonus manfaat dari Design Sprint—atau lebih tepatnya Prototyping—adalah komunikasi yang jauh lebih baik antara orang bisnis dengan orang teknis.

Bagaimana? Tertarik Mencoba Design Sprint?

Kebetulan besok siang saya akan mengadakan workshop Design Sprint di Open Incubator di Bandung.

Segera daftarkan dirimu di sini.

1. Meski amat minoritas, beberapa orang mencoba menggunakan Scrum di proyek non-software. Scrum secara definisi memang hanya membatas dirinya untuk masalah yang kompleks.
2. Design Sprint juga amat memungkinkan digunakan untuk non-software. Persyaratannya hanyalah visual dan cukup cepat dibuat barang atau prototypenya.