Kisah satu desain ulang yang mengubah pendekatan pengembangan di ISPsystem.
Saya bergabung dengan ISPsystem pada April 2016. Saat itu, situasi dengan desain produk adalah sebagai berikut: keputusan produk dibuat oleh manajemen dan programmer, tidak ada desainer atau desainer. Situasi pasar membutuhkan produk dengan "antarmuka lain", sehingga manajemen memutuskan untuk mendesain ulang bagian klien
BILLmanager . Ini seharusnya menjadi balon uji, upaya pertama untuk melakukan sesuatu dengan desain baru.
Saya adalah satu-satunya perancang UX di perusahaan: Saya mempelajari produk yang sudah ada, mempelajari pengguna, berkenalan dengan umpan balik dari mitra dan pemasar mereka. Ini adalah praktik desain produk umum yang mempertimbangkan spesifikasi produk kompleks. Saya sangat dibantu oleh manajer produk, karena dia tahu produk yang terbaik.
Setiap minggu saya menunjukkan hasilnya dalam bentuk prototipe, sirkuit, dll ke manajemen perusahaan. Ini mirip dengan bagaimana desainer klien bekerja dengan pelanggan, dengan semua pro dan kontra: Anda dapat melepaskan diri dari tanggung jawab atas keputusan, hal utama adalah "menjual" mereka kepada manajemen. Tetapi karena saya sudah memiliki pengalaman dalam perusahaan produk dan manajemen memercayai saya dalam hal-hal ini, kami segera bekerja bersama untuk solusi yang saya kembangkan dan berubah menjadi prototipe.
Pengembang bertemu prototipe
Pada Agustus 2016, prototipe klien BILLmanager sudah siap dalam bentuk konseptual mereka. Fungsionalitas versi lama produk telah sepenuhnya ditransfer ke antarmuka baru, dengan beberapa peningkatan. Prototipe dikembangkan dengan baik dari sudut pandang visual, tetapi saya ingin lebih, jadi saya memesan desain visual dari perusahaan pihak ketiga. Namun, kami segera menyadari bahwa upaya ini tidak berhasil, pekerjaan berulang konstan diperlukan pada komponen visual, dan kami membutuhkan desainer visual pada staf. Dalam beberapa bulan, kami mengembangkan bahasa visual kami sendiri. Bahkan, pada saat itu kami memiliki beberapa bagian dari sistem desain masa depan: bahasa visual, elemen dan template.
Secara paralel, mulai sekitar Agustus 2016, pengembang mulai menerapkan antarmuka baru. Orang-orang menganggap prototipe sebagai alternatif dari tugas teknis. Seperti yang terjadi pada saat-saat seperti itu, pertanyaan mulai muncul dalam skala besar, yang bermuara pada satu hal: apakah kita melakukan apa yang programmer dengan cepat dan hanya menerapkan atau apa yang ditemukan dan dirancang oleh seorang desainer? Untuk menyelesaikan masalah ini dengan cepat dan menyederhanakan komunikasi, kami telah menciptakan tim desainer dan front-end.
Departemen UX sebagai tim desainer dan render terdepan
Pada pertengahan musim gugur 2016, departemen UX dibentuk di perusahaan di bawah kepemimpinan saya, yang terdiri dari desainer UX, desainer visual, tender front-end, dan penguji. Tugas utama kami adalah meluncurkan akun pribadi ISPsystem dengan antarmuka baru (kami menggunakan BILLmanager di tempat kami) pada akhir Maret 2017 dan kami memiliki dua kelompok masalah. Pengembang dengan buruk memprediksi waktu pekerjaan mereka, dan kami tidak begitu mengerti bagaimana membangun interaksi antara pengembang dan desainer.
Apa yang kami berikan kepada pengembang
Saat Anda menggunakan Sketch dan Zeplin, interaksi antara desainer dan pengembang sangat sederhana. Tapi kami memiliki 150+ halaman dalam prototipe interaktif, yang kami pelajari untuk digunakan sebagai alternatif TK untuk programmer dan spesifikasi untuk penguji. Kami tidak ingin merender semua 150+ halaman dengan berbagai status di Sketch dan kami sampai pada kesimpulan bahwa kami akan melakukan ini hanya untuk halaman unik. Juga, semua elemen seharusnya muncul di Zeplin: tombol, bidang formulir, dll. Setelah beberapa waktu, kami mempelajari nama pendekatan semacam itu - ini adalah
sistem desain berdasarkan desain atom . Ini masih dalam pengembangan, tetapi desainer dan pengembang sudah menggunakannya. Yang terakhir di perusahaan untuk sistem desain adalah desainer visual.
Sebagai hasilnya, kami menyediakan dua jenis artefak kepada pengembang:
- tata letak apa yang akan menjadi sistem desain di Zeplin (atau lebih tepatnya sudah dalam Figma),
- prototipe produk, alternatif untuk TK dalam bentuk HTML yang dihasilkan dari Axure.
Pada saat yang sama, perancang UX selalu siap memberi tahu pengembang dan penguji apa dan bagaimana seharusnya bekerja dan terlihat.
Scrum dengan desainer
Pada Februari 2017, kami memutuskan untuk meningkatkan akurasi tenggat waktu perkiraan dan mencoba menerapkan Scrum. Kompleksitas Scrum kami adalah bahwa anggota tim sangat berbeda dalam hal kompetensi dan budaya. Desainer tidak seperti programmer: kami merencanakan tugas kami secara berbeda, kami memiliki sikap berbeda terhadap apa yang dianggap hasil yang baik.
Begini cara kami membangun proses:
- desainer berlari ke depan;
- Ada jaminan simpanan prototipe, yang dikerjakan secara umum, di mana Anda dapat melihat seperti apa keseluruhan produk;
- pada saat merencanakan sprint, desainer menyediakan prototipe dan mock-up dari bagian produk yang direncanakan akan dilakukan dalam sprint. Prototipe ini dirinci dan dijelaskan oleh perancang UX ke titik di mana pengembang dapat mengatur dan menguraikan tugas mereka;
- pada saat perencanaan, perancang UX aktif memberi saran kepada pengembang dan penguji tentang apa dan bagaimana cara kerjanya;
- pada saat perencanaan, manajer produk harus memberi tahu perancang UX bagian mana dari produk yang rencananya akan dilakukan dalam sprint berikutnya sehingga perancang UX dapat merencanakan pekerjaannya.
Para pengembang dengan cepat menyadari nilai dari desainer UX, yang dapat dengan cepat ditangani ketika tidak jelas apa dan bagaimana cara kerjanya. Konflik masih terjadi, tetapi praktik Scrum, kerja tim, dan tujuan bersama membantu mengatasinya.
Apa hubungan penguji dengan itu?
Peran penguji dalam proses itu sangat penting. Ini adalah orang yang paling tahu tentang fungsionalitas produk. Penguji adalah orang pertama yang melihat prototipe desainer UX dan dengan cepat memberikan umpan balik dalam hal kepatuhan prototipe dan fungsionalitas. Prototipe yang disetujui menjadi sumber pengetahuan bagi penguji tentang bagaimana produk harus bekerja. Kedua belah pihak tertarik dalam kerja sama yang erat.
Akibatnya, tim tepat waktu merilis antarmuka baru dari akun pribadi ISPsystem. Kami belajar bagaimana bekerja di Scrum, untuk memprediksi pekerjaan departemen UX sebagai tim front-end dan desainer. Dan pada musim panas 2017, mereka menghadapi masalah baru.
BILLmanager adalah produk yang fleksibel. Dan ini merupakan masalah bagi perancang
Ketika seorang desainer menggambar poster, mengeset buku atau membuat sampul untuk majalah, ia bekerja dengan informasi statis. Ini memiliki teks tertentu, gambar tertentu, dan konten lainnya.
Ketika seorang desainer mendesain aplikasi atau antarmuka situs, informasinya tidak statis. Ada informasi tentang apa data itu, tetapi data itu sendiri tidak. Katakanlah ada blog, setiap entri blog memiliki judul, anotasi, tanggal rilis, gambar, dll. Tidak ada judul tertentu, tetapi ada pemahaman bahwa akan selalu ada judul, dan tanggal akan selalu memiliki format tanggal. Tugas menjadi lebih rumit, kami memiliki tipe data, tetapi tidak ada data: kami perlu memikirkan tentang apa kontennya, batasan apa yang dapat dan harus dibebankan padanya. Kemungkinan besar, akan ada nilai artistik yang lebih sedikit daripada poster, tetapi perancang ingin mendapatkan hasil yang akan indah, nyaman dan mudah dimengerti.
Dalam kasus BILLmanager, administrator penyedia hosting dapat mengubah pengaturan sehingga, misalnya, untuk formulir pemesanan server khusus, kumpulan bidang dapat berbeda. Dalam satu kasus, kami pasti akan memiliki prosesor, disk, dan memori, dan yang lain, itu tidak akan (atau akan, tetapi, misalnya, menjadi satu bidang), dan ini tidak dapat diprediksi. Dalam hal ini, perancang bahkan tidak memiliki kumpulan data tetap, kami tidak hanya tahu data spesifik, kami tidak tahu jenis data ini ... dan ini menyulitkan pekerjaan.
Ketika kami mulai membuat versi kotak, penguji mulai memeriksa semua pengaturan yang mungkin dalam BILLmanager. Kemudian menjadi jelas bahwa, di satu sisi, prototipe tidak cukup lengkap untuk menutupi kemungkinan pengaturan BILLmanager yang fleksibel. Di sisi lain, arsitektur produk lama tidak cukup fleksibel untuk menerapkan sejumlah besar ide desain. Dari musim gugur 2017 hingga musim semi 2018, kami mendesain ulang prototipe dan mencari kompromi untuk menyelesaikan masalah ini. Dan dengan beberapa batasan pada pengaturan, mereka merilis
versi kotak dari bagian klien dari BILLmanager 6 Beta pada Mei 2018.
Departemen desainer UX
Sementara departemen UX sedang memecahkan masalah dengan fleksibilitas BILLmanager, manajemen memutuskan untuk memproses antarmuka produk lain perusahaan dan mengimplementasikan Scrum dan proses desain di tim lain. Kami mulai dengan VMmanager 6, mengumpulkan tim produk lengkap dari peserta dengan kompetensi yang berbeda, mandiri untuk menciptakan produk: back-end, front-end, penguji, perancang UX, perancang produk dan manajer proyek. Menjadi jelas bahwa semua produk lain akan secara bertahap dikembangkan oleh tim yang sama, dan kami memulai transisi bertahap ke struktur matriks untuk mengelola pengembangan produk.
Dalam konteks ini, departemen UX seharusnya tidak lagi menjadi salah satu tim produk. Setelah merilis bagian klien dari BILLmanager 6 Beta, sebagian besar departemen UX menjadi bagian dari tim BILLmanager dan sekarang terlibat dalam menyelesaikan masalah arsitektur dan versi mobile dari bagian klien. Pada saat yang sama, kami mulai bekerja pada pembentukan departemen UX yang dapat bekerja dengan semua produk secara bersamaan.
Desainer UX untuk setiap tim produk. Pusat Kompetensi Desain
Sistem ISP memiliki empat produk kompleks. Kami memastikan bahwa setiap tim memiliki desainer UX sendiri. Ini adalah orang yang bertanggung jawab atas desain produknya. Tanggung jawabnya termasuk menyiapkan prototipe untuk perencanaan sprint dan mengendalikan bahwa semua yang diperlukan untuk pengembang adalah dalam versi piksel-sempurna. Dia adalah konduktor kebijakan desain perusahaan untuk timnya. Salah satu tugasnya adalah memastikan bahwa hasil pengembangan adalah produk yang sesuai dengan desain.
Kami juga memiliki beberapa orang yang membentuk pusat kompetensi desain perusahaan. Ini termasuk desainer visual. Pusat ini membentuk kebijakan desain produk perusahaan, bekerja pada sistem desain. Dia juga mengajar desainer UX dalam tim, menyelesaikan masalah desain paling kompleks, mengajar pengembang, manajer produk dan proyek bagaimana bekerja dengan desainer UX, dan mengimplementasikan proses desain dalam tim Scrum.