Mempromosi untuk Pembuatan semula Produk Lengkap

Memujuk pasukan saya untuk mengubah reka bentuk Fabrik Crashlytics dalam Firebase

Crashlytics in Fabric (kiri), direka semula Crashlytics dalam Firebase (kanan)

Baru-baru ini saya mempunyai peluang untuk mengubah reka bentuk Crashlytics, alat pelaporan crash yang membantu pemaju aplikasi mudah alih memahami mengapa aplikasi mereka terhempas. (Pernahkah anda mengalami kemalangan app pada anda? Crashlytics membantu pemaju membetulkannya.)

Pasukan saya menyertai Firebase di Google pada Januari 2017 sebagai sebahagian daripada pengambilalihan Fabric. Salah satu matlamat pemerolehan adalah membawa Crashlytics kepada Firebase. Ini bermaksud mendesain semula dan membina semula produk kami kepada Firebase, yang menggunakan Reka Bentuk Bahan dan mempunyai sistem rekaan visual yang sangat berbeza.

Oleh kerana kita perlu melakukan kemas kini reka bentuk visual Crashlytics, saya memutuskan ia adalah satu peluang yang baik untuk memikirkan semula pengalaman pengguna keseluruhannya, bukan hanya pelabuhan ke atas ciri-ciri seperti itu. Crashlytics adalah produk yang sangat dikasihi tetapi telah mendapat banyak hutang reka bentuk sejak penciptaannya pada tahun 2011. Kami mendengar dari ramai pengguna bahawa mereka mengalami kesukaran menggunakan ciri-ciri atau tidak dapat mencari ciri yang telah kami ada. Ia juga semakin sukar untuk pasukan kami mengetahui di mana untuk meletakkan ciri-ciri baru kerana produk itu tidak mempunyai hierarki maklumat yang jelas - untuk diri sendiri dan pengguna kami. Ia adalah masa untuk reka bentuk semula.

Tetapi pertama, saya perlu membina kes saya.

Satu tidak semata-mata memulakan reka bentuk semula produk. Ia mengambil masa untuk memahami pengguna, bagaimana mereka menggunakan produk anda, dan masalah yang mereka ada. Sangat penting untuk mendapatkan semua pandangan ini sebelum memulakan reka bentuk semula itu untuk memastikan bahawa pasukan sedang menyelesaikan masalah yang betul dan sejajar dengan matlamat projek.

Langkah 1: Memahami pengguna anda

Saya bermula dengan mengumpulkan maklumat. Saya bercakap dengan rakan sepasukan Crashlytics yang telah bekerja pada produk ini selama bertahun-tahun, pasukan hubungan pemaju kami, penyelidik pengguna, dan sudah tentu, pengguna kami. Saya perlu memahami mengapa dan bagaimana orang menggunakan Crashlytics sebelum saya dapat mengetahui bagaimana untuk meningkatkan pengalaman pengguna mereka.

Nasib baik Jason St Pierre, pengurus produk saya, telah bekerja di Crashlytics selama lebih dari 5 tahun dan sering berbincang dengan pengguna, jadi dia mempunyai pemahaman yang mendalam tentang bagaimana pelbagai orang menggunakan Crashlytics. Dia mengenal pasti 4 pengguna Crashlytics yang paling kritikal:

  1. Memantau kestabilan versi aplikasi yang baru dikeluarkan
  2. Memeriksa kestabilan aplikasi
  3. Mengutamakan kemalangan untuk menetapkan
  4. Menyelesaikan masalah pelanggan
Perjalanan pengguna yang paling kritikal dalam Crashlytics: memantau kestabilan versi aplikasi yang dilancarkan

Saya memetakan setiap perjalanan pengguna ke dalam aliran menggunakan personas, yang menunjukkan perjalanan mikro yang konsisten antara semua 4 perjalanan: aliran "menyiasat dan memperbaiki". Saya berkongsi perjalanan ini dengan pasukan dan menyemak semula aliran yang diperlukan. Aliran ini menjajarkan pasukan Crashlytics pada pemahaman yang berasaskan, asas bagaimana pengguna menggunakan produk kami.

Aliran

Langkah 2: Memahami titik kesakitan mereka

Setelah kami menyelaraskan bagaimana orang menggunakan produk kami, kami perlu memahami titik kesakitan mereka dengan UX yang sedia ada. Pasukan Crashlytics sangat kolaboratif dan kami semua melabur dalam membina pengalaman hebat untuk pengguna kami. Saya mahu satu cara untuk melibatkan mereka dalam proses reka bentuk semula yang lebih kolaboratif daripada saya berkongsi konsep dan mendapatkan maklum balas mereka. Pasukan ini juga mempunyai banyak konteks berharga mengenai produk yang akan berguna untuk memanfaatkan reka bentuk semula, kerana banyak daripada mereka telah mengusahakan produk tersebut selama bertahun-tahun.

Ramai orang di pasukan Crashlytics menyebut pelbagai aspek papan pemuka yang memerlukan penambahbaikan. Untuk memanfaatkan pengetahuan mereka, saya memutuskan untuk menjalankan beberapa kajian pengguna dalaman. Matlamat saya ialah untuk memahami apa yang menjadi masalah kesakitan terbesar dalam pengalaman pengguna berdasarkan apa yang kita dengar dari pelanggan selama ini.

