Cara mendesain sistem notifikasi. Petunjuk langkah demi langkah dengan contoh-contoh

Sulit membayangkan layanan modern tanpa sistem pemberitahuan terintegrasi. Kami dengan hati-hati diberitahu bahwa salah satu teman kami menghargai foto itu, kurir dengan pizza yang sudah lama ditunggu-tunggu sudah berada di jalan, dan taksi tiba di rumah.

Dalam sistem manajemen pekerjaan, peran pemberitahuan menjadi sangat penting karena sangat terintegrasi ke dalam alur kerja tim. Seperti bola yang dilemparkan dari tangan ke tangan, pemberitahuan segera menginformasikan tentang perubahan tugas, menyerukan pelaksanaan bagian pekerjaan mereka dan meminta informasi penting.

Di bawah ini saya akan membagikan pengalaman saya dengan pendekatan sistematis untuk merancang pemberitahuan. Bagaimana cara mendeteksi dan memperhitungkan semua situasi untuk membuat produk lebih bermanfaat bagi pengguna dan menghemat sumber daya tim Anda?

Langkah 1: Identifikasi peserta proses

Pertimbangkan kisah klasik agen pemasaran:
Direktur seni Anthony sedang terburu-buru: perusahaannya akan segera meluncurkan produk baru di pasar, sehingga spanduk promo harus dikirimkan pada akhir minggu. Desainer Johnny telah menyelesaikan semua pekerjaan, tetapi untuk menerimanya, tata letak harus disetujui oleh manajer proyek.
Karena itu, Anthony menetapkan tugas untuk disetujui dengan tenggat waktu hingga Jumat dan menambahkan penjelasan: "Harap setujui spanduk untuk kampanye."



Mari kita lihat lebih dekat siapa yang berpartisipasi dalam sistem:

1. Perancang adalah pelaksana tugas. Meskipun karyanya telah selesai, penting baginya untuk mengetahui hasilnya: model diterima atau dikembalikan untuk revisi.
2. Art Director - menerima karya yang dilakukan dan menyetujuinya dengan manajer-pelanggan. Penting baginya untuk memantau proses pemungutan suara dan membuat keputusan taktis dengan cepat.
3. Manajer - dapatkan pekerjaan yang telah selesai untuk disetujui. Penting bagi mereka untuk memahami bahwa mereka diminta untuk memeriksa dan betapa pentingnya untuk mempertimbangkan tugas tersebut. Dan, tentu saja, buat keputusan dengan kesempatan untuk mengomentarinya.

Untuk membangun model pemberitahuan, kami menyoroti peran abstrak yang terlibat dalam sistem:

1. Kontraktor - satu atau sekelompok orang yang kepadanya tugas tersebut ditugaskan. Didefinisikan oleh bidang Pelaku dalam tugas.
2. Inisiator - pengguna yang memulai proses persetujuan.
3. Approver - Satu atau sekelompok pengguna yang ditugaskan untuk persetujuan.

Seringkali ada peran implisit dalam sistem yang tidak boleh Anda lupakan. Misalnya, jika Anda ingin mengirim pemberitahuan tentang status proses yang sedang berlangsung, akan sangat berguna untuk memperkenalkan peran "Robot" - pesan kepada pengguna atas nama produk Anda.

Cobalah untuk membatasi daftar ini. Semakin kompleks sistem peran yang Anda bangun, semakin sulit bagi pengguna untuk memahami apa logika kerjanya.

Langkah 2: Bangun tabel "Acara - Pemberitahuan"

Bangun bingkai

Untuk merancang pemberitahuan secara sistematis dan visual, mari buat tabel. Bingkai akan terdiri dari dua bagian:

Kolom kiri. Di sini kami akan mencatat kemungkinan peristiwa dalam proses persetujuan berdasarkan peran. Mereka akan menyebabkan pengiriman pemberitahuan. Tidak semua peran dalam praktik dapat memengaruhi sistem. Misalnya, "Kontraktor" dalam contoh kami hanyalah pengamat, jadi Anda tidak dapat menambahkannya ke kolom kiri. Total, kami mendapatkan tiga bagian:

