Desain APIs Seperti Kamu Mendesain User experience

on

|

views

and

comments

Apa itu Pengalaman Pengguna?

Pengalaman Pengguna (UX) adalah nilai yang Anda berikan kepada pengguna Anda ketika mereka menggunakan produk Anda. Ini adalah istilah yang sebagian besar terkait dengan User Interface yang tampak cantik. Namun, dengan prinsip:

User Experience Design (UXD atau UED) “adalah proses meningkatkan kepuasan pengguna dengan suatu produk dengan meningkatkan kegunaan, aksesibilitas, dan kesenangan yang disediakan dalam interaksi dengan produk.”

Desainer menghabiskan banyak waktu untuk memastikan bahwa mereka membuat setiap interaksi, setiap elemen UI senyaman mungkin.

Memproduksi jenis UX terbaik terutama proses – proses yang digunakan tim Desain / UX untuk memastikan bahwa desain mereka bernilai, diinginkan, dan dapat digunakan oleh masyarakat. Ini bukan hanya tentang menyediakan UI yang indah. Mereka memastikan bahwa dalam proses desain semua pemangku kepentingan dilibatkan sehingga tidak ada kejutan mendadak menjelang akhir. Mereka juga melakukan penelitian yang cukup, pengujian pengguna dan prototyping untuk memastikan bahwa semua ide atau desain yang mereka hasilkan, mereka beresonansi dengan pengguna target.

“Desain tidak hanya seperti apa dan rasanya. Desain adalah cara kerjanya. ” – Steve Jobs.

Mengapa Anda harus peduli tentang Desain API?

Cara kita melihat siklus hidup API di Postman, ini berisi tahapan seperti Merancang, Melakukan debugging, pengujian otomatis, Mendokumentasikan API, Memantau dan Menerbitkan API sehingga pengguna akhir dapat mulai mengkonsumsinya.

Siklus Hidup API

“Merancang dan Mengolok-olok API” adalah langkah pertama dan terpenting dari siklus hidup ini. Insinyur yang baik dapat mengatakan bahwa jika Anda mulai dengan fondasi yang goyah atau batuan dasar yang buruk, Anda akan runtuh, dan hal yang sama berlaku untuk API. Jika Anda belum melakukan pekerjaan yang baik dalam mendesain API, itu akan memiliki efek berjenjang pada langkah-langkah lain dalam siklus hidup.

Ketika API telah dibangun, perubahan itu sulit, mahal dan intensif waktu. Lebih buruk lagi, perubahan pada API yang dipublikasikan mungkin menghancurkan klien mana pun yang menggunakan API. Desain memungkinkan untuk merencanakan semua detail, mengulang beberapa proposal dan melakukan analisis bagaimana-jika. Selain itu, perubahan yang dilakukan pada API dalam tahap perancangan mudah dan murah untuk dilakukan .

“Desain API membantu kita menghindari membangun API yang salah, atau API dengan cara yang salah.”

Namun, Anda akan menemukan pengembang menghabiskan lebih banyak waktu untuk mengembangkan dan mengkode API mereka daripada mendesainnya. API dianggap dikonsumsi oleh mesin dan bukan entitas yang menghadap pengguna, sebagai akibatnya banyak organisasi tidak menghabiskan cukup perhatian dan sumber daya untuk mengatur proses desain untuk API. Tetapi hari ini, ketika arsitektur microservice mengambil alih dunia, API mulai lebih terlihat seperti produk daripada teknologi. Mereka harus dilihat sebagai cara untuk menyediakan fungsionalitas kepada pengguna akhir.

“Di ruang API, kami membangun sesuatu di atas mesin untuk digunakan mesin dan ini salah karena ada orang di sisi lain klien API.” – Ronnie Mitra , Direktur Teknologi di Publicis Sapient

Merancang UX yang lebih baik, tetapi untuk API

Banyak RESTful API yang dirancang hari ini tidak lebih dari browser objek yang menghadirkan representasi internal dari domain / objek bisnis melalui HTTP / S sebagai lapisan transport. Jadi, bagaimana Anda bisa menjadi lebih baik dalam merancang API, bagaimana Anda dapat memastikan semua API yang Anda desain mengikuti pola yang konsisten, bagaimana Anda dapat memastikan bahwa orang-orang baru yang bergabung dengan tim tidak menemukan kembali roda pembuatan keputusan desain tentang API yang ada organisasi telah belajar dari waktu ke waktu. Jika Anda membaca pertanyaan-pertanyaan di atas lagi apa yang Anda temukan hilang adalah proses desain API mirip dengan yang dipekerjakan desainer UX dan ini adalah jenis masalah yang sedang dipecahkan oleh mereka setiap hari.

