App Store | Perencanaan dan Desain
17161
page-template,page-template-full_width,page-template-full_width-php,page,page-id-17161,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,footer_responsive_adv,qode-theme-ver-10.1.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive

PERENCANAAN DAN DESAIN

Tulang punggung situs web adalah konten dan desain.
Arah utama dipandu oleh fase strategi
Kami merencanakan dan merancangnya dalam bentuk yang lebih spesifik.

cara membuat website

Telepon: 0361-238091

Jam Kerja Senin – Sabtu dari pukul 9:00 – 17:00 WITA

Skenario pengalaman situs

Kami akan mengarahkan arus pengalaman pengguna di situs Web sesuai target dan dengan rute masuk. Dengan melakukan ini, kita bisa mewujudkan layout konten dan desain navigasi di sepanjang garis perilaku pengguna.

Kami akan skenario pengalaman pengguna di situs dan mencerminkan dalam garis-garis aliran dan navigasi.

Peta jalan bisnis dan jurnal pelanggan yang diproduksi dalam fase strategis adalah diagram peran situs web dan pergerakan target di seluruh bisnis, dan pergerakan dan arus target di luar situs Web didefinisikan. Namun, walaupun ini sangat ideal untuk menggambar desain tanah dari situs web, tidak mungkin untuk secara jelas menarik aliran seperti apa dan bagaimana pengalaman pengguna di situs web. Jadi, hal pertama yang kita lakukan di tahap desain adalah membuat skenario pengalaman situs.

Skenario rinci flow dari pintu masuk untuk keluar dari website

Skenario pengalaman situs adalah diagram pergerakan pengguna yang mengunjungi situs web di dalam situs web. Jalur utama dari pintu masuk situs ke pintu keluar (goal) didefinisikan, dan berdasarkan kebijakan ini, struktur kategori situs web, komposisi navigasi global, komposisi navigasi lokal, atau tata letak dasar halaman akan diputuskan.

 

Meskipun merupakan situs Web dengan struktur yang sama, pengalaman seperti tempat kunjungan dan cara bermigrasi akan bervariasi dari target ke target. Juga, meskipun target yang sama memiliki kebutuhan dan status yang berbeda dalam proses pembelian, rute masuk dan halaman arahan akan berubah, dan garis perilaku di situs akan berubah juga.

Perencanaan konten

Konten bagus bukan kuantitas atau kualitas. Kuantitas dan kualitas yang tepat diperlukan untuk memenuhi KPI (Key Performance Indicator) dan ROI (Return On Investment) yang mogok dari strategi. Dari sudut pandang ini, kami akan merencanakan konten bermanfaat yang akan menghasilkan hasil.

Isi sistem akuisisi

Ini adalah konten yang dirancang sebagai tujuan utama untuk menarik pelanggan. Bertujuan untuk meningkatkan jumlah kunjungan oleh SEO, SNS, iklan, dll, tingkat bouncing dan kedalaman gulir dll adalah indikator. Pada dasarnya, 1 content = 1 halaman. Meskipun ini adalah tujuan menarik pelanggan, jika Anda mengecewakan harapan pengguna yang berkunjung, Anda akan dibawa kembali ke waktu singkat, sehingga konten yang memenuhi kebutuhan pengguna yang serupa dengan konten pengalaman sangat diperlukan. Namun, karena itu menjadi pintu masuk situs Web, maka menjadi konten yang menekankan judul, tampilan pertama, dimana membimbing setelah membaca konten.

Pengalaman konten

Berdasarkan skenario perjalanan dan pengalaman pelanggan, ada konten yang ditemukan berdasarkan kebutuhan informasi. Sebagai hasil dari kebutuhan pengguna sebagai basis, ia mungkin tumpang tindih dengan konten pelanggan yang menarik sebagai hasilnya, namun dibuat dari sudut pandang murni meminta pengguna tanpa memikirkan penyebaran dengan kata kunci atau SNS. Oleh karena itu, penting untuk mencocokkan tingkat pemenuhan konten dengan kebutuhan pengguna lebih dari sekadar menarik konten pelanggan.

Desain peta situs

Tentukan struktur kategori dan halaman situs web. Selain menunjukkan struktur, ini adalah salah satu spesifikasi penting yang menggambarkan garis alur, kata kunci, pengaturan dan persyaratan dari berbagai nilai atribut dan juga berfungsi sebagai dasar untuk jadwal dan perkiraan.

