Studi kasus desain produk end-to-end tentang penemuan menu, pemesanan, dan layanan meja dalam konteks hospitality Indonesia.
Tamu restoran perlu membuat beberapa keputusan sebelum makanan sampai di meja. Mereka perlu memahami menu, memilih hidangan, memeriksa biaya, menentukan cara membayar, dan mengetahui apa yang terjadi setelah pesanan dikirim. Masing-masing keputusan terlihat sederhana, tetapi friksi muncul ketika urutannya tidak jelas atau tamu harus mengambil keputusan sambil menunggu orang lain.
Saya mengeksplorasi bagaimana pengalaman pemesanan melalui tablet untuk Plataran dapat membuat urutan tersebut lebih mudah dipahami, sekaligus tetap mencerminkan karakter dining Indonesia. Saya mengerjakan seluruh proses desain secara mandiri, mulai dari problem framing dan eksplorasi persona hingga information architecture, wireframe, dan high-fidelity screens.
Studi kasus ini mengikuti perjalanan dari problem framing dan tema riset, eksplorasi persona, customer journey, information architecture, wireframe, hingga high-fidelity screens. Bagian akhir membahas pertimbangan produk dan validasi yang diperlukan untuk pengalaman dining yang dapat diandalkan.
Arah visual membawa identitas dining Plataran ke dalam antarmuka pemesanan.
🧭 Konteks Proyek dan Problem Framing
Proyek ini bergerak dari pemahaman terhadap masalah pemesanan menuju definisi model interaksi yang diusulkan. Tema riset membentuk tujuan; persona membuat tujuan tersebut konkret; information architecture dan sketsa mengatur perjalanan; visual design menerjemahkannya menjadi pengalaman tablet.
Setiap tahap menghubungkan masalah pemesanan dengan keputusan desain. Tema riset menetapkan prioritas, sedangkan flow, sketsa, dan screen menunjukkan bagaimana prioritas tersebut membentuk perjalanan tamu.
Gambaran Umum dan Konteks Proyek
Plataran menjadi konteks yang relevan untuk mengeksplorasi self-ordering karena pengalaman dining lebih luas daripada sekadar memilih produk dari katalog. Identitas dining Indonesia, penyajian makanan, dan suasana restoran membentuk ekspektasi tamu terhadap layanan. Karena itu, antarmuka transaksi perlu terasa terhubung dengan makanan dan venue.
Brief berfokus pada periode layanan yang sibuk, terutama makan siang dan makan malam, ketika pertanyaan tentang pemesanan, pembayaran, dan tempat duduk dapat saling berebut perhatian. Respons yang diusulkan adalah aplikasi touchscreen atau tablet yang memungkinkan tamu menjelajahi menu, menyusun pesanan, memilih jalur layanan, dan membayar.
Scope saya mencakup analisis riset, pengembangan persona, information architecture, user flow, paper wireframe, visual design, dan eksplorasi prototype. Deliverable desain mencakup perjalanan yang dihadapi tamu dari welcome hingga konfirmasi pesanan.
Tantangan produknya adalah memberi tamu kontrol yang cukup untuk menyelesaikan keputusan pemesanan rutin tanpa membuat pengalaman restoran terasa impersonal. Hal ini berarti mempertimbangkan tone welcome screen, cara memperkenalkan hidangan yang belum dikenal, visibilitas detail pesanan, dan hubungan antara pesanan dengan lokasi layanan yang dituju.
Problem Statement dan Friksi dalam Pemesanan
Problem framing berpusat pada empat isu: antrean di kasir, ketidakpastian tempat duduk, keputusan yang terburu-buru, dan pilihan pembayaran yang terbatas. Saya memperlakukannya sebagai bagian yang saling terhubung dari satu perjalanan, bukan sebagai permintaan terpisah untuk membuat screen baru.
Menunggu di titik pemesanan
Proses yang berpusat pada kasir dapat menumpuk beberapa aktivitas di satu titik. Tamu mungkin masih membaca menu ketika gilirannya tiba, lalu bertanya, mengonfirmasi pesanan, dan membayar sebelum tamu berikutnya dapat dilayani. Pertanyaan desainnya adalah apakah sebagian persiapan tersebut dapat dilakukan melalui interface, dengan bantuan staf ketika diperlukan.
Tujuannya adalah mengurangi ketergantungan pada satu handoff transaksional. Menu yang menarik saja tidak cukup jika tamu masih harus mengulang seluruh pesanan di counter.
Ketidakpastian tentang lokasi dining
Brief juga menggambarkan kebingungan tentang tempat duduk yang tersedia dan lokasi tamu akan menerima makanan. Keduanya berkaitan, tetapi membutuhkan jawaban berbeda. Seating menyangkut tempat yang sesuai untuk dining; delivery identification menyangkut tujuan pesanan tertentu.
Desain mengeksplorasi table-service code sebagai bagian dari perjalanan pemesanan. Code memberi interface cara menghubungkan pesanan dengan penanda fisik, sementara pertanyaan operasional tentang pengelolaan kursi dan marker tetap perlu dijawab pada tahap produk.
Memilih dalam keadaan terburu-buru
Menu perlu mendukung perbandingan, terutama ketika nama hidangan atau bahan belum familiar. Jika tamu baru mulai membandingkan saat tiba di kasir, tekanan untuk segera selesai dapat mengalahkan informasi yang dibutuhkan untuk memilih.
Respons desainnya adalah menyediakan kategori, foto makanan, deskripsi, dan harga sebelum checkout. Tamu dapat menjelajahi menu dan meninjau pilihannya dalam interface yang sama, bukan memadatkan discovery dan commitment ke dalam satu interaksi.
Menyesuaikan preferensi pembayaran
Brief memasukkan kartu debit dan kredit, QRIS, serta uang tunai sebagai preferensi pembayaran yang perlu dipertimbangkan. Konsep self-ordering yang berguna perlu menjelaskan posisi pembayaran dalam perjalanan, termasuk cara tamu yang tetap memilih interaksi di counter menyelesaikan pesanan.
Information architecture mempertahankan jalur pembayaran di aplikasi dan di counter. Payment screen high-fidelity menunjukkan pilihan kartu dan QRIS. Perbedaan antara flow yang lebih luas dan screen yang benar-benar divisualisasikan penting saat menilai kelengkapan konsep.
🔎 Riset dan Definisi Pengalaman
Riset dan Analisis
Input riset berpusat pada empat tema: permintaan saat periode layanan sibuk, kesulitan memilih dari menu yang luas, keterbatasan informasi tentang ketersediaan meja, dan kebutuhan akan beberapa metode pembayaran.
Tema-tema tersebut mengarahkan pekerjaan pada pemahaman menu, visibilitas pesanan, koordinasi table service, dan pilihan pembayaran. Tema itu juga membentuk pertanyaan yang nantinya perlu diuji bersama tamu dan staf.
Mengubah tema menjadi pertanyaan desain
Langkah pentingnya adalah menerjemahkan setiap tema menjadi pertanyaan yang dapat dijawab desain. Untuk demand yang tinggi, pertanyaannya adalah di mana tamu dapat menyiapkan pesanan tanpa bergantung pada kasir untuk setiap pilihan. Untuk menu yang kompleks, pertanyaannya adalah bagaimana interface mendukung discovery sebelum meminta commitment.
Untuk ketidakpastian tempat duduk, pertanyaannya adalah bagaimana pesanan membawa informasi layanan yang cukup agar sampai ke tamu. Untuk preferensi pembayaran, pertanyaannya adalah bagaimana pengalaman menawarkan pilihan yang mudah dikenali tanpa memaksa semua tamu memakai metode yang sama.
Pertanyaan-pertanyaan ini menghubungkan masalah dengan mekanisme yang diusulkan. Order summary yang terlihat membantu tamu memeriksa jumlah dan biaya sebelum membayar. Table-code field dapat menangkap hubungan dengan tujuan pengantaran. Namun, tidak satu pun fitur tersebut dengan sendirinya membuktikan antrean lebih pendek atau makanan dikirim ke lokasi yang benar.
Sintesis menjadi arah produk yang koheren
Tema-tema tersebut mengarah pada sequence yang dipandu: memperkenalkan pengalaman, membantu tamu menjelajahi menu, membiarkan mereka memeriksa dan mengubah pesanan, menetapkan konteks layanan, lalu memperjelas langkah setelah pembayaran.
Interaksi sebaiknya meminta informasi ketika informasi itu memang relevan. Menu discovery membutuhkan starting point yang ringan. Order review membutuhkan detail. Payment membutuhkan commitment dan respons yang jelas. Menampilkan semuanya sekaligus akan membuat welcome screen memikul keputusan yang seharusnya muncul di tahap berikutnya.
Arah produk akhirnya adalah konsep tablet ordering dengan navigasi yang terlihat dan hubungan yang konsisten dengan cart. Wireframe berikutnya memiliki tugas yang jelas: membuat sequence mudah dipahami, bukan sekadar membagi konten yang sama ke lebih banyak halaman.
Tujuan Desain
Tujuan desain digunakan untuk mendefinisikan dukungan yang dibutuhkan interface. Mengurangi waktu tunggu berarti memungkinkan persiapan pesanan rutin melalui aplikasi. Menyederhanakan menu berarti mengelompokkan hidangan dengan jelas dan meletakkan informasi yang cukup dekat dengan setiap item agar tamu dapat membandingkan pilihan.
Tujuan table service berarti menghubungkan pesanan dengan lokasi pengantaran. Fleksibilitas pembayaran berarti mengakui cara berbeda yang mungkin dipilih tamu, termasuk jalur dengan bantuan counter dalam flow yang lebih luas.
Tujuan tersebut membawa trade-off. Informasi produk yang lebih lengkap membantu pilihan, tetapi terlalu banyak informasi dapat memperlambat scanning. Review step tambahan memperpanjang interaksi, namun memberi kesempatan memperbaiki pesanan sebelum commitment. Cabang pembayaran dan layanan menambah pilihan sekaligus kompleksitas.
Respons desain saya adalah menjaga interaksi awal tetap fokus dan membuka detail secara bertahap. Welcome screen menawarkan satu starting action. Browsing menampilkan kategori dan rekomendasi. Detail item dibuka ketika diminta. Order review mengumpulkan informasi yang dibutuhkan untuk commitment.
Eksplorasi Persona
Alex Walker merepresentasikan situasi target konsep ini: seorang project manager berusia 32 tahun di Jakarta Selatan yang menyeimbangkan hari kerja padat dengan waktu makan siang yang terbatas. Ia menginginkan makanan yang baik dan proses yang praktis, tanpa menghabiskan sebagian besar waktu istirahat untuk menunggu atau mengambil keputusan secara terburu-buru.
Alex menjaga kebutuhan yang konsisten selama flow dirancang. Label kepribadian dan demografi memberi konteks; batasan yang paling berpengaruh adalah waktu yang terbatas, keinginan terhadap kualitas makanan, dan preferensi terhadap interaksi digital yang jelas.
Persona Alex menjaga situasi pemesanan saat makan siang tetap terlihat sepanjang proses desain.
Tujuan dan motivasi
Persona menggabungkan efisiensi, kualitas makanan, dan minimnya waktu tunggu yang tidak perlu. Tujuan tersebut mencegah konsep mengoptimalkan kecepatan dengan mengorbankan pilihan. Alex tetap perlu memahami apa yang dipesan dan merasa nyaman dengan biayanya.
Tujuan dan motivasi.
Karena itu desain mempertahankan foto makanan dan deskripsi bahan, bukan mengubah menu menjadi daftar nama yang padat. Editable review step juga tetap menjadi bagian journey. Jalur yang cepat tetapi berujung pada pesanan yang salah akan gagal memenuhi kebutuhan pengguna yang sama-sama ingin dilayani.
Pain point dan ekspektasi
Artefak persona menunjukkan waktu makan siang yang terbatas, keputusan yang terburu-buru, pembayaran yang tidak nyaman, serta frustrasi karena antrean atau ketidakpastian seating. Pengalaman yang diharapkan adalah mudah dipelajari, jelas dinavigasi, dan kompatibel dengan metode pembayaran yang familiar.
Pain point.
Perilaku.
Kebutuhan pengguna.
Frustrasi.
Ekspektasi tersebut diterjemahkan menjadi keputusan yang terlihat: category navigation, running order panel, quantity controls, table-service code, dan payment selection. Hal ini belum cukup untuk mengasumsikan semua tamu akan memilih kiosk atau datang sendirian. Keluarga, grup besar, dan tamu yang membutuhkan bantuan staf tetap perlu dipertimbangkan sebelum rollout nyata.
Customer Journey dan Urutan Pengalaman
Customer journey map mengorganisasi pengalaman menjadi arrival, menu browsing, order review, table code dan payment, lalu dining. Map ini menghubungkan pilihan di layar dengan pergerakan fisik tamu di venue.
Saat tiba, tamu membutuhkan orientasi. Saat browsing, kebutuhannya bergeser menjadi pemahaman menu. Saat review, akurasi dan biaya menjadi utama. Saat payment, tamu membutuhkan keyakinan bahwa transaksi dan pesanan sudah bergerak maju. Saat dining, layanan harus mengirimkan makanan dan menyediakan bantuan.
CJM menghubungkan action, touchpoint, thought, pain point, emosi, dan opportunity dalam sequence dining lima fase.
Map juga membuat handoff terlihat. Interface dapat menangkap identitas meja, tetapi staf tetap perlu menafsirkannya secara konsisten. Interface dapat mengonfirmasi pesanan dikirim, tetapi fulfillment bergantung pada apa yang terjadi di luar layar.
CJM menggunakan thought yang dibayangkan dan kurva emosi yang membaik untuk mengeksplorasi pengalaman yang diinginkan. Elemen ini bukan bukti customer satisfaction. Map berkontribusi sebagai sequence kebutuhan tamu dan pertanyaan untuk setiap service handoff.
✍️ Dari Journey ke Interface
Information Architecture dan User Flow
Architecture dimulai dari welcome screen dan memisahkan dine-in dari takeaway. Keduanya bergerak melalui menu browsing, product selection, order details, checkout, dan payment preference. Struktur ini mencakup scope layanan yang lebih luas daripada walkthrough screen final.
Untuk dine-in, flow mempertimbangkan pembayaran di aplikasi atau counter, lalu table service atau counter pickup. Jalur table service mencakup pengisian nomor meja. Takeaway mengarah ke pickup dengan pilihan pembayaran yang berbeda.
Bagian akhir flow menunjukkan payment-method selection, eksekusi pembayaran, payment status, pencetakan order, dan penyelesaian journey. Ini adalah completion path yang diinginkan, bukan dokumentasi seluruh failure dan recovery state.
Information architecture menghubungkan dine-in dan takeaway dengan pilihan payment serta fulfillment. Pemilihan metode dan konfirmasi pembayaran ditunjukkan sebagai sequence penyelesaian bersama.
User flow menunjukkan browsing, pemilihan item, order review, pengisian table code, payment, dan cabang layanan. Pernyataan waktu sebelum-sesudah, pengurangan antrean, validasi heatmap, dan routing tanpa staf adalah skenario yang diinginkan, bukan hasil terverifikasi atau hasil yang sudah diimplementasikan.
Mengapa service mode dipisahkan
Dine-in dan takeaway dapat berbagi menu yang sama, tetapi membutuhkan informasi fulfillment yang berbeda. Pesanan dine-in mungkin perlu dihubungkan dengan meja atau service marker. Pesanan takeaway membutuhkan ekspektasi pickup yang jelas. Pemisahan mode memberi screen berikutnya cara meminta informasi yang relevan saja.
Trade-off-nya adalah pilihan mode di awal menambah satu keputusan sebelum browsing. Dalam architecture, keputusan itu menetapkan service route. Sequence high-fidelity berfokus pada dine-in/table service, jadi penanganan takeaway secara lengkap tidak boleh disimpulkan hanya dari screen tersebut.
Bagian architecture yang belum terselesaikan
Flow memuat pilihan pembayaran di lebih dari satu titik. Flow juga menggabungkan jalur counter dan in-app dengan sequence payment bersama di bagian berikutnya. Ini adalah design gap yang penting dicatat karena arti setiap pilihan menentukan apa yang seharusnya dilihat tamu setelahnya.
Diagram menetapkan cakupan yang diinginkan, tetapi production specification membutuhkan perbedaan konsisten antara lokasi pembayaran, metode pembayaran, tipe fulfillment, dan status transaksi. Pertimbangan produk di bawah menjelaskan cara menyederhanakan keputusan tersebut.
Paper Wireframing
Sketsa kertas menunjukkan sembilan screen yang diusulkan: welcome, pemilihan dine-in atau takeaway, menu browsing, My Order, payment preference, service choice, table-code entry, payment options, dan confirmation. Sketsa menangkap sequence interaksi sebelum treatment high-fidelity.
Paper wireframe. Sketsa memperlihatkan mode dan pilihan service yang tidak semuanya muncul sebagai screen terpisah dalam walkthrough high-fidelity.
Hal yang dijelaskan oleh sketsa
Sketsa menu menetapkan hubungan antara category navigation dan area konten utama. Sketsa order menyatukan item terpilih dan jumlahnya untuk ditinjau. Sketsa service dan table code mengeksplorasi bagaimana pesanan digital membawa konteks pengantaran fisik.
Pemisahan payment preference dari payment options juga memperlihatkan pertanyaan yang ingin dijawab architecture: di mana tamu membayar dan metode apa yang dipakai. Keduanya terlihat, meskipun flow berikutnya masih membutuhkan klarifikasi tentang urutan dan cabangnya.
Tahap ini penting karena alasan di balik desain dapat diperiksa tanpa bergantung pada visual polish. Sebuah screen dapat terlihat meyakinkan tetapi mengajukan pertanyaan yang salah pada waktu yang salah. Sketsa menjadi catatan bagaimana konsep membagi pertanyaan tersebut sepanjang journey.
Sketsa menjelaskan struktur interaksi dan hubungannya dengan high-fidelity screen. Usability testing bersama partisipan tetap dibutuhkan untuk menilai apakah tamu dapat mengikuti sequence dan pulih ketika keputusan tidak jelas.
Arah Visual Design
Konsep high-fidelity menggunakan referensi visual Plataran untuk menghubungkan ordering interface dengan lingkungan dining. Warna hangat, action button cokelat gelap, foto makanan, dan logotype restoran memberi identitas yang konsisten.
Format tablet memungkinkan pemisahan yang jelas antara navigasi dan konten menu. Kategori berada di panel kiri yang persisten, sedangkan area utama menampilkan hidangan atau task aktif. Layout ini mendukung pergantian kategori tanpa menyembunyikan status order di balik menu navigasi lain.
Foto memiliki peran khusus: membantu tamu mengenali dan membandingkan hidangan. Nama dan deskripsi tetap penting, terutama untuk bahan lokal yang belum tentu dikenali pengunjung pertama kali. Visual dapat mengundang eksplorasi, tetapi informasi perlu membantu keputusan setelah sebuah item menarik perhatian.
Welcome, service-code, dan payment screen menggunakan imagery restoran sebagai konteks. Menu dan review screen menyediakan ruang lebih besar untuk konten terstruktur. Perbedaan ini mencerminkan pekerjaan tiap momen: orientasi, pilihan, verifikasi, dan commitment.
Touch target, kontras teks di atas foto, keterbacaan pada sudut pemasangan perangkat, dan penggunaan oleh orang dengan tingkat familiaritas digital yang berbeda perlu diperhatikan ketika arah visual ini dikembangkan.
📱 High-Fidelity Screen dan Alasan Interaksi
Walkthrough final berisi delapan screen. Setiap screen menangani keputusan tertentu sambil menghubungkannya dengan langkah berikutnya. Pertanyaan utamanya adalah bagaimana keputusan tersebut membantu tamu melanjutkan perjalanan dengan informasi dan kontrol yang cukup.
Screen Satu: Welcome
Welcome screen menggunakan foto ruang dining, pengantar singkat tentang pengalaman restoran, dan action Start Order. Tujuannya menetapkan konteks dan membuat langkah pertama terlihat jelas.
Welcome screen menghubungkan ordering interface dengan venue dan memberi tamu satu starting action.
Satu primary action mencegah momen awal memikul seluruh konfigurasi layanan. Tamu dapat memahami cara memulai sebelum berhadapan dengan hidangan, quantity control, atau detail payment. Brand treatment membuat screen sesuai dengan venue, tetapi tidak boleh membuat action sulit ditemukan.
Foto dan copy pada screen menyampaikan atmosphere. Keduanya tidak membuktikan keandalan transaksi setelahnya. Dalam setting nyata, orientasi yang jelas atau opsi bantuan dapat membantu tamu yang belum pernah menggunakan sistem pemesanan ini.
Screen Dua: Order Now
Order Now menempatkan kategori dan rekomendasi dalam satu view. Panel kiri berisi Recommendation, promosi prototype, Appetizer, Main Course, Beverage, dan Dessert. Area utama menampilkan category card dan recommendation grid, sementara order panel memberi akses ke item yang dipilih.
Navigasi menu dan jalur yang terlihat menuju My Order tetap tersedia saat tamu menjelajahi hidangan.
Menu Main Course
Grid memungkinkan tamu memindai satu kategori dan memeriksa item yang menarik. Penempatan informasi yang konsisten membuat perbandingan lebih mudah karena tamu tidak perlu mempelajari ulang posisi nama atau harga setiap hidangan.
Untuk menu Indonesia, nama hidangan dan referensi bahan dapat memiliki makna budaya namun tetap asing bagi sebagian pengunjung. Gambar memperkenalkan hidangan; teks pendamping perlu membantu pemahaman. Foto saja tidak dapat menjawab pertanyaan tentang bahan, proses, atau kesesuaian hidangan.
Screen Empat: Item Detail
Memilih hidangan membuka modal di atas menu. Contoh Sapi Kecombrang berisi foto, deskripsi, harga, quantity control, serta action Cancel dan Add to Order.
Detail modal menjaga tamu tetap berada dalam konteks browsing saat mengambil keputusan untuk satu item.
Modal mempersempit task. Tamu dapat memeriksa satu item, memilih jumlah, lalu menambahkannya atau kembali ke menu. Menu yang tetap terlihat di belakang menjaga orientasi dan mencegah setiap pemeriksaan produk berubah menjadi perjalanan full-page.
Pilihan ini juga menciptakan constraint desain: modal harus tetap terbaca dan mudah ditutup pada shared touch device. Konsep menyediakan pattern-nya, sedangkan focus handling, touch behavior, dan detail customization membutuhkan spesifikasi sebelum implementasi.
Screen Lima: My Order
My Order mengumpulkan hidangan terpilih dalam view itemized dengan harga, jumlah, dan total per item. Summary menampilkan subtotal, baris pajak prototype, total, quantity editing, dan action checkout. Field discount atau gift juga ditampilkan.
Review screen memperlihatkan jumlah item dan total pesanan sebelum checkout.
Langkah ini menyediakan kesempatan koreksi sebelum commitment. Nilainya tetap ada walaupun menambah satu screen. Perubahan di sini dapat lebih mudah daripada mengoreksi order setelah payment atau setelah dapur mulai menyiapkan makanan.
Summary juga menjadikan biaya bagian dari review. Data item dan total yang sama perlu konsisten sampai payment dan fulfillment; jika tidak, kejelasan yang dibangun di sini hilang pada saat commitment.
Screen Enam: Table Code Entry
Table-code screen meminta tamu mengambil service marker dan memasukkan code-nya. Contoh menampilkan 27, dengan keypad numerik dan route kembali atau home.
Service-code screen meminta tamu menghubungkan pesanan dengan service marker fisik.
Code menghubungkan pesanan digital dengan titik layanan fisik. Tamu memiliki cara eksplisit untuk memberikan konteks pengantaran, bukan membiarkan informasi tersebut berada di luar interaksi.
Service model perlu menentukan apakah identifier menunjuk meja tetap atau marker yang dapat dipindahkan. Model juga perlu menjelaskan siapa yang memberikannya, bagaimana perpindahan lokasi ditangani, dan apakah seat assignment berlangsung di tempat lain. Keputusan tersebut menentukan informasi yang dapat diandalkan oleh tim dapur dan floor.
Screen Tujuh: Payment Options
Payment screen menampilkan pilihan kartu dan QRIS dalam panel yang fokus, dengan QRIS terpilih pada state yang diilustrasikan. Action Pay mengikuti pemilihan metode.
Payment screen membuat pilihan kartu dan QRIS terlihat sebelum action Pay.
Desain menggunakan label dan payment mark yang mudah dikenali agar tamu memahami pilihannya. Option yang terpilih juga membuat commitment berikutnya terlihat, bukan meminta tamu menyimpulkannya dari screen berikut.
IA yang lebih luas mencakup counter payment, sementara screen ini mengilustrasikan method selection di aplikasi. Service lengkap perlu menjelaskan cara tamu menuju jalur bantuan dan kapan order dianggap accepted. Itu adalah keputusan proses yang tidak dapat diselesaikan oleh payment-method modal saja.
Screen Delapan: Confirmation
Confirmation screen menggunakan checkmark, pesan terima kasih, instruksi untuk menunggu di meja, dan action Home. Screen ini menutup interaksi langsung dan memberi tahu langkah berikutnya yang diharapkan sistem dari tamu.
Final screen menyampaikan intended completion state dan action tamu berikutnya.
Kejelasan penting karena tamu tidak perlu menebak apakah harus tetap di kiosk, mengambil receipt, atau kembali ke meja. Confirmation adalah janji interface bahwa order telah bergerak maju.
Konsep ini belum mendokumentasikan technical acceptance signal di balik janji tersebut. Pada product considerations, successful payment dibedakan dari kitchen-accepted order agar pesan dapat diikat pada event yang dapat diandalkan.
🧪 Eksplorasi Prototype dan Design Outcome
Eksplorasi Prototype dan Conceptual Heatmap
Eksplorasi prototype menyertakan heatmap pada menu view. Heatmap menempatkan aktivitas di sekitar category card, konten rekomendasi, dan foto makanan. Artefak ini membantu memahami pola perhatian yang sedang dieksplorasi.
Saya menggunakan heatmap ilustratif ini untuk mempertanyakan apakah card dan foto yang menonjol dapat mengalihkan perhatian dari category label dan order panel. Karena itu heatmap menjadi prompt untuk observasi lanjutan, bukan alasan untuk menghentikan refinement layout.
Illustrative heatmap pada menu view, menyoroti card dan foto makanan untuk pengujian perhatian berikutnya.
Dalam batas tersebut, heatmap tetap menghasilkan pertanyaan berguna. Apakah category card dapat dibedakan dari hidangan? Apakah route ke My Order jelas setelah item ditambahkan? Apakah tamu memahami recommendation grid sebagai starting point, bukan keseluruhan menu?
Pertanyaan tersebut menggeser diskusi dari apakah gambar menarik perhatian menjadi apakah interface mendukung task yang diinginkan. Perbedaan ini penting saat menentukan hal yang perlu diuji dan keputusan desain yang dapat dipertahankan dengan evidence.
Design Outcome dan Dampak yang Dituju
Output desain adalah pengalaman tablet yang didukung persona, branching flow, paper wireframe, dan delapan high-fidelity screen. Bersama-sama, artefak ini membuat sequence pemesanan terlihat dari welcome hingga confirmation.
Desain bertujuan mengurangi tekanan pada kasir, memudahkan pemilihan menu, memperjelas koordinasi table service, dan menawarkan payment yang praktis. Tujuan itu dicapai dengan mendistribusikan menu discovery melalui aplikasi, menjaga detail order tetap terlihat, menangkap service identifier, serta menampilkan payment choice yang familiar.
Kontribusi artefak ini adalah sequence keputusan yang dapat diperiksa. Product considerations di bawah menjelaskan cara menguji apakah sequence yang sama bekerja bagi tamu, staf, dan operasional restoran.
🚀 Product Considerations dan Langkah Berikutnya
Memindahkan desain interface menjadi service yang berjalan membutuhkan penyelesaian keputusan di antara screen dan operasi. Pertanyaan berikut akan saya jawab melalui development dan validation.
Tetapkan seating dan penempatan device sebelum menyempurnakan flow
Saya akan menentukan bagaimana tamu duduk, di mana mereka browsing, dan apa arti service code. Shared kiosk dapat mendukung self-ordering, tetapi mungkin menciptakan antrean sendiri dan mengharuskan tamu meninggalkan meja. Tablet di meja mendukung browsing sambil duduk, namun membawa biaya hardware, cleaning, maintenance, dan support.
Alternatif mobile memiliki asumsi berbeda tentang konektivitas dan device tamu. Alternatif ini perlu dinilai dengan journey yang sama, bukan dipilih hanya karena mengurangi hardware restoran. Pertanyaan utamanya adalah model mana yang membantu tamu memilih dan menyelesaikan order dengan effort staf yang dapat diterima.
Untuk konsep ini, saya akan mempertahankan seating yang dipandu host dan mendefinisikan fixed table identifier atau portable service marker secara eksplisit. Tim floor membutuhkan prosedur konsisten untuk assignment, invalid code, perpindahan, dan exception. Table-code input tidak boleh bertanggung jawab menentukan ketersediaan kursi.
Sederhanakan keputusan yang mendeskripsikan order
IA mencampur lokasi pembayaran, metode pembayaran, dan cara makanan dikirim. Saya akan memisahkan keputusan tersebut dan menanyakannya hanya ketika keputusan itu mengubah route.
Untuk dine-in awal, sequence dapat mencakup seating, browsing dan review order, konfirmasi service identifier, pilihan payment atau jalur bantuan, lalu accepted-order confirmation. Takeaway menjadi fulfillment path terpisah, bukan sequence yang diduplikasi di diagram yang sama.
Perbaikannya adalah model yang lebih konsisten untuk dipahami design, engineering, dan operations. Setiap pilihan seharusnya dapat dijelaskan tanpa menemukan pertanyaan pembayaran tambahan di tengah journey.
Proposed service flow. Rekonsiliasi payment, order acceptance, dan recovery perlu dispesifikasikan serta divalidasi sebelum implementasi.
Rancang recovery bersama successful path
Saya akan menentukan situasi yang dapat mengganggu meal journey sebelum screen dianggap siap dikembangkan. Item dapat tidak tersedia, tamu dapat memasukkan code yang salah, koneksi dapat gagal, atau payment dapat tetap unresolved.
Setiap situasi membutuhkan penjelasan dan route ke depan. Item yang tidak tersedia sebaiknya mengembalikan tamu ke order yang dapat diedit. Code yang salah harus dapat diperbaiki tanpa membangun ulang cart. Payment yang unresolved harus mencegah repeated charge dan memberi staf informasi yang cukup untuk membantu.
Order record dan payment attempt membutuhkan identifier yang konsisten agar recovery tidak menghasilkan kitchen ticket ganda. Interface perlu membedakan pending payment, confirmed transaction, failed attempt, dan kasus yang membutuhkan rekonsiliasi. Behavior detail akan ditentukan bersama provider payment dan fulfillment.
Kitchen acceptance adalah event terpisah. Tamu hanya boleh diberi tahu bahwa makanan sedang disiapkan ketika service dapat mendukung pernyataan tersebut. Jika estimated wait ditampilkan, sumbernya harus jelas dan nilainya dapat berubah mengikuti kondisi.
Pertahankan assisted service dan tingkatkan inclusive use
Hospitality mencakup bantuan bagi tamu yang kebutuhannya tidak dapat direduksi menjadi standard ordering path. Bantuan perlu mudah ditemukan saat ketidakpastian mungkin muncul: memilih hidangan, memahami bahan, menyelesaikan code, dan melakukan payment.
Untuk konteks lokal, saya akan mengevaluasi apakah bahasa Indonesia dan Inggris pada menu berguna bagi guest mix yang dituju. Language switching yang jelas harus mempertahankan cart. Penjelasan bahan perlu berasal dari informasi restoran yang terpelihara, dengan bantuan staf untuk pertanyaan diet dan alergi, bukan asumsi dari foto makanan.
Saya juga akan memeriksa kontras teks di atas foto, ukuran touch target, keyboard use jika relevan, focus behavior pada item modal, serta keterjangkauan dan keterbacaan device. Identitas visual dapat tetap hangat dan mudah dikenali sambil interaksinya menjadi lebih mudah digunakan.
Jaga scope delivery pertama tetap sempit
Saya akan memulai dengan satu dine-in journey yang dapat diandalkan: menu dan availability terkini, editable order review, service identifier yang terdefinisi, payment serta assistance path yang didukung, dan accepted-order record yang dapat digunakan tim floor dan dapur.
Ekspansi takeaway, personalized recommendation, loyalty, seating tool lanjutan, dan mid-meal reordering mengikuti setelah core journey dipahami. Fitur-fitur tersebut membawa kebutuhan data, service, dan fulfillment berbeda. Menambah semuanya sekaligus akan menyulitkan identifikasi alasan pilot berhasil atau gagal.
Business case perlu mempertimbangkan biaya device dan operasi di samping kemungkinan berkurangnya pekerjaan kasir yang repetitif atau order yang salah. Waktu staf mungkin berpindah ke bantuan dan exception handling, bukan hilang. Kapasitas dapur tetap membatasi kecepatan fulfillment.
Tetapkan measurement dan rencana pilot
Saya akan mengukur waktu dari tamu siap memesan hingga order diterima dengan benar, termasuk waktu menunggu di kiosk dan recovery. Pengalaman median dan slow-end membantu melihat apakah tamu umumnya terbantu sementara sebagian kelompok mengalami kesulitan. Waktu dari kedatangan hingga makanan diterima memberi pemeriksaan yang lebih luas terhadap service.
Completion berarti order diterima dengan benar, dengan seluruh ordering attempt sebagai denominator. Supporting measure mencakup abandoned attempt, assistance request, order correction, duplicate charge atau ticket, payment exception, dan makanan yang terkirim ke lokasi salah.
Guardrail mencakup beban staf, kitchen delay, dan persepsi tamu terhadap hospitality. Interface yang lebih cepat tidak membenarkan lebih banyak fulfillment error atau pengalaman yang lebih buruk bagi orang yang membutuhkan bantuan. Definisi dan batas yang dapat diterima perlu disepakati sebelum pilot dinilai.
Saya kemudian akan membandingkan pilot terbatas dengan baseline dari periode layanan yang serupa, sambil memperhitungkan demand, staffing, party size, dan ketersediaan menu. Feedback tamu dan staf membantu menjelaskan perubahan, bukan meninggalkan tim hanya dengan dashboard. Masalah rekonsiliasi yang berulang, fulfillment yang salah, atau overload staf menjadi alasan untuk menghentikan sementara dan memperbaiki service sebelum diperluas.
📝 Refleksi dan Pembelajaran
Refleksi dan Product Learning
Proyek ini memberi saya pandangan end-to-end tentang cara keputusan interface membentuk ordering journey. Persona menerjemahkan brief yang luas menjadi situasi pengguna yang konsisten. Architecture memperlihatkan cabang service dan payment. Sketsa membuat keputusan tersebut terlihat sebelum screen final memberinya identitas visual.
Pembelajaran pentingnya adalah seberapa banyak hal yang belum terselesaikan dapat tersembunyi di balik screen yang persuasif. Table-code field terlihat sederhana sampai tim floor harus menentukan apa yang diidentifikasi code tersebut. Confirmation terlihat lengkap sampai payment dan kitchen acceptance tidak sejalan. Self-ordering station terlihat efisien sampai tamu harus mengantre untuk menggunakannya.
Pertanyaan operasional sebaiknya membentuk interface sejak awal. Pattern menu, detail, dan review menyediakan fondasi yang berguna; nilainya bergantung pada service di sekelilingnya yang mampu memenuhi pilihan tamu secara konsisten.
Iterasi berikutnya adalah memvalidasi journey penuh bersama tamu dan staf, lalu menentukan apakah konsep ini layak mendapat investasi. Tujuannya tetap pengalaman ordering yang lebih jelas, mendukung makanan yang dipesan, dan memberi ruang untuk hospitality yang personal.
📌 Disclaimer: Studi kasus ini merefleksikan proses dan perspektif digital product saya melalui konsep mandiri yang dibuat untuk tujuan edukasi. Proyek ini bukan engagement resmi dan bukan perubahan produk yang dirilis. Elemen ilustratif, keterbatasan riset, serta tidak adanya dampak produk atau bisnis yang terverifikasi dijelaskan berdasarkan evidence yang tersedia. Nama brand dan imagery adalah milik pemiliknya masing-masing. Semua pandangan di sini merupakan pandangan pribadi saya.
💬 Mari Terhubung: Punya feedback atau pemikiran tentang studi kasus ini? Saya ingin mendengarnya. Silakan tinggalkan komentar atau jelajahi karya product dan experience lainnya di cahyadiaditya.site. Untuk berdiskusi, hubungi saya melalui Telegram atau terhubung melalui LinkedIn. Terima kasih sudah membaca.
