Devrime Karşı Evrim: Sınırlı kaynaklarla bir tasarım sistemi uygulamak
TL;DR Özeti
- Çoğu (çoğu?) dijital ürün ekibi, tasarım merkezli liderliğe ve/veya büyük bir ürün yeniden tasarımından geçmek (veya kapsamlı bir şekilde yeni bir tasarım sistemi uygulamak) için gerekli kaynaklara sahip değildir.
- Bununla birlikte, bu kuruluşlardaki tasarımcıların ortak bir hatası, sistemdeki büyük değişikliği temsil eden "ideal", istek uyandıran kalıplar tasarlamaktır: yani, sistemi en iyi şekilde geliştirecek bir sistem yerine, "hadi aklımıza gelen en iyi sistemi tasarlayalım" . var olan ürün.
- Benim tercih ettiğim yaklaşım daha az "devrim", daha çok "evrim"dir: Sistemi mevcut ürünün köklerinden büyüterek (devrim niteliğindeki değişimi zorlamak yerine), daha tutarlı, öngörülebilir, kullanıcı dostu bir kullanıcı deneyimini çok daha hızlı elde edeceksiniz. .
Şirketlerin tasarım değişikliğini kolaylaştırmak için sınırlı kaynakları var
Airbnb ve Apple gibi kuruluşlar , ürüne yönelik önce tasarım yaklaşımının güzel deneyimlere ve hatta bazen ticari başarıya yol açabileceğini bize gösterdi! MailChimp ve Google gibi şirketler ( Material Design'ın lansmanıyla birlikte ), kapsamlı pozitif tasarım değişikliğine doğru rota düzeltme konusunda takdire şayan bir iş çıkardılar.
Tasarım ekipleri genellikle tasarım sistemleri hakkında konuşurken akıllarında şu şirketler vardır: " [ürünümüz] için bir Materyal Tasarıma ihtiyacımız var!" Çok heyecan verici şeyler, ancak bu, sınırlı, yüksek talep gören mühendislik kaynaklarına sahip ve halihazırda yüklü bir birikime sahip bir ekip için zor bir iş: iyi tasarlanmış bir ürüne sahip olmayı çok isterler, ancak önce [X, Y, ve Z projeleri]… muhtemelen tasarım değişikliklerinden daha net "ROI" hikayelerine sahip olan projeler.
Tanıdık geliyor mu? Özellikle çalışmayı tercih ettiğim erken ve orta aşama organizasyonlarda bana öyle geliyor.
Yani sınırlı bir Mühendislik "bütçesi" ile çalışan bir tasarımcısınız. Ürününüz için harika fikirleriniz ve uygulamaya can attığınız yeni modeller, davranışlar ve estetikler var. Ancak bugün geri adım atıp tüm ürününüze baktığınızda, bu konuda şöyle hissediyorsunuz:
İşte burada: zamanla kardeş sayfalar, akışlar ve diğer ürün dallarıyla birleştirilen büyük, temel kullanıcı deneyimleriniz var. Bunlar, çeşitli tasarım yönergelerine sahip çeşitli ürün çalışanları tarafından aylar veya yıllar boyunca inşa edildi. Bu özelliklerden bazıları muhtemelen MVP çözümleri olarak oluşturulmuştur — "Müşterilerimizin buna şimdi ihtiyacı var! 'Tasarım'ı daha sonra ekleyeceğiz” ve o zamandan beri dokunulmadı. Tüm bunlar, kullanıcı ve iş için en iyi niyetlerle inşa edildi, ancak bir tasarım sistemi olarak, bir fare yuvası deneyimiyle uğraşıyor olabilirsiniz.
Peki, ürün tasarımcısı olarak bu şeyi nasıl şekillendirirsiniz?
Devrim: Tasarım nirvanasına tek seferde ulaşmak
Yaşasın devrim! Sketch'te Apple Thunderbolt ekranınızın önünde otururken, bu kolayca yakalanabileceğiniz bir duygusal tuzaktır: “Keşke sıfırdan başlayabilseydim, bu ürünü şarkı söyletebilseydim! ”. Ancak bunu gerçekten uygulamayı nasıl planlıyorsunuz? Muhtemelen şöyle bir şey:
Harika bir iş çıkardınız: Mükemmel tasarım sisteminizi elde ettiniz! Bir tasarım sistemi uygulamak için bu yaklaşımı parçalayalım.
Artıları
- Ürününüz artık hayallerimizdeki tasarıma sahip! BÜYÜLEYİCİ!
- Odadaki aynı tasarımcılarla her şeyi aynı anda tasarladınız, bu nedenle hepsi süper uyumlu ve düşünceli. ÇOK İYİ GELİYOR!
- Bu… hemen hemen asla bu şekilde yürümez.
- Tonlarca kaynağın uzun bir süre boyunca tahsis edilmesi gerekiyordu.
- Bu, bir boşlukta tasarlandı (iyi araştırılmış olsun ya da olmasın), bu nedenle, gerçek kullanıcılar onu kullanmaya başladığında kaçınılmaz olarak keşfedeceğiniz bazı gerçek dünya zorluklarını dikkate almıyor.
- Son olarak (ama belki de çoğunlukla ), kullanıcılarınız/müşterileriniz, ürününüzün eski berbat sürümünü aylarca veya yıllarca kullanmak zorunda kaldılar , ancak bu yeni şeyi piyasaya sürdüğünüzde ürün tasarımında ani ve büyük bir değişiklikle karşı karşıya kaldılar.
"Kuzey Yıldızı" modeli: her seferinde bir harika sinyalle ürün tasarımı nirvanasına ulaşmak
Yani, ekibiniz ideal ürün deneyimini tasarlıyor, ancak tek taraflı bir tasarım devrimi için gereken kaynaklara sahip olmadığınız ortaya çıktı. Bunu hayal et! Ama artık bu harika kalıpları, davranışları ve kuralları tasarladığımıza göre, her halükarda ürün sayfaları ve özellikleri üzerinde çalışırken bunları fırsatçı bir şekilde uygulamaya başlayalım. İşte hiçbir şey yok:
Pekala, burada biraz hareket var ve bu sürecin sonunda ürünümüzde gerçekten güzel deneyimler elde ettik (hala yanımızda biraz bagaj taşıyor olsak bile).
Artıları
- Ürününüzde parça parça da olsa tasarım hayallerinizin gerçekleştiğini görün.
- Tam Tasarım Devrimi'nden çok daha gerçekçi.
- Uzak bir gelecekte (ve bu yıllar boyunca aynı tasarım tercihlerini korumayı başardıysanız), ürünün geri kalanının şekillendiğini görebilirsiniz. Belki.
- Daha dramatik değişiklikler, değişiklik başına daha fazla kaynak gerektirir (uç vakaları, teknik kısıtlamaları vb. açtıkça), bu nedenle değişim hızı, eski veya daha ihtiyatlı bir şekilde değiştirilmiş kalıpları kullandığınız duruma göre daha yavaştır.
- Sonunda harika bir tasarım elde ettiniz, ancak bu projenin geçiş aşamalarına bakın: Kullanıcılarınız ve müşterileriniz , deneyim ve stilin ekrandan ekrana önemli ölçüde değişebildiği bu gerçekten yamalı ürünü aylarca veya yıllarca kullandı. Gerçekten de çalışmanızın bundan yıllar sonra nihayet meyve vermesi için mi tasarlıyorsunuz ? Öyle düşünmedim.
- Ürününüzün çoğunluğu bu yeni sisteme geçtiğinde, siz (ve tasarım topluluğunun geri kalanı) muhtemelen neyin iyi, yaygın ve hatta modaya uygun olarak kabul edilen kullanıcı arayüzü tasarımı açısından değiştiniz. Bütün bunlar işe yarıyor ve siz hala birkaç yıllık bir tasarıma (bu doğru, “yeni tasarımınız”) takılıp kalıyorsunuz.
Tarz ve davranış açısından bunlar çok farklıdır , bu nedenle, kullanıcı deneyiminizin bölümlerini yavaş yavaş taşıyorsanız, ürününüz genelinde önemli ölçüde farklı biçimler ve girdiler sunulur. Parça parça dramatik tasarım değişiklikleri yapma konusunda daha büyük bir sorunu temsil eden küçük bir örnek.
Ama umut var! Sahip olduklarınızın üzerine inşa edilen bir sistem tasarlayarak zorlu, baştan savma tasarım değişikliklerinden kaçınabilirsiniz. Hatta ürününüzü bugün bulunduğu yerden “geliştirmeniz” gerektiği bile söylenebilir…
Bu Evrim Bebeğim : sahip olduklarınızın değerini anlayarak daha iyi bir ürüne daha hızlı ulaşmak
Sınırlı Mühendislik bütçesine sahip bir tasarım ekibi için, tasarım sisteminizi, ürününüzün hâlihazırda yaptıklarından en iyi şekilde yararlanarak ve bunun üzerine inşa ederek oluşturmanızı (veya geliştirmenizi) öneririm. Küçük bir başlangıç ekibindeki ilk tasarımcı olsanız bile, birisi (tasarımcı, ürün lideri veya geliştirici) bu UI kararlarını gerçek nedenlerle vermeyi seçti . Adımlarınız, ürününüzün mevcut durumuna bağlı olarak değişecektir, ancak süreç şöyle başlar:
- Mevcut tasarım sisteminiz hakkında bilgi edinin (varsa) : bileşenler nereden geliyor? Kuruluşunuzda bir yerde temel stiller sayfası veya kitaplık var mı? Bunlar nasıl organize ediliyor? Kim inşa etti? En çok kimler kullanıyor ve hangi kısımlarını kullanıyorlar? Onsuz ne zaman araziye çıkmak zorunda kalacaklar?
- Ürününüzde gördüğünüz kalıpları ve davranışları envanterleyin : kullanıcılara farklı türde bilgileri nasıl sunarsınız? Kullanıcılar görmek istediklerini nasıl seçerler? Bilgileri nasıl giriyorlar? Arayüz öğeleri için: sekmeler, kartlar, listeler veya formlar görüyor musunuz? Her element hangi durumlarda ortaya çıkıyor?
- Ürününüzün takip ediyor gibi göründüğü kuralları yazın ; sonra kuralları kendiniz sıkılaştırın: tüm tasarım borcunun arkasında bir yerlerde, ürününüzün nasıl bir araya getirildiğine dair bir mantık var. Ürününüzün takip ediyor göründüğü tasarım kurallarını anlayın ve ardından bu kuralları ikiye katlayın. " Tabloları pek çok şey için kullanıyor gibiyiz, buna kullanıcıların neyle etkileşim kuracaklarını seçmeleri gerektiği zamanlar da dahil, " belki de bir kurala dönüşüyor: " kullanıcıların ilgili ancak bağımsız öğeler arasında seçim yapmasına izin vermek için tablo satırları kullanıyoruz ."
- Ekip(ler)inizden fikir birliği alın: değerlendirmenizi ve planınızı iletin. Fikir birliği oluşturmayı söylemek yapmaktan daha kolaydır, ancak bu sistemi mevcut üründen oluşturmuş olmanız , bu konuşmayı ve geçişi yepyeni kalıplar ve kurallar oluşturmanıza göre daha kolay hale getirecektir. Elbette bu paydaşların çoğu, ürünün bugün nasıl göründüğüne de katkıda bulunuyordu, bu nedenle bu yol, rollerine ve mevcut tasarımlarda işlenen tüm organizasyonel bilgilere daha saygılıdır.
- Bu sistemle oluşturmaya başlayın: Artık hangi kuralların ve kalıpların kullanılacağını bildiğinize göre, bu kalıpları belirleyin ve kuralları izlemeye başlayın! Mühendisleriniz bir dahaki sefere bir tablo, kart, form vb. koyarken, bunun belirtilen öğe olduğundan ve onu doğru şekilde kullandıklarından emin olun. Zamanla, arayüzünüzün daha fazlası bu yeni tasarım sistemini kullanacak, ancak arayüzün eski bölümleriyle nispeten iyi uyum sağlamalıdır.
Artıları
- ÇOK YEŞİL . Yeni sistemi mevcut kalıplardan gevşek bir şekilde temel alarak, daha hızlı "iyi" hale gelirsiniz.
- "İyi deneyimler", "eski deneyimler" ile nispeten iyi bir şekilde karışarak daha sorunsuz bir deneyim sağlar - evet, o zorlu geçiş ayları ve/veya yıllarında bile.
- Daha az dramatik değişiklik, yeni bileşenlerinizi ve kalıplarınızı daha hızlı uygulayabileceğiniz anlamına gelir. Daha sonra hepsi sisteme bağlandıklarında, bunları sistem düzeyinde değiştirebilir ve güncelleyebilirsiniz: bu, Jones'un kapı komşusuna (yani rakiplerinize) daha sonra, kaçınılmaz olarak ulaştıklarında ayak uydurabilme olasılığınızı artırır. kendilerine ait yeni bir kullanıcı arayüzü.
- Daha az dramatik değişiklik, kullanıcının bakış açısına göre de iyi olabilir : kullanıcılar bir şekilde değişiklikten hoşlanmazlar (şimdiye kadarki her Facebook yeniden tasarımına veya en sevdiğiniz B2B aracının büyük ölçekli yeniden tasarımına bakın), bu nedenle büyük sıçramalardan kaçınmak, sizinle olan ilişkinizdeki tümsekleri azaltabilir. kullanıcılar/müşteriler.
- Bu, daha az kaynak yoğundur ve organik organizasyonunuz için daha doğaldır. "Devrim" ve dev yönetici inisiyatiflerinin aksine, bu, ekibin iyi niyetini daha iyi koruyabilir. İyi bir tasarım yapmayı gerçekten zor bir işmiş gibi hissettirmek yerine doğru hissettirir.
- Hiçbiri!
- Şaka yapıyorum. Gördüğünüz gibi, bu modelde aslında tasarım nirvanasının “ideal” aşamasına gelmedik. Daha muhafazakar “Evrim” modeli bize iyi tasarımı daha hızlı ve daha kolay sağladı, ama belki de başka türlü sahip olabileceğimiz bazı 'büyük fikir' fırsatlarını benimsemedik.
- Bazen, küçük çalışmak ve "büyük bir vizyon" planlamamak, daha sonra tasarım sistemi evriminizde bazı bağımlılıkları ve/veya fırsatları kaçırmanıza neden olabilir. Bunu hafifletmenin yolları var - örneğin, "bebek adımlarını atmak" dışında bir tür vizyona sahip olmak - ki buna daha sonra daha ayrıntılı bir gönderide değineceğim.
- Bazen ürününüzdeki "eski" ürün tasarımı gerçekten çok kötüdür, dolayısıyla iyi bir başlangıç noktası bile olmayabilir. (Bu, izlenmesi gereken cezbedici bir zihinsel yoldur, ancak sizi bunu yapmaktan caydırırım: çoğu durumda, orta derecede başarılı bir ürün üzerinde çalışıyorsanız, tercih edin ya da etmeyin, eski tasarımdaki bir şey iyi çalışıyor demektir. ).
İşiniz, müşterilerinizin ve kullanıcılarınızın ürününüzle yaşadıkları deneyimleri iyileştirmektir. Her küçük tasarımda ay için ateş ederseniz ve ardından bu değişiklikleri gerçeğe dönüştürmek için bir grup Mühendislik kaynağını yakarsanız, bu kaynakları yetersiz bir şekilde "harcaıyor" ve böylece kullanıcılarınız için diğer şeyleri geliştirmek için yapabileceğiniz iş miktarını sınırlıyor olabilirsiniz. . Bir kullanıcı akışını mükemmel yapmak, üç kullanıcı akışını iyi yapmaktan daha mı iyidir ? Belki sizin için, ama muhtemelen kullanıcılarınız için değil.
Tasarım sisteminizde daha gerçekçi davranarak - onu mevcut temellerden inşa ederek ve geçiş dostu tutarak - yeni bir sistemi daha hızlı benimseyebilirsiniz ve siz (ve kullanıcılarınız) avantajlardan yararlanmaya başlayabilirsiniz.
Öyleyse ilerleyin ve Evrim yapın!
Güncelleme (bir yıl kadar sonra)
Hired için üzerinde çalıştığım bu tasarım sistemi hakkında başka bir yazı yazdım — bir yıl önce bu "Evolution" parçasına ilham veren aynı proje.
Bir tasarım sistemi oluşturmaktan elde edilen zaferler, kayıplar ve derslerBu projeden bazı dersler alarak "Kuzey Yıldızı benzeri" bir yaklaşım konusundaki pozisyonumu biraz yumuşattım, ancak bu yazının temel kiracıları hala geçerli: Çoğu durumda, Evrim hala kullanıcılarınız, ürününüz için sorumlu yaklaşımdır. ve kuruluşunuz.