Atur kelompok konten yang tercantum dalam fase strategi dan susunlah itu sebagai sebuah situs web. Kami akan menentukan struktur situs web sambil menyeimbangkan persyaratan strategis seperti sudut pandang pemasaran strategis dan sudut pandang UX dan logika informasi. Melalui serangkaian desain peta situs, struktur kategori dan jumlah halaman diselesaikan, sehingga memungkinkan untuk merumuskan kutipan dan jadwal yang lebih terperinci.

Sitemap tingkat tinggi

Ini adalah peta situs kasar yang mengatur struktur dasar situs web. Kami tidak melakukan identifikasi halaman secara terperinci, namun menentukan struktur kategori dasar yang mempengaruhi navigasi global dan hubungan antar kategori. Hal ini juga terletak antara skenario pengalaman situs dan peta tingkat rendah / situs dan juga digunakan untuk memasukkan gagasan desain garis aliran dalam struktur situs web. Terutama di situs yang sangat besar, saat membuat peta situs secara tiba-tiba oleh unit halaman, sering kali Anda tidak dapat memahami keseluruhan situs Web, jadi pada tahap awal Anda akan terlebih dulu membuat peta situs tingkat tinggi dan menentukan keseluruhan struktur .

Peta situs tingkat randah

Ini adalah peta situs yang tepat yang memecah ke unit halaman. Berdasarkan tingkat tinggi · sitemap, kita akan mengklasifikasikan isi yang diekstraksi dalam tahap strategi secara rinci dan membuatnya menjadi halaman. Pada peta tingkat rendah / situs, tidak hanya struktur yang didefinisikan secara sederhana, tetapi juga nama direktori, nama file, kata kunci yang sesuai, atribut TITLE dan atribut META, cakupan CMS dan SSL, ruang lingkup prototipe dan desain, ruang lingkup HTML, tahap pembelahan Ini adalah dokumen yang memiliki karakteristik yang mendekati spesifikasi yang menggambarkan informasi yang diperlukan untuk memproduksi situs web berdasarkan halaman. Ini juga akan menjadi dasar jadwal dan perkiraan setelah tahap pengembangan.

Wireframe

Pada tahap pertama desain visual, ini adalah dokumen untuk mendefinisikan isi dan fungsi yang akan ditempatkan di layar. Kami terutama menggunakannya di situs Web kecil dan aplikasi dengan struktur khusus.

Wireframe adalah dokumen yang dibuat untuk desain layar. Informasi dan fungsi yang akan dipajang di layar ditentukan untuk setiap layar. Kerangka dari setiap halaman dan penyempurnaan isi dan desain visual dilakukan berdasarkan informasi ini. Selain itu, dengan perusahaan klien, kita akan membahas diskusi tentang isi setiap layar begitu kita melakukan konsultasi di tahap bingkai kawat.

Kerugian dari Wireframe

Sebenarnya, dalam alur kerja kita saat ini, kesempatan untuk membuat wireframes jauh berkurang. Sebagai gantinya, desain layar dilakukan dengan menggunakan HTML mockup. Itu karena wire frame memiliki kelemahan berikut.

 

 

  • Perancang perlu menjelaskan maksud struktur dokumen pada coder
  • Kami membutuhkan dokumen lain untuk menentukan struktur file dan informasi header yang dipikirkan perancang
  • Saya harus menyalin dan menyalin teks pada WF atau PSD pada saat coding
  • Ada batasan untuk mengekspresikan struktur tautan, gerakan, kegunaan di atas kertas
  • Saat melakukan koreksi terhadap bagian umum, kita harus melakukan koreksi untuk setiap halaman
  • Dalam kasus Web responsif, perlu dibuat dua jenis WF untuk PC dan smartphone
  • Saya harus mencetak WF baru setiap kali saya memperbaruinya

 

 

Meskipun ini adalah masalah yang dapat dikurangi tergantung pada kecerdikan, dalam mockup HTML, karena banyak kelemahan ini dipecahkan, prototip HTML diadopsi secara preferensial dalam desain layar saat ini. Namun, pertimbangan diberikan pada kasus di mana orang yang bertanggung jawab atas perusahaan klien yang bertanggung jawab atas desain dan HTML oleh perusahaan lain terbiasa melakukan konfirmasi / pengambilan keputusan pada kerangka kawat, kasus bahwa jumlah layarnya kecil dan rangka kawat dapat berjalan dengan lancar. Jika ada keadaan yang harus dilakukan, Anda juga bisa memilih bingkai gambar untuk disain layar.

