Menjaga Fitur Tetap Konsisten di Web dan Mobile

Membangun fitur yang sama untuk web dan mobile bukan berarti menyalin tampilan dari satu platform ke platform lain. Keduanya berbagi tujuan produk, tetapi memiliki ukuran layar, pola navigasi, kondisi jaringan, dan siklus rilis yang berbeda.

Menurut saya, konsistensi yang penting bukan membuat semuanya terlihat identik. Pengguna perlu mendapatkan aturan dan hasil yang sama, sementara interaksinya boleh menyesuaikan platform.

Sepakati perilaku inti terlebih dahulu

Sebelum tim membahas komponen UI, tulis alur bisnis dalam bentuk yang tidak bergantung pada platform.

Contoh untuk pengumpulan tugas:

Pengguna memilih tugas yang masih terbuka.
Pengguna melampirkan jawaban.
Sistem memvalidasi tipe dan ukuran file.
Pengguna mengirim jawaban.
Sistem mencatat waktu dan status pengiriman.

Web mungkin menggunakan drag-and-drop, sedangkan mobile membuka camera atau file picker. Perilaku intinya tetap sama: validasi, permission, deadline, dan hasil pengiriman.

Jadikan backend sumber aturan bisnis

Validasi di client penting untuk respons yang cepat, tetapi server tetap harus menjadi sumber kebenaran. Jika deadline hanya diperiksa di web dan mobile, request dari versi lama masih dapat melewati aturan tersebut.

Aturan seperti berikut sebaiknya diputuskan oleh backend:

Hak akses pengguna
Status dan transisi data
Batas waktu
Perhitungan nilai
Duplikasi transaksi
Hubungan antar-entity

Client menerjemahkan hasil aturan menjadi pengalaman yang sesuai untuk platformnya.

Gunakan kontrak yang sama

Type dan schema API yang berbeda antara web dan mobile mudah bergeser seiring waktu. Jika memungkinkan, hasilkan client dari satu schema atau gunakan package type bersama.

type SubmissionStatus = 'draft' | 'uploading' | 'submitted' | 'failed';

type Submission = {
  id: string;
  assignmentId: string;
  status: SubmissionStatus;
  submittedAt?: string;
};

Type bersama tidak berarti seluruh logic harus dibagikan. Ia hanya menjaga agar kedua platform berbicara tentang bentuk data dan status yang sama.

Terima bahwa siklus rilis berbeda

Web dapat diperbarui dalam beberapa menit. Mobile harus melewati proses build, review store, dan keputusan pengguna untuk memperbarui aplikasi.

Akibatnya, backend perlu mendukung lebih dari satu versi mobile untuk sementara. Hindari perubahan API yang langsung mengharuskan semua client menggunakan field baru.

Feature flag juga perlu mempertimbangkan versi aplikasi:

feature enabled
AND user is eligible
AND app version supports the contract

Dengan begitu, fitur dapat dirilis bertahap tanpa membuat versi lama masuk ke alur yang tidak dapat diselesaikan.

Rancang untuk jaringan mobile

Web di desktop sering digunakan dengan koneksi yang relatif stabil. Mobile lebih sering berpindah jaringan atau kehilangan koneksi ketika pengguna berpindah layar.

Beberapa penyesuaian yang biasa diperlukan:

Payload lebih kecil
Upload yang dapat dilanjutkan
Timeout yang realistis
Status progress yang jelas
Penyimpanan draft lokal
Retry untuk operasi yang aman

Jangan menganggap tombol yang sudah ditekan berarti server sudah menerima request. Tampilkan status yang membedakan proses lokal, proses upload, dan konfirmasi server.

Bagikan bahasa desain, bukan semua komponen

Design token seperti warna, spacing, typography, radius, dan istilah status dapat dibagikan. Namun komponen web dan mobile sering lebih sehat jika mengikuti primitive platform masing-masing.

Modal web mungkin lebih cocok menjadi bottom sheet di mobile. Hover state tidak punya padanan langsung pada layar sentuh. Tombol kembali juga memiliki ekspektasi berbeda.

Konsistensi visual sebaiknya membantu pengenalan, bukan memaksa interaksi yang terasa asing.

Uji skenario lintas platform

Jangan hanya menguji web dan mobile secara terpisah. Beberapa bug muncul ketika satu pengguna berpindah perangkat:

Membuat draft di mobile lalu membukanya di web
Mengubah profil di web saat mobile masih menyimpan cache lama
Mengirim data dari dua perangkat
Menerima notifikasi mobile setelah aksi selesai di web
Menggunakan versi mobile lama dengan data dari fitur baru

Skenario lintas platform membantu menemukan konflik state dan asumsi yang tidak terlihat dalam test satu aplikasi.

Dokumentasikan perbedaan yang disengaja

Jika perilaku web dan mobile berbeda, catat alasannya. Tanpa dokumentasi, perbedaan yang memang dirancang dapat dianggap bug, sedangkan perbedaan yang tidak disengaja dianggap normal.

Dokumen tidak perlu panjang. Tabel kecil tentang kemampuan, batasan, dan status implementasi sering sudah cukup untuk menjaga product, design, QA, dan engineering berada pada pemahaman yang sama.

Kesimpulan

Fitur lintas platform membutuhkan satu pemahaman tentang aturan produk dan dua cara menerjemahkannya ke pengalaman pengguna.

Saya berusaha membagikan kontrak, istilah, serta business rules, lalu memberi ruang bagi web dan mobile untuk mengikuti kebiasaan platform masing-masing. Hasilnya tidak selalu identik, tetapi tetap terasa sebagai produk yang sama.