Di halaman ini
Catatan kontak sudah terbuka ketika petugas penjualan menemukan duplikat. Dalam alur ilustratif ini, otomatisasi dapat menyelesaikannya, tetapi petugas harus membuka dasbor terpisah, mencari kontak yang sama, lalu kembali ke CRM untuk memeriksa hasil. Otomatisasi mungkin cepat; perjalanan memutar di sekelilingnya tidak.
Ini memunculkan pertanyaan produk yang mudah terlewat saat merancang otomatisasi: di mana hasilnya sebaiknya muncul?
Percakapan yang dipelajari tentang otomatisasi kerja menyarankan tindakan dilakukan di dalam sistem pencatat utama, alih-alih meminta tiap pengguna mempelajari antarmuka baru. Klaim itu adalah hipotesis desain, bukan bukti bahwa penerapan tertentu meningkatkan penggunaan. Gagasan itu berguna karena mengubah satuan desain dari layar menjadi tugas yang selesai.
Ikuti catatan, keputusan, dan serah terima
Petakan satu tugas nyata. Di mana catatan pertama kali muncul? Siapa yang menentukan apakah catatan siap? Apa yang perlu diperiksa orang itu? Di mana mereka memeriksa bahwa perubahan benar-benar terjadi? Hitung langkah dan titik ketika konteks harus disalin atau diketik ulang.
Dalam contoh duplikat kontak yang dibayangkan, petugas sudah membuka catatan pelanggan. Saran di samping catatan itu dapat menunjukkan bidang yang bertentangan dan penggabungan yang diusulkan. Peninjauan dapat tetap dekat dengan keputusan. Hasil dapat muncul pada catatan yang diperbarui. Jalur itu mungkin memerlukan lebih sedikit langkah daripada dasbor baru, meskipun dasbor tampak lebih rapi dalam demo.
- Buka catatanpekerjaan yang sudah adakonteks yang sama
- Tinjau saranbidang yang bertentanganorang memutuskan
- Izinkan perubahancakupan yang tepatkeadaan akhir
- Periksa hasilcatatan yang diperbarui
Percakapan sumber juga membedakan langkah yang dapat dihapus, tindakan deterministik, keputusan yang memerlukan penilaian, dan persetujuan manusia. Lokasi antarmuka berpengaruh berbeda untuk masing-masing. Pembaruan deterministik mungkin berjalan tanpa layar dan meninggalkan status jelas. Penggabungan ambigu memerlukan penjelasan dan titik tinjauan. Tindakan berdampak memerlukan kewenangan orang yang bertanggung jawab, di mana pun antarmuka berada.
Panduan kami tentang mengintegrasikan beberapa alat bisnis meminta tim menentukan sumber kebenaran. Keputusan itu membantu menempatkan interaksi: sistem yang menguasai catatan sering menjadi tempat wajar untuk memeriksa dan memperbaikinya. Namun, tidak setiap alat dapat menampilkan semua penjelasan yang diperlukan.
Hasil yang melekat dalam alur tetap perlu jejak yang dapat diperiksa
“Tidak perlu antarmuka baru” dapat menjadi slogan yang menyembunyikan kendali yang hilang. Jika otomatisasi mengubah catatan di CRM, pengguna perlu mengetahui apa yang berubah, mengapa, dan apakah sistem lain sekarang setuju. Pesan singkat “selesai” tidak cukup bila tugas melintasi dua sistem.
Rancangan mungkin memerlukan status ringkas dalam alat kerja dan tampilan riwayat lebih rinci di tempat lain. Keduanya melayani saat yang berbeda. Petugas perlu bertindak pada catatan saat ini. Administrator mungkin perlu meninjau pekerjaan gagal, izin, dan pola di beberapa akun. Jadi, antarmuka terbaik mungkin mempunyai lebih dari satu tampilan, masing-masing sesuai tugas.
Tajo sudah menyediakan sumber aktivitas MCP berisi hasil, tahap, dan data peristiwa mentah yang bisa dibuka. Ilustrasi di bawah menempatkan gagasan itu dalam percakapan dan menambah panel verifikasi usulan. Operator membaca hasil segera, lalu memeriksa bukti saat perlu. Tata letak ini tidak membuktikan kecocokan dengan semua aplikasi host.
Penulisan yang selesai tetap memerlukan bukti
Apakah sinkronisasi pelanggan selesai?
Penulisan diterapkan. Verifikasi tertunda.
Keadaan di tujuan belum diperiksa.
Aktivitas sinkronisasi
- Permintaan diterima
- Pembaruan diterapkan
- Pemeriksaan tujuan tertunda
Proses contoh · 14:32 UTC
Yang diketahui
- Respons penyedia
- Diterima
- Hasil penulisan
- Diterapkan
- Baca ulang dari tujuan
- Tertunda
Panggilan berhasil tidak membuktikan keadaan akhir.
Tata letak yang diusulkan berdasarkan umpan aktivitas Tajo. Ilustrasi ini menambahkan status verifikasi; fitur baca ulang tujuan belum dinyatakan tersedia.
Pertimbangkan contoh ilustratif kedua: pengelola toko ingin tahu apakah pesanan uji menghasilkan pembaruan pelanggan yang dimaksud. Hasil singkat di dekat pesanan dapat menunjukkan catatan tujuan serta statusnya. Konsol integrasi terpisah dapat menampilkan aturan pemetaan dan riwayat kesalahan. Panduan integrasi Brevo dan Shopify menyarankan memeriksa kontak dan pesanan uji di tujuan sebelum memakai data yang tersinkronisasi. Antarmuka harus membantu orang melakukan pemeriksaan itu, bukan hanya mengumumkan bahwa permintaan telah dikirim.
Perbedaan ini menghindari perangkap yang sering terjadi. Alat dapat mudah dibuka tetapi sulit dipercaya. Menunjukkan keadaan akhir di tempat pengguna bekerja mungkin lebih bernilai daripada mengurangi satu klik menuju dasbor. Namun, jika aplikasi yang ada tidak dapat menampilkan konteks cukup, memaksa seluruh keputusan masuk dalam notifikasi kecil justru memperburuk tugas.
Uji jalurnya, bukan kesukaannya
Perlihatkan kedua rancangan kepada orang yang mengerjakan tugas: saran yang melekat dalam alur dan halaman khusus. Berikan kasus yang sama. Amati apakah mereka menemukan catatan, memahami tindakan usulan, mengenali saran salah, dan mengonfirmasi hasil. Hitung serah terima serta asumsi yang keliru, bukan hanya detik.
Pisahkan kewenangan dari kemudahan. Tombol di samping catatan tetap harus menghormati izin peminta dan aturan persetujuan alur kerja. Artikel tentang ahli tugas yang membentuk otomatisasi menjelaskan mengapa orang yang tahu pengecualian perlu mendefinisikannya, sementara sistem menegakkan akses dan kontrak data.
Ada alasan untuk menambah layar baru: diagnosis lintas sistem, pengaturan, tinjauan massal, dan audit dapat melampaui kemampuan CRM atau admin toko. Pertanyaan tepatnya adalah apakah layar itu membantu menyelesaikan tugas yang meminta orang meninggalkan pekerjaan awalnya.
Ketika menguji rancangan, sertakan orang yang menangani pengecualian, bukan hanya orang yang menyelesaikan jalur rutin. Tindakan ringkas di dalam catatan mungkin ideal untuk kasus biasa tetapi membuat penanggung jawab pengecualian kekurangan riwayat untuk memutuskan. Antarmuka harus membuat serah terima terlihat sekaligus memperpendek jalur normal.
Antarmuka layak ada ketika membawa keputusan atau bukti yang diperlukan. Jika pekerjaan dapat diselesaikan dan diperiksa di tempat ia dimulai, layar lain hanyalah jalan memutar.
Pertanyaan yang sering diajukan
Apakah setiap otomatisasi membutuhkan dasbor sendiri?
Tidak. Tanyakan dulu di mana pengguna melihat masalah dan membuat keputusan. Catatan, notifikasi, atau antrean tinjauan yang sudah ada mungkin tempat paling langsung untuk menampilkan hasil.
Kapan antarmuka terpisah berguna?
Gunakan ketika orang perlu menyelidiki beberapa sistem, mengatur, mengawasi, atau melihat riwayat yang tidak dapat ditampilkan jelas oleh alat yang ada. Ukur langkah baru yang ditambahkannya.
Apakah menampilkan hasil di alat lain menghapus kebutuhan kendali?
Tidak. Akses, tinjauan, audit, dan penanganan kegagalan tetap perlu dirancang secara jelas. Letak tombol tidak memberikan kewenangan mengubah catatan.