1. Inisiator - tindakan inisiator dari awal pernyataan sampai akhir;
2. Menyetujui - pengambilan keputusan dan komentar tentang hal itu;
3. Robot - peristiwa status sistem.

Baris atas Di sini kami merekam peran yang harus menerima pemberitahuan. Dalam praktiknya, berbagai saluran komunikasi juga digunakan, misalnya, pemberitahuan push atau SMS. Untuk kesederhanaan, kami hanya akan mempertimbangkan satu saluran komunikasi "Kotak Masuk" - umpan pemberitahuan pribadi:

1. Setuju
2. Pemain
3. Penggagas

Tabel paling mudah dirawat di Google Sheets. Selain fungsionalitas yang kuat, akan nyaman baginya untuk berbagi dengan tim Anda dan departemen lain yang membutuhkan informasi ini. Misalnya, dengan Dukungan Pelanggan.

Bagikan tautan dengan hak akses Mengomentari. Jadi tim akan memiliki kesempatan untuk membahas acara di komentar pada sel dan tidak ada seorang pun kecuali Anda akan dapat mengubah atau menghapusnya.

Isi acara

Ketika bingkai tabel sudah siap, kita mulai mengisi kolom kiri dengan semua peristiwa yang bisa dilakukan pengguna dalam persetujuan. Adalah perlu bagi setiap peran untuk mengevaluasi setiap keadaan antarmuka dan menuliskan tindakan yang tersedia. Pada titik ini, ikuti beberapa tips:

1. Tuliskan kejadian bersuku kata satu jika memungkinkan. Jika Anda terburu-buru dengan pengelompokan, Anda dapat kehilangan beberapa peristiwa sederhana, segera mempersulit kata-kata dan kehilangan kejelasan tabel.
2. Pertimbangkan model logis dari sistem. Beberapa peristiwa, tergantung pada konteksnya, dapat menghasilkan hasil yang berbeda. Misalnya, jika kami menghapus pemberi persetujuan terakhir dari proses aktif, selain dari peristiwa penghapusan, pernyataan itu sendiri harus dibatalkan.
3. Jangan takut duplikat. Untuk beberapa peran, acara dapat diulang. Misalnya, pemrakarsa dan pengguna mana pun dengan hak dapat mengubah tanggal tenggat. Biarkan ini memperbesar tabel, tetapi ini akan membantu untuk lebih menggambarkan sistem tindakan yang tersedia untuk semua orang dan unik untuk setiap peran.

Langkah 3: Tentukan prinsip-prinsip untuk menerima pemberitahuan

Acara sudah siap, tetapi sebelum menambahkan pemberitahuan, ada baiknya menentukan prinsip untuk menerimanya berdasarkan peran. Mereka berguna untuk merancang hanya daftar yang relevan untuk setiap peran dan tidak membanjiri pengguna dengan informasi yang tidak perlu. Ini akan membantu hasil wawancara pengguna, studi tentang produk serupa, serta solusi konseptual yang dimasukkan ke dalam sistem.

Dalam model persetujuan kami, kami menguraikan prinsip-prinsip berikut:

1. Inisiator - menerima pemberitahuan tentang keputusan yang disetujui dan tentang semua perubahan yang dilakukan seseorang dalam prosesnya.
2. Approver - menerima pemberitahuan tentang dimulainya persetujuan baru dengan partisipasinya dan semua perubahan signifikan pada proses.
3. Pelaku - adalah seorang pengamat. Dia belajar tentang permulaan persetujuan, keputusan yang diambil dan akhirnya.

Catat prinsip-prinsip ini untuk setiap peran dalam jalur penerima. Lebih mudah untuk menunjukkannya dengan komentar pada sel. Dengan pengembangan sistem, prinsip-prinsip ini akan membantu mempertahankan satu arah.

Langkah 4: Isi Pemberitahuan

Akhirnya, Anda dapat mulai membuat notifikasi sendiri. Pergi berurutan dari acara dari kolom kiri melalui sel-sel dari masing-masing peran penerima. Ikuti panduan ini:

1. Cobalah untuk menggunakan kembali kata-kata atau bagian yang identik. Jadi notifikasi akan lebih konsisten. Jika Anda membuat produk internasional, ini akan memudahkan pekerjaan tim pelokalan.
2. Di baris pemberitahuan, sorot data variabel di antara teks isi. Misalnya, "USER: ubah tanggal tenggat menjadi DATE." Ini akan memudahkan pengembang untuk bekerja dengan string Anda.
3. Jangan lupa tentang aturan pemberitahuan yang baik: kata-kata pendek, informasi bermanfaat maksimal, nada sesuai dengan merek Anda, prinsip penerimaan yang dipilih. Coba pra-uji panjang garis di antarmuka pemberitahuan push produk atau seluler Anda - beberapa formulasi mungkin sulit dibaca atau dipotong dengan elips.
4. Letakkan tanda hubung di mana notifikasi tidak boleh dikirim. Ketika sebuah proyek membutuhkan waktu yang lama, mudah untuk bingung di mana Anda belum mengisi tabel tersebut, dan di mana Anda memutuskan bahwa itu seharusnya tidak. Ini juga akan menghapus masalah tim.

Menurut situasinya, masukkan kode warna dalam sel dan perbaiki sebagai legenda di header tabel. Sebagai contoh: teks hitam - draft garis, teks hijau - baris diperiksa dan siap untuk bekerja, teks merah - ada masalah implementasi dan detail dalam komentar sel.

Langkah 5: Menyelesaikan Acara

Setelah mengisi semua sel, tabel harus diselesaikan:

1. Bawa semua garis seperti itu ke satu bentuk. Kadang-kadang terjadi bahwa dalam daftar besar bagian-bagian yang identik dalam arti berbeda: kasus yang sedikit berbeda, preposisi, sinonim.
2. Tambahkan kata-kata untuk acara massal di mana memungkinkan untuk mengurangi jumlah notifikasi karya. Misalnya, "USER: Menambahkan file N ke pernyataan"
3. Tambahkan baris unik baru untuk mengganti grup tindakan berurutan. Misalnya, alih-alih menghapus pemberi persetujuan dan kemudian menambahkan yang lain, Anda dapat membuat acara "Mengganti pemberi persetujuan dengan PERSETUJUAN ke PERSETUJUAN"
4. Diskusikan semua pemberitahuan dengan tim pengembangan. Arsitektur produk mungkin tidak memungkinkan Anda untuk merealisasikan beberapa ide Anda, walaupun mereka terlihat sederhana dan logis. Semakin cepat Anda menunjukkan konsep kepada pengembang backend Anda, semakin banyak waktu yang akan Anda hemat dalam pengembangan lebih lanjut.

Kesimpulan

Bahkan skenario paling kompleks dapat menjadi visual dan mudah dikembangkan jika Anda melakukan pendekatan secara sistematis dan mematuhi prinsip-prinsip yang dipilih. Tabel notifikasi yang dirancang dengan baik akan membantu desainer membuat produk lebih bermanfaat dan mudah dipahami oleh pengguna. Tim - tidak menghabiskan sumber daya tambahan untuk memahami ide dan semua detail, tetapi berkonsentrasi pada kualitas implementasi.

Beberapa tips berguna untuk pekerjaan lebih lanjut dengan tabel:

1. Untuk skenario produk yang berbeda, gunakan halaman tabel terpisah. Akan lebih mudah dinavigasi dan menemukan tempat yang tepat.
2. Berikan presentasi kepada tim pengembangan. Jelaskan logika dan prinsip-prinsip konstruksinya. Jawab pertanyaan sehingga setiap orang memiliki pemahaman yang sama tentang pekerjaan itu.
3. Jika desainer lain bekerja dengan pemberitahuan di produk Anda, terapkan pendekatannya dan gunakan tabel umum. Jadi semua acara akan disimpan di satu tempat, dan keseluruhan gambar akan terlihat.