Prototipe HTML

Dalam desain layar kami, kami dapat menggunakan prototipe HTML dan bukan wireframes. Hal ini bisa dikonfirmasi di browser, kompatibilitas multi-perangkat juga dilakukan, sehingga Anda bisa mengecek spesifikasi layar lebih akurat. Aplikasi dan tampilan dasar ditiru wireframes, sedangkan yang dibuat dalam HTML adalah prototipe HTML. Perbedaan terbesar adalah Anda bisa mengecek desain layar saat benar-benar beroperasi di browser.

Mengapa kami merekomendasikan prototipe HTML

 

Prototipe HTML bisa mengatasi banyak kerugian dari wireframe. Misalnya, poin berikut bisa dikatakan sebagai keuntungan dari prototip HTML.

 

 

  • Anda bisa mengecek struktur link, ukuran layar, ukuran karakter, tingkah laku yang responsif, dll.
  • Karena file desain dapat dialihkan ke pengkodean, efisiensi produksi meningkat
  • Isi dari desain layar bisa langsung tercermin dalam HTML
  • Dokumen desain yang menyertai wireframe menjadi tidak perlu
  • Anda bisa menggunakan penggantian massal dengan editor, sehingga Anda bisa melakukan perubahan dengan cepat
  • Jangan repot-repot mencetak untuk pengiriman
  • Penciptaan template CMS dapat dilanjutkan bersamaan dengan desain visual

 

 

Meskipun ada banyak manfaat terutama pada produktivitas sisi produksi, ini juga merupakan keuntungan besar bagi pihak perusahaan klien khususnya yang dapat dikonfirmasikan saat beroperasi dengan cara yang sama seperti situs web sebenarnya pada tahap perancangan. Memang, dari beberapa perusahaan klien yang biasa menggunakan wireframes, prototipe HTML jauh lebih mudah dipahami dan lebih mudah membayangkan bentuk jadi.

 

 

Desain layar dengan prototipe HTML unik bagi perusahaan kami, dan ini hampir tidak dilakukan oleh perusahaan lain. Ini karena semua staf memiliki pengalaman produksi, menyentuh HTML adalah faktornya. Selain itu, kami mempersiapkan template dan sebagainya untuk segera membuat prototipe HTML, dan kami berada di tempat.

Kami akan menganggap prototipe HTML ini sebagai hasil utama dalam desain layar, mengingat susunan isi, tata letak dasar, struktur dokumen akhir dan sebagainya.

Seleksi / desain CMS

Ada banyak prestasi WordPress, dan pengetahuan seperti kustomisasi melimpah. Selain WordPress, kita akan memilih dan merancang CMS yang paling sesuai sesuai kebutuhan, sistem operasi, anggaran dll yang dibutuhkan untuk website.

Di situs Web terbaru, hampir tidak ada waktu untuk tidak memperbarui setelah diluncurkan. Oleh karena itu, ada banyak kasus di mana penerapan CMS diperlukan. Bahkan untuk sebagian besar proyek yang kami bantu, CMS / simplified CMS seperti WordPress diimplementasikan.

Manfaat mengenalkan CMS

Apakah CMS diperkenalkan atau tidak sering dinilai berdasarkan pembaruan atau tidak diperlukan, namun CMS memiliki banyak kelebihan sebagai berikut, termasuk itu.

 

 

  • Anda dapat memperbarui tanpa menggunakan alat pengembangan
  • Anda dapat mengontrol waktu rilis
  • Anda bisa membatasi siapa yang bisa mengedit dan mempublikasikan dengan setting permission
  • Konten diubah menjadi DB, membuat penambahan dan modifikasi menjadi lebih mudah
  • Pekerjaan manual seperti link paste pada saat penambahan konten berkurang
  • Karena bagian UI merupakan templated, menjadi mudah untuk memperbarui semua bersama-sama
  • Tag dan konten lainnya ditangani sebagai data, sehingga mudah menambahkan fungsi dll.
  • Lebih mudah untuk melakukan sinkronisasi dan back up pementasan dan produksi

 

 