Saya mencetak dan memotong papan pemuka Crashlytics dan menubuhkan sesi individu dengan rakan sepasukan di mana saya meminta mereka menyusun semula kepingan dan mengubah reka bentuk papan pemuka, bercakap dengan kuat untuk menerangkan pemikiran mereka.

Rakan-rakan seperjuangan bersenang-senang merangka semula Crashlytics dengan potongan kertasBeberapa papan pemuka yang direka bentuk semula - beberapa orang juga menambah ciri-ciri baru dengan post-its

Ini sangat bermanfaat. Bukan sahaja menyeronokkan (berapa kerap pereka digital dapat bermain dengan kertas sebenar pada masa kini?), Saya dapat melihat apa yang setiap orang dikenalpasti sebagai titik kesakitan tanpa mereka yang berat sebelah oleh orang lain. Ini memudahkan saya mengenali tema yang berulang. Misalnya, setiap orang menumpukan pada penambahbaikan penapis dan meningkatkan hierarki maklumat. Saya juga belajar dari pasukan hubungan pemaju yang mempunyai ciri-ciri yang sukar digunakan dan dicari.

Saya berkongsi pelajaran ini kembali kepada pasukan dalam dek yang berterusan yang mengkatalogkan usaha reka bentuk semula. Saya juga menyediakan daftar masuk reka bentuk mingguan dengan pasukan untuk berkongsi kemas kini reka bentuk dan membawa mereka sepanjang perjalanan reka bentuk semula.

Slaid dari dek proses reka bentuk semula yang menggariskan tema berulang di laman Ikhtisar Crashlytics

Langkah 3: Tentukan masalah pengguna

Selepas memahami matlamat pengguna dan titik kesakitan, masalah pengguna menjadi lebih jelas. Saya mengambil semua pembelajaran saya dari sesi potongan kertas dan perbualan dengan pengguna dan pasukan, kemudian menyempitkan masalah pengguna utama kami:

Masalah 1: Pengguna mendapati sukar untuk mendapatkan maklumat yang mereka benar-benar peduli

Perkara pertama yang kebanyakan pengguna lakukan di papan pemuka kami ialah tatal ke bawah. Maklumat yang mereka cari adalah lebih bawah halaman atau memerlukan berbilang klik untuk sampai ke. Ia dikebumikan di sebalik ciri yang kurang penting.

Halaman butiran masalah dalam Fabrik Crashlytics

Masalah 2: Pengguna tidak tahu ciri wujud

Saya pernah bertanya kepada pengguna tentang menambah ciri untuk log apa yang berlaku dalam aplikasi yang membawa kepada kemalangan. Ciri ini sudah wujud di papan pemuka kami - ia hanya dikebumikan di UI. Pasukan sokongan kami mendengar banyak kes serupa dari pengguna juga. Masalah ini juga mencerminkan masalah yang dihadapi oleh pasukan kita sendiri: kesukaran mengetahui di mana untuk meletakkan ciri-ciri.

Halaman terperinci sesi dalam Fabrik Crashlytics

Tema utama yang muncul ialah hierarki maklumat produk kami tidak jelas, yang saya berikan kepada pihak yang berkepentingan sebagai masalah utama yang perlu kita selesaikan. Oleh kerana mereka telah menjadi sebahagian daripada proses reka bentuk sepanjang masa, ia mudah untuk diselaraskan dan mendapat pembelian.

Bagaimana ia berfungsi?

Pasukan secara rasmi membeli-masuk dengan keperluan untuk reka bentuk semula. Mereka memahami masalah yang dimiliki pengguna dan dipersetujui di mana sebahagian daripada pengalaman pengguna memerlukan penambahbaikan. Kejayaan! Langkah seterusnya adalah untuk benar-benar mereka bentuk semula papan pemuka, yang berlaku dalam beberapa bulan akan datang melalui banyak percambahan saranan, kerjasama, daftar masuk, dan ujian pengguna.

Membina kes untuk reka bentuk semula melibatkan satu tan tetapan konteks. Ia mungkin menjadi jelas kepada anda sebagai pereka bahawa produk memerlukan reka bentuk semula, tetapi tidak dapat pergi jauh sendirian. Reka bentuk produk adalah usaha pasukan, dan penting bagi pasukan untuk menyelaraskan mengapa reka bentuk semula diperlukan. Ia juga mustahil untuk mengubah reka bentuk sesuatu jika anda tidak memahami bagaimana ia digunakan sekarang.

Dengan memahami pengguna Crashlytics yang mendalam, masalah kesakitan mereka, dan masalah mereka, saya lebih bersedia untuk mengubah reka bentuk produk. Dan dengan membawa orang lain melalui proses itu, seluruh pasukan dapat lebih memahami pengguna kami dan memenuhi keperluan mereka. Selepas berbulan-bulan bekerja keras dan bercakap dengan pengguna, kami berjaya melancarkan reka bentuk semula Crashlytics dalam Firebase awal tahun ini, memaparkan hierarki maklumat yang lebih baik dan menyegarkan visual, sebagai tambahan kepada beberapa ciri baru!

Untuk membuat kesimpulan, inilah bahagian kegemaran saya dalam reka bentuk Crashlytics:

Animasi animasi apabila pengguna berjaya membaiki pepijat!