Navigasi Perusahaan: Metodologi Desain untuk Kolaborasi Pemangku Kepentingan

Merancang (atau mendesain ulang) sistem navigasi perusahaan bukanlah tugas yang bisa dianggap enteng. Aplikasi perusahaan melayani sejumlah besar pengguna, mengakomodasi berbagai persona, dan berisi volume konten dan fitur yang signifikan. Beberapa aplikasi perusahaan bahkan memiliki banyak produk desktop dan seluler berbasis web yang perlu diintegrasikan dengan mulus untuk pengalaman pengguna yang lebih menyenangkan.

Meskipun ini mungkin tampak sebagai tugas yang menakutkan atau bahkan tidak mungkin ditangani dengan baik oleh tim besar "ahli", seorang arsitek informasi tunggal atau desainer UX dapat menangani perombakan desain UX aplikasi perusahaan sendirian—selama dia mengikuti metodologi yang efektif. untuk kerjasama pemangku kepentingan.

“Saat makan gajah, gigit satu per satu.” - Creighton Williams Abrams Jr.

Tentang Sistem Desain Navigasi Perusahaan

Perbedaan utama antara aplikasi perusahaan dan sistem berbasis web yang lebih kecil adalah banyaknya konten dan berbagai fitur. Di mana sistem yang lebih kecil dapat secara efektif bergantung pada sistem navigasi yang relatif datar (yaitu, lebih sedikit klik untuk mengakses semua konten), arsitektur aplikasi perusahaan seringkali memerlukan menu multi-level dan mekanisme pencarian jalan yang ditempatkan dengan hati-hati. Semakin kompleks sistem navigasi, semakin penting bahwa sistem itu sendiri mudah digunakan, terorganisir dengan baik, dan selaras dengan model mental pengguna.

Tujuan akhirnya mungkin jelas, tetapi jika ada desain "sempurna" untuk sistem navigasi perusahaan, setiap perusahaan akan mengadopsinya. Tanpa sistem yang disempurnakan, ada banyak ruang untuk perbaikan, kreativitas, dan inovasi. Ini juga mengungkapkan fakta bahwa setiap perusahaan berbeda, dengan berbagai kasus penggunaan dan persyaratan untuk navigasi melalui aplikasi yang kompleks.

Navigasi Sekedar “Wayfinding”

Pada dasarnya, navigasi adalah “penemuan jalan”. Kapal pelaut dapat menavigasi lautan terbuka yang luas dengan menggunakan bintang-bintang; pelancong darat dapat menemukan tujuan mereka dengan bantuan landmark; dan, pengguna aplikasi perusahaan mencapai tujuan akhir mereka dengan mengandalkan berbagai indikator digital.

Misalnya, di dunia digital, navigasi bergantung pada pemilihan dan penempatan kata kunci, label, warna, ikonografi, objek ajakan bertindak, dan indikator dalam layar lainnya. Ketika konten tidak terorganisir dengan baik, fitur diberi label secara tidak sengaja, kata kunci dipilih secara sembarangan, atau ikon tidak jelas atau tidak konvensional, pengguna mungkin menjadi frustrasi atau tersesat… dan mereka mungkin pergi begitu saja.

Metodologi untuk Kolaborasi dalam Desain Navigasi

Lingkungan perusahaan secara inheren kompleks dan membutuhkan banyak organisasi untuk berfungsi secara efektif. Tidak ada satu orang pun yang secara intuitif dapat mengetahui atau memahami seluruh cakupan aplikasi perusahaan atau ekspektasi unik dan beragam dari basis penggunanya. Ada banyak pendapat mengenai kiriman mana yang penting untuk setiap metodologi desain yang diberikan. Terlepas dari apa yang dibuat pada akhirnya, metodologi apa pun harus dimulai dengan kolaborasi pemangku kepentingan.

1. Rapat Pembukaan Pemangku Kepentingan

Setiap proyek skala besar harus dimulai dengan pertemuan awal pemangku kepentingan. Pada dasarnya, ini adalah pertemuan besar dengan semua pemain kunci yang hadir (dari jarak jauh atau di tempat) untuk memulai proyek. Biasanya, pertemuan awal pemangku kepentingan memiliki fasilitator tunggal yang memperkenalkan tujuan proyek, mengidentifikasi semua peran pemangku kepentingan, dan tunduk pada pimpinan proyek (jika sesuai) untuk konteks tambahan, sehingga kolaborasi dapat dimulai.

Semakin besar tim, semakin penting untuk mengadakan pertemuan awal pemangku kepentingan resmi. Sama seperti upacara pembukaan Olimpiade, titik awal yang agak seremonial untuk sebuah proyek ini menjelaskan kepada semua pemangku kepentingan bahwa “permainan telah dimulai.”