Namun, spesifikasi rinci bervariasi tergantung pada CMS. Mengingat persyaratan server, ukuran lalu lintas, struktur operasi, update konten, kenyamanan UI, fleksibilitas kustomisasi, kerjasama dengan CRM dan SFC, biaya pengenalan, dll, juga memungkinkan untuk membantu Anda memilih solusi optimal. .

Manfaat WordPress

Karena kami bukan vendor CMS, kami tidak akan merekomendasikan CMS spesifik secara istimewa. Namun, situasi sebenarnya adalah WordPress sangat besar dalam hal pencapaian. Itu karena WordPress memiliki kelebihan sebagai berikut.

 

  • Biaya lisensi open source gratis
  • Digunakan di seluruh dunia dan memiliki banyak plugin
  • Mengasumsikan lingkungan server umum, dan ada beberapa batasan oleh lingkungan
  • Dibuat dengan PHP, jadi jika Anda seorang programmer Anda dapat dengan mudah menyesuaikannya
  • Mudah menyesuaikan layar manajemen, bisa disesuaikan dengan tingkat kemahiran
  • Kami memiliki track record yang luas dari WordPress, ada pengetahuan tentang penyesuaian yang setara dengan CMS berbayar

 

Karena WordPress banyak digunakan, ada kesalahpahaman bahwa security broken case difokuskan, mengakibatkan kelemahan keamanan, namun keamanannya tidak jauh berbeda dengan CMS umum dalam hal keamanan. Selain itu, kami juga menerapkan langkah-langkah untuk memaksimalkan keamanan dengan menerapkan pembatasan IP pada layar manajemen, mengubah URL layar manajemen menjadi string karakter yang sewenang-wenang, dan merancang otentikasi dasar dan otentikasi login.

Pedoman Coding

Mengenai pengkodean HTML, kami merumuskan pedoman pengkodean yang memperhatikan aspek-aspek seperti standar web, kegunaan, aksesibilitas, SEO, karakteristik proyek, dan lain-lain, dan membaginya dalam tim pengembangan.

Kami akan mengembangkan aturan pengkodean yang mencerminkan tren teknologi terkini.

Dengan mendefinisikan aturan coding dengan jelas, kita tetap menjaga kualitas koding. Dengan asumsi pengkodean dengan banyak orang, ini didefinisikan sebagai aturan umum dalam tim pengembang, namun dapat digunakan sebagai aturan operasi setelah situs dilepaskan, dan dikirimkan sebagai salah satu kiriman jika diperlukan. Saya akan

Item utama dari pedoman tersebut adalah sebagai berikut. Namun, mengingat karakteristik situs web dan sistem operasi, kami menggunakan yang disesuaikan untuk setiap proyek.

  • Lingkungan yang disarankan
  • Setelan peramban prasyarat
  • Versi HTML
  • Kode karakter
  • Kode umpan baris
  • Aturan referensi badan
  • Aturan karakter tergantung model
  • Aturan Link / path
  • Aturan META tag
  • Aturan OGP tag
  • Aturan TITLE tag
  • Aturan analisis terkait analisis log
  • Aturan elemen HEAD lainnya
  • Aturan Logical tag
  • Aturan Emphasis tag
  • Aturan Form
  • Accessibility compliant
  • Aturan Section
  • Indentasi karakter ruang
  • Item terlarang (spam mesin pencari)
  • Filosofi desain CSS
  • Format deskripsi CSS
  • Aturan deskripsi JavaScript
  • Definisi perpustakaan JavaScript
  • Aturan terkait antar perangkat
  • Jenis direktori / aturan penamaan
  • Jenis file / aturan penamaan
  • Jenis gambar / aturan penamaan
  • File referensi eksternal
  • Tidak perlu file

Notation uniform guideline

Kami juga berpegang pada kualitas salinan di dalam situs web. Notasi dan istilah teknis, seperti notasi dan ungkapan yang cenderung berbeda antar pengarang, dikesampingkan dan kualitas salinannya tetap konstan.

Kami akan merumuskan peraturan yang digunakan di website dan memastikan kualitas dalam proses penyalinan.

Kami akan menyiapkan panduan untuk penyalinan di website terlebih dahulu. Dengan melakukan ini, ini mencegah inkonsistensi dalam notasi dan ekspresi, dan mengamankan kualitas konten. Pada dasarnya dibuat bagi staf produksi untuk memanfaatkan pada saat tes, namun jika perlu, hal itu dapat disampaikan sebagai kiriman.

