Proses Desain Responsif yang Efisien

Seperti apa proses desain responsif Anda? Apakah Anda merasa itu efisien? Artikel berikut adalah kutipan dari bab Ben Callahan "Proses Responsif," pertama kali diterbitkan dalam versi eBook Smashing Book 5 (daftar isi). —Ed.

“Responden yang berhasil untuk RFP ini akan memberikan tiga opsi desain statis untuk dievaluasi oleh tim kami.” Saya tidak pernah menjadi penggemar berat mengambil pendekatan desain multi-opsi, tapi saya mengerti — terkadang klien membutuhkan ini.

“Masing-masing opsi ini akan menyediakan desain untuk tiga tata letak unik: halaman beranda, halaman daftar, halaman detail.” Baiklah. Sekarang, kami memiliki hingga sembilan file desain statis. Ini menjadi sedikit di luar kendali.

“Masing-masing desain halaman unik ini harus mempertimbangkan ukuran seluler, tablet, dan desktop.” Saya tidak pernah hebat dalam matematika, tetapi saya bisa melakukan perhitungan ini. Dua puluh tujuh file desain statis?! Tidak akan terjadi.

Ini adalah permintaan proposal kehidupan nyata yang saya terima belum lama ini. Ternyata klien sangat setuju dengan pendekatan yang lebih efisien. Tapi pengalaman ini benar-benar membuat saya berpikir… Hal tersulit dalam melakukan hal ini sebenarnya bukanlah melakukan hal ini. Ini bekerja dengan orang-orang saat Anda melakukan hal ini.

Soalnya, hampir setiap calon klien di luar sana sudah memiliki website . Bagi kami, itu berarti sebagian besar klien datang ke sini dengan serangkaian harapan, bersama dengan beban mereka sendiri dari proyek web sebelumnya. Bagasi itu dapat berdampak drastis pada cara klien Anda mendekati proyek — dan Anda. Untuk membantu mengurangi efek negatif dari ekspektasi ini, saya menemukan cara terbaik untuk mengelolanya adalah menjadi orang yang menetapkannya.

Ini adalah tujuan saya dalam bab ini untuk membantu Anda menjadi lebih sukses dengan proyek web Anda dengan memulai dari awal ; dengan bekerja sejak hari pertama untuk membantu menetapkan harapan klien Anda tentang apa yang akan terjadi, dan dengan bekerja sepanjang siklus hidup proyek untuk melakukan hal yang sama.

Perbedaan Utama Dalam Proses Untuk Desain Web Responsif

Sebelum Anda membuka editor teks favorit Anda, sebelum Anda membuka Macaw, sebelum Anda mengeluarkan buku sketsa Anda atau mulai memahat dengan teks, Anda perlu membantu pelanggan Anda memahami prosesnya. Ada banyak cara untuk melakukan ini, dan yang paling tidak saya sukai adalah mencoba menjualnya dengan proses baru. Menurut pengalaman saya, menunjukkan nilai dalam cara berpikir Anda sejak dini — bahkan sebelum kontrak ditandatangani — adalah pendekatan terbaik. Ini memberi klien Anda kepercayaan diri bahwa Anda tahu apa yang Anda bicarakan, tetapi itu juga berarti Anda perlu mendapatkan kepercayaan mereka untuk mencoba cara baru.

Untuk mendorong ini, ada empat cita -cita yang saya dan tim coba ingat saat kami berinteraksi satu sama lain: berkolaborasi, beralih, beradaptasi, dan memprioritaskan. Izinkan saya menjelaskan secara singkat mengapa ide-ide spesifik ini akan membuat Anda tetap lurus dan sempit.

Berkolaborasi

Saya tahu saya tahu. Semua orang di mana pun berbicara tentang kolaborasi dan bagaimana kolaborasi itu diperlukan untuk melakukan pekerjaan yang hebat. Nah, Anda tahu apa? Itu benar. Tentu saja, Anda perlu berkolaborasi dalam tim Anda, tetapi ada jenis kolaborasi lain yang dibutuhkan saat ini — berkolaborasi dengan klien Anda . Saya punya pengingat penting untuk Anda: klien juga manusia. Mereka mungkin tidak memiliki keahlian Anda dalam hal desain dan pengembangan web, tetapi mereka tahu lebih banyak tentang bisnis mereka daripada Anda.

Sekali lagi, itu dimulai dari awal. Di Sparkbox, saya telah mencari cara untuk lebih kolaboratif dalam menghadirkan klien baru. Sebagai bagian dari ini, kami telah mengambil pendekatan baru untuk menulis perkiraan. Alih-alih seorang pelanggan datang kepada kami dan menjelaskan proyek mereka sehingga kami dapat menghilang selama seminggu dan kembali dengan The Perfect Solution, kami telah mengundang mereka untuk membantu kami dengan perkiraan. Ini sangat mudah — kami menyebutnya estimasi kolaboratif dan klien menyukainya.

Kami mulai dengan spreadsheet Google dasar yang memiliki beberapa bidang yang dapat disesuaikan dan menghitung berapa biaya yang kami perlukan untuk melakukan pekerjaan itu. Kami memulai dengan rentang yang luas karena kami melakukan ini sangat awal dalam proses — biasanya hanya setelah panggilan telepon 30 menit. Kemudian kami membaginya dengan klien, dan kami mengerjakannya bersama.

Inilah mengapa ini penting: kami berkolaborasi dalam hal pertama yang kami lakukan dengan klien kami. Kami ingin mereka tahu bahwa kami menambahkan nilai lebih ketika kami bekerja dengan mereka daripada untuk mereka. Ini hanyalah salah satu cara kita menaruh uang kita di mana mulut kita berada.

Kami juga mengundang klien kami ke saluran komunikasi tim kami dengan kami. Kami penggemar berat Slack dan Basecamp. Alat-alat ini memberikan perpaduan yang baik antara dokumentasi formal dan percakapan informal, yang keduanya diperlukan untuk memfasilitasi kolaborasi yang berkualitas.

Dalam desain ulang terbuka Daniel Mall dari situs web Reading Is Fundamental, kita semua melihat sekilas bagaimana Dan membawa pelanggannya ke dalam proyek bersamanya. Brad Frost melangkah lebih jauh dengan proyek GitHub yang disebut "Project Hub" yang merupakan alat untuk melacak kemajuan proyek Anda.

Ingat, ini semua hanyalah alat. Alat dapat membantu, tetapi yang benar-benar dibutuhkan adalah perubahan cara berpikir kita. Teman saya Kevin Sharon pernah mengatakan sesuatu yang sangat menyentuh kepada saya. Dia berkata, "Jika Anda tidak bisa mengatakan 'Tidak,' itu bukan kolaborasi." Saya tidak tahu tentang Anda, tetapi saya memiliki banyak hubungan dengan klien di mana saya tidak memiliki wewenang untuk menolak — bahkan jika saya tahu dari pengalaman apa yang mereka minta tidak akan berhasil. Klien ini datang kepada Anda dengan solusi daripada masalah yang perlu dipecahkan.

Saya malu untuk mengakuinya, tetapi saya juga memiliki hubungan klien yang sebaliknya. Terkadang rasa frustrasi menguasai diri saya, dan saya lupa bahwa saya membutuhkan klien saya untuk menjadi bagian dari proyek tersebut. Ketika kami mendengar ide dari pelanggan kami dan langsung tidak setuju, kami sama bersalahnya dengan mereka dalam menolak proses kolaboratif. Banyak studio web tidak mengizinkan kolaborasi semacam ini dalam proses mereka, seringkali karena mereka tidak percaya klien mereka cukup kreatif atau teknis untuk berkontribusi dengan cara yang berarti.

Kolaborasi adalah jalan dua arah. Mengubah pandangan Anda tentang pelanggan Anda ke arah mereka menjadi kontributor sejati dalam pekerjaan Anda akan menghasilkan segala macam cara baru untuk memasukkan mereka dan membantu Anda menciptakan produk yang lebih baik.

Pengulangan

Kami secara teratur mencari peluang untuk menghadirkan sebagian kecil fungsionalitas berkualitas tinggi dengan kecepatan luar biasa. Mengambil pendekatan seperti ini menunjukkan kemajuan lebih awal dan memberikan peluang nyata untuk membiarkan apa yang telah Anda pelajari menciptakan momentum untuk membawa Anda melalui sebuah proyek.

Jika Anda merasakan bahwa mungkin ada tantangan politik dalam mengubah cara kerja klien Anda, inilah tip pro (dan saya merasakan ini di setiap proyek yang kami lakukan): bekerja berulang-ulang dapat membantu mengubah skeptis menjadi advokat. Kebanyakan orang lebih cenderung membiarkan Anda mencoba cara baru mengerjakan fase kecil daripada keseluruhan proyek. Sekali lagi, poin utama di sini adalah untuk menunjukkan nilai Anda lebih awal untuk mendapatkan kepercayaan dari pelanggan Anda.