Sebagai seorang desainer, yang terbaik adalah mendapatkan daftar pemangku kepentingan dan peran mereka sebagai referensi saat menjadwalkan sesi desain navigasi dan wawancara. Semua orang di daftar ini penting dan berharga untuk pekerjaan yang perlu dilakukan.

2. Brainstorming Langit Biru

Dengan semua pemangku kepentingan diidentifikasi dan dilibatkan, temukan waktu untuk bertemu dalam kelompok yang lebih kecil atau jadwalkan wawancara individu untuk melakukan sesi brainstorming dan ide. Dengan membuka pintu untuk bermimpi tentang masa depan "langit biru", individu cenderung tidak menyaring ide atau pendapat mereka, dan inovasi diberi kesempatan untuk melebarkan sayapnya.

Dalam banyak kasus, hambatan historis atau batasan yang tidak berdasar mungkin tetap ada di benak pemangku kepentingan tetapi tidak ada lagi dalam kenyataan (karena, misalnya, teknologi baru, perubahan pasar, perubahan pendapatan yang dihasilkan oleh aplikasi perusahaan, atau faktor lainnya) . Ketika pemangku kepentingan berbagi kekhawatiran tentang hambatan ini, cobalah untuk bertanya “mengapa” sebelum menerimanya apa adanya. Mungkin ada peluang tersembunyi di sini.

Untuk memulai proses brainstorming ini, mulailah dengan beberapa pertanyaan:

1. Jika Anda melompat ke depan 5 atau 10 tahun ke depan tanpa batasan atau hambatan, apa yang ingin Anda lihat dalam desain masa depan?
2. Pernahkah Anda memiliki ide—terlepas dari betapa mudah atau rumitnya—tetapi tidak ada kesempatan untuk mewujudkannya?
3. Jika Anda adalah CEO perusahaan ini, apa yang akan Anda lakukan dalam situasi ini?
4. Apakah Anda melihat ada kebutuhan di pasar yang dapat dilayani oleh aplikasi ini?

Tampaknya pendekatan ini akan membuka "kaleng cacing", tetapi selama semua orang jelas tentang skenario "langit biru", hal-hal besar dapat terjadi. Cobalah!

3. Titik Nyeri dan Identifikasi Masalah

Ketika pengguna mengalami rasa sakit atau frustrasi dengan menavigasi melalui sistem perusahaan skala besar untuk menemukan konten atau fitur yang seharusnya lebih mudah diakses, pengguna tersebut cenderung menyerah dan (terkadang) menemukan alternatif. Alternatif itu mungkin dengan pesaing.

Bersikaplah realistis dan agresif dalam mengidentifikasi titik dan masalah pengguna. Banyak pemangku kepentingan memiliki akses langsung ke umpan balik pengguna melalui survei, sesi pelatihan, dan bentuk komunikasi lainnya. Manfaatkan pengetahuan ini untuk mendapatkan pemahaman yang lebih baik tentang kegagalan sistem navigasi perusahaan saat ini.

Pertanyaan-pertanyaan ini dapat membuat bola bergulir dengan mengidentifikasi titik dan masalah rasa sakit:

1. Apa yang paling dikeluhkan pengguna?
2. Apakah Anda menggunakan layanan apa pun (seperti analisis lalu lintas web atau pelacakan klik) yang melacak perilaku pengguna dalam sistem?
3. Apakah ada area sistem perusahaan yang jarang digunakan, dan Anda tidak dapat menjelaskan alasannya?
4. Jika Anda dapat mengubah sesuatu tentang aplikasi ini, apakah itu?

Wawasan di mana pengguna mengalami masalah akan memainkan peran utama dalam mengidentifikasi kesenjangan dalam desain saat ini. Tangkap titik-titik ini untuk digunakan dalam metodologi ini.

4. Diagram Afinitas

Sebagai seorang desainer, "catatan tempel" bisa menjadi teman terbaik Anda. Tetapi jika terlalu banyak pemangku kepentingan tidak berada di kantor yang sama atau Anda adalah satu-satunya sumber daya yang jauh, catatan tempel kertas digunakan dengan sia-sia. Menemukan pendekatan yang efektif untuk kolaborasi online sangat penting. Ada berbagai macam alat kolaborasi online yang dapat digunakan untuk menangkap semua masukan dari fase Blue Sky Brainstorming dan Pain Points dan Identifikasi Masalah.

