Sangat sering di perusahaan, desain sepenuhnya tergantung pada perancang. Dia bahkan mungkin tiba-tiba mengubahnya sepenuhnya, meskipun ada protes dari "front" dan "mobilshchiki". Kami memiliki pendapat yang berbeda: pandangan dunia internal perancang atau visi pengembang tidak akan terlalu memengaruhi produk. Desain produk adalah bagian nyata dari bisnis yang berinteraksi dengan klien. Perancang tidak dapat memperkenalkan "Wishlist" -nya sendiri, ia harus fokus pada kebutuhan pelanggan. Produk yang bagus berkembang secara organik, dengan memperhatikan pelanggan. Ini berlaku untuk saturasi fungsional dan desain.
Perancang tidak boleh menjadi pembawa persyaratan untuk aplikasi, bisnis harus menentukan apa yang akan terjadi. Tidak peduli siapa yang mengerjakan desain pembayaran ePayments, baik situs dan aplikasi akan indah dan nyaman, dan gaya tidak akan berubah secara dramatis dengan 180 °. Prinsip ini berfungsi untuk kepentingan pengembang frontend dan seluler.
Hari ini, saya, perancang proyek Timur, akan memberi tahu Anda bagaimana kami mendesain ulang aplikasi seluler dan bagaimana sistem desain kami muncul.
Bagaimana semuanya dimulai
Ketika saya pertama kali datang ke proyek, aplikasi tampak seperti ini:
Dan sebelum itu umumnya seperti ini:
Apa yang tidak cocok dengan saya di dalamnya:
1. Aplikasi tidak skala. Awalnya, kami memiliki 2 mata uang (EUR dan USD) dan 2 kartu (untuk mata uang yang sama). Mereka saling berhubungan baik secara visual maupun logis. Bagian dolar adalah kartu dolar dan sebagainya. Kemudian RUB ditambahkan dan seluruh tata letak mulai "pergi". Untuk menambahkan elemen baru harus menggunakan kruk. EPayments memiliki rencana untuk memperluas daftar mata uang dan kami perlu memikirkan cara menambahkannya tanpa kesulitan bagi klien. Perilaku di semua layar harus tetap dapat diprediksi. Jika di satu layar daftar mata uang diproses oleh pola perilaku tertentu, maka di layar lain pola bekerja dengan mata uang harus diulang.
2. Desain usang. Aplikasi ini terlihat sangat "sampah" dan keras, saya ingin lebih banyak udara dan lebih sedikit elemen yang tidak perlu. Mengapa kita perlu gradien dan "kecantikan" jika setelah 5 menit mata mulai lelah dalam aplikasi?
3. Perbedaan desain. Untuk iOS dan Android, ada 2 aplikasi yang secara fundamental berbeda. Jika seseorang beralih dari satu OS ke OS lain, ia kehilangan semua akumulasi pengalaman pengguna. Pemilik Samsung tidak dapat memberi tahu pemilik iPhone bagaimana melakukan operasi.
4. Alur kerja yang tidak optimal. Ketika kami memiliki cara baru untuk mentransfer dana dari dompet, tugas ini sampai pada analis yang membuat mocap. Kemudian dia mendatangi saya dan sebuah layar ditarik untuk diterjemahkan. Kemudian pengembang seluler mengubah semuanya menjadi kode dan menabraknya ke dalam aplikasi. Ini adalah proses yang tidak sehat, dari mana dimungkinkan untuk membuang 80% dari biaya tenaga kerja. Anda dapat menghemat banyak waktu di sini hanya dengan menghilangkan perancang dari jalur perakitan. Jika ada elemen antarmuka yang sudah jadi, Anda dapat merakit jendela terjemahan dari mereka.
Merancang masa depan yang lebih cerah
Maka saya mulai bekerja. Pertama-tama, saya ingin membuat aplikasi yang ramah pengguna. Layanan keuangan umumnya tidak boleh menempati pelanggan lama. Di dalamnya Anda perlu menavigasi dengan cepat, memilih operasi, menjalankannya, dan melanjutkan bisnis Anda lebih jauh.
Konstanta penting lainnya adalah keramahan pengembang. Jika kita memiliki chip baru, mata uang atau layanan, front dan mobilisator seharusnya tidak menderita dan membangkitkan semua gaya. Mereka hanya menambahkan fitur baru yang terlihat jelas dan diharapkan.
Saya mencari analogi yang paling sederhana dan menyadari bahwa kami membutuhkan konstruktor jendela. Kami memiliki serangkaian kontrol (kembali, maju, pemilihan akun, memasukkan detail) dan aturan untuk bekerja dengannya (warna, indentasi, ukuran elemen). Dalam perancang, analis dan pekerja seluler dapat membuat kartu layanan dan modal baru sendiri tanpa mendatangi saya "untuk tunduk".
Penting untuk mempertimbangkan bahwa produk berkembang luas. Hari ini kami memiliki 3 mata uang, dalam setahun mungkin ada 33. Hari ini kami memberikan 15 cara untuk mentransfer uang, besok akan menjadi 115. Dalam aplikasi, entitas yang benar-benar baru dapat muncul: kartu virtual, pembelian stok, atau layanan lainnya.
Buang belenggu keterbatasan
Masalah : proyek memiliki semakin banyak elemen - mata uang, metode transfer, dan sebagainya. Banyak elemen yang disusun secara horizontal, semakin banyak, semakin tidak nyaman untuk menggunakannya.
Solusi : sediakan ekspansi terlebih dahulu, pilih posisi elemen yang nyaman.
Masalah utama dari versi sebelumnya adalah penskalaan. Jadi, kami memiliki layar bersyarat dengan resolusi 480 * 720 px. Dan di atasnya secara horizontal ada 3 tab dengan metode transfer uang. Nah, besok mereka akan berusia 15. Siapa yang waras akan menggulir 15 tab ke kanan? Atau apakah Anda perlu membuatnya berukuran mikro sehingga Anda bisa menggunakannya hanya dengan jari kelingking?
Dalam ePayments, klien memiliki satu dompet dengan beberapa bagian mata uang. Elemen yang paling dapat diukur dari UI seluler adalah daftar. Itu bisa terbalik hampir tanpa akhir dengan gerakan yang sangat akrab. Sekalipun ada elemen yang tiba-tiba terlalu banyak, Anda selalu dapat mempercepat filter atau mencari.
Batas kenyamanan sekitar 10 mata uang atau metode transfer. Ketika ada lebih banyak dari mereka, kita akan menghubungkan mekanisme kedua, yang sekarang dalam pengembangan - bagian yang dipilih. Klien sendiri memilih bagian mata uang mana yang lebih penting baginya dan menandainya dengan tanda bintang. Atau buat dashboard Anda di konstruktor, seperti layar mulai di Jira.
Selain itu, saya punya "burger" di sebelah kiri dan sebuah bar di bagian bawah. Operasi paling penting yang kami tempatkan di panel bawah. Pertama-tama, Anda melihat keseimbangan bagian dan kartu. Kemudian Anda dapat pergi ke resepsi atau transfer, melihat riwayat transaksi atau menukar mata uang. Semua hal yang kurang penting saya taruh di "burger". Sekarang terdapat kebohongan, misalnya, program afiliasi yang jarang diakses.
Oke, masalahnya teratasi, pergi ke yang berikutnya.
Kami menyimpan perbedaan di masa lalu
Masalah : Aplikasi iOS dan Android tidak sama. Desain mereka sudah ketinggalan zaman, antarmuka memiliki banyak elemen tambahan. Sulit bagi klien untuk berkonsentrasi, ia cepat lelah.
Solusi : membuat aplikasi sesuai dengan pedoman, tetapi dengan desain terpadu. Bersihkan dari gradien, kerjakan kegunaan.
Seperti yang saya katakan, versi untuk Android dan iOS adalah aplikasi yang secara fundamental berbeda. Tidak ada yang baik untuk klien atau kita. Selain itu, pengembang mengalami masalah dalam meluncurkan fitur dan pengujian baru. Karena itu, kami memutuskan untuk membawa semuanya ke satu bentuk.
Anda tidak dapat membuat aplikasi yang identik. Google memiliki Desain Material, Apple memiliki Antarmuka Manusia. Tetapi elemen dasar yang kami buat serupa. Grid, sebagian besar kontrol dan susunan blok menjadi sama. Kontrol yang bertanggung jawab untuk struktur dasar disesuaikan dengan panduan sistem operasi. Solusi termudah adalah dengan sepenuhnya port aplikasi. Tapi ini lebih merupakan tanda kemalasan dan ketidaktahuan pemandu. Dan panduan ditulis oleh orang-orang yang berkali-kali lebih pintar dari kita, perlu mendengarkan mereka.
Pertama kami memperbarui aplikasi di Android. Itu lebih murah di "poin cerita", sebagian besar pelanggan kami menggunakan OS ini. Selain itu, pada titik tertentu kami memiliki ketidakseimbangan dalam tim pengembangan seluler - ada lebih banyak orang di tim pengembangan Android dan kami dapat mengalokasikan sebagian dari mereka untuk dirancang ulang. Versi ini telah maju dan versi untuk iOS sekarang secara bertahap menyusulnya.
Ini didasarkan pada panduan Desain Bahan dan berkat ini kami memiliki aplikasi di mana seseorang dengan Xiaomi bersyarat akrab dengan segalanya. Dia dengan cepat belajar bagaimana mengiriminya uang yang diperoleh ke kartu bank.
Ketika kami meluncurkan desain ulang, kami mulai mengumpulkan reaksi dan kritik yang membangun. Pertama, ada aliran negatif kecil dari mereka yang tidak suka mendesain ulang sebagai fenomena. Ini normal dan tidak perlu takut. Setiap layanan dihadapkan dengan ini. Kemudian semuanya menjadi tenang dan Anda dapat mengumpulkan informasi yang berguna.
Pada awalnya, peringkat turun sedikit, lalu kembali ke 4.6. Kami membuat beberapa komentar kritis dan ulasan menjadi baik dan baik lagi. Mulai saat ini, Anda dapat menggunakan aplikasi untuk iOS.
Sekarang aplikasinya sangat mirip. Beberapa hal sengaja dilakukan tidak sesuai dengan pedoman, tetapi metrik utama adalah reaksi pelanggan. Segalanya tampak nyaman bagi pengguna: penilaian tidak berubah, kami berterima kasih atas desain ulang di ulasan.
Fakta bahwa aplikasi menjadi serupa tercermin dalam pengembangan. Sekarang mereka lebih mudah untuk diuji, kasus-kasus di Testrail sama. Semua dokumentasi kasus digandakan - secara alami, sebagaimana diubah. Misalnya, ketika kami sedang menyiapkan fitur dalam aplikasi iOS, JSON sudah memiliki Android dan pengembang tidak harus masuk ke permintaan.
Kami memberikan tampuk pemerintahan
Masalah : Proses pengembangan tidak dioptimalkan. Setiap kartu terjemahan baru diambil dan dikembangkan dari awal.
Solusi : buat satu set elemen dan aturan siap pakai, mengubah proses menjadi "perancang".
Ide desainer muncul bersamaan dengan desain ulang aplikasi, tetapi kami menerapkannya sedikit kemudian. Seperti yang saya katakan, aplikasi seharusnya tidak tergantung pada saya. Jika kami memperkenalkan fitur baru, maka tugas beralih dari analis ke pengembang seluler. Mereka merakit jendela dari kontrol yang sudah selesai, memeriksa gaya, margin, dan yang lainnya - dan voila, jendela sudah siap. Saya dapat membuat ikon, tetapi partisipasi langsung saya harus berakhir di sana.
Pertama, saya menggambar setiap layar secara terpisah. Kemudian ia mengelompokkan elemen berulang: daftar, kontrol, tombol, ilustrasi, layar konfirmasi, dan sebagainya. Ketika aplikasi sudah siap, saya memiliki UI komponen lengkap.
Lihatlah unsur-unsurnya, setiap orang memiliki sesuatu yang serupa:
• pos
• "kembali"
• ahli droplist
• garis untuk memasukkan detail
• "selanjutnya"
Kami melakukan elemen-elemen ini sebelumnya. Plus, kami menyiapkan panduan untuk warna, lekukan dan font. Pada output, kami mendapatkan konstruktor di mana pengembang mengubah gambar dalam Paint bersyarat dari analis menjadi jendela terjemahan selesai.
Secara alami, pekerja mobile harus bekerja untuk mengubah banyak layar menjadi sistem komponen yang rapi. Tapi itu terjadi pada mereka sesudahnya: tidak perlu lagi pergi ke Zeplin untuk tata letak layar, memperbaiki dan menyimpannya di masa depan. Ada komponen, ada style sheet yang ketat.
Untuk meringkas
Saya suka apa yang kami lakukan. Aplikasi ini menjadi lebih indah, sangat dihargai oleh pelanggan. Menjadi lebih mudah bagi front dan mobilisator untuk bekerja.
Kami belum sepenuhnya menggunakan metrik yang menunjukkan bagaimana perilaku pengguna telah berubah. Jadi sekarang kita hanya bisa menilai berdasarkan penilaian dan ulasan pelanggan. Peringkat tetap sama - 4,6 di Google Play, 4,8 di AppStore. Sebagian besar ulasan negatif berkaitan dengan proses verifikasi, tampaknya bagi pelanggan untuk waktu yang lama. Dan secara positif, aplikasi ini sering dipuji.
Metrik lain, hanya internal: Saya sangat jarang membuka file sketsa dengan proyek seluler. Pengembang menambahkan cara baru untuk menyetor dan menarik tanpa saya. Ini berarti bahwa komponen UI berfungsi dan saya dapat membuat desain sistemik, tanpa kediktatoran perancang.
Sekarang kami berencana untuk membawa produk ke satu tampilan di platform yang berbeda, termasuk versi desktop. Selain itu, kami berencana untuk "menyekop" seluruh struktur skenario fitur dalam aplikasi seluler sehingga klien menghabiskan lebih sedikit waktu untuk operasi. Nah, pada saat yang sama, kita akan meninggalkan burger di sebelah kiri - ini adalah pola yang sudah ketinggalan zaman, ada pilihan yang lebih nyaman.
Mencari pekerjaan?
Kami mencari karyawan untuk bekerja di kantor di St. Petersburg. Jika Anda tertarik dengan fintech, kami menunggu Anda. Di bawah ini Anda akan menemukan lowongan dan tautan ke halaman terkait hh.ru.