UX yang hebat idealnya mengikuti aturan kegunaan yang didefinisikan oleh Peter Morville yang dikenal sebagai UX Honeycomb .

The Honeycomb UX

Untuk merancang API dengan UX yang hebat, Anda harus menjawab pertanyaan-pertanyaan ini saat mendesainnya:

  1. Berguna : Apakah API bermanfaat dari sudut pandang pengguna akhir?
  2. Dapat digunakan : Dapatkah API digunakan dengan cepat oleh pengembang dan menyediakan fungsionalitas yang mudah digunakan?
  3. Diinginkan : Apakah fungsionalitas yang disediakan oleh API sesuatu yang menghasilkan keinginan pada pengembang dan pengguna akhir?
  4. Dapat ditemukan : Dapatkah dokumentasi API ditemukan dengan mudah, dan dapatkah pengembang segera menggunakannya?
  5. Diakses : Dapatkah API menyediakan fungsionalitas bagi pengguna akhir yang memiliki kendala / batasan teknis dalam mengkonsumsinya?
  6. Kredibel : Apakah data yang disediakan oleh API dapat dipercaya?
  7. Berharga : Apakah API berkontribusi terhadap laba perusahaan dan meningkatkan kepuasan pelanggan?

Menentukan Proses Desain untuk API

Kekuatan suatu desain terletak pada langkah-langkah yang diambil untuk membuatnya seperti pada hasil akhir. Proses desain membantu Anda untuk tetap transparan dan efisien saat merancang solusi. Ini menetapkan harapan yang jelas dan mengurangi risiko memberikan hasil yang tidak diinginkan.

Proses desain Double Diamond oleh British Design Council adalah salah satu dari sekian banyak proses desain. Hal ini memungkinkan orang untuk membuat keputusan desain yang disengaja dengan menjelajahi berbagai pilihan (pemikiran divergen) sambil memvalidasi yang lebih kuat dan menyingkirkan yang lebih lemah (pemikiran konvergen).

Proses desain Berlian Ganda

Pendekatan ini akan membantu Anda dalam mencapai dua hal terpenting dalam setiap proses desain:

  1. Merancang Hal yang Tepat
  2. Merancang Hal yang Benar

Merancang Hal yang Tepat

Fase ini dibagi menjadi Discover / Research dan Define / Synthesis . Sementara merancang sesuatu yang baru, sangat mudah bagi orang untuk meledakkan ruang lingkup masalah yang sebenarnya dan mengerahkan semua upaya mereka untuk merancang sesuatu yang tidak ada yang benar-benar ingin atau akan digunakan. Fase perancangan ini membuat kami tetap membumi dan memastikan bahwa kami merancang untuk hal yang benar dengan melakukan penelitian yang tekun dan mendefinisikan pernyataan masalah yang tepat untuk diselesaikan.

Temukan / Penelitian

Saat Anda sedang membangun Produk, Fitur, atau API baru, Anda mencoba menyelesaikan masalah. Untuk memberikan solusi, Anda harus terlebih dahulu memahami masalahnya. Mulailah selalu dengan memperoleh Pengetahuan Domaintentang masalah. Cobalah untuk memahami masalah apa yang Anda coba selesaikan, untuk siapa ini dibuat, dll. Klarifikasi kasus penggunaan dan persyaratannya. Penelitian tentang solusi yang ada untuk memahami bagaimana mereka memecahkan masalah yang sama dan apa yang dapat Anda pelajari dari keputusan arsitektur / teknis mereka. Berbicara dengan semua tim di dalam / di luar organisasi Anda yang merupakan pemangku kepentingan untuk API baru ini yang mungkin termasuk Tim Produk, Tim Desain, Tim Keamanan, dll. Perspektif mereka yang berbeda akan memberi Anda pandangan yang lebih luas untuk memikirkan API Anda dan keputusan teknis yang Anda berencana untuk mengambil dari titik itu dan seterusnya.

Anda juga dapat memanfaatkan Jaringan API Tukang Pos untuk penelitian atau referensi Anda untuk mengetahui bagaimana API organisasi yang berbeda terlihat. Postman API Network berisi daftar beragam API yang diterbitkan oleh organisasi dari banyak domain dan industri yang berbeda. Misalnya, jika Anda sedang membangun API di ruang FinTech, untuk penelitian Anda, Anda dapat memeriksa beberapa API yang diterbitkan oleh organisasi lain di bagian Layanan Keuangan.