Salah satu cara iterasi memanifestasikan dirinya adalah dalam pembuatan prototipe. Kami terus mencari peluang untuk mengidentifikasi tantangan yang signifikan, menyarankan solusi yang memungkinkan, membuktikan atau menyangkal validitasnya melalui pembuatan prototipe, revisi, dan ulangi.

Seringkali kita mencari kesempatan untuk memulai dengan fase penemuan berbayar sebelum memulai proyek besar; menganggapnya sebagai kencan sebelum Anda menikah. Ini memberi Anda kesempatan untuk belajar lebih banyak tentang proyek dan bagaimana rasanya bekerja dengan klien ini. Kedua belah pihak dapat menentukan apakah hubungan kerja itu cocok.

Keterlibatan awal dapat mengambil banyak bentuk, tetapi tujuan utamanya adalah untuk:

1. Lebih memahami ruang lingkup proyek
2. Identifikasi dan buktikan kemungkinan solusi untuk tantangan terbesar
3. Cari tahu apakah kecocokan klien/vendor benar
4. Buktikan kamu mampu
5. Dapatkan bayaran untuk hal di atas

Klien Anda akan menghargai pendekatan ini dan Anda akan membangun fondasi yang bagus untuk pekerjaan di masa depan. Dan jika Anda mempelajari sesuatu yang secara dramatis mengubah pemahaman Anda tentang proyek, Anda hanya akan berkomitmen pada fase kecil. Pembelajaran ini akan sangat menginformasikan langkah selanjutnya dalam proses dan mendorong Anda menuju solusi yang lebih baik.

Kami memiliki pelanggan yang telah bekerja dengan kami selama bertahun-tahun; sebenarnya, kami baru saja memulai proyek ketiga puluh kami dengan mereka. Bagi saya, ini adalah tanda bahwa kami telah menemukan cara yang saling menguntungkan untuk bekerja sama — mereka melihat nilai dalam apa yang kami tawarkan, dan kami secara kreatif dan teknis puas dalam pekerjaan kami dengan mereka. Dalam mencoba menunjukkan dengan tepat apa yang membuat hubungan ini berhasil, saya terus kembali ke pendekatan berulang kami. Ada banyak waktu ketika mereka datang kepada kami dengan masalah dan ide bagaimana menyelesaikannya. Alih-alih hanya menggigit apa yang mungkin merupakan proyek 12 minggu, kami secara teratur menyarankan fase berulang yang lebih kecil yang menguji solusi yang mungkin dan memiliki investasi awal yang jauh lebih rendah. Mengambil pendekatan ini telah memungkinkan kami untuk mendapatkan kepercayaan mereka. Kepercayaan itu sangat diperlukan dalam menciptakan hubungan yang berkelanjutan, dan iterasi adalah inti dari semuanya.

Menyesuaikan

Ketika desain web responsif muncul, saya ingat saya dikejutkan oleh gagasan bahwa fleksibilitas yang melekat pada produk yang kami bangun sedang bekerja dalam proses kami. Samantha Warren mengatakan yang terbaik: "Proses Anda harus responsif seperti produk yang Anda rancang."

Sebenarnya, tidak ada proses yang sempurna untuk pekerjaan semacam ini. Anda dan saya perlu merangkul batasan yang kita hadapi. Setiap proyek, klien, ruang lingkup, garis waktu, anggaran, tim, tumpukan teknologi, matriks dukungan berbeda. Organisasi yang berhasil dalam bisnis ini adalah organisasi yang dapat bekerja dalam batasan proyek dan tetap melakukan pekerjaan yang tidak lekang oleh waktu.

Pandangan saya tentang proses jelas sulit untuk dijelaskan kepada pelanggan. Diberi kesempatan, saya mungkin akan mengunci beberapa orang kunci (termasuk klien) yang terlibat dengan proyek di sebuah ruangan selama beberapa minggu dan memberi mereka mandat untuk mencari tahu. Ambillah dari saya, klien tidak suka dikurung di kamar selama berminggu-minggu.

Sebaliknya, kita harus menemukan keseimbangan antara proses yang sangat kaku (di mana setiap langkah ditata dan didokumentasikan) dan proses improvisasi (di mana kita memercayai tim untuk menemukan pendekatan terbaik saat mereka berjalan). Ada banyak faktor yang perlu dipertimbangkan dalam menemukan keseimbangan ini. Berikut adalah tiga untuk memulai: ukuran tim; pengalaman tim; dan kekritisan proyek.

Ukuran Tim

Jauh lebih mudah untuk memungkinkan fleksibilitas yang besar dalam proses ketika Anda memiliki tim yang sangat kecil. Dua atau tiga orang yang duduk di ruangan yang sama akan dapat melacak apa yang terjadi tanpa banyak struktur. Ambil ukuran tim hingga enam atau tujuh dan mulai sulit untuk memahami dampak setiap pemain pada kemajuan keseluruhan proyek. Tingkatkan tim Anda menjadi sepuluh, lima belas, atau lebih dan itu hampir tidak mungkin.

Ini sangat pribadi bagi saya. Ketika saya pertama kali memulai Sparkbox dengan mitra saya, hanya ada empat dari kami. Kami masing-masing memiliki peran yang cukup jelas, dan kami dapat beroperasi dengan cukup efektif tanpa banyak proses. Karena kami semua duduk di satu ruangan besar bersama-sama, ada komunikasi yang konstan tentang semua aspek bisnis kami.

Sekarang, kami memiliki 23 orang penuh waktu, ditambah tiga orang magang. Kami tentu saja belum tumbuh secepat beberapa tempat — kami sangat berhati-hati dengan pertumbuhan kami — tetapi ungkapan "sakit tumbuh" masih terdengar benar. Kami harus terus-menerus bereksperimen dengan kapan, apa, dan bagaimana berkomunikasi. Hanya melalui eksperimen inilah kita dapat menemukan keseimbangan yang tepat untuk kita.

Pelajaran di sini adalah bahwa ukuran tim Anda memengaruhi jenis proses yang dapat Anda terapkan untuk proyek tertentu. Umumnya, semakin banyak orang yang Anda miliki dalam suatu proyek, semakin banyak kekakuan yang Anda perlukan. Saat ukuran tim Anda berkurang, Anda bisa lolos dengan proses yang tidak terlalu formal. Merupakan tanggung jawab manajer proyek Anda untuk memantau denyut nadi tim dan menyesuaikan proses agar semuanya berjalan lancar.

Pengalaman Tim

Ketika Anda bekerja dengan tim yang tidak berpengalaman, proses yang lebih ketat akan membantu menjaga semua orang pada halaman yang sama. Bahkan, saya percaya tim yang tidak berpengalaman membutuhkan proses konkret sebagai konteks untuk mendapatkan pengalaman. Hanya setelah menunjukkan keberhasilan dalam lingkungan yang lebih kaku, Anda dapat mulai mengupas lapisan proses yang memungkinkan tim lebih bebas dalam cara kerjanya.

Ini, sekali lagi, adalah konsep yang cukup pribadi bagi saya, terutama karena cara kami mengatur tim untuk sebuah proyek. Kami mengumpulkan tim unik untuk setiap proyek yang kami ambil; bahkan selama proyek berlangsung, ada kemungkinan kami akan merotasi orang masuk dan keluar dari tim. Hal ini dapat menciptakan tantangan, terutama jika pengalaman individu-individu tersebut sangat berbeda. Sebagian besar, itu berarti bahwa kita perlu menyadari fakta bahwa orang yang berbeda membutuhkan tingkat proses yang berbeda untuk menjadi sukses. Manajer proyek kami memantau ini dengan cermat dan menyesuaikan sesuai kebutuhan.

Kami memiliki banyak desainer dan pengembang berpengalaman, jadi keseimbangan ini sebagian besar tentang menyebarkan orang-orang yang kurang berpengalaman. Menambahkan satu atau dua pengembang baru ke tim yang sangat terampil akan meningkatkan standar untuk semua orang. Pengembang baru akan belajar dari yang lebih berpengalaman, dan yang lebih berpengalaman akan belajar dengan mengajar para pengembang baru. Ini menghasilkan win-win!

Kekritisan Proyek

Gagasan tentang betapa pentingnya proyek ini berasal dari seorang pria bernama Alistair Cockburn, salah satu penandatangan asli Agile Manifesto. Dalam tulisannya tentang “Crystal Methods”, Cockburn menjelaskan kisaran kekritisan dengan melengkapi pernyataan ini.

Cacat menyebabkan hilangnya:

1. Kenyamanan (tidak kritis)
2. Uang tambahan (agak kritis)
3. Uang penting (kritis)
4. Hidup (sangat kritis)

Semakin kritis produk kita, semakin kaku proses kita. Anda mungkin pernah mengalami hal ini jika Anda pernah bekerja untuk bisnis kecil dan besar. Kecil, perusahaan lokal cenderung memberi Anda lebih banyak kebebasan dalam cara Anda bekerja karena mereka memiliki lebih sedikit yang dipertaruhkan (kekritisan lebih rendah); perusahaan besar memiliki lebih banyak kerugian (kekritisan lebih tinggi) jika proses Anda tidak menghasilkan hasil yang baik.

Ketika saya baru memulai industri ini, saya bekerja hampir secara eksklusif dengan bisnis lokal kecil. Saya mengelola proyek dengan catatan tempel, email, dan panggilan telepon setiap minggu. Sekarang, saya terlibat dengan organisasi yang jauh lebih besar. Mengelola proyek-proyek ini mengharuskan kami untuk berpartisipasi dalam pertemuan harian stand-up, retrospektif, dan perencanaan sprint. Kami menemukan diri kami membangun burn-up, bekerja di JIRA (perangkat lunak pelacakan masalah), dan menghitung kecepatan kami lebih dari yang saya akui. Semua ini karena kekritisan pekerjaan — persentase kecil dari jumlah yang cukup besar tetaplah jumlah yang besar. Perusahaan-perusahaan besar ini memahami hal ini, dan mereka memiliki proses untuk melindungi mereka dari kerugian besar tersebut.

Prioritaskan

Karena ukuran layar yang kami rancang untuk berkurang, demikian juga opsi kami untuk prioritas komunikasi. Pikirkanlah: kami biasanya menggunakan hal-hal seperti ukuran, posisi, urutan, dan kontras untuk membantu pengguna memahami di mana mereka harus fokus. Di layar kecil, hanya ada begitu banyak yang dapat Anda lakukan dengan ukuran objek atau posisi judul. Kami hanya tidak memiliki kebebasan yang sama seperti yang kami miliki ketika fokus kami adalah pada pengalaman layar yang lebih besar.

Untuk alasan ini, sangat penting untuk memahami prioritas konten dan fungsionalitas di seluruh sistem. Luke Wroblewski dengan cemerlang mendorong kami untuk memikirkan perangkat seluler terlebih dahulu untuk membantu klien kami memahami apa yang benar-benar penting. Sebenarnya, tanpa pemahaman yang kuat tentang prioritas, desain web responsif hanyalah dugaan.

Kami telah mendorong hal ini pada pelanggan kami dengan membuat mereka berpikir linier sejak awal proses. (Di bagian "Menyelesaikan" di bawah ini, saya akan membagikan jenis alat yang kita gunakan untuk melakukan ini.) Berpikir secara linier memiliki manfaat mengharuskan orang untuk memilih apa yang paling penting, dan prioritas inilah yang perlu Anda sepakati. Menetapkan ini langsung dalam proyek Anda akan meletakkan dasar yang diterima untuk membangun, dan memberikan jawaban atas banyak pertanyaan Anda akan menemukan diri Anda bertanya nanti dalam proyek.

Kami baru-baru ini memiliki proyek di mana klien kami datang kepada kami dengan wireframe layar lebar yang sudah disatukan. Mereka telah melakukan ini dalam upaya untuk menghemat uang, dan kami senang untuk mencoba bekerja dengan mereka dengan cara ini. Ketika kami mulai mendesain, klien tidak senang dengan pekerjaan kami. Baru pada pertengahan proyek kami menyadari bahwa wireframe layar lebar tidak cukup mengidentifikasi prioritas konten dan fungsionalitas. Ini adalah inti dari masalah yang kami alami. Kami akhirnya kembali untuk melakukan beberapa analisis konten dan prioritas untuk mendapatkan kembali momentum pada proyek. Seandainya kami melakukannya lebih awal, kami bisa bekerja lebih efisien di seluruh proyek. Sayangnya, dalam upaya membantu mereka menghemat uang, kami harus melakukan beberapa pengerjaan ulang yang sebenarnya bisa dihindari jika kami meletakkan fondasi yang tepat terlebih dahulu! Pelajaran yang didapat — tetapkan prioritas lebih awal.

Empat Cita-cita

Saat Anda melompat ke proyek berikutnya, ingatlah bahwa Anda perlu menyertakan klien Anda dalam proyek tersebut. Cari peluang untuk berkolaborasi dengan mereka alih-alih hanya bekerja untuk mereka. Ingatlah bahwa semakin Anda menunjukkan nilai lebih awal, semakin banyak kepercayaan yang akan Anda peroleh. Iterasi membantu Anda melakukan ini — jangan takut untuk memulai dari yang kecil! Juga, ingatlah bahwa Anda pasti harus menyesuaikan cara kerja Anda agar lebih sesuai dengan apa yang mungkin dibutuhkan oleh proyek atau klien tertentu. Terakhir, dorong keras untuk menetapkan prioritas konten dan fungsionalitas di awal proyek. Ini akan membayar dividen nanti dalam proyek ketika muncul pertanyaan tentang pentingnya jenis konten tertentu.

Di luar empat cita-cita ini, saya ingin memberikan sedikit kerangka kerja untuk Anda saat Anda mempertimbangkan proses seperti apa yang akan berhasil dalam kehidupan Anda sehari-hari.

Kerangka Kerja Untuk Mempertimbangkan Proses

Proses Kami Selalu Berjuang Untuk Hidupnya

Satu hal yang membuat saya takjub tentang sebagian besar presentasi atau proses penulisan adalah seberapa percaya diri orang-orang yang berbagi. Mungkin kita adalah outlier, tapi proses kita selalu berjuang untuk hidupnya. Jika cara kerja baru muncul, kami akan mencobanya. Jika menurut kami ada petunjuk tentang cara yang lebih baik untuk melakukan sesuatu, kami akan menggali untuk mengungkapnya. Ini hanya bagaimana kita terhubung. Saya merasa bahwa banyak dari Anda juga terhubung dengan cara ini.

Mari kita sepakat bahwa proses kita tidak pernah selesai.

Bergeser Dari Hand-off Linear

Sebagian besar di industri setuju bahwa kita harus berhenti melempar kiriman ke tembok. Sebaliknya, banyak yang berpikir tentang bagaimana mengatur ulang tim mereka dengan harapan bahwa melibatkan orang yang tepat selama proyek akan meningkatkan empati rekan tim dan meningkatkan standar untuk semua orang. Trent Walton menggambarkan hal ini dengan fasih dalam postingannya yang berjudul “Reorganisasi.” Di dalamnya, ia menceritakan bahwa struktur tim Anda sering membatasi jenis proses yang dapat Anda gunakan dan mendorong kami untuk mempertimbangkan tim lintas disiplin yang lebih kecil. Kami telah melihat ini benar dan mengambil pendekatan yang sangat mirip. Sejujurnya, proses linier masa lalu kita mungkin selalu sedikit tidak efisien. Saya percaya desain web responsif hanya membuat ketidakefisienan itu menjadi lebih jelas; menangani pekerjaan responsif telah membawa saya ke percakapan dengan klien kami seputar struktur organisasi mereka — lebih banyak bukti bahwa RWD benar-benar merupakan katalisator untuk perubahan organisasi.

Kita perlu melibatkan lebih banyak disiplin untuk lebih banyak proyek. Saya suka menganggap ini sebagai spiral melalui sebuah proyek dengan mata kita terfokus pada produk akhir, pada satu hasil. Dengan setiap putaran, kami melibatkan semua disiplin ilmu, dan kami mendapatkan lebih banyak kejelasan di semua titik keputusan. Konsepnya sederhana: biarkan seluruh tim memainkan peran selama durasi proyek. Dengan kata lain, kenali dan rangkul dampak yang membuat perubahan di satu area proyek terhadap yang lain.

Saya dan tim saya mendapatkan ide ini (berputar melalui sebuah proyek) karena interaksi kami dengan seorang mentor bisnis saya. Namanya Geoff, dan dia orang yang sangat tajam. Dia telah menjadi CFO dari beberapa organisasi yang cukup besar dan telah meniti karir dengan membantu para pemimpin visioner memahami keuangan perusahaan mereka.

Ketika kami pertama kali bertemu dengan Geoff, kami berada dalam mode krisis. Kami memiliki tantangan besar di depan kami, tantangan yang baik saya maupun mitra saya tidak tahu bagaimana mengatasinya. Geoff mendudukkan kami semua dan meminta kami untuk "memulai dengan tujuan akhir". Dia ingin kami menjelaskan seperti apa jadinya setelah kami berhasil melewati masa-masa sulit di masa depan. Dia ingin kita mendefinisikan kesuksesan kali ini dalam kehidupan perusahaan kita. Saat kami terus bertemu dengan Geoff, saya mulai frustrasi. Setiap kali kami duduk, saya berharap dia akan memberi kami nasihat yang kami butuhkan untuk mulai memecahkan masalah yang kami hadapi. Sebaliknya, dia terus-menerus mengajukan lebih banyak pertanyaan. Ini berlangsung selama beberapa minggu, dan itu adalah waktu yang sulit bagi saya.

Saya tidak akan pernah melupakan pertemuan yang saya lakukan dengan Geoff dan rekan-rekan saya di mana semuanya mulai masuk akal. Pertemuan kami dimulai seperti yang lainnya; kami melewati pemahaman kami saat ini tentang masalah di depan kami dan meluangkan waktu untuk berbagi wawasan baru yang kami peroleh. Hanya kali ini, masing-masing dari kita mulai melihat solusi yang muncul. Itu tidak sepenuhnya jelas, tetapi mulai menjadi fokus. Dari tiga opsi yang kami pertimbangkan, satu mulai terlihat jauh lebih menarik daripada yang lain. Apa yang telah kami pelajari selama beberapa bulan terakhir tidak salah lagi membawa kami ke pilihan terbaik untuk mengatasi masalah yang kami hadapi.