Setelah Anda mendapatkan masukan dalam jumlah yang signifikan, langkah selanjutnya adalah mengatur masukan tersebut ke dalam kelompok afinitas. Diagram afinitas adalah latihan kolaboratif yang memungkinkan semua pemangku kepentingan kesempatan untuk menemukan hubungan atau fitur bersama antara ide individu atau jenis konten. Latihan ini memungkinkan seorang desainer untuk menyatukan semua ide "langit biru" dan "titik rasa sakit dan masalah".

Misalnya, mungkin membantu untuk mengelompokkan konten proses dan prosedur ke dalam perpustakaan, atau peristiwa terkini dan pembaruan yang layak diberitakan ke dalam surat kabar online yang terkonsolidasi. Dorong pemangku kepentingan untuk menjadi kreatif tentang bagaimana mereka merumuskan kelompok afinitas.

Dalam sesi diagram afinitas pemangku kepentingan, ajukan pertanyaan seperti ini:

1. Fitur atau konten mana yang terasa seperti milik bersama?
2. Apakah pengguna mencoba mengambil tindakan tertentu yang akan lebih mudah jika dilakukan secara berurutan?
3. Apakah ada kemampuan yang berlebihan yang dapat dengan mudah digabungkan atau disederhanakan?
4. Apakah ada peluang untuk mencocokkan ide langit biru dengan titik nyeri atau masalah yang ada?

Dorong pemangku kepentingan untuk memikirkan skenario spesifik yang membawa pengguna ke fitur tertentu dalam sistem. Menggunakan skenario kehidupan nyata menempatkan segala sesuatunya ke dalam perspektif dan memudahkan pemangku kepentingan untuk berempati terhadap pengalaman pengguna.

5. Reorganisasi Logis

Setelah latihan diagram afinitas selesai, penting untuk mundur dan melihat sistem secara holistik. Seringkali ada urutan operasi logis yang dapat diikuti pengguna dalam lingkungan kompleks apa pun. Pertimbangkan dengan cermat apakah ada peluang untuk menyediakan layanan yang saat ini tidak tersedia (inovasi), atau untuk mendorong pengguna memperluas utilitas sistem navigasi perusahaan (penemuan) dengan menyediakan indikator pencarian jalan.

Untuk menangkap organisasi logis atau urutan operasi ini, desainer dapat membuat diagram alur atau, dalam skenario yang lebih kompleks, peta perjalanan pengguna, dimulai dengan alur kerja utama, lalu bercabang ke konten atau fitur lain.

Pertanyaan yang mungkin mendorong pemangku kepentingan Anda meliputi:

1. Sekarang pengguna "di sini," apa lagi yang bisa dia lakukan?
2. Apa aktivitas logis berikutnya untuk pengguna dalam skenario ini?
3. Apakah kita kehilangan peluang untuk memecahkan masalah pengguna dari sudut pandang ini?
4. Apakah ada fitur atau konten yang ada di tempat lain yang dapat berguna dalam skenario ini?

Setelah Anda memulai percakapan tentang topik ini, berkolaborasilah dengan pemangku kepentingan untuk mengatur ulang kelompok afinitas yang sesuai.

6. Hirarki

Dalam kelompok afinitas yang lebih besar atau antara kelompok afinitas individu, kemungkinan akan ada hubungan atau ketergantungan. Bekerja dengan pemangku kepentingan untuk mengidentifikasi hubungan atau ketergantungan tersebut, dan kemudian mengaturnya ke dalam hierarki. Hirarki hanyalah cara mewah untuk menggambarkan bagaimana suatu konten atau fitur termasuk dalam grup konten atau fitur serupa. Misalnya, satu artikel berita termasuk dalam suatu topik, dan topik tersebut termasuk dalam bagian yang didedikasikan untuk berita.

Peringatan!

Pada titik ini dalam proses desain, pemangku kepentingan mungkin ingin menggunakan organisasi departemen perusahaan yang ada sebagai dasar untuk hierarki sistem perusahaan. Meskipun mudah untuk meniru organisasi departemen perusahaan (yang biasanya merupakan tempat kepemilikan konten dan fitur), ini bisa menjadi kesalahan besar!

Pengguna tidak peduli siapa yang memiliki konten. Selain itu, karena perusahaan besar sering melakukan reorganisasi, sistem desain navigasi perusahaan yang selaras dengan organisasi departemen tidak akan lagi berlaku segera setelah "reorganisasi" pertama terjadi.

Manfaatkan metodologi yang disajikan sejauh ini, dan dorong kembali pendekatan berbahaya ini. Pertanyaan-pertanyaan ini dapat membantu memfasilitasi percakapan dengan pemangku kepentingan:

1. Bagaimana kelompok afinitas ini terkait, dan mengapa mereka terkait?
2. Apakah ada ketergantungan antara kelompok afinitas yang perlu kita akui?
3. Apakah pengguna dapat menyelesaikan tugas tanpa harus menavigasi ke area lain dari sistem?
4. Apakah ada hierarki konvensional yang akrab bagi pengguna dari dalam industri lain atau model layanan yang dapat digunakan sebagai referensi?

Pada titik ini dalam proses desain, ada banyak cara untuk memverifikasi apakah pendekatan itu berhasil. Pertimbangkan berbagai metode pengujian pengguna dan penelitian pengguna untuk mengonfirmasi hierarki Anda, atau untuk mengidentifikasi area masalah yang memerlukan perhatian lebih.

7. Nomenklatur dan Parameter

Dengan model lengkap arsitektur aplikasi perusahaan masa depan—juga dikenal sebagai arsitektur informasi—saatnya memilih kata kunci (nomenklatur) dan menetapkan parameter (definisi).

Nomenklatur, atau pelabelan, merupakan elemen penting dari desain navigasi karena tiga alasan utama: (a) nomenklatur terkait langsung dengan SEO (optimasi mesin telusur) di mana mesin telusur terutama mencari konten dengan kata kunci; (b) menggunakan terminologi yang tepat sebagai mekanisme pencarian jalan akan membantu pengguna menemukan apa yang mereka cari dengan berfungsi sebagai “landmark” digital; dan (c) label pintar dapat mengarahkan pengguna ke area sistem yang mungkin tidak mudah diakses dari halaman arahan utama atau halaman beranda. Findability didorong oleh mekanisme wayfinding, seperti label. Jika label menyesatkan atau tidak intuitif, pengguna mungkin tidak perlu mengekliknya sama sekali.

Dengan semua nomenklatur (label) yang diidentifikasi dalam model arsitektur informasi, berkolaborasilah dengan pemangku kepentingan untuk menentukan parameter (definisi) untuk setiap area berlabel dalam model. Ini akan memastikan bahwa konten dan fitur milik area tertentu. Selain itu, latihan ini menciptakan pedoman jangka panjang untuk membangun arsitektur aplikasi perusahaan yang akan bertahan lebih lama dari proses desain saat ini.

Mengenai nomenklatur dan parameter, berikut adalah beberapa pertanyaan untuk diajukan kepada pemangku kepentingan yang akan mendorong percakapan:

1. Apa yang paling sering ditelusuri pengguna saat mereka berkunjung?
2. Apakah ada konten atau fitur yang sulit ditemukan? Mengapa mereka sulit ditemukan?
3. Apakah ada istilah atau istilah industri yang mungkin asing bagi sebagian pengguna, sehingga mempersulit mereka untuk menemukan apa yang mereka cari?
4. Bagaimana kita bisa memilih label yang konvensional atau mainstream?

Seperti disebutkan di atas, ada banyak metode berbeda yang dapat digunakan untuk menguji nomenklatur, seperti penyortiran kartu, pengujian A/B, dan UX berorientasi objek (OOUX). Ketika berhadapan dengan sistem perusahaan yang sangat teknis dengan banyak istilah industri, pertimbangkan untuk membangun kosakata terkontrol atau glosarium dalam sistem untuk referensi pengguna.

8. Integrasi dengan Proses Desain Pengalaman Pengguna

Dengan gambaran lengkap tentang arsitektur informasi masa depan, sekarang saatnya untuk menerapkan hasil metodologi ini ke proses desain pengalaman pengguna secara keseluruhan.

Meskipun mungkin ada area dari sistem navigasi perusahaan yang baru dibuat yang tidak ada saat proyek desain sedang berjalan, area tersebut dapat "dinonaktifkan" atau disembunyikan hingga konten atau fitur siap dirilis. Kemudian, setelah desainer pindah, pemangku kepentingan dapat terus membangun sistem menuju impian “langit biru” mereka.

“Jika Anda membangunnya, [mereka] akan datang.” - Lapangan Impian, 1989.

Garis bawah

Merancang sistem navigasi perusahaan bukanlah tugas yang mudah. Namun, memanfaatkan pengetahuan pemangku kepentingan akan membuat upaya itu dapat dikelola.

Mengesampingkan kompleksitas proyek desain skala besar, tujuannya selalu untuk mengingat pengguna. Dengan pendekatan langsung untuk riset pengguna, dan mengajukan pertanyaan cerdas kepada orang-orang yang memiliki kontak langsung dengan pengguna, bahkan desainer jarak jauh, solo, atau lepas dapat menangani masalah desain besar. Jangan terintimidasi—lakukan saja selangkah demi selangkah.