Jaringan API di dalam aplikasi tukang pos

Langkah ini akan menghasilkan banyak informasi yang tidak terstruktur, tumpang tindih dan konflik kasus penggunaan / persyaratan. Jadi pada langkah selanjutnya, susun informasi ini sehingga Anda dapat membuat keputusan desain yang lebih baik di sekitar API Anda.

Definisikan / Sintesis

Dari data mentah, temukan tren dan wawasan yang menjangkau berbagai pengguna dan skenario. Cobalah untuk menjabarkan kasus penggunaan yang tepat dan persyaratan yang Anda rencanakan untuk dipenuhi. Tahap proses ini juga merupakan waktu yang tepat untuk menghilangkan ketergantungan apa pun yang mungkin dimiliki API Anda pada layanan lain, yang cukup umum dalam arsitektur layanan microser. Tentukan Model Sumber Daya Anda dan hubungan di antara mereka, yang akan membantu Anda mengidentifikasi semua Sumber Daya yang Anda perlukan untuk mengekspos API. Anda juga harus secara jelas menguraikan perilaku dan harapan API sehingga konsumen tidak perlu membuat asumsi apa pun saat menggunakan API Anda. Melakukan ini akan membantu Anda mengidentifikasi jumlah logika bisnis yang akan menjadi bagian dari layanan atau klien.

Merancang Hal yang Benar

Fase ini dibagi menjadi Develop / Ideation dan  Deliver / Implementation . Fase ini akan memastikan bahwa apa pun yang Anda putuskan untuk desain, itu dirancang dengan cara yang tepat untuk memastikan bahwa Anda tidak berkompromi dengan kualitas, konsistensi, keamanan, dan praktik terbaik yang digariskan oleh organisasi / industri.

Kembangkan / Gagasan:

Setelah Anda jelas tentang ‘apa yang perlu dicapai’ menggunakan API, sekarang saatnya untuk merancang API tersebut sehingga Anda dapat berkomunikasi tentang apa yang Anda sebagai niat penyedia API untuk kirim. Deskripsi API Bahasa seperti OpenAPI / Swagger, RAML, dll adalah cara yang bagus untuk mengekspresikan aspek-aspek penting dari API. Terutama keputusan desain frontend dan keputusan desain arsitektur, yang terlihat oleh konsumen, dapat ditangkap oleh bahasa deskripsi API. Tetapi satu kekurangan dengan bahasa deskripsi API ini adalah mereka bisa terlalu teknis, verbal dan sulit untuk dikolaborasikan. Jadi, yang bisa Anda lakukan adalah mengimpor file spesifikasi Swagger , OpenAPI , atau RAML ke dalam Postman Collection .

Jika Anda telah bekerja erat dengan tim UX / Desain sebelum Anda akan memperhatikan bahwa beberapa hasil pada akhir proses desain mereka adalah dokumentasi di sekitar semua fitur dan interaksi, representasi berbagai keadaan UI (keadaan kesalahan, keadaan kosong, dll) dan prototipe yang menunjukkan interaksi yang tepat dengan UI dan apa yang harus menjadi hasil yang diharapkan.

Menggunakan koleksi Postman Anda juga dapat mencapai hasil yang sama untuk API Anda dan memberikan transparansi total kepada semua pemangku kepentingan di sekitarnya.

  • Dokumentasi API: Anda dapat mendokumentasikan koleksi, folder, permintaan , hingga rincian dokumentasi header, parameter kueri, dll dalam permintaan. Bersamaan dengan ini, Postman juga menghasilkan dokumentasi yang tampak indah di luar kotak yang dapat dibagikan kepada siapa pun.
  • Skenario / keadaan API yang berbeda: Anda dapat merancang Contoh yang berbeda untuk setiap API sehingga konsumen tahu permintaan untuk mengirim dan respons apa yang diharapkan. Secara umum, Anda disarankan untuk menambahkan contoh untuk semua skenario permintaan / respons yang berbeda untuk API, termasuk respons kesalahan, tanggapan kosong, dll.
  • Prototipe: Anda dapat membuat server Mock yang akan mengembalikan contoh yang dirancang sebagai respons. Ini sangat membantu karena segera memungkinkan konsumen API Anda dan mereka dapat mulai membuat prototipe / menguji kasus penggunaan mereka meskipun API yang sebenarnya tidak siap.

Memberikan / Implementasi:

Setelah Anda berhasil merancang API Anda sekarang adalah waktu untuk memulai implementasi. Tetapi sebelum Anda mulai mengkode API Anda, Anda harus membuat Tes Kontrak untuk API Anda yang akan memastikan bahwa jika ada perubahan selama pengembangan dalam desain permintaan / respons API yang disepakati, tes Kontak ini akan mulai gagal. Kemudian Anda dapat memperbarui kode Anda atau menginformasikan semua tim yang terpengaruh. Juga, sangat mudah di Postman untuk berkolaborasi dengan seluruh tim Anda. Anda dapat terus menerima umpan balik menggunakan komentar saat Anda benar-benar mengembangkan API Anda dan setiap perubahan yang Anda buat akan segera tersedia untuk semua orang yang terlibat dalam proses.

. . .

Membangun Panduan Gaya Desain, tetapi untuk API

Ketika Anda bekerja dalam tim yang sedang berkembang dengan orang-orang baru bergabung setiap saat, setelah titik waktu tertentu menjadi sangat sulit untuk memastikan kualitas, konsistensi, dan keamanan API. Bayangkan apa yang akan terjadi jika setiap pengembang baru akan mulai mengikuti konvensi penamaan titik akhir mereka sendiri, menggunakan Otorisasi, parameter kueri tajuk, struktur respons kesalahan dan keberhasilan, dll saat mengembangkan API.

Tim desain menghadapi tantangan serupa saat membuat UI baru. Mereka menyelesaikan ini dengan membangun Panduan Gaya Desain yang memastikan bahwa semua orang di tim menggunakan komponen UI yang sama, warna, tipografi, dll. Menggunakan Panduan Gaya Desain, menjadi mudah untuk berkomunikasi antar tim, menjaga UI konsisten dalam jangka panjang dan membawa ketangkasan. dalam proses desain dan pengembangan.

Jadi, mengapa tidak memiliki Panduan Gaya Desain untuk API itu sendiri? Perusahaan seperti Google , Microsoft , Cisco , Paypal , dan banyak lagi lainnya bergantung pada panduan Style API ini untuk memastikan API mereka tetap konsisten, terlihat kohesif dan intuitif. Manfaat konsistensi bertambah secara agregat; konsistensi memungkinkan tim untuk meningkatkan kode umum, pola, dokumentasi, dan keputusan desain. Ini juga akan memastikan pengalaman pengembang semulus mungkin, baik bagi produsen dan konsumen API. Beberapa hal penting yang harus menjadi bagian dari Panduan Gaya API adalah:

  • Struktur URL: Seperti apa seharusnya format URL untuk sumber daya yang diberikan, seperti apa jalur, parameter kueri, dll.
  • Metode permintaan: Tetapkan daftar metode permintaan dan tentukan kapan akan menggunakan metode permintaan yang mana. Ini akan memastikan bahwa metode permintaan memiliki perilaku yang sama di seluruh API Anda.
  • Header Permintaan / Respons: Daftar header yang harus digunakan dengan API saat meminta layanan dan merespons kembali.
  • Kode status respons: Buat daftar kode status yang diizinkan untuk API Anda dan atur dengan jelas pedoman kapan menggunakan kode status tertentu.
  • Kesalahan: Desain format respons kesalahan umum yang dapat digunakan semua pengembang lain. Respons kesalahan yang baik harus membuat pengembang mengenali, mendiagnosis, dan memulihkan dari kesalahan.
  • Pembuatan Versi: Tetapkan panduan tentang cara membuat versi API dan poin yang perlu diingat saat membuat versi API.
  • Penyaringan / Paginasi / Penyortiran: Cara mendukung penyaringan dan paginasi di API Anda yang mengembalikan kumpulan data, seperti apa respons JSON dengan hasil yang disaring / paginasi / diurutkan.

Untuk membantu orang memulai dengan cepat, saya telah menerbitkan koleksi sebagai templat yang dapat Anda impor dan mulai mengutak-atik.

Pemikiran Terakhir

Seperti semua proses desain lainnya, proses desain API juga perlu menjadi proses berulang. Menerbitkan API ke pengguna Anda bukanlah akhir dari siklus hidup API. Anda harus menjaga saluran umpan balik konstan dari konsumen API selalu terbuka dan pastikan bahwa Anda terus mengakomodasi saran menggunakan proses desain yang sama.

sumber:blog.marvelapp.com

Share this
Tags

Must-read

Mantaflow Creating Fire

Menciptakan efek api? Mudah dengan Mantaflow! https://www.youtube.com/watch?v=lR9vjaYzeYQ
spot_img

Recent articles

More like this