Saya adalah blok teks. Untuk mengubah teks ini, klik tombol Edit. Dari sini, contoh teks dari blok teks disusun. Saat memasukkan teks Harap hapus dan masukkan

  • Judul halaman
  • Angka (notasi full-width / half-width / Chinese)
  • Tanggal
  • Alfabet
  • Tanda baca
  • Tanda kurung
  • Simbol
  • Karakter terlarang (karakter tergantung model)
  • Notasi hak cipta
  • Komposisi body
  • Judul
  • Label link
  • Hypertext
  • Aturan tombol
  • Form terkait
  • Langkah Notasi
  • Notasi gambar
  • Notasi & Tampilkan daftar aturan

Bentuk desain

Formulir yang bisa mendapatkan informasi pengguna bisa menjadi fungsi penting secara strategis. Kami merencanakan dan menyiapkan cara efektif untuk menggunakan formulir dan cara mengumpulkan data dari perilaku pengguna, proses customerisasi, karakteristik konten, dll.

Kami akan merancang sebuah metode untuk mendapatkan informasi pelanggan informatif yang dapat dimanfaatkan sebagai data pemasaran.

Formulir seperti pertanyaan dan bahan permintaan adalah fungsi yang disisihkan untuk website. Ini bukan hanya jendela penyelidikan. Terutama di situs BtoB, ini menjadi titik kontak penting untuk memperoleh informasi pelanggan, dan bentuknya seringkali merupakan tujuan akhir di situs web.

 

Oleh karena itu, kita tidak hanya merancang bentuk internal seperti EFO (Entry Form Optimization), tapi juga bagaimana mengatur bentuk dan cara memanfaatkannya dalam skenario pengalaman situs. Kami akan mengklarifikasi rencana terlebih dahulu.

  • Jenis data yang akan diperoleh
  • Metode input data
  • Bagaimana meng output data
  • Definisi kondisi input
  • Spesifikasi validasi inline
  • Definisi solusi dan API yang bekerja sama
  • Teks konfirmasi e-mail dikirim ke pengirim
  • Pengaturan teks dan alamat surat surat masuk untuk dikirim ke penanggung jawabnya
  • Adanya / tidak adanya fungsi pelaporan berkala dan rincian spesifikasi

Persyaratan sistem definisi & desain

Sebagai insinyur yang terdaftar, desain sisi server dan pengembangan skala kecil akan ditangani secara internal. Desain dan dokumentasi mutu juga dimungkinkan, mengingat perusahaan klien dan karakteristik proyek.

Kami adalah insinyur yang terdaftar di perusahaan, dan kami juga melakukan pengembangan di sisi server dan juga front end. Kami juga memiliki pengetahuan yang luas tentang metode perancangan berbasis dokumen seperti definisi persyaratan sistem dan dokumen desain.

 

Yang penting dalam dokumentasi sistem adalah menyeimbangkan penyempurnaan dan kecepatan. Dalam persyaratan definisi dan dokumen desain yang terlalu rumit, masalah besar akan terjadi setelah pembangunan. Di sisi lain, tidak mungkin mendokumentasikan spesifikasi sistem yang belum selesai. Oleh karena itu, kami akan memutuskan konten desain secara rinci dengan mempertimbangkan kegunaan dan efisiensi kerja yang realistis, seperti memperbaiki item yang sangat penting sementara memperbaiki faktor-faktor yang berubah tergantung pada cara disain dan pengembangan.

Dalam definisi persyaratan, hal-hal berikut terutama didefinisikan.

 

  • Lingkup pengembangan
  • Konsep sistem
  • Persyaratan lingkungan (perangkat keras, perangkat lunak, jaringan)
  • Proses bisnis
  • Kebutuhan fungsional
  • Persyaratan kinerja
  • Input / Output
  • Kebutuhan data (database)
  • Persyaratan keamanan
  • Persyaratan mutu

Mengenai disainnya, kita sering berhadapan dengan isi berikut.

 

  • Struktur fungsional
  • Tipe data dan metode pengolahannya
  • Komponen layar dan perilaku backend
  • Pemilihan software dan solusi
  • Spesifikasi dan metode operasi API
  • Definisi modul program
  • Aliran proses
  • Jenis dan perilaku data input / output
Jangan ragu untuk menghubungi kami untuk apa pun.