Pelajaran ini sangat berharga bagi saya. Apa yang diajarkannya kepada saya adalah bahwa proses linier mengharuskan kita membuat keputusan sebelum kita memiliki semua informasi. Bagaimana mungkin kita bisa mengetahui semua yang perlu kita ketahui untuk membuat satu set gambar rangka tanpa mempertimbangkan desain visual? Bagaimana kita bisa menyempurnakan desain antarmuka tanpa bereksperimen dengan beberapa kode front-end? Ketika kami bertindak seolah-olah mungkin untuk memulai dengan konten, kemudian melakukan beberapa desain pengalaman pengguna, kemudian melakukan beberapa desain antarmuka pengguna, dan seterusnya, kami mengabaikan dampak yang dimiliki masing-masing kiriman ini terhadap yang lain. Sebaliknya, kita perlu mengizinkan mereka untuk saling memberi tahu. Kita perlu memberi mereka ruang untuk bernapas, menyesuaikan diri, dan menggunakan apa yang dipelajari dari proyek untuk membawa mereka maju.

Inilah proses spiral yang didorong oleh Geoff kepada kami. Minggu-minggu mengajukan pertanyaan itu menginformasikan pemahaman kami tentang masalah tersebut. Alih-alih membuat keputusan (menyetujui desain UI) dan melanjutkan seolah-olah itu tidak akan pernah berubah (OK, pengembang front-end, buat kode desain ini), Geoff memaksa kami untuk menyadari bahwa kami tidak memiliki semua informasi yang kami butuhkan untuk membuat keputusan terbaik. Geoff ingin kita menunggu sampai "saat terakhir yang bertanggung jawab" untuk memutuskan.

Saya telah mencoba menerjemahkan ide spiral ini menjadi apa yang kita lakukan setiap hari, dan saya mendapatkan visualisasi seperti ini:

Silakan masukkan disiplin Anda sendiri ke dalam irisan kue di atas — gambar disederhanakan untuk mengilustrasikan pendekatannya. Penting untuk dicatat bahwa titik-titik itu bukanlah hasil dalam pengertian tradisional. Mereka mewakili peluang bagi Anda untuk duduk bersama klien Anda dan meninjau kemajuan Anda menuju "satu hasil". Ini berarti: berhenti menyempurnakan kiriman karena takut mengecewakan klien Anda. Sangat tidak efisien untuk membuat gambar rangka Anda terlihat cantik di Illustrator ketika sketsa di papan tulis bisa digunakan. Kami bahkan berhenti menyebutnya sebagai kiriman dan mulai menyebutnya sebagai pembaruan .

Alur kerja semacam ini cukup fleksibel untuk digunakan pada jenis proyek apa pun karena Anda dapat dengan mudah menukar jenis disiplin ilmu yang diperlukan untuk proyek tersebut. Upacara di sekitar proses dapat dibuat lebih kaku atau lebih improvisasi tergantung pada pengalaman orang yang terlibat. Kuncinya adalah memastikan semua orang terlibat.

Pendekatan ini menunda keputusan sampai Anda memiliki informasi yang tepat. Ia mengakui bahwa keputusan yang dibuat oleh satu disiplin pasti akan mempengaruhi yang lain. Ini membuka percakapan ke tim dan membutuhkan dukungan dari semua yang terlibat. Ini kurang formal tetapi lebih efisien. Ini kurang dapat diprediksi, tetapi saya yakin ini memiliki potensi untuk menghasilkan produk yang jauh lebih baik.

Mari kita sepakat bahwa kita perlu mencari kontribusi multidisiplin.

Efisiensi Adalah Kunci

Jika kita punya banyak waktu di dunia, kita tidak perlu khawatir tentang proses kita — kita bisa mencoba hal-hal sampai kita menemukan ide bagus. Anda dan saya sama-sama tahu ini bukan masalahnya.

Banyak penyesuaian yang kami lakukan pada proses kami di Sparkbox adalah karena kami mencari cara yang lebih cepat untuk mencapai sesuatu. Janji peningkatan kecepatan juga merupakan cara kami memperoleh peluang untuk bekerja dengan beberapa tim internal yang sangat berbakat di pelanggan yang lebih besar. Semua orang mencari keuntungan efisiensi.

Mari kita sepakat bahwa proses yang baik juga merupakan proses yang efisien.

Selalu Berkembang. Multidisiplin. Efisien. Saat kita masuk ke dalam mur dan baut hal ini, saya ingin kita mengingat tiga hal ini. Kita dapat menggunakan ide-ide ini sebagai filter yang melaluinya kita mempertimbangkan pendekatan baru.

Teori yang cukup

Sudah cukup teorinya. Mari kita masuk ke mur dan baut dari pekerjaan ini. Saya mendapati diri saya terus-menerus mengajukan tiga pertanyaan di seluruh proyek web kami:

1. Untuk siapa kita membangun?
2. Apa yang kita ingin mereka peroleh dari pengalaman itu?
3. Bagaimana seharusnya kita menyajikan pengalaman?

Tujuannya adalah menemukan cara untuk mengatakan hal yang benar (what) dengan cara yang benar (how) kepada orang yang tepat (who). Rahasia komunikasi yang hebat dalam bentuk apa pun adalah menjawab pertanyaan-pertanyaan ini. Anda tentu saja akan mengajukan banyak pertanyaan lain selama proyek Anda. Pertanyaan seperti pola navigasi seperti apa yang harus saya gunakan di situs ini, atau apakah kami benar-benar membutuhkan iklan di bagian atas setiap halaman? Saya menyarankan bahwa memiliki jawaban atas siapa, apa dan bagaimana akan membawa Anda ke arah yang benar saat Anda menjawab semua pertanyaan lain yang muncul.

Mudah-mudahan, Anda sudah membaca bab Dan Mall (sebelum yang ini). Di dalamnya, dia melakukan pekerjaan yang bagus dengan memberikan beberapa konteks seputar pemahaman dengan siapa Anda berkomunikasi. Penjelasannya tentang wawancara dan pertemuan awal akan menggerakkan Anda dengan kokoh ke arah yang benar.

Demikian pula, bab berikutnya oleh Eileen Webb adalah semua tentang strategi konten untuk proyek responsif Anda. Ini adalah bab yang menyeluruh, dan dia menjawab pertanyaan seputar apa yang kami coba komunikasikan lebih baik daripada yang pernah saya bisa.

Jadi, sisa bab ini didedikasikan untuk menjawab pertanyaan ketiga, “Bagaimana?” Saya akan berbagi dengan Anda jenis alat yang paling membantu saya dan tim saya di Sparkbox dan percaya bahwa mereka juga akan membantu Anda!

Menyelesaikannya

Seperti yang saya sebutkan sebelumnya, memahami prioritas konten dan fungsionalitas yang kami sajikan sangat penting untuk berkomunikasi secara efektif. Berikut adalah beberapa cara kebenaran ini memanifestasikan dirinya dalam pekerjaan yang kita lakukan.

Panduan Prioritas Konten

Panduan prioritas konten adalah "pemodelan konten bagian, wireframe bagian stripped-down" (lihat "Panduan Prioritas Konten" oleh Emily Gray.); seperti model konten mini, dalam urutan prioritas, dan dengan kolaborasi klien. (Lihat https://bit.ly/content-priority-guide untuk contoh kerja panduan prioritas konten.)

Panduan prioritas konten memberi tahu Anda jenis konten apa yang harus ada di setiap halaman. Ini bisa berupa hal-hal sederhana seperti judul, gambar utama, dan body copy pada posting blog, atau bisa lebih kompleks: pertimbangkan semua jenis konten yang mungkin Anda perlukan di halaman detail produk situs e-niaga.

Hal ini juga memungkinkan untuk penjelasan dari setiap jenis konten. Jika Anda memiliki deskripsi singkat tentang suatu produk, panduan prioritas mungkin mengatakan, “Satu kalimat yang menjelaskan produk dan apa yang membuatnya unik.” Untuk item seperti gambar pahlawan, Anda dapat memberikan beberapa detail tentang arah seni foto jika itu relevan untuk kasus tertentu.

Panduan prioritas konten juga membantu Anda mengidentifikasi komponen yang dapat digunakan kembali dengan cepat. Ini sangat membantu saat Anda merencanakan pengelolaan konten itu — mengenali pola yang dapat digunakan kembali berarti Anda dapat membangun sistem yang lebih efisien untuk mengelola konten.

Yang terpenting, panduan prioritas ada dalam urutan prioritas . Ini memicu diskusi tentang apa yang benar-benar penting pada halaman tertentu. Ini sangat membantu saat Anda mempertimbangkan bagaimana situs akan merespons di seluruh lebar viewport. Dan karena tidak berisi konten yang sebenarnya, ini memfasilitasi percakapan hebat tentang apa dan mengapa jenis konten, yang dapat dengan mudah diabaikan jika Anda segera mulai menulis salinannya.

Jika klien Anda mengalami kesulitan memprioritaskan (dan mereka mungkin akan melakukannya), Anda dapat menempatkan keputusan ini di sekitar apa yang paling penting ke dalam spreadsheet dan memberi mereka pilihan untuk memeriksa — primer, sekunder, tersier, dll. Hasilnya sama: Anda memiliki daftar jenis konten yang diprioritaskan untuk setiap halaman, tetapi proses untuk sampai ke sana mungkin terasa sedikit lebih ramah bagi klien jika mereka diberi beberapa opsi.

Arsitektur Informasi

Setelah Anda memiliki pemahaman yang baik tentang jenis dan prioritas konten yang perlu ada dalam sistem, penting untuk mempertimbangkan bagaimana konten tersebut harus dikelompokkan dan jalur melalui konten yang Anda inginkan agar diambil oleh pengguna Anda. Pemikiran seperti ini sangat penting untuk pembuatan situs yang dapat digunakan.

Saya baru-baru ini melihat Aaron Quinn berbicara tentang arsitektur informasi dan dia mengatakan sesuatu yang benar-benar melekat pada saya. Dia menyarankan bahwa kita mungkin terlalu mengandalkan akal sehat kita dalam hal pengelompokan informasi. Sebagai gantinya, dia membuat kasus bagi kami untuk mempertimbangkan konsensus atas akal sehat ketika merencanakan bagaimana pengguna kami akan berinteraksi dengan apa yang kami bangun. Mari saya jelaskan mengapa dengan cerita singkat.

Kami memiliki klien yang telah bekerja sama dengan kami selama lebih dari satu tahun sekarang. Dia telah mem-bootstrap produk SAAS yang sangat sukses yang kami bantu buatnya. Wanita ini sangat cerdas; dia bekerja di web setiap hari — begitulah cara dia mencari nafkah. Belum lama ini, saya berbicara dengannya tentang produk selanjutnya dan dia mengatakan ini kepada saya: "Saya pikir kita perlu membuat beberapa perubahan pada tab di situs kita." Saya berhenti karena saya mati-matian mencoba mengingat di mana kami telah menerapkan tab di situsnya. Merasakan kebingungan saya, dia melanjutkan untuk menjelaskan lebih banyak tentang apa yang dia harapkan. Setelah beberapa saat, saya menyadari bahwa dia sedang berbicara tentang navigasi. Sungguh membuka mata bahwa pengusaha web yang cerdas ini menyebut navigasinya sebagai "tab."

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efisien. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

That's enough theory. Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. Who are we building for?
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

Getting It Done

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

Information Architecture

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

Style Comparisons

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

You get the idea. The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

User Experience Design

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

Itu banyak. And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

Jika kita membangun secara responsif, kita perlu fokus pada pengujian solusi satu situs di seluruh lebar viewport. Kita perlu mengukur kegunaan keseluruhan, bukan hanya titik putus. Ini akan membantu kami menciptakan pengalaman yang paling berguna bagi kebanyakan orang.

Dan sekarang, beberapa pembaruan yang kami gunakan dengan klien kami untuk membantu mencapai tujuan ini.

Prototipe Konten

Anda pernah mendengar bahwa seorang desainer web harus mempelajari beberapa CSS, bukan? Yah, saya setuju, dan saya pikir ahli strategi konten harus mempelajari beberapa HTML. Untuk alasan ini, dan banyak lainnya, kami telah membangun prototipe konten cukup awal dalam proses pengembangan web kami. Segera setelah kami mulai mendapatkan gambaran yang jelas tentang konten yang sebenarnya, kami mulai menandai konten tersebut dengan hypertext . Ini adalah apa yang kita lakukan dengan HTML, kan? Siapa yang lebih baik untuk membungkus konten dalam tag semantik daripada orang-orang yang paling memahami konten? Meskipun alat seperti Penurunan Harga dapat bekerja dengan baik, saya pikir yang terbaik adalah mempelajari beberapa HTML dasar sebelum Anda langsung beralih ke Penurunan Harga. Memahami mengapa Anda menulis konten dengan cara ini sama pentingnya dengan menulis HTML sebenarnya. Alat seperti Markdown menambahkan lapisan abstraksi antara tindakan Anda dan output dari tindakan tersebut — abstraksi yang baik-baik saja, setelah Anda memahami apa yang diberikannya kepada Anda.

Saat kami membuat prototipe konten, kami sengaja mengabaikan hampir semua gaya. Kami meninggalkan mereka cukup jelek, jadi sangat jelas kami belum merancang apa pun. Ini membuat percakapan tetap fokus pada konten dan prioritas konten itu. Ketahuilah bahwa ketika Anda menunjukkan ini kepada pelanggan, mereka akan segera pulang sesuai urutannya — yang persis seperti yang Anda ingin mereka lakukan: dapatkan prioritas itu dengan benar! Selain itu, kami biasanya menyertakan cukup CSS untuk menampilkan pengelompokan, seperti:

Aku bilang itu jelek.

Kami juga membanjiri prototipe konten kami dengan tautan. Salah satu alasan kami membuat ini adalah untuk memungkinkan orang menavigasi dari halaman ke halaman, untuk melihat apakah alur melalui konten berfungsi.

Ingat, Anda harus mempersiapkan klien Anda untuk melihat pembaruan buruk semacam ini. Jika tidak, mereka pasti akan berpikir dua kali untuk melibatkan Anda dalam proyek mereka. Namun, ada sesuatu yang hebat tentang melihat konten mentah yang ditandai di browser.

Satu catatan penting: kami menyadari bahwa markup semantik murni mungkin bukan yang akan diproduksi. Meskipun ini ideal, realitas pekerjaan di web saat ini adalah bahwa hal itu perlu dipelihara dan diperluas oleh individu dan tim dengan keahlian yang sangat bervariasi. Namun, memulai dengan markup versi murni ini adalah cara yang fantastis untuk mengingatkan kita akan cita-cita kita. Kemudian, saat kami menyesuaikan markup untuk memungkinkan penataan gaya, penggunaan kembali, perluasan, dan sebagainya, kami sangat sadar bahwa setiap perubahan yang kami buat menjauhkan kami dari yang ideal. Setiap perubahan adalah kompromi dan harus dipertimbangkan secara mendalam sebelum dibuat.

Wireframe Statis

Beberapa tahun terakhir telah melihat sedikit ketidaksukaan untuk gambar rangka statis yang lebih tradisional. Saya percaya mereka masih bisa menambahkan banyak nilai. Saya juga percaya mereka mungkin tidak diperlukan pada setiap proyek. Saat kami menggunakannya, kami biasanya melakukannya dengan lebar yang sempit — sama tidak nyamannya dengan ini — untuk membantu kami fokus pada prioritas. Membatasi real estat visual kami memaksa fokus ini. Kami telah menggunakan banyak alat untuk melakukan ini, mulai dari Keynote hingga Balsamiq. Sejujurnya, salah satu dari alat ini akan melakukan pekerjaan itu. Temukan satu yang membuat Anda nyaman dan mulai bekerja.

Kami juga melakukan banyak sketsa. Papan tulis, pensil dan kertas, berbagai aplikasi sketsa. Kami memotret barang-barang ini dan membagikannya dengan klien kami, dengan sengaja menjaga semuanya tetap mentah. Bahan mentah adalah bagian penting dari apa yang kami lakukan. Ini membantu pelanggan kami mengetahui bahwa kami tidak membuang waktu untuk memoles dokumen yang tidak akan mendapat manfaat dari poles, dan itu membuat umpan balik tetap fokus. Hal terakhir yang kami inginkan adalah seseorang mengomentari warna gambar rangka kami.

Wireframe Interaktif

Bagian dari dorongan menjauh dari wireframes yang lebih tradisional telah mendukung pendekatan yang lebih interaktif. Seperti Manifesto Agile yang mempromosikan perangkat lunak yang berfungsi daripada dokumentasi, banyak di industri kami percaya bahwa menunjukkan niat Anda untuk interaksi melalui prototipe jauh lebih kuat daripada mencoba menggambarkannya secara statis. Saat ini, alat yang tersedia untuk pembuatan prototipe cepat sangat mampu: kerangka kerja seperti Bootstrap dan Foundation; CSS (atau Sass and LESS) toolkit seperti Bourbon dan Pure CSS; alat prototyping visual seperti InVision dan Marvel. Bahkan alat desain dan pengembangan web visual seperti Macaw atau alat presentasi seperti Keynote dapat digunakan untuk membuat gambar rangka yang sangat interaktif.

Manfaat dari pendekatan ini adalah Anda dapat menunjukkan ide kepada orang-orang alih-alih mencoba menjelaskannya kepada mereka. Jika sebuah gambar bernilai seribu kata, sebuah prototipe bernilai seribu gambar.

Kami sekarang bekerja dengan organisasi yang memahami hal ini. Salah satu tujuan mereka adalah untuk membawa prototipe cepat lebih awal ke dalam proses mereka sehingga mereka dapat menggunakan prototipe untuk studi kegunaan, serta kode produksi. Pekerjaan kami dengan mereka difokuskan pada pembuatan sistem komponen yang dapat digunakan di semua properti web mereka. Sistem ini juga nantinya akan digunakan untuk memungkinkan tim mereka membangun wireframes interaktif dengan sangat cepat. Karena kami akan membangunnya dengan mempertimbangkan merek mereka, gambar rangka interaktif akan sangat mirip dengan rilis produksi mereka, yang akan sangat membantu dalam pengujian UX mereka.

Pendekatan semacam ini berfokus pada kesuksesan jangka panjang dari properti web. Ini mewujudkan alur kerja "satu yang dapat disampaikan" yang kita bicarakan sebelumnya dengan melibatkan semua disiplin ilmu dalam pembuatan prototipe, dan memungkinkan apa yang dipelajari selama desain dan pengembangannya untuk menginformasikan keputusan lebih lanjut. Saya yakin kita melihat pergeseran menuju organisasi yang membangun sistem front-end yang matang alih-alih meretas CSS bersama sebagai renungan. Memberi organisasi kemampuan untuk menguji versi statis dari pekerjaan web mereka dengan pengguna nyata adalah langkah besar menuju penyemenan ini sebagai norma dalam waktu dekat.

Desain dan Pengembangan UI

“Desain yang baik adalah pemecahan masalah.”

— Seni dan Ilmu Desain Web, Jeffrey Veen (2000) .

Bagi Anda yang berprofesi sebagai desainer, kutipan ini sangat tepat. Banyak orang melihat apa yang kita lakukan sebagai hiasan, tetapi sebenarnya lebih dari itu. Selama beberapa tahun terakhir, saya telah menemukan diri saya sepenuh hati setuju dengan sentimen pernyataan Jeff, tetapi juga sangat menyadari kecenderungan desainer untuk melebih-lebihkan solusi mereka. Ini membawa saya ke apa yang saya sebut "titik peralihan."

Jika Anda memecah aktivitas desain menjadi tiga fase — membangun estetika, memecahkan masalah, dan menyempurnakan solusi (seperti yang ditunjukkan di atas) — pergeseran dari pemecahan masalah ke penyempurnaan solusi adalah titik peralihan. Ini adalah saat terakhir yang bertanggung jawab untuk pindah ke media web. Jika Anda tidak melakukan ini, Anda akhirnya akan melakukan fase penyempurnaan itu beberapa kali — dan itu sangat tidak efisien.

Jika Anda pernah menghabiskan waktu berjam-jam untuk mengutak-atik PSD, menyerahkannya kepada pengembang untuk dibuat, dan kemudian memeriksanya kembali dalam satu atau dua minggu, Anda pernah mengalami rasa sakit ini. Semua upaya yang Anda lakukan untuk memperbaiki dan menyempurnakan dengan mendorong piksel statis menjadi sia-sia. Segera setelah desain mengubah media (dari desain statis di Photoshop atau beberapa alat lain ke HTML dan CSS di browser), diperlukan penyempurnaan lain. Gagasan di balik titik peralihan adalah untuk menyadari betapa tidak efisiennya hal ini. Alih-alih menyempurnakan dengan alat statis, dapatkan kode desain dasar sesegera mungkin dan tangani penyempurnaan di media akhir — web.

Ini sering membutuhkan pasangan desain, secara harfiah duduk bersama untuk membuat penyempurnaan itu menjadi hidup. Meskipun ini terkadang terasa lambat dan menyakitkan, ini sebenarnya sangat bermanfaat bagi semua yang terlibat. Saat seorang desainer berbagi dengan pengembang front-end jenis penyesuaian gaya yang ingin mereka lihat, pengembang front-end mempelajari apa yang penting dalam desain yang disempurnakan. Sementara pengembang front-end membuat perubahan yang diminta, perancang melihat bagaimana perubahan itu dibuat, mungkin mempelajari sedikit CSS. Proses ini membuat semua orang lebih pintar. Ini juga berarti bahwa pada saat kedua pasangan ini, itu akan berjalan lebih cepat.

Saat ini, kita harus merasa nyaman dengan sejumlah alat untuk memulai percakapan UI dan kita perlu mengubah pengkodean desain tersebut lebih awal dalam prosesnya. Mari kita lihat beberapa cara untuk melakukan ini.

Ubin Gaya

Samantha Warren membuat terobosan baru ketika dia memperkenalkan ubin gaya sebagai cara untuk "mendefinisikan bahasa visual" untuk web. Kami yang memiliki latar belakang branding segera melihat betapa berharganya ubin gaya.

Ubin gaya cukup sederhana. Mereka umumnya termasuk palet warna, pilihan tipografi, tekstur, dan ikonografi atau gaya ilustrasi. Mereka sengaja bukan comp satu halaman penuh. Sebaliknya, mereka mewakili desain yang cukup untuk menentukan apakah kita bergerak ke arah yang benar. Untuk alasan ini, mereka bekerja paling baik ketika klien Anda telah menyatakan apa yang mereka inginkan, tetapi Anda tidak sepenuhnya yakin bahwa Anda berada di halaman yang sama.

Saya mulai menghargai ubin gaya, sebagian besar karena kecepatannya. Di mana kami biasa menghabiskan waktu seminggu merancang beranda dan subhalaman di Photoshop, sekarang kami dapat membuat ubin gaya sederhana dalam hitungan jam. Ini dapat menghemat waktu dan uang, dan memberi Anda keyakinan bahwa Anda bergerak ke arah yang benar.

Samantha memiliki beberapa contoh di situs ubin gaya, dan ada beberapa sumber daya hebat yang tercantum di bawah ini yang mencakup penggunaannya dalam proses dunia nyata:

• “Get Your (Visual) Style On”: Yesenia Perez-Cruz, Dan Mall dan presentasi saya di Artifact Conference di Austin, Texas (13 Mei 2013).
• “Keputusan Desain Lebih Cepat dengan Ubin Gaya”: Samantha Warren di An Event Apart di Austin, Texas (Februari 2015).
• Podcast Panduan Gaya dengan Samantha Warren

Karena sifatnya yang statis, kami tidak terlalu sering menggunakannya. Arah desain awal kami biasanya dibuat dengan kolase elemen atau prototipe gaya, keduanya dibahas selanjutnya.

Kolase Elemen

Dan Mall memperkenalkan kami pada elemen kolase sebagai "kumpulan potongan-potongan yang berbeda tanpa logika atau urutan tertentu." Sifatnya yang beraneka ragam memperjelas bahwa apa yang Anda lihat bukanlah desain yang sudah final; alih-alih, kolase elemen memberi klien konteks berbagai komponen yang mungkin hidup dalam sistem bersama. Mereka membantu kita meletakkan beberapa daging di tulang kerangka gambar; mereka membantu kita membayangkan arah yang kita tuju; mereka memungkinkan kita untuk mulai memvisualisasikan blok bangunan situs kita tetapi mendorong kita untuk tidak melupakan keseluruhannya.

Salah satu manfaat kolase elemen adalah Anda dapat memilih komponen mana yang akan ditampilkan. Apakah klien Anda benar-benar peduli tentang bagaimana pencarian disajikan kepada pengguna mereka? Besar! Mungkin Anda harus meluangkan waktu untuk mengatasi masalah itu — masukkan ke dalam elemen kolase. Apakah klien Anda terobsesi dengan tombol ajakan bertindak? Tempatkan mereka di kolase elemen. Mentalitas pilih-dan-pilih ini memudahkan untuk menyesuaikan setiap kolase dengan apa yang paling penting dalam proyek Anda. Klien Anda akan sangat menghargai ini.

Pada proyek baru-baru ini, kami perlu menetapkan arah desain untuk mendesain ulang salah satu properti web klien kami. Katie Kovalcin (salah satu desainer kami) memimpin upaya desain tim kami, dan dia memilih untuk membuat dua kolase elemen daripada membuat kompilasi beranda.

Total waktu yang kami investasikan dalam menciptakan dua konsep desain ini adalah sekitar 16 jam. Ketika saya bertanya kepada Katie berapa lama waktu yang dibutuhkan jika dia diminta untuk membuat dua halaman beranda, dia menjawab:

“Dalam langkah ini, mencoba mencari tahu estetika baru mereka, akan sulit untuk menemukan estetika itu sambil mencoba menyusun hierarki halaman dan mencari tahu interaksinya juga. Jadi, untuk menata seluruh beranda sebagai cara untuk mengetahui estetika terkadang bisa memakan waktu hingga satu minggu, tergantung pada seberapa banyak kami harus bekerja. Saya akan mengatakan mungkin hampir 25–30 jam masing-masing.

Tapi keluar dari kolase elemen, cukup mudah untuk bergerak maju dengan tata letak halaman dan semua hal lainnya karena tidak ada banyak kesulitan untuk mencari tahu gaya tombol apa yang akan kita gunakan, atau font, atau warna. .”

Artinya, dengan menggunakan kolase elemen, kami membagi waktu yang kami habiskan untuk membangun estetika.

Ada satu ungkapan lain yang sangat menarik dalam kutipan Katie di atas; dia berkata "akan sulit untuk menemukan estetika itu ketika mencoba menyusun hierarki halaman dan mencari tahu interaksinya juga." Dengan kata lain, memulai dengan comp beranda mencoba menyelesaikan terlalu banyak, terlalu cepat. Saat kami mengambil langkah yang lebih kecil terlebih dahulu (dengan menggunakan kolase elemen atau ubin gaya), kami dapat membagi dan menaklukkan tantangan desain di depan kami. Ini membawa klien kami ke dalam percakapan lebih sering dan memungkinkan kami untuk belajar sambil berjalan, semuanya menghasilkan pekerjaan yang lebih baik.

Prototipe Gaya

Anda dapat menganggap prototipe gaya sebagai ubin gaya interaktif. Jenis hal yang sama yang mungkin Anda sertakan dalam ubin gaya — tanda merek, tajuk utama, gaya paragraf, gaya tombol, perlakuan tautan, rekomendasi warna — disertakan dengan prototipe gaya. Satu-satunya perbedaan adalah bahwa kami mengambil satu langkah lebih jauh dan mengkodekannya.

Kelebihannya adalah kami dapat menunjukkan tipe web asli, warna asli, status hover nyata, gaya ilustrasi dengan vektor web, dan bagaimana tipe dan tata letak dasar dapat merespons. Kami meminta klien kami untuk meninjaunya di browser pilihan mereka. Ini membuka percakapan tentang apa artinya mendukung browser. Misalnya, jika mereka menggunakan browser yang tidak mendukung border-radius , mereka tidak akan melihat sudut membulat.

Kami juga dapat membuat prototipe gaya dalam waktu sekitar satu hari, yang memberi kami manfaat efisiensi yang sama dengan yang diberikan ubin gaya kepada kami. Klien menyukai mereka karena mereka dapat berinteraksi dengan mereka. Mereka dapat melihatnya di ponsel dan tablet mereka. Mereka bisa mulai bermain dengan mereka.

Akhirnya, di dunia di mana sebagian besar dari kita percaya bahwa desainer web harus belajar kode, prototipe gaya adalah pengantar yang fantastis untuk menulis HTML dan CSS. Karena kesederhanaannya, bahkan seorang desainer non-coding dapat mengetahui cara membuatnya. Sebelum mereka menyadarinya, mereka akan memiliki kepercayaan diri untuk menyempurnakan CSS produksi, alih-alih secara statis mengejek perubahan yang ingin mereka lihat.

Saat kami mendesain situs Sparkbox asli, dan saat kami mendesain ulang baru-baru ini, kami menggunakan prototipe gaya untuk menetapkan arah desain.

Desain Atom

Jeremy Keith pertama kali memperkenalkan saya pada ide untuk memulai desain dengan "atom-atom dari sebuah situs" selama keynote Breaking Development-nya yang berjudul "Tidak Ada Web Seluler." Brad Frost meresmikan istilah tersebut pada Juni 2013 ketika ia menguraikan model mental untuk mendekati desain "sistem komponen" untuk web.

Premis dasarnya adalah bahwa kita harus mempertimbangkan lima tingkat perincian dalam pekerjaan kita untuk membuat sistem komponen yang dapat digunakan kembali. Tingkat terkecil disebut atom; pikirkan input HTML sederhana atau label untuk input. Atom-atom ini dapat digabungkan menjadi molekul; mungkin molekul pencarian terdiri dari tombol, label, dan input. Molekul-molekul ini dapat digabungkan untuk membentuk organisme; mungkin tajuk situs web akan berisi molekul pencarian, merek, dan navigasi. Organisme ini disatukan untuk membentuk template dan halaman. Template penuh dengan data umum; halaman adalah template yang memiliki data nyata yang disuntikkan ke dalamnya. Semua teori ini dapat membantu kami membuat kode yang lebih modular, dapat digunakan kembali, dan dapat diperpanjang.

Satu hal yang saya pelajari saat kami mendekati proyek kami di sepanjang garis pemikiran ini adalah bahwa desain atom jauh lebih mudah ketika Anda membiarkannya berkembang dari refactoring. Cara umum bagi kami untuk bekerja adalah membangun komponen kecil dalam HTML dan CSS tanpa banyak khawatir tentang atom, molekul, atau organisme. Kemudian, setelah kita menyelesaikan masalah UX dan UI dengan sebuah antarmuka, kita dapat memfaktorkan ulang kode itu menjadi struktur atom. Pendekatan terbalik ini berarti kita tidak membuang-buang waktu untuk mencoba berpikir berlebihan tentang apa yang seharusnya menjadi molekul versus organisme. Sebagai gantinya, kami membiarkan berbagai level berkembang seiring dengan berkembangnya sistem itu sendiri.

Hasil dari pendekatan atom adalah perpustakaan pola yang dapat diintegrasikan ke dalam suatu sistem.

Perpustakaan Pola

Pustaka pola adalah seperti apa kedengarannya — pustaka pola yang ada di sistem Anda. Ada banyak orang yang mengerjakan solusi perpustakaan pola akhir-akhir ini; orang-orang seperti Brad Frost, Anna Debenham, Jina Bolton, dan Bermon Painter telah berbicara dan menulis tentang topik tersebut. Faktanya, Brad dan Dave Olson telah menciptakan salah satu alat yang lebih terkenal yang tersedia saat ini, Lab Pola. Pattern Lab sangat bagus karena memungkinkan Anda untuk memisahkan konten tertentu dari modul HTML, dan menyediakan kerangka atom yang memudahkan untuk membangun sistem pola. Mereka juga menambahkan beberapa fitur hebat untuk pengujian saat Anda dalam pengembangan. Semuanya sangat mudah dijalankan secara lokal dan memiliki antarmuka sederhana yang dapat dengan mudah ditampilkan ke klien. Jika Anda ingin masuk ke desain berbasis pola, ini adalah tempat yang fantastis untuk memulai.

Banyak yang terjadi di ruang ini sekarang, dan ada banyak sumber daya lain bagi kita yang tertarik untuk belajar lebih banyak. Brad telah bekerja dengan Anna Debenham dan Brendan Falkowski (bersama dengan beberapa orang lainnya) untuk membuat Sumber Daya Panduan Gaya Situs Web. Ini adalah kumpulan luar biasa dari banyak contoh, artikel, ceramah, podcast, dan lainnya yang mencakup desain dan pengembangan yang digerakkan oleh pola.

Sejauh ini, tantangan terbesar adalah menemukan cara untuk menjaga perpustakaan pola tetap up to date setelah pola diintegrasikan dengan sistem back-end. Saya belum melihat solusi sempurna untuk ini, tetapi ada banyak orang cerdas yang mengerjakannya. Lihat Rizzo oleh Lonely Planet sebagai contoh yang bagus dari sebuah organisasi yang dengan tekun bekerja untuk memecahkan masalah ini. Bahkan jika kita tidak memiliki solusi jangka panjang yang sempurna, saya telah melihat manfaat luar biasa dari mendesain dengan cara ini. Itu membuat Anda berpikir secara modular, dan ini membuat pekerjaan front-end yang kami lakukan lebih mudah untuk diintegrasikan dan dipelihara.

Bagaimana dengan Breakpoint?

Setiap kali saya berbicara atau menulis tentang proses, saya selalu ditanya tentang memilih breakpoints. Anehnya, percakapan ini hampir tidak pernah muncul dalam pekerjaan responsif kami dari hari ke hari. Tentu saja, beberapa klien datang kepada kami setelah melakukan banyak pekerjaan meninjau analitik dan memprioritaskan perangkat — semuanya atas nama mendokumentasikan breakpoint sistem. Garis pemikiran ini tidak pernah masuk akal bagi saya.

Saya yakin Stephen Hay yang pertama kali mengatakannya: "Mulailah dari yang kecil dan tambahkan titik henti sementara saat situs rusak." Situs kami sering kali memiliki lusinan titik henti sementara — sebagian besar tidak sesuai dengan ukuran perangkat yang umum. Ketika Anda melihat bahwa konten dan desain Anda tidak lagi bekerja secara harmonis, perbaiki.

Sekarang, ada perbedaan antara apa yang disebut Stephanie Rieger sebagai breakpoint mayor dan breakpoint minor. (Saya juga pernah mendengarnya disebut breakpoints dan tweakpoints.) Mari saya jelaskan masing-masing.

Breakpoint Utama

Ketika ada pergeseran dalam tata letak yang memerlukan modul terpisah untuk bekerja sama dalam perubahan desainnya, kami menggunakan titik henti umum (breakpoint utama). Mungkin Anda memiliki penyesuaian tata letak yang memindahkan daftar produk bertumpuk pada lebar viewport kecil ke tata letak dua kolom dengan lebar viewport lebih besar. Dalam hal ini, Anda akan ingin melacak di mana pergeseran tata letak ini terjadi karena kemungkinan ada banyak perubahan lain yang perlu terjadi pada lebar viewport yang sama.

Sebagian besar pekerjaan yang kami lakukan memiliki antara tiga dan enam breakpoint utama. Ini sering ditetapkan sebagai variabel Sass dalam alur kerja kami sehingga kami dapat membuat perubahannya nanti di satu tempat. Itu juga umum bagi kita untuk memiliki satu set breakpoint utama untuk bagian utama dari sebuah situs. Misalnya, kami mungkin memiliki tiga breakpoint utama di header situs kami dan tiga breakpoint utama yang sama sekali berbeda di footer. Ini membuat pekerjaan kami tetap modular dan memungkinkan bagian-bagian ini berkembang secara independen sambil tetap mempertahankan kohesi dengan sistem secara keseluruhan.

Breakpoint Kecil

Saat diperlukan perubahan yang lebih halus pada jenis atau spasi, kita masih dapat menggunakan kueri media untuk membuat penyesuaian ini (titik putus sementara). Ini biasanya merupakan modifikasi gaya satu kali untuk hal-hal seperti ukuran font (untuk menjaga panjang garis tetap terkendali) atau untuk menambah jarak saat lebar area pandang meningkat. Penyesuaian kecil ini menunjukkan perhatian mendalam terhadap detail yang benar-benar dapat membedakan pekerjaan Anda.

Alih-alih menggunakan variabel praprosesor untuk ini, kami biasanya hanya menggunakan nomor hardcoded. Kami, kadang-kadang, juga menggunakan perhitungan praprosesor untuk menjaga ini relatif terhadap breakpoint utama. Misalnya, jika kita memiliki breakpoint utama pada 30em yang disebut $bp_header-show-nav , saya mungkin ingin menyesuaikan ukuran font heading pada 5em di atas $bp_header-show-nav . Dalam hal ini, itu akan terjadi pada 35em. Jika kita menggeser breakpoint utama itu ke 32em di beberapa titik di masa mendatang, perubahan kecil akan terjadi di 37em. Berpikir relatif dengan breakpoint kecil dapat membantu jika Anda menduga bahwa breakpoint utama mungkin berubah. Anda harus menggunakan penilaian Anda berdasarkan kasus per kasus untuk membuat keputusan terbaik.

Bacaan lebih lanjut

Untuk mengetahui lebih lanjut tentang breakpoint, lihat artikel ini:

• “Tidak Ada Titik Putus”
• "Di Antara" oleh Mark Boulton
• “Desain Responsif Pragmatis” oleh Stephanie Rieger

Transisi Keluar

Saat ini, membangun situs hebat saja tidak cukup. Kita juga harus mempertimbangkan umur panjang dari apa yang kita bangun. Sementara pendekatan seperti desain atom dapat membantu, kita perlu berbuat lebih banyak. Saat ini, sebagian besar proyek kami menyertakan beberapa jenis komponen pelatihan — dan saya tidak berbicara tentang mengajar klien untuk menggunakan CMS. Ketika organisasi mulai benar-benar memahami nilai yang ditawarkan web kepada mereka, mereka memutuskan untuk membangun tim mereka sendiri untuk memiliki dan memelihara properti web mereka. Jika kita ingin membangun sesuatu yang tahan lama, kita perlu memastikan tim yang mengerjakan pekerjaan kita mampu mempertahankannya dengan baik. Untuk alasan ini, kami melakukan lebih banyak pelatihan mendalam seputar teknik yang kami gunakan untuk membangun untuk web.

Untungnya, sekarang ada banyak cara umum untuk mendekati transisi. Setiap repo yang kami buat di kontrol sumber memiliki file readme yang berguna; kami memberikan pengujian otomatis yang mendukung kode kami; dan kami sedang mengerjakan beberapa cara untuk mentransisikan anggaran kinerja proyek sehingga klien kami terus mempertahankan kecepatan situs mereka. Seiring dengan pemikiran atom, kami juga memberikan contoh kerja subsistem yang kami bangun. Misalnya, kami biasa mempertimbangkan cara kerja tipografi di semua properti web dalam konteks merek pelanggan, jadi kami mungkin juga memberikan dokumentasi mendetail tentang sistem tipografi ini, serta halaman contoh yang menunjukkan cara menggunakannya. Penambahan jenis ini pada pekerjaan kami membuat waktu menjadi lebih mudah saat kami meneruskan kode dari tim kami ke tim klien kami.

Ada juga dampak yang lebih dalam dari semua ini. Memahami siapa yang akan memelihara sistem yang Anda bangun juga harus memengaruhi keputusan yang Anda buat seputar pilihan teknologi dan teknik pengembangan. Dengan kata lain, jika tim web klien Anda tidak siap untuk menggunakan Grunt dengan Assemble dan server lokal dari baris perintah, Anda perlu menemukan cara kerja yang lebih sesuai dengan kemampuan mereka. Ingat, Anda sedang membangun ini untuk mereka.

Juga sangat bermanfaat untuk mengundang tim desain dan pengembangan web klien kami untuk berpartisipasi bersama kami dalam proyek tersebut. Menggunakan proyek sebagai kesempatan untuk melatih tim klien Anda menunjukkan nilai yang luar biasa dan menjadikan Anda pilihan yang mudah di antara pesaing Anda.

Orang Di Atas Proses

Satu hal terakhir yang saya pelajari dalam terus mengembangkan alur kerja kami adalah bahwa proses yang Anda pilih untuk digunakan jauh lebih penting daripada orang yang menggunakannya. Jika Anda ingin membangun produk web yang lebih baik, mulailah dengan mengembangkan orang-orang Anda. Ini akan membawa Anda lebih jauh daripada tweak apa pun untuk proses atau alur kerja Anda.

Menjaga Tim Anda Bahagia

Sepanjang baris yang sama, saya akan merekomendasikan membaca Flow oleh Mihaly Csikszentmihalyi. Dalam buku ini, dia menjelaskan penelitian yang telah dia lakukan untuk lebih memahami kebahagiaan individu. Dia menjelaskan apa yang dia sebut "saluran aliran", memetakan tingkat keterampilan di sepanjang sumbu x terhadap tingkat tantangan di sepanjang sumbu y . Saluran aliran adalah area di mana keterampilan Anda bertemu dengan tantangan yang memadai. Terlalu banyak tantangan untuk keterampilan Anda menciptakan kecemasan dan terlalu sedikit tantangan untuk keterampilan Anda menghasilkan kebosanan.

Ini dapat diterjemahkan menjadi apa yang kita lakukan dengan mempertimbangkan di mana kita menantang diri kita sendiri dalam pekerjaan kita sehari-hari. Di Sparkbox, kami berbicara tentang budaya belajar. Itu (semoga) berarti keterampilan tim saya terus meningkat. Oleh karena itu, untuk menjadi bahagia kita perlu menemukan tantangan yang terus meningkat untuk mencocokkan keterampilan kita yang terus meningkat. Merupakan tanggung jawab kami untuk menyeimbangkan kebutuhan akan inovasi ini dengan tanggung jawab keuangan dalam anggaran yang dimiliki klien kami.

Ini rumit. Bagi kami, itu berarti kami harus berhenti menciptakan kembali roda; itu membuat kami mempertimbangkan pustaka elemen antarmuka yang teruji dengan baik sebagai lawan dari berulang kali memecahkan masalah yang sama pada setiap proyek. Artinya kita perlu memahami di mana setiap pelanggan kita harus mengeluarkan uang untuk berinovasi. Dan itu membutuhkan sedikit transparansi antara klien tersebut dan tim kami sehingga kami semua berada di halaman yang sama.

Pada akhirnya, ini menghasilkan lebih banyak tim konten — tim yang menyukai pekerjaan yang mereka lakukan karena menantang mereka dengan cara yang benar. Dan itu membuat lebih banyak klien konten — klien yang menghormati rekomendasi Anda tentang di mana dan mengapa mereka harus berinvestasi. Ini sangat baik untuk semua orang yang terlibat.

Maju

Ini adalah bagian di mana saya sangat menginspirasi Anda dan mendorong Anda untuk berani menghadapi dunia baru desain web. Tapi, sejujurnya, saya telah berjuang untuk meringkas sentimen penutup untuk bab ini.

Setelah beberapa perenungan, saya yakin ini karena proses menulis tidak pernah benar-benar selesai.

Saya harap saat Anda membaca kata-kata ini, Anda menemukan diri Anda lebih terinspirasi untuk berinvestasi dalam pemahaman Anda sendiri tentang cara kerja web, dan lebih bersedia untuk berinvestasi dalam pemahaman rekan tim Anda. Saya harap Anda merasa bersemangat untuk mencoba pendekatan baru, tetapi saya juga berharap Anda merasa diberdayakan untuk merobek halaman-halaman ini jika tidak berhasil untuk Anda. Hanya Anda, tim, dan pelanggan Anda yang dapat menemukan cara terbaik untuk mendekati suatu proyek. Ini adalah sifat dari apa yang kita lakukan.

Waktunya sekarang — jadi, lakukanlah!