Verimli Duyarlı Tasarım Süreci

Duyarlı tasarım süreciniz nasıl? Verimli olduğunu düşünüyor musunuz? Aşağıdaki makale, Ben Callahan'ın ilk olarak Smashing Book 5'in (içindekiler) e-Kitap versiyonunda yayınlanan “Responsive Process” bölümünden bir alıntıdır. —Ed.

"Bu RFP'ye başarılı bir şekilde yanıt veren kişi, ekibimizin değerlendirmesi için üç statik tasarım seçeneği sunacaktır." Çok seçenekli bir tasarım yaklaşımı benimsemenin hiçbir zaman büyük bir hayranı olmadım, ama anlıyorum - bazen bir müşterinin buna ihtiyacı var.

"Bu seçeneklerin her biri üç benzersiz düzen için tasarım sağlayacaktır: ana sayfa, listeleme sayfası, detay sayfası." Tamam. Şimdi, dokuz adede kadar statik tasarım dosyasıyız. Bu biraz kontrolden çıkıyor.

"Bu benzersiz sayfa tasarımlarının her biri mobil, tablet ve masaüstü boyutlarını hesaba katmalıdır." Matematikte hiçbir zaman harika olmadım ama bu hesabı yapabilirim. Yirmi yedi statik tasarım dosyası mı?! Olmayacak.

Bu, çok uzun zaman önce aldığım gerçek bir teklif talebi. Müşterinin daha verimli bir yaklaşıma çok uygun olduğu ortaya çıktı. Ama bu deneyim beni gerçekten düşündürdü… Bu işi yapmanın en zor yanı aslında bu işi yapmak değil. Bu işleri yaparken insanlarla çalışmaktır.

Görüyorsunuz, neredeyse her potansiyel müşterinin zaten bir web sitesi var. Bizim için bu, çoğu müşterinin buna geçmiş web projelerinden kendi bagajlarıyla birlikte bir dizi beklentiyle geldiği anlamına geliyor. Bu bagaj, müşterinizin projeye nasıl yaklaştığı ve sizin üzerinde büyük bir etkiye sahip olabilir. Bu beklentilerin olumsuz etkilerini azaltmaya yardımcı olmak için, onları yönetmenin en iyi yolunun onları belirleyen kişi olmak olduğunu buldum.

Bu bölümdeki amacım , en baştan başlayarak web projelerinizde daha başarılı olmanıza yardımcı olmak; Müşterinizin olacaklarla ilgili beklentilerini belirlemeye yardımcı olmak için ilk günden itibaren çalışarak ve aynısını yapmak için bir projenin yaşam döngüsü boyunca çalışarak.

Duyarlı Web Tasarımı Sürecindeki Temel Farklılıklar

Favori metin düzenleyicinizi açmadan önce, Macaw'ı açmadan önce, eskiz defterinizi çıkarmadan veya metinle şekillendirmeye başlamadan önce, müşterinizin süreci anlamasına yardımcı olmanız gerekir. Bunu yapmanın birçok yolu var ve benim en az sevdiğim şey onları yeni bir süreçte satmaya çalışmak. Tecrübelerime göre, erkenden - hatta bir sözleşme imzalanmadan önce - düşünce tarzınıza değer vermek en iyi yaklaşımdır. Bu, müşterinize neden bahsettiğinizi bildiğinize dair güven verir, ancak aynı zamanda yeni bir yol denemek için güvenlerini kazanmanız gerektiği anlamına gelir.

Bunu teşvik etmek için, birbirimizle etkileşime girerken benim ve ekibimin aklında tutmaya çalıştığım dört ideal var: işbirliği yap, yinele, uyarla ve öncelik ver. Bu spesifik fikirlerin sizi neden doğru yolda tutacağını kısaca açıklayayım.

işbirliği yap

Biliyorum biliyorum. Herkes her yerde işbirliğinden ve harika işler yapmak için nasıl gerekli olduğundan bahsediyor. Biliyor musun? Bu doğru. Elbette, ekibiniz içinde işbirliği yapmanız gerekiyor, ancak bu günlerde ihtiyaç duyulan başka bir tür işbirliği daha var - müşterinizle işbirliği yapmak . Size önemli bir hatırlatmam var: Müşteriler de insandır. Web tasarımı ve geliştirme konusunda sizin uzmanlığınıza sahip olmayabilirler, ancak işleri hakkında sizden çok daha fazlasını biliyorlar.

Yine en baştan başlar. Sparkbox'ta, yeni müşterileri aramıza katmak için daha işbirlikçi olmanın bir yolunu arıyordum. Bunun bir parçası olarak, tahmin yazmak için yeni bir yaklaşım izliyoruz. Bir haftalığına ortadan kaybolmamız ve Mükemmel Çözüm ile geri dönebilmemiz için bize gelip projesini anlatan bir müşteri yerine, onları tahminde bize yardımcı olmaya davet ediyoruz. Çok kolay — biz buna işbirlikçi tahmin diyoruz ve müşteriler buna bayılıyor.

Birkaç ayarlanabilir alana sahip temel bir Google e-tablosu ile başlıyoruz ve işi yapmanın maliyetinin ne olacağını hesaplıyoruz. Geniş aralıklarla başlıyoruz çünkü bunu sürecin çok başlarında yapıyoruz - genellikle sadece 30 dakikalık bir telefon görüşmesinden sonra. Daha sonra müşteri ile paylaşıyoruz ve üzerinde birlikte çalışıyoruz.

İşte bu neden önemli: Müşterilerimizle yaptığımız ilk şey üzerinde işbirliği yapıyoruz. Onlar için değil, onlarla çalıştığımızda daha fazla değer kattığımızı bilmelerini istiyoruz. Bu, paramızı ağzımızın olduğu yere koymamızın sadece bir yolu.

Müşterilerimizi de bizimle ekip iletişim kanallarımıza davet ediyoruz. Slack ve Basecamp'ın büyük hayranlarıyız. Bu araçlar, her ikisi de kaliteli işbirliğini kolaylaştırmak için gerekli olan resmi dokümantasyon ve gayri resmi konuşmanın harika bir karışımını sağlar.

Daniel Mall'un Reading Is Fundamental web sitesinin açık yeniden tasarımında, Dan'in müşterilerini onunla birlikte projeye nasıl dahil ettiğine dair hepimiz bir fikir edindik. Brad Frost, projenizin ilerlemesini takip etmek için bir araç olan “Project Hub” adlı GitHub projesiyle bunu bir adım daha ileri götürdü.

Unutmayın, bunların hepsi sadece araçlar. Araçlar yardımcı olabilir, ancak gerçekten ihtiyaç duyulan şey, nasıl düşündüğümüzde bir değişiklik. Arkadaşım Kevin Sharon bir keresinde bana çok dokunaklı bir şey söyledi. 'Hayır' diyemiyorsan, bu işbirliği değildir" dedi. Sizi bilmem ama benim geri itme yetkisine sahip olmadığım müşterilerle pek çok ilişkim oldu - istediklerinin işe yaramayacağını deneyimlerimden bilsem bile. Bu müşteriler, çözülmesi gereken sorunlardan ziyade çözümlerle size gelirler.

Kabul etmekten utanıyorum ama bunun tam tersi olan müşteri ilişkilerim de oldu. Bazen hayal kırıklığım beni alt ediyor ve müvekkilimin projenin bir parçası olmasına ihtiyacım olduğunu unutuyorum. Müşterilerimizden bir fikir duyduğumuzda ve hemen aynı fikirde olmadığımızda, ortak bir süreci reddetmekte onlar kadar suçluyuz. Çoğu web stüdyosu, müşterilerinin anlamlı bir şekilde katkıda bulunacak kadar yaratıcı veya teknik olduğuna inanmadıkları için süreçlerinde bu tür bir işbirliğine izin vermeye istekli değildir.

İşbirliği iki yönlü bir yoldur. Müşterilerinize bakış açınızı, işinize gerçek katkıda bulunanlar olmalarına doğru kaydırmak, onları dahil etmenin her türlü yeni yolunun ortaya çıkmasına ve daha iyi bir ürün yaratmanıza yardımcı olacaktır.

yinele

Küçük, yüksek kaliteli bir işlevsellik alt kümesini muazzam bir hızla sunmak için düzenli olarak fırsatlar ararız. Böyle bir yaklaşımı benimsemek, ilerlemeyi erkenden gösterir ve öğrendiklerinizin sizi bir projeye taşıması için ivme yaratmasına izin vermek için gerçek fırsatlar sunar.

Müvekkilinizin çalışma şeklini değiştirmede politik zorluklar olabileceğini düşünüyorsanız, işte size bir profesyonel ipucu (ve bunu yaptığımız her projede hissediyorum): tekrar tekrar çalışmak, şüphecileri savunuculara dönüştürmeye yardımcı olabilir. Çoğu insan, tüm bir projeden çok küçük bir aşamada yeni bir çalışma yöntemi denemenize izin verir. Yine burada en önemli nokta, müşterinizin güvenini kazanmak için değerinizi erken göstermektir.

Yinelemenin kendini göstermesinin bir yolu prototiplemedir. Sürekli olarak önemli bir zorluğu belirlemek, olası bir çözüm önermek, prototipleme, gözden geçirme ve tekrarlama yoluyla geçerliliğini kanıtlamak veya çürütmek için fırsatlar arıyoruz.

Genellikle büyük bir projeye başlamadan önce ücretli bir keşif aşamasıyla başlama şansı ararız; evlenmeden önce flört olarak düşün. Bu size proje ve bu müşteriyle çalışmanın nasıl bir şey olduğu hakkında daha fazla bilgi edinme fırsatı verir. Her iki taraf da çalışma ilişkisinin uygun olup olmadığını belirleyebilir.

İlk angajmanlar birçok şekilde olabilir, ancak birincil hedefler şunlardır:

1. Projenin kapsamını daha iyi anlayın
2. En büyük zorluklara olası çözümleri belirleyin ve kanıtlayın
3. Müşteri/satıcı uyumunun doğru olup olmadığını anlayın
4. yetenekli olduğunu kanıtla
5. Yukarıdakiler için ödeme alın

Müşterileriniz bu yaklaşımı takdir edecek ve gelecekteki çalışmalar için harika bir temel oluşturacaksınız. Ve proje hakkındaki anlayışınızı önemli ölçüde değiştiren bir şey öğrenirseniz, yalnızca küçük bir aşamaya bağlı kalacaksınız. Bu öğrenme, süreçteki bir sonraki adımı büyük ölçüde bilgilendirecek ve sizi daha iyi bir çözüme doğru itecektir.

Uzun yıllardır birlikte çalıştığımız bir müşterimiz var; Aslında, onlarla otuzuncu projemize kısa süre önce başladık. Bana göre bu, birlikte çalışmak için karşılıklı olarak yararlı bir yol bulduğumuzun bir işareti - sunduğumuz şeyin değerini görüyorlar ve onlarla yaptığımız çalışmalardan yaratıcı ve teknik olarak memnunuz. Bu ilişkiyi neyin başarılı kıldığını belirlemeye çalışırken, yinelemeli yaklaşımımıza geri dönüyorum. Birçok kez bize bir sorunla ve onu nasıl çözeceğimize dair bir fikirle geldiler. 12 haftalık bir projeyi sadece ısırmak yerine, olası çözümleri test eden ve çok daha düşük bir başlangıç ​​yatırımına sahip olan daha küçük, yinelemeli aşamaları düzenli olarak önerdik. Bu yaklaşımı benimsemek onların güvenini kazanmamızı sağladı. Bu güven, sürdürülebilir bir ilişki yaratmada vazgeçilmezdir ve her şeyin merkezinde yineleme vardır.

Adapte olmak

Duyarlı web tasarımı sahneye çıktığında, inşa ettiğimiz ürünün doğasında bulunan esnekliğin sürecimize dahil olduğu fikrinden etkilendiğimi hatırlıyorum. Samantha Warren en iyisini söyledi: "Sürecin, tasarladığın ürünler kadar duyarlı olmalı."

Gerçek şu ki, bu tür işler için mükemmel bir süreç yoktur. Sen ve ben bize sunulan kısıtlamaları benimsememiz gerekiyor. Her proje, müşteri, kapsam, zaman çizelgesi, bütçe, ekip, teknoloji yığını, destek matrisi farklıdır. Bu işte başarılı olan kuruluşlar, bir projenin kısıtlamaları içinde çalışabilen ve yine de zamansız işler yapabilen kuruluşlardır.

Süreç hakkındaki görüşlerimi bir müşteriye açıklamak kesinlikle zor. Fırsat verildiğinde, muhtemelen projeyle ilgili birkaç kilit kişiyi (müşteri dahil) birkaç hafta boyunca bir odaya kilitler ve onlara bunu çözmeleri için yetki verirdim. Benden al, müşteriler haftalarca bir odaya kilitlenmekten hoşlanmazlar.

Bunun yerine, çok katı bir süreç (her adımın düzenlendiği ve belgelendiği) ile doğaçlama bir süreç (ekibe giderken en iyi yaklaşımı bulacağına güvendiğimiz) arasında bir denge bulmalıyız. Bu dengeyi bulmak için dikkate alınması gereken birçok faktör vardır. Başlangıç ​​için burada üç tane var: takımın büyüklüğü; ekibin deneyimi; ve projenin kritikliği.

Takımın Büyüklüğü

Çok küçük bir ekibiniz olduğunda, süreçte büyük esnekliğe izin vermek çok daha kolaydır. Aynı odada oturan iki veya üç kişi, çok fazla yapı olmadan neler olup bittiğini takip edebilecek. Takım büyüklüğünü altı veya yediye çıkardığınızda, her bir oyuncunun tüm projenin ilerleyişi üzerindeki etkisini anlamak zorlaşmaya başlar. Ekibinizi on, on beş veya daha fazlasına yükseltin ve neredeyse imkansız hale geliyor.

Bu benim için çok kişisel. Sparkbox'ı ortaklarımla ilk kurduğumda sadece dört kişiydik. Her birimizin oldukça iyi tanımlanmış bir rolü vardı ve fazla süreç olmadan oldukça etkili bir şekilde çalışabildik. Hep birlikte büyük bir odada oturduğumuz için işimizin tüm yönleriyle ilgili sürekli bir iletişim vardı.

Şimdi 23 tam zamanlı çalışanımız ve üç çırağımız var. Kesinlikle bazı yerler kadar hızlı büyümedik - büyümemiz konusunda çok bilinçliyiz - ancak “büyüme sancıları” ifadesi hala kulağa doğru geliyor. Ne zaman, ne ve nasıl iletişim kuracağımızı sürekli olarak denemek zorunda kaldık. Bizim için doğru olan dengeyi ancak bu deney yoluyla bulabiliriz.

Buradaki ders, ekibinizin boyutunun belirli bir proje için uygulayabileceğiniz süreç türünü etkilemesidir. Genel olarak, bir projede ne kadar çok insan varsa, o kadar fazla katılığa ihtiyacınız olacaktır. Takım boyutunuz azaldıkça, daha az resmi bir süreçle kurtulabilirsiniz. Ekibin nabzını izlemek ve işlerin sorunsuz ilerlemesini sağlamak için süreci ayarlamak proje yöneticinizin sorumluluğundadır.

Ekibin Deneyimi

Deneyimsiz bir ekiple çalışırken daha titiz bir süreç herkesin aynı fikirde olmasına yardımcı olacaktır. Aslında, deneyimsiz bir ekibin deneyim kazanmak için bağlam olarak somut bir sürece ihtiyacı olduğuna inanıyorum. Ancak daha katı bir ortamda başarıyı gösterdikten sonra, bir ekibin nasıl çalıştığı konusunda daha fazla özgürlük sağlayan süreç katmanlarını soymaya başlayabilirsiniz.

Bu yine benim için oldukça kişisel bir kavram, çoğunlukla bir proje için ekipleri nasıl organize ettiğimizden dolayı. Aldığımız her proje için benzersiz bir ekip oluşturuyoruz; bir proje sırasında bile, insanları ekibin içine ve dışına döndürmemiz mümkün. Bu, özellikle bu bireylerin deneyimi çok farklıysa, zorluklar yaratabilir. Çoğunlukla, farklı insanların başarılı olmak için farklı süreç seviyelerine ihtiyaç duyduğu gerçeğinin bilincinde olmamız gerektiği anlamına gelir. Proje yöneticilerimiz bunu yakından takip eder ve gerektiğinde ayarlar.

Çok sayıda deneyimli tasarımcı ve geliştiricimiz var, bu nedenle bu denge çoğunlukla daha az deneyimli insanları yaymakla ilgili. Çok yetenekli bir ekibe bir veya iki yeni geliştirici eklemek, herkes için çıtayı yükseltecektir. Yeni geliştiriciler daha deneyimlilerden öğrenecek ve daha deneyimli olanlar yeni geliştiricilere öğreterek öğrenecekler. Bu bir kazan-kazan için yapar!

Projenin Kritikliği

Projenin ne kadar kritik olduğu fikri, Çevik Manifesto'nun orijinal imzacılarından Alistair Cockburn adlı bir beyefendiden geliyor. “Crystal Methods” üzerine yazılarında Cockburn, bu ifadeyi tamamlayarak kritikliğin kapsamını açıklar.

Kusurlar aşağıdakilerin kaybına neden olur:

1. Konfor (kritik değil)
2. İsteğe bağlı para (biraz kritik)
3. Temel para (kritik)
4. Hayat (çok kritik)

Ürünümüz ne kadar kritikse, sürecimiz de o kadar katı olmalıdır. Hem küçük hem de büyük işletmeler için çalıştıysanız, bunu deneyimlemiş olabilirsiniz. Küçük, yerel şirketler, daha az tehlikede oldukları için (daha düşük kritiklik); Eğer süreciniz iyi sonuçlar vermiyorsa, büyük şirketlerin kaybedecek daha çok şeyi vardır (daha yüksek kritiklik).

Bu sektöre yeni başladığımda, neredeyse yalnızca küçük, yerel işletmelerle çalıştım. Projeleri iki haftada bir yapışkan notlar, e-posta ve telefon görüşmesi ile yönettim. Şimdi, çok daha büyük organizasyonlarla ilgileniyorum. Bu projeleri yönetmek, günlük stand-up'lara, retrospektiflere ve sprint planlama toplantılarına katılmamızı gerektirir. Kendimizi yanıklar oluştururken, JIRA'da (sorun izleme yazılımı) çalışırken ve kabul ettiğimden daha fazla hızımızı hesaplarken buluyoruz. Bütün bunlar işin kritikliği nedeniyledir - yeterince büyük bir sayının küçük bir yüzdesi hala çok büyük bir sayıdır. Bu daha büyük şirketler bunu anlıyor ve onları bu korkunç kayıplardan korumak için bir süreçleri var.

Öncelik ver

Tasarladığımız ekranların boyutu küçüldükçe iletişim önceliği seçeneklerimiz de küçülüyor. Bir düşünün: Kullanıcıların nereye odaklanmaları gerektiğini anlamalarına yardımcı olmak için genellikle boyut, konum, düzen ve kontrast gibi şeyleri kullanırız. Küçük bir ekranda, bir nesnenin boyutuyla veya bir başlığın konumuyla ancak bu kadar yapabilirsiniz. Odak noktamız daha büyük ekran deneyimlerindeyken sahip olduğumuz özgürlüklerin aynısına sahip değiliz.

Bu nedenle, bir sistem genelinde içeriğin ve işlevselliğin önceliğini anlamak çok önemlidir. Luke Wroblewski, müşterilerimizin gerçekten neyin önemli olduğunu anlamalarına yardımcı olmak için önce mobil cihazlar hakkında düşünmemizi zekice teşvik etti. Gerçek şu ki, sağlam bir öncelik anlayışı olmadan, duyarlı web tasarımı sadece tahminden ibarettir.

Sürecin çok başlarında lineer düşünmelerini sağlayarak müşterilerimizde bunu teşvik ettik. (Aşağıdaki “Bunu Tamamlamak” bölümünde, bunu yapmak için kullandığımız araç türlerini paylaşacağım.) Doğrusal düşünmenin, insanların en önemli olanı seçmesini gerektirme avantajı vardır ve bu, üzerinde anlaşmanız gereken önceliktir. Bunu projenize hemen yerleştirmek, üzerine inşa edilecek kabul edilen bir temel oluşturacak ve projede daha sonra kendinize soracağınız birçok soruya yanıt sağlayacaktır.

Yakın zamanda, müşterimizin bize geniş ekran tel kafesleri bir araya getirilmiş olarak geldiği bir projemiz vardı. Bunu biraz para biriktirmek için yapmışlardı ve biz de onlarla bu şekilde çalışmaktan mutluyduk. Tasarıma başladığımızda müşteri işimizden memnun değildi. Geniş ekran tel çerçevelerin içerik ve işlevselliğin önceliğini yeterince belirlemediğini projenin yarısına kadar fark ettik. Bu, yaşadığımız sorunların en önemli noktasıydı. Projeye ivme kazandırmak için bazı içerik analizi ve önceliklendirme yapmak için geri döndük. Bunu daha önce yapmış olsaydık, proje boyunca daha verimli çalışabilirdik. Ne yazık ki, paradan tasarruf etmelerine yardımcı olmak için, önce doğru temeli atmış olsaydık kaçınılabilecek bazı yeniden çalışmalar yapmak zorunda kaldık! Alınan ders — önceliği erkenden belirleyin.

Dört İdeal

Bir sonraki projenize atlarken, müşterinizi projeye dahil etmeniz gerektiğini unutmayın. Onlar için çalışmak yerine onlarla işbirliği yapma fırsatlarını araştırın. Değeri ne kadar erken gösterirseniz, o kadar çok güven kazanacağınızı unutmayın. Yineleme bunu yapmanıza yardımcı olur - küçük başlamaktan korkmayın! Ayrıca, belirli bir proje veya müşterinin ihtiyaç duyabileceği şeye daha iyi uyması için çalışma şeklinizi kesinlikle uyarlamanız gerekeceğini unutmayın. Son olarak, projenin başlarında bir içerik ve işlevsellik önceliği oluşturmak için çok zorlayın. Bu, projede daha sonra belirli içerik türlerinin önemi hakkında sorular ortaya çıktığında temettü ödeyecek.

Bu dört idealin ötesinde, günlük hayatınızda ne tür bir sürecin işe yarayacağını düşünürken size biraz çerçeve sağlamak istiyorum.

Süreci Düşünmek İçin Bir Çerçeve

Sürecimiz Daima Yaşamı İçin Savaşıyor

Çoğu sunum veya süreç üzerine yazı yazma konusunda beni şaşırtan şeylerden biri, insanların paylaşımının ne kadar kendinden emin göründüğü. Belki aykırı olan biziz, ancak sürecimiz her zaman hayatı için savaşıyor. Yeni bir çalışma şekli gelirse, deneyeceğiz. Bir şeyi yapmanın daha iyi bir yolunun ipucu olduğunu düşünürsek, onu ortaya çıkarmak için etrafa bakınırız. Bu sadece bu şekilde kabloluyuz. Birçoğunuzun da bu şekilde kablolanmış olduğunu hissediyorum.

Sürecimizin asla tamamlanmadığı konusunda hemfikir olalım.

Doğrusal Aktarımlardan Uzaklaşın

Sektördeki çoğu kişi, teslimatları duvardan aşağı atmayı bırakmamız gerektiği konusunda hemfikir. Bunun yerine birçok kişi, proje süresince doğru kişilerin dahil edilmesinin ekip arkadaşı empatisini artıracağı ve herkes için çıtayı yükselteceği umuduyla ekiplerini nasıl yeniden organize edeceklerini düşünüyor. Trent Walton, “Reorganization” adlı yazısında bunu etkili bir şekilde anlatıyor. İçinde, ekibinizin yapısının genellikle kullanabileceğiniz süreç türünü kısıtladığını ve bizi daha küçük disiplinler arası ekipleri düşünmeye teşvik ettiğini anlatıyor. Bunun doğru olduğunu gördük ve çok benzer bir yaklaşım izledik. Doğrusu, geçmişteki doğrusal süreçlerimiz muhtemelen her zaman biraz verimsiz olmuştur. Duyarlı web tasarımının bu verimsizliği çok daha belirgin hale getirdiğine inanıyorum; Duyarlı çalışmayla uğraşmak, beni müşterilerimizle kurumsal yapıları hakkında konuşmaya yönlendirdi - RWD'nin gerçekten kurumsal değişim için bir katalizör olduğuna dair daha fazla kanıt.

Daha fazla proje için daha fazla disiplini dahil etmemiz gerekiyor. Bunu, gözlerimiz sıkıca nihai ürüne, tek bir teslimata odaklanmış bir projede sarmal olarak düşünmek hoşuma gidiyor. Her sarmalda, tüm disiplinleri dahil ediyoruz ve tüm karar noktalarında daha fazla netlik kazanıyoruz. Konsept basittir: tüm ekibin bir proje süresince bir rol oynamasına izin verin. Başka bir deyişle, bir projenin bir alanında değişiklik yapmanın diğerleri üzerindeki etkisini kabul edin ve benimseyin.

Ekibim ve ben bu fikre (bir projeden geçerek), bir iş danışmanımla olan etkileşimlerimiz sayesinde ulaştık. Adı Geoff ve çok keskin bir adam. Bazı büyük kuruluşların CFO'suydu ve vizyoner liderlerin şirketlerinin mali durumunu anlamalarına yardımcı olmak için bir kariyer yaptı.

Geoff ile ilk tanıştığımızda kriz modundaydık. Önümüzde, ne ortaklarımın ne de benim nasıl ele alacağımızı bilmediğimiz büyük bir zorluk vardı. Geoff hepimizi oturdu ve "sonunu düşünerek başlamamızı" istedi. Önümüzdeki zor günleri atlattıktan sonra nasıl görüneceğini açıklamamızı istedi. Şirketimizin hayatında bu kez başarıyı tanımlamamızı istedi. Geoff ile görüşmeye devam ettikçe hüsrana uğramaya başladım. Her oturduğumuzda, karşılaştığımız sorunu çözmeye başlamak için ihtiyacımız olan tavsiyeyi vereceğini umuyordum. Bunun yerine, sürekli olarak daha fazla soru sordu. Bu birkaç hafta boyunca devam etti ve benim için zor bir zamandı.

Geoff ve ortaklarımla yaptığım ve her şeyin anlam kazanmaya başladığı toplantıyı asla unutmayacağım. Toplantımız diğerleri gibi başladı; Sorunla ilgili mevcut anlayışımızı önümüze koyduk ve edindiğimiz yeni içgörüleri paylaşmak için biraz zaman ayırdık. Ancak bu sefer her birimiz çözümün ortaya çıktığını görmeye başladık. Tam olarak net değildi, ama odaklanmaya başladı. Düşündüğümüz üç seçenekten biri diğerlerinden çok daha çekici görünmeye başladı. Geçtiğimiz aylarda öğrendiklerimiz, bizi karşılaştığımız sorunu çözmek için en iyi seçeneğe yönlendirdi.

Bu ders benim için çok değerliydi. Bana öğrettiği şey, doğrusal bir sürecin, tüm bilgilere sahip olmadan önce kararlar vermemizi gerektirdiğidir. Görsel tasarımı düşünmeden bir dizi tel kafes oluşturmak için bilmemiz gereken her şeyi nasıl bilebiliriz? Bazı ön uç kodlarını denemeden arayüz tasarımını nasıl mükemmelleştirebiliriz? İçerikle başlamak, sonra biraz kullanıcı deneyimi tasarımı yapmak, sonra biraz kullanıcı arayüzü tasarımı yapmak ve bu şekilde devam etmek mümkünmüş gibi davrandığımızda, bu çıktıların her birinin diğerleri üzerindeki etkisini görmezden geliyoruz. Bunun yerine, birbirlerini bilgilendirmelerine izin vermeliyiz. Onlara nefes almaları, uyum sağlamaları ve projeden öğrendiklerini onları ileriye taşımak için kullanmaları için yer vermeliyiz.

Bu tam olarak Geoff'un bizi zorladığı sarmal süreç. Soru sormakla geçen o haftalar, sorunu anlamamızı sağlıyordu. Bir karar vermek (bir kullanıcı arayüzü tasarımını onaylamak) ve hiç değişmeyecekmiş gibi devam etmek yerine (Tamam, ön uç geliştirici, bu tasarımı kodla), Geoff bizi ihtiyacımız olan tüm bilgilere sahip olmadığımızı kabul etmeye zorladı. en iyi kararı vermek için. Geoff, karar vermek için "son sorumlu ana" kadar beklememizi istedi.

Bu sarmal fikrini her gün yaptığımız şeye çevirmeye çalıştım ve şöyle bir görselleştirmeye ulaştım:

Lütfen yukarıdaki pasta dilimlerine kendi disiplinlerinizi koyun - yaklaşımı göstermek için resim basitleştirilmiştir. Bu noktaların geleneksel anlamda çıktılar olmadığını not etmek önemlidir. Müşterinizle oturup "tek teslim edilebilir" olana doğru ilerlemenizi gözden geçirmeniz için fırsatları temsil ederler. Bunun anlamı şudur: müşterinizi hayal kırıklığına uğratma korkusuyla çıktıları iyileştirmeyi bırakın. Beyaz tahta üzerinde bir eskiz yapacaksa, Illustrator'da tel çerçevelerinizin güzel görünmesini sağlamak son derece verimsizdir. Hatta bunları teslim edilebilirler olarak adlandırmayı bıraktık ve güncellemeler olarak adlandırmaya başladık.

Bu tür bir iş akışı, her tür projede kullanılabilecek kadar esnektir, çünkü proje için gerekli olan disiplin türlerini basitçe değiştirebilirsiniz. Süreç etrafındaki tören, ilgili kişilerin deneyimine bağlı olarak daha katı veya daha doğaçlama yapılabilir. Anahtar, tüm insanların dahil olduğundan emin olmaktır.

Bu yaklaşım, doğru bilgiye sahip olana kadar kararları geciktirir. Bir disiplin tarafından alınan kararların şüphesiz diğerlerini etkileyeceğini kabul eder. Sohbeti ekibe açar ve ilgili herkesin katılımını gerektirir. Daha az resmi ama daha verimli. Daha az tahmin edilebilir, ancak çok daha iyi bir ürün sunma potansiyeline sahip olduğuna inanıyorum.

Multidisipliner katkı aramamız gerektiği konusunda hemfikir olalım.

Verimlilik Anahtardır

Dünyada bu kadar zamanımız olsaydı, sürecimiz hakkında endişelenmemize gerek kalmazdı - harika bir fikre tökezleyene kadar bir şeyler deneyebilirdik. Sen de ben de durumun böyle olmadığını biliyoruz.

Sparkbox'taki sürecimizde yaptığımız ayarlamaların çoğu, bir şeyi başarmanın daha hızlı bir yolunu arıyor olmamızdan kaynaklanıyor. Artan hız vaadi, aynı zamanda daha büyük müşterilerde çok yetenekli bazı dahili ekiplerle çalışma fırsatlarını da nasıl kazandığımızdır. Herkes verimlilik kazancı arıyor.

İyi bir sürecin aynı zamanda verimli bir süreç olduğu konusunda hemfikiriz.

Sürekli Gelişen. multidisipliner. Verimli. Bu işin özüne inerken, bu üç şeyi aklımızda tutmamızı istiyorum. Bu fikirleri, içinden yeni yaklaşımları düşündüğümüz bir filtre olarak kullanabiliriz.

Yeter Teori

Bu kadar teori yeter. Gelelim bu işin püf noktalarına. Web projelerimiz boyunca kendimi sürekli olarak üç soru sorarken buluyorum:

1. Kimin için inşa ediyoruz?
2. Deneyimden ne kazanmalarını istiyoruz?
3. Deneyimi nasıl sunmalıyız?

Amaç, doğru şeyleri (neyi) doğru şekilde (nasıl) doğru kişilere (kime) söylemenin bir yolunu bulmaktır. Her türden mükemmel iletişimin sırrı bu soruları yanıtlamaktan geçiyor. Elbette projeniz boyunca birçok başka soru soracaksınız. Bu sitede ne tür gezinme kalıpları kullanmalıyım veya gerçekten her sayfanın başında bir reklama ihtiyacımız var mı? Kimin, neyin ve nasıl sorularına cevap vermenin, ortaya çıkan diğer tüm soruları cevaplarken sizi doğru yöne götüreceğini öneriyorum.

Umarım Dan Mall'ın bölümünü okumuşsunuzdur (bundan hemen önce). İçinde, kiminle iletişim kurduğunuzu anlama konusunda bazı bağlamlar sağlayarak harika bir iş çıkarıyor. Mülakat ve başlangıç ​​toplantılarıyla ilgili açıklamaları sizi sağlam bir şekilde doğru yöne götürecektir.

Benzer şekilde, Eileen Webb'in bir sonraki bölümü, duyarlı projeniz için içerik stratejisi hakkındadır. Kapsamlı bir bölüm ve iletişim kurmaya çalıştığımız şeyin ne olduğuyla ilgili soruları benden daha iyi yanıtlıyor.

Bu nedenle, bu bölümün geri kalanı üçüncü soruyu yanıtlamaya adanmıştır, “Nasıl?” Sparkbox'taki ekibim ve benim için en yararlı olan araç türlerini sizinle paylaşacağım ve onların da size yardımcı olacağına güveneceğim!

Yaptırmak

Daha önce de belirttiğim gibi, sunduğumuz içeriğin ve işlevselliğin önceliğini anlamak, etkili bir şekilde iletişim kurmak için çok önemlidir. İşte bu gerçeğin yaptığımız işte kendini göstermesinin birkaç yolu.

İçerik Önceliği Kılavuzu

Bir içerik önceliği kılavuzu, "kısmen içerik modelleme, kısmen soyulmuş tel kafes"tir (Emily Gray'in "İçerik Önceliği Kılavuzu"na bakın); mini bir içerik modeli gibi, öncelik sırasına göre ve müşteri işbirliğiyle. (İçerik önceliği kılavuzunun çalışan bir örneği için https://bit.ly/content-priority-guide adresine bakın.)

İçerik önceliği kılavuzu, her sayfada ne tür içeriğin bulunması gerektiğini söyler. Bunlar, bir blog gönderisindeki başlık, birincil resim ve gövde kopyası gibi basit şeyler olabilir veya çok daha karmaşık olabilir: bir e-ticaret sitesinin ürün detay sayfasında ihtiyaç duyabileceğiniz tüm içerik türlerini düşünün.

Ayrıca her içerik türünün açıklamasına da izin verir. Bir ürünle ilgili kısa bir açıklamanız varsa, öncelik kılavuzunda "Ürünü ve onu benzersiz kılan şeyi açıklayan bir cümle" diyebilir. Kahraman resmi gibi bir öğe için, belirli bir durumla ilgiliyse, fotoğrafın sanat yönü hakkında bazı ayrıntılar verebilirsiniz.

İçerik önceliği kılavuzları, yeniden kullanılabilir bileşenleri hızla belirlemenize de yardımcı olur. Bu, o içeriğin yönetimini planlarken çok yardımcı olur - yeniden kullanılabilir kalıpları tanımak, içeriği yönetmek için daha verimli bir sistem oluşturabileceğiniz anlamına gelir.

En önemlisi, bir öncelik kılavuzu öncelik sırasına göredir . Herhangi bir belirli sayfada gerçekten neyin önemli olduğu hakkında bir tartışmayı kışkırtır. Bu, bir sitenin görüntü alanı genişliklerinde nasıl yanıt vereceğini düşündüğünüzde çok yardımcı olur. Ve gerçek içerik içermediği için, kopyayı hemen yazmaya başlarsanız kolayca gözden kaçabilecek içerik türlerinin ne ve neden hakkında harika sohbetleri kolaylaştırır.

Müşterileriniz öncelik vermekte zorlanıyorsa (ve muhtemelen yapacaklardır), bu kararları bir elektronik tabloya neyin en önemli olduğuna yerleştirebilir ve onlara kontrol etme seçenekleri sunabilirsiniz - birincil, ikincil, üçüncül vb. Sonuç aynıdır: her sayfa için öncelikli içerik türleri listesi, ancak oraya gitme süreci, müşteriye bazı seçenekler sunulursa, müşteriye biraz daha kolay gelebilir.

Bilgi Mimarisi

Sistemde bulunması gereken içeriğin türlerini ve önceliğini iyi anladıktan sonra, bu içeriğin nasıl gruplandırılması gerektiğini ve kullanıcılarınızın içerik boyunca izlemesini istediğiniz yolları düşünmek çok önemlidir. Bu tür bir düşünce, kullanılabilir bir sitenin oluşturulması için çok önemlidir.

Geçenlerde Aaron Quinn'in bilgi mimarisi hakkında konuştuğunu gördüm ve bana gerçekten takılan bir şey söyledi. Bilgiyi gruplamak söz konusu olduğunda sağduyumuza çok fazla güvenebileceğimizi öne sürdü. Bunun yerine, kullanıcılarımızın inşa ettiğimiz ürünle nasıl etkileşime gireceğini planlarken sağduyu yerine fikir birliğini göz önünde bulundurmamızı önerdi. Nedenini kısa bir hikaye ile açıklayayım.

Bir yılı aşkın süredir birlikte çalıştığımız bir müşterimiz var. Oluşturmasına yardım ettiğimiz çok başarılı bir SAAS ürününü önyükledi. Bu kadın inanılmaz derecede zeki; her gün internette çalışıyor - hayatını böyle kazanıyor. Çok uzun zaman önce, ürününde sırada ne olduğu hakkında onunla konuşuyordum ve bana şunu söyledi: "Sitemizdeki sekmelerde bazı değişiklikler yapmamız gerektiğini düşünüyorum." Durakladım çünkü umutsuzca onun sitesinde sekmeleri nereye uyguladığımızı hatırlamaya çalışıyordum. Kafamın karıştığını hissederek, ne umduğu hakkında daha fazla açıklamaya devam etti. Birkaç dakika sonra navigasyondan bahsettiğini anladım. Bu bilgili web girişimcisinin navigasyonundan "sekmeler" olarak bahsetmesi çok açıklayıcıydı.

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. Efficient. 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.

Bu çok fazla. 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.

Duyarlı bir şekilde oluşturuyorsak, görüntü alanı genişliklerinde tek site çözümünü test etmeye odaklanmamız gerekir. Sadece kırılma noktalarını değil, bütünün kullanılabilirliğini ölçmemiz gerekiyor. Bu, çoğu insan için en kullanışlı deneyimi yaratmamıza yardımcı olacaktır.

Ve şimdi, bu hedeflere ulaşmaya yardımcı olmak için müşterilerimizle birlikte kullandığımız birkaç güncelleme.

İçerik Prototipi

Bir web tasarımcısının biraz CSS öğrenmesi gerektiğini söylediğini duydunuz, değil mi? Pekala, katılıyorum ve bence bir içerik stratejisti biraz HTML öğrenmeli. Bu nedenle ve diğer pek çok nedenle, web geliştirme sürecimizde oldukça erken içerik prototipleri oluşturuyoruz. Gerçek içeriğin net bir resmini elde etmeye başlar başlamaz, bu içeriği hiper metin ile işaretlemeye başlarız. HTML ile yaptığımız şey bu, değil mi? İçeriği en iyi anlayan kişilerden daha iyi kim anlamsal etiketlere sarılabilir? Markdown gibi araçlar da işe yarasa da, doğrudan Markdown'a geçmeden önce bazı temel HTML'leri öğrenmenin en iyisi olduğunu düşünüyorum. İçeriği neden bu şekilde yazdığınızı anlamak, HTML'yi gerçekten yazmak kadar önemlidir. Markdown gibi araçlar, eylemleriniz ve bu eylemlerin çıktısı arasına bir soyutlama katmanı ekler - size ne verdiğini anladığınızda iyi olan bir soyutlama.

Bir içerik prototipi oluşturduğumuzda, neredeyse tüm stilleri kasıtlı olarak dışarıda bırakıyoruz. Onları oldukça çirkin bırakıyoruz, bu yüzden hiçbir şey tasarlamadığımız çok açık. Bu, sohbetin içeriğe ve içeriğin önceliğine odaklanmasını sağlar. Bunu bir müşteriye gösterdiğinizde, hemen sıraya gireceklerini bilin - tam olarak onlardan yapmalarını istediğiniz şey budur: önceliği doğru alın! Ayrıca, genellikle aşağıdaki gibi gruplamaları gösterecek kadar CSS ekleriz:

Sana çirkin olduğunu söylemiştim.

Ayrıca içerik prototiplerimizi bağlantılarla dolduruyoruz. Bunları oluşturmamızın bir nedeni, insanların içerikteki akışın işe yarayıp yaramadığını görmek için sayfadan sayfaya gezinmesine izin vermektir.

Unutmayın, müşterilerinizi bu tür çirkin güncellemeleri görmeye hazırlamanız gerekiyor. Aksi takdirde, sizi projelerine dahil etme konusunda kesinlikle ikinci düşünceleri olacaktır. Ancak, bir tarayıcıda işaretlenmiş ham içeriği görme konusunda güçlü bir şey var.

Önemli bir not: Tamamen semantik işaretlemenin muhtemelen üretime gidecek şey olmadığını biliyoruz. Bu ideal olsa da, bugün web üzerinde çalışmanın gerçekliği, çılgınca değişen becerilere sahip bireyler ve ekipler tarafından sürdürülebilir ve genişletilebilir olması gerektiğidir. Ancak, işaretlemenin bu saf versiyonuyla başlamak, bize ideallerimizi hatırlatmanın harika bir yoludur. Ardından, biçimlendirmeyi, yeniden kullanılabilirliği, genişletilebilirliği vb. sağlamak için biçimlendirmeyi ayarlarken, yaptığımız her değişikliğin bizi idealden uzaklaştırdığının çok farkındayız. Her değişiklik bir uzlaşmadır ve yapılmadan önce derinlemesine düşünülmelidir.

Statik Tel Çerçeveler

Geçtiğimiz birkaç yıl, daha geleneksel statik tel çerçeveler için biraz hoşnutsuzluk gördü. Hala çok fazla değer katabileceklerine inanıyorum. Ayrıca her projede gerekli olmayabileceğine inanıyorum. Bunları kullandığımızda, önceliğe odaklanmamıza yardımcı olmak için genellikle dar genişliklerde - bu ne kadar elverişsiz olsa da - yaparız. Görsel gayrimenkulümüzü sınırlamak bu odağı zorlar. Bunu yapmak için Keynote'tan Balsamiq'e kadar pek çok araç kullandık. Dürüst olmak gerekirse, bu araçlardan herhangi biri işi yapacak. Rahat edeceğiniz birini bulun ve işe başlayın.

Ayrıca bol bol eskiz yapıyoruz. Beyaz tahtalar, kalem ve kağıt, çeşitli eskiz uygulamaları. Bu şeylerin fotoğraflarını çekiyoruz ve kasıtlı olarak hepsini çok ham tutarak müşterilerimizle paylaşıyoruz. Hamlık, yaptığımız işin önemli bir parçasıdır. Müşterilerimize, ciladan fayda sağlamayacak belgeleri cilalamak için zaman kaybetmediğimizi bilmelerine yardımcı olur ve geri bildirimin odaklanmasını sağlar. İstediğimiz son şey, birinin tel çerçevelerimizin renkleri hakkında yorum yapması.

Etkileşimli Tel Çerçeveler

Daha geleneksel tel çerçevelerden uzaklaşmanın bir kısmı, daha etkileşimli bir yaklaşımdan yana olmuştur. Çevik Manifesto'nun dokümantasyon yerine çalışan yazılımları teşvik etmesi gibi, sektörümüzdeki birçok kişi, bir prototip aracılığıyla etkileşim niyetinizi göstermenin, onu statik olarak tanımlamaya çalışmaktan çok daha güçlü olduğuna inanıyor. Bu günlerde, hızlı prototipleme için mevcut araçlar son derece yetenekli: Bootstrap ve Foundation gibi çerçeveler; Bourbon ve Pure CSS gibi CSS (veya Sass ve LESS) araç takımları; InVision ve Marvel gibi görsel prototipleme araçları. Macaw gibi görsel web tasarım ve geliştirme araçları veya Keynote gibi sunum araçları bile çok etkileşimli tel çerçeveler oluşturmak için kullanılabilir.

Bu yaklaşımın yararı, insanlara fikri açıklamaya çalışmak yerine onlara gösterebilmenizdir. Bir resim bin kelimeye bedelse, bir prototip bin resme bedeldir.

Artık bunu anlayan bir organizasyonla çalışıyoruz. Hedeflerinden biri, hızlı prototiplemeyi süreçlerine daha erken dahil etmek ve böylece prototipleri kullanılabilirlik çalışmaları ve üretim kodu için kullanabilmeleri. Onlarla yaptığımız çalışma, tüm web mülklerinde kullanılabilecek bir bileşen sistemi oluşturmaya odaklanmıştır. Bu sistem aynı zamanda ekiplerinin çok hızlı bir şekilde etkileşimli tel çerçeveler oluşturmasına izin vermek için de kullanılacaktır. Markalarını göz önünde bulundurarak inşa edeceğimiz için, etkileşimli tel çerçeveler üretim sürümlerine çok benzeyecek ve bu da UX testlerinde çok yardımcı olacak.

Bu tür bir yaklaşım, bir web mülkünün uzun vadeli başarısına odaklanır. Prototipin oluşturulmasına tüm disiplinleri dahil ederek ve tasarım ve geliştirme sırasında öğrenilenlerin daha sonraki kararları bildirmek için izin vererek daha önce bahsettiğimiz "tek teslim edilebilir" iş akışını somutlaştırır. Sonradan düşünülerek CSS'yi bir araya getirmek yerine olgun ön uç sistemleri oluşturan kuruluşlara doğru bir kayma gördüğümüze inanıyorum. Bir kuruluşa web çalışmalarının statik bir versiyonunu gerçek kullanıcılarla test etme yeteneği vermek, bunu yakın gelecekte bir norm olarak sağlamlaştırmaya yönelik büyük bir adımdır.

UI Tasarım ve Geliştirme

“İyi tasarım problem çözmektir.”

— Web Tasarım Sanatı ve Bilimi, Jeffrey Veen (2000) .

Tasarımcı olanlarınız için bu alıntı çok doğru geliyor. Birçok insan yaptığımız şeyi dekorasyon olarak görüyor, ama çok daha fazlası. Geçtiğimiz birkaç yıl içinde, Jeff'in bu sözlerine tüm kalbimle katılıyorum, ama aynı zamanda tasarımcıların çözümlerini aşırı hassaslaştırma eğilimlerinin de son derece farkındayım. Bu beni “geçiş noktası” dediğim şeye götürüyor.

Tasarım etkinliğini üç aşamaya bölerseniz - estetiği oluşturmak, sorunu çözmek ve çözümü geliştirmek (yukarıda belirtildiği gibi) - sorun çözmeden çözüm iyileştirmeye geçiş, geçiş noktasıdır. Bu, web ortamına geçmek için son sorumlu an. Bunu yapmazsanız, o iyileştirme aşamasını birden çok kez gerçekleştirirsiniz ve bu oldukça verimsizdir.

Bir PSD üzerinde saatlerce ince ayar yaptıysanız, onu inşa etmesi için bir geliştiriciye verdiyseniz ve ardından bir veya iki hafta içinde tekrar kontrol ettiyseniz, bu acıyı yaşadınız. Etrafta statik pikselleri iterek iyileştirme ve iyileştirme için harcadığınız tüm çaba boşa gider. Tasarım ortamı değiştirir değiştirmez (Photoshop'taki veya başka bir araçtaki statik tasarımdan tarayıcıdaki HTML ve CSS'ye), başka bir iyileştirme aşamasına ihtiyaç vardır. Geçiş noktasının arkasındaki fikir, bunun ne kadar verimsiz olduğunu anlamaktır. Statik araçlarla rafine etmek yerine, temel tasarımı mümkün olan en kısa sürede kodlayın ve iyileştirmeyi son ortam olan web'de gerçekleştirin.

Bu genellikle, bu iyileştirmelerin hayata geçmesi için kelimenin tam anlamıyla birlikte oturan tasarım eşleştirmesini gerektirir. Bu bazen yavaş ve acı verici gelse de, aslında ilgili herkes için çok faydalıdır. Bir tasarımcı, bir ön uç geliştiriciyle, görmek istedikleri stil ayarlama türlerini paylaştığında, ön uç geliştirici, rafine bir tasarımda neyin önemli olduğunu öğrenir. Ön uç geliştirici istenen değişiklikleri yaparken, tasarımcı bu değişikliklerin nasıl yapıldığını görür, belki biraz CSS öğrenir. Bu süreç herkesi daha akıllı yapar. Aynı zamanda bu iki çiftin bir dahaki sefere çok daha hızlı gideceği anlamına gelir.

Bu günlerde, kullanıcı arayüzü konuşmalarını başlatmak için bir dizi araç konusunda rahat olmamız ve bu tasarımların kodlamasını sürecin başlarında değiştirmemiz gerekiyor. Bunu yapmanın birkaç yoluna bir göz atalım.

Stil Fayansları

Samantha Warren, web için "görsel bir dil tanımlamanın" bir yolu olarak stil döşemelerini tanıttığında yeni bir çığır açtı. Marka geçmişine sahip olanlarımız, stil karolarının ne kadar değerli olabileceğini hemen anladı.

Stil karoları oldukça basittir. Genellikle renk paletlerini, tipografi seçimlerini, dokuları ve ikonografi veya illüstrasyon stillerini içerirler. Kasıtlı olarak tam sayfa bir kompozisyon değiller . Bunun yerine, doğru yönde hareket edip etmediğimizi belirlemeye yetecek kadar tasarımı temsil ediyorlar. Bu nedenle, müşteriniz ne istediğini ifade ettiğinde en iyi şekilde çalışırlar, ancak aynı sayfada olduğunuza tam olarak ikna olmazsınız.

Stil karolarını, çoğunlukla hızlarından dolayı takdir etmeye geldim. Photoshop'ta bir ana sayfa ve alt sayfa tasarlamak için bir hafta harcadığımız yerde, şimdi birkaç saat içinde basit bir stil döşemesi oluşturabiliyoruz. Bu, zamandan ve paradan tasarruf sağlayabilir ve size doğru yönde ilerlediğinize dair güven verebilir.

Samantha'nın stil karoları sitesinde bir avuç örnek var ve aşağıda gerçek dünyadaki kullanımlarını kapsayan birkaç harika kaynak var:

• “Görsel Tarzınızı Getirin”: Yesenia Perez-Cruz, Dan Mall ve Austin, Teksas'taki Artifact Konferansı'ndaki sunumum (13 Mayıs 2013).
• “Stil Fayanslarla Daha Hızlı Tasarım Kararları”: Samantha Warren Austin, Teksas'taki An Event Apart'ta (Şubat 2015).
• Samantha Warren ile Stil Rehberi Podcast'i

Statik yapıları nedeniyle onları çok sık kullanmıyoruz. İlk tasarım yönümüz, tipik olarak, her ikisi de daha sonra ele alınan bir eleman kolajı veya bir stil prototipi ile belirlenir.

Öğe Kolajları

Dan Mall bizi eleman kolajlarıyla "belirli bir mantık veya düzen olmaksızın farklı parçaların bir araya getirilmesi" olarak tanıttı. Onların alacalı doğası, baktığınız şeyin nihai bir tasarım olmadığını açıkça ortaya koyuyor; bunun yerine, öğe kolajları, müşterilere bir sistemde birlikte yaşayabilecek çeşitli bileşenlerin bağlamını sağlar. Bir tel kafesin kemiklerine biraz et koymamıza yardım ederler; hareket ettiğimiz yönü hayal etmemize yardımcı olurlar; sitemizin yapı taşlarını görselleştirmeye başlamamıza izin veriyorlar ama bütünü gözden kaçırmamamız için bizi teşvik ediyorlar.

Öğe kolajlarının bir yararı, hangi bileşenlerin gösterileceğini seçebilmenizdir. Müşteriniz, aramanın kullanıcılarına nasıl sunulduğuyla gerçekten ilgileniyor mu? Harika! Belki bu endişeyi ele almak için biraz zaman harcamalısın - onu element kolajına koy. Müşteriniz harekete geçirici mesaj düğmelerine takıntılı mı? Bunları öğe kolajına yerleştirin. Bu seç ve seç mantığı, her bir kolajı projenizde en önemli olanla uyarlamanızı kolaylaştırır. Müşterileriniz bunu çok takdir edecek.

Yakın tarihli bir projede, müşterimizin web özelliklerinden birinin yeniden tasarımı için tasarım yönünü belirlememiz gerekiyordu. Katie Kovalcin (tasarımcılarımızdan biri) ekibimizin tasarım çabalarına öncülük ediyordu ve ana sayfa kompozisyonları yapmak yerine iki element kolajı oluşturmayı tercih etti.

Bu iki tasarım konseptini yaratmak için harcadığımız toplam süre yaklaşık 16 saatti. Katie'ye iki ana sayfa kompozisyonu yapması istenseydi bunun ne kadar süreceğini sorduğumda, şöyle cevap verdi:

"Bu adımda, yeni estetiğini anlamaya çalışırken, sayfanın hiyerarşisini ortaya koymaya ve etkileşimleri anlamaya çalışırken o estetiği bulma konusunda hokkabazlık yapmak zor olurdu. Bu nedenle, estetiği anlamanın bir yolu olarak tüm ana sayfayı düzenlemek, ne kadar çalışmamız gerektiğine bağlı olarak bazen bir hafta kadar sürebilir. Her biri muhtemelen 25-30 saate yakın diyebilirim.

Ancak öğe kolajından çıkarken, sayfa düzeni ve diğer tüm şeylerle ilerlemek oldukça kolaydı çünkü hangi düğme stillerini, yazı tiplerini veya renkleri kullanacağımızı bulmak için çok fazla karıştırma yok. ”

Bu, bir element kolajı kullanarak, bir estetik oluşturmak için harcadığımız süreyi dörde böldük demektir.

Katie'nin yukarıdaki alıntısında gerçekten ilginç bir ifade daha var; "Sayfanın hiyerarşisini ortaya koymaya ve etkileşimleri anlamaya çalışırken bu estetiği bulmanın zor olacağını" söyledi. Başka bir deyişle, bir ana sayfa kompozisyonu ile başlamak, çok kısa sürede çok fazla şey başarmaya çalışmaktır. İlk önce daha küçük bir adım attığımızda (eleman kolajları veya stil karoları kullanarak), önümüze çıkan tasarım zorluklarını bölebilir ve üstesinden gelebiliriz. Bu, müşterilerimizi sohbete daha sık dahil eder ve ilerledikçe öğrenmemizi sağlar, bunların tümü daha iyi çalışmayla sonuçlanır.

Stil Prototipleri

Stil prototiplerini etkileşimli stil karoları olarak düşünebilirsiniz. Bir stil kutucuğuna ekleyebileceğiniz aynı tür şeyler (marka işareti, başlıklar, paragraf stilleri, düğme stilleri, bağlantı işleme, renk önerileri) bir stil prototipine dahildir. Tek fark, bunu bir adım daha ileri götürüp kodlamamız.

Bunların güzelliği, gerçek web türünü, gerçek renkleri, gerçek vurgulu durumları, web vektörleriyle çizim stilini ve tür ile temel düzenin nasıl yanıt verebileceğini gösterebilmemizdir. Müşterilerimizden bunları kendi seçtikleri tarayıcıda incelemelerini istiyoruz. Bu, bir tarayıcıyı desteklemenin ne anlama geldiğiyle ilgili konuşmaları açar. Örneğin, border-radius özelliğini desteklemeyen bir tarayıcı kullanırlarsa, yuvarlatılmış köşeler görmezler.

Ayrıca stil prototiplerini yaklaşık bir günde oluşturabiliyoruz, bu da bize stil karosunun sağladığı verimlilik avantajlarının aynısını sağlıyor. Müşteriler, onlarla etkileşime girebildikleri için onları severler. Onları telefonlarında ve tabletlerinde görebilirler. Onlarla oynamaya başlayabilirler.

Son olarak, çoğumuzun web tasarımcılarının kodlamayı öğrenmesi gerektiğine inandığımız bir dünyada, stil prototipleri HTML ve CSS yazmaya harika bir giriş niteliğindedir. Basitlikleri nedeniyle, kodlama yapmayan bir tasarımcı bile onları nasıl oluşturacağını anlayabilir. Daha farkına varmadan, görmek istedikleri değişiklikleri statik olarak taklit etmek yerine üretim CSS'sini iyileştirme güvenine sahip olacaklar.

Orijinal Sparkbox sitesini tasarlarken ve yakın zamanda yeniden tasarlarken, bir tasarım yönü oluşturmak için stil prototiplerini kullandık.

Atom Tasarımı

Jeremy Keith, "Mobil Web Yok" başlıklı Breaking Development açılış konuşmasında tasarıma "bir sitenin atomları" ile başlama fikriyle beni tanıştırdı. Brad Frost, Haziran 2013'te web için bir "bileşenler sistemi" tasarımına yaklaşmak için zihinsel bir model oluşturduğunda bu terimi resmileştirdi.

Temel öncül, yeniden kullanılabilir bileşen sistemleri oluşturmak için çalışmalarımızda beş ayrıntı düzeyini göz önünde bulundurmamız gerektiğidir. En küçük seviyeye atom denir; basit bir HTML girdisi veya bir girdi için bir etiket düşünün. Bu atomlar moleküller halinde birleştirilebilir; belki bir arama molekülü bir düğme, etiket ve girdiden oluşur. Bu moleküller, organizmaları oluşturmak üzere birleştirilebilir; belki bir web sitesinin başlığı arama, marka ve gezinme moleküllerini içerebilir. Bu organizmalar, şablonlar ve sayfalar oluşturmak için bir araya getirilir. Şablonlar genel verilerle doludur; sayfalar, içlerine gerçek verilerin enjekte edildiği şablonlardır. Tüm bu teoriler daha modüler, yeniden kullanılabilir ve genişletilebilir kodlar oluşturmamıza yardımcı olabilir.

Projelerimize bu düşünce doğrultusunda yaklaşırken öğrendiğim bir şey, atom tasarımının yeniden düzenlemeden çıkmasına izin verdiğinizde çok daha kolay olduğudur. Çalışmamızın yaygın bir yolu, atomlar, moleküller veya organizmalar hakkında fazla endişelenmeden HTML ve CSS'de küçük bir bileşen oluşturmaktır. Ardından, bir arayüzle UX ve UI problemini çözdükten sonra, bu kodu atomik bir yapıya dönüştürebiliriz. Bu ters yaklaşım, bir organizmaya karşı bir molekülün ne olması gerektiğini fazla düşünmeye çalışmakla zaman kaybetmediğimiz anlamına gelir. Bunun yerine, sistemin kendisi geliştikçe çeşitli seviyelerin gelişmesine izin veriyoruz.

Atomik bir yaklaşımın sonucu, bir sisteme entegre edilebilen bir model kütüphanesidir.

Desen Kitaplıkları

Bir kalıp kitaplığı, kulağa nasıl geliyorsa öyledir - sisteminizde var olan kalıpların bir kitaplığı. Bugünlerde desen kitaplığı çözümleri üzerinde çalışan birçok insan var; Brad Frost, Anna Debenham, Jina Bolton ve Bermon Painter gibi insanlar konu hakkında konuşmuş ve yazmıştır. Aslında, Brad ve Dave Olson, bugün mevcut olan en iyi bilinen araçlardan biri olan Pattern Lab'ı yarattılar. Model Laboratuvarı harika çünkü belirli içeriği HTML modüllerinden ayırmanıza izin veriyor ve bir kalıp sistemi oluşturmayı kolaylaştıran atomik bir çerçeve sağlıyor. Ayrıca geliştirme aşamasındayken test etmeniz için bazı harika özellikler de eklediler. Her şeyi yerel olarak çalıştırmak çok kolaydır ve bir müşteriye kolayca gösterilebilen basit bir arayüze sahiptir. Desen odaklı tasarıma girmek istiyorsanız, burası başlamak için harika bir yerdir.

Şu anda bu alanda çok şey oluyor ve daha fazlasını öğrenmek isteyenler için başka birçok kaynak var. Brad, Web Sitesi Stil Rehberi Kaynakları oluşturmak için Anna Debenham ve Brendan Falkowski (birkaç başka kişiyle birlikte) ile birlikte çalıştı. Bu, model odaklı tasarım ve geliştirmeyi kapsayan birçok örnek, makale, konuşma, podcast ve daha fazlasını içeren muazzam bir koleksiyon.

Şimdiye kadarki en büyük zorluk, kalıplar bir arka uç sistemiyle entegre edildikten sonra bir kalıp kitaplığını güncel tutmanın bir yolunu bulmaktır. Henüz bunun için mükemmel bir çözüm görmedim, ancak üzerinde çalışan birçok parlak beyin var. Bu sorunu çözmek için özenle çalışan bir organizasyona harika bir örnek olarak Rizzo by Lonely Planet'e göz atın. Uzun vadeli mükemmel bir çözümümüz olmasa bile, bu şekilde tasarlamanın muazzam faydalarını gördüm. Modüler düşünmenizi sağlar ve bu, yaptığımız ön uç çalışmayı entegre etmeyi ve sürdürmeyi çok daha kolay hale getirir.

Peki ya Kesme Noktaları?

Ne zaman süreç hakkında konuşsam veya yazsam, her zaman kesme noktalarını seçmem isteniyor. Garip bir şekilde, bu konuşma, günden güne duyarlı çalışmalarımızda neredeyse hiç ortaya çıkmıyor. Elbette, bazı müşteriler analitiği gözden geçirmek ve cihazlara öncelik vermek için bir ton iş yaparak bize geliyorlar - hepsi de sistemin kesme noktalarını belgelemek adına. Bu düşünce tarzı bana hiçbir zaman çok mantıklı gelmedi.

Bunu ilk söyleyenin Stephen Hay olduğuna inanıyorum: "Küçük başlayın ve site bozulduğunda bir kesme noktası ekleyin." Sitelerimizde genellikle düzinelerce kesme noktası bulunur ve bunların çoğu yaygın cihaz boyutlarıyla uyumlu değildir. İçeriğinizin ve tasarımınızın artık uyum içinde çalışmadığını gördüğünüzde düzeltin.

Şimdi, Stephanie Rieger'in majör kırılma noktaları ve minör kırılma noktaları dediği şey arasında bir fark var. (Ayrıca kesme noktaları ve ince ayar noktaları olarak adlandırıldıklarını duydum.) Her birini açıklamama izin verin.

Başlıca Kırılma Noktaları

Tasarım değişikliğinde birlikte çalışmak için ayrı modüller gerektiren düzende kaymalar olduğunda, ortak bir kesme noktası (ana kesme noktası) kullanırız. Küçük görüntü alanı genişliklerinde yığılmış bir ürün listesini daha büyük görüntü alanı genişliklerinde iki sütunlu bir düzene taşıyan bir düzen ayarınız olabilir. Bu durumda, aynı görüntü alanı genişliğinde gerçekleşmesi gereken başka birçok değişiklik olması muhtemel olduğundan, bu yerleşim değişikliğinin nerede olduğunu takip etmek isteyeceksiniz.

Yaptığımız işlerin çoğunda üç ila altı ana kesme noktası vardır. Bunlar, daha sonra tek bir yerde değişiklik yapabilmemiz için genellikle iş akışımızda Sass değişkenleri olarak ayarlanır. Bir sitenin ana bölümleri için bir dizi önemli kesme noktasına sahip olmamız da yaygındır. Örneğin, sitemizin üstbilgisinde üç ana kesme noktamız ve altbilgide tamamen farklı üç ana kesme noktamız olabilir. Bu, çalışmamızı modüler tutar ve bir bütün olarak sistemle uyumu korurken bu bölümlerin bağımsız olarak gelişmesine izin verir.

Küçük Kesme Noktaları

Tür veya boşlukta daha ince değişiklikler gerektiğinde, bu ayarlamaları yapmak için yine de bir medya sorgusu kullanabiliriz (küçük bir kesme noktası). Bunlar, yazı tipi boyutu (satır uzunluğunu kontrol altında tutmak için) veya görüntü alanı genişliği arttıkça aralığı artırmak gibi şeyler için tipik olarak bir kerelik stil değişiklikleridir. Bu küçük ayarlamalar, işinizi gerçekten farklı kılabilecek ayrıntılara gösterilen derin dikkati gösterir.

Bunlar için önişlemci değişkenleri kullanmak yerine, genellikle yalnızca sabit kodlanmış sayılar kullanırız. Bunları büyük bir kırılma noktasına göre tutmak için zaman zaman önişlemci hesaplamalarını da kullandık. Örneğin, 30em'de $bp_header-show-nav adında büyük bir kesme noktamız varsa, bir başlığın yazı tipi boyutunu $bp_header-show-nav kesme noktası üzerinden 5em olarak ayarlamak isteyebilirim. Bu durumda, bu 35em'de olur. Gelecekte bir noktada bu büyük kesme noktasını 32em olarak değiştirirsek, küçük değişiklik daha sonra 37em'de gerçekleşecektir. Ana kırılma noktalarının değişebileceğinden şüpheleniyorsanız, göreceli olarak küçük kesme noktalarıyla düşünmek yardımcı olabilir. En iyi kararları vermek için muhakemenizi duruma göre kullanmanız gerekecek.

Daha fazla okuma

Kesme noktaları hakkında daha fazla bilgi için şu makalelere göz atın:

• “Kırılma noktası yok”
• Mark Boulton'dan "Arada"
• Stephanie Rieger tarafından “Pragmatik Duyarlı Tasarım”

Dışa Geçiş

Bu günlerde, sadece harika siteler oluşturmak yeterli değil. Ayrıca inşa ettiğimiz şeyin ömrünü de dikkate almalıyız. Atom tasarımı gibi yaklaşımlar yardımcı olabilirken, daha fazlasını yapmamız gerekiyor. Şu anda projelerimizin çoğu bir tür eğitim bileşeni içeriyor ve müşteriye CMS'yi kullanmayı öğretmekten bahsetmiyorum. Kuruluşlar, web'in kendilerine sunduğu değeri gerçekten anlamaya başladıkça, web mülklerine sahip olmak ve bunları sürdürmek için kendi ekiplerini oluşturmaya karar veriyorlar. Kalıcı bir şey inşa etmek istiyorsak, işimizi üstlenen ekibin onu düzgün bir şekilde sürdürebildiğinden emin olmalıyız. Bu nedenle, web için derlemek için kullandığımız teknikler hakkında çok daha derinlemesine eğitim yapıyoruz.

Neyse ki, artık geçişe yaklaşmanın birçok yaygın yolu var. Kaynak kontrolünde oluşturduğumuz her repo, kullanışlı bir benioku dosyasına sahiptir; kodumuzu destekleyen otomatik testler sunuyoruz; ve müşterilerimizin sitelerinin hızını korumaya devam etmeleri için bir projenin performans bütçesini aktarmanın bazı yolları üzerinde çalışıyoruz. Atomik düşünmenin yanı sıra, inşa ettiğimiz alt sistemlerin çalışan örneklerini de sunuyoruz. Örneğin, bir müşterinin markası bağlamında tipografinin tüm web mülklerinde nasıl çalıştığını düşünmek bizim için yaygın bir durumdur, bu nedenle, bu tipografik sistem hakkında ayrıntılı belgeler ve bunun nasıl kullanılacağını gösteren bir örnek sayfası da sağlayabiliriz. Ekibimizden müşterimizin ekibine kodu ilettiğimiz için işimize bu tür eklemeler çok daha kolay bir zaman sağlıyor.

Tüm bunların daha derin yansımaları da var. İnşa ettiğiniz sistemi kimin sürdüreceğini anlamak, teknoloji seçimi ve geliştirme tekniği konusunda verdiğiniz kararları da etkilemelidir. Başka bir deyişle, müşterinizin web ekibi, Grunt'u Assemble ve komut satırından yerel bir sunucu ile kullanmaya hazır değilse, yetenekleriyle daha iyi eşleşen bir çalışma yolu bulmanız gerekir. Unutma, bunu onlar için yapıyorsun.

Ayrıca, müşterimizin web tasarım ve geliştirme ekiplerini projede bizimle birlikte katılmaya davet etmek de çok faydalı oldu. Projeyi müşterinizin ekibini eğitmek için bir fırsat olarak kullanmak, inanılmaz bir değer sergiliyor ve sizi rakipleriniz arasında kolay bir seçim haline getiriyor.

Süreç Üzerindeki İnsanlar

İş akışımızı sürekli geliştirirken öğrendiğim son bir şey, kullanmayı seçtiğiniz sürecin, onu kullanan insanlardan çok daha az önemli olduğudur. Daha iyi web ürünleri oluşturmak istiyorsanız, işe insanlarınızı geliştirerek başlayın. Bu, sizi süreciniz veya iş akışınızdaki herhangi bir ince ayardan daha ileriye götürecektir.

Ekibinizi Mutlu Tutmak

Aynı satırlar boyunca, Mihaly Csikszentmihalyi'nin Akış'ı okumanızı tavsiye ederim. Bu kitapta bireysel mutluluğu daha iyi anlamak için yaptığı araştırmaları anlatıyor. "Akış kanalı" olarak adlandırdığı şeyi, beceri düzeyini x ekseni boyunca y ekseni boyunca meydan okuma düzeyine göre çizerek tanımlar. Akış kanalı, becerinizin yeterli bir zorlukla karşılandığı alandır. Beceriniz için çok fazla meydan okuma endişe yaratır ve beceriniz için çok az meydan okuma can sıkıntısı ile sonuçlanır.

Bu, günlük işlerimizde kendimizi nerede zorladığımızı göz önünde bulundurarak ne yaptığımıza çevrilebilir. Sparkbox'ta bir öğrenme kültürü hakkında konuşuyoruz. Bu (umarım) ekibimin becerisinin sürekli arttığı anlamına gelir. Öyleyse, mutlu olmak için, sürekli artan becerimize uygun sürekli artan zorluklar bulmamız gerekir. Müşterilerimizin sahip olduğu bütçelerdeki bu yenilik ihtiyacını finansal sorumlulukla dengelemek bizim sorumluluğumuzdur.

Bu zor. Bizim için bu, tekerleği yeniden icat etmeyi bırakmamız gerektiği anlamına geliyordu; her projede aynı sorunları tekrar tekrar çözmek yerine, iyi test edilmiş arayüz öğelerinin kitaplıklarını düşünmemize yol açtı. Bu, müşterilerimizin her birinin yenilik yapmak için nereye para harcaması gerektiğini anlamamız gerektiği anlamına geliyor. Ve bu müşteriler ve ekibimiz arasında, hepimizin aynı sayfada olması için biraz şeffaflık gerektirdi.

Sonunda, daha içerikli bir ekip yaratır - yaptıkları işi seven, çünkü onları doğru şekilde zorlayan bir ekip. Ayrıca, nereye ve neden yatırım yapmaları gerektiğine dair önerilerinize saygı duyan daha içerikli bir müşteri sağlar. Bu, katılan herkes için harika.

ileri

Bu, size derinden ilham verdiğim ve sizi cesur yeni bir web tasarımı dünyasına cesaretlendirmeye teşvik ettiğim kısım. Ama dürüst olmak gerekirse, bu bölümün kapanışını özetlemekte zorlandım.

Biraz düşündükten sonra, bunun süreç üzerine yazmanın hiçbir zaman gerçekten yapılmamasından kaynaklandığına inanıyorum.

Umarım bu kelimeleri okudukça, web'in nasıl çalıştığına dair kendi anlayışınıza yatırım yapmak için daha fazla ilham almış ve takım arkadaşlarınızın anlayışına yatırım yapmaya daha istekli olmuşsunuzdur. Umarım yeni bir yaklaşım denemekten heyecan duymuşsunuzdur, ancak umarım işinize yaramazsa bu sayfaları yırtıp atacak gücü de hissetmişsinizdir. Bir projeye yaklaşmanın en iyi yolunu yalnızca siz, ekibiniz ve müşteriniz bulabilir. Yaptığımız işin doğası bu.

Şimdi zamanı - öyleyse, başla!