Ayarlar Sayfası Sorunu

Ayarlar sayfası, ürününüzdeki en dürüst ekrandır. Tek kaydırmada, ekibin hangi kararları vermeyi reddettiğini gösterir. Her anahtar fosilleşmiş bir tartışmadır. Her iç içe sekme, kimsenin çözmediği bir "sonra hallederiz"dir.

Çoğu ayarlar sayfası çöplüktür. Hayır diyemeyen mühendislerin, opt-out isteyen pazarlamacıların ve "karar ver" yerine "yapılandırılabilir olsun" diyen PM'lerin üç yıl boyunca döktüğü anahtarlar. Sonuç, ekibin demo yapmaktan utandığı ve kullanıcının dokunmaya korktuğu bir ekran.

Bu yazı, ayarları birinci sınıf bir ürün yüzeyi olarak ele almanın savunması. Beş arketip, altı kural, zaten kullandığınız ürünlerden gerçek örnekler ve yayına çıkmadan önce çalıştırmanız gereken bir denetim.

Ayarlar, ekibi ele veren ekrandır

Ayar yayılması, kurumsal işlev bozukluğunun öncü bir göstergesidir. Ekip bir varsayılan üzerinde anlaşamadığında anahtar yayına çıkar. Bir müşteri şikayet ettiğinde ve kimse karşı çıkmak istemediğinde anahtar yayına çıkar. PM iki akış arasında karar veremediğinde ikisi de bir ayarın arkasında yayına çıkar.

Altı ay sonra anahtarların yarısının neden var olduğunu kimse hatırlamaz. Bir ayarı kaldırmak, ekibin ilk seferde kaçındığı kararın aynısını gerektirir, bu yüzden ayarlar birikir. Üç yıldan uzun süredir yayında olan herhangi bir ürüne bakın, ayar ağacında verilmemiş kararları sayabilirsiniz.

Kötü ayarlar sayfalarının beş arketipi

Kötü ayarlar sayfaları rastgele değildir. Beş kalıba ayrılırlar ve her biri belirli bir kurumsal tembellik türünün varış noktasıdır.

1. Çöplük

Kronolojik birikim. Ayarlar eklendikleri sırayla görünür, asla gruplanmaz. En yeni feature flag, 2019'dan kalma bir bildirim tercihinin yanında, iki yıl önce mezun olması gereken bir beta anahtarının yanında durur. Cursor buna doğru kayıyor. Her sürüm Genel sekmesine üç anahtar ekliyor ve Genel sekmesi artık birbiriyle ilgisiz kararlardan oluşan 40 satırlık bir kaydırma. Çöplük, kimsenin aktif olarak tasarlamadığı her ayarlar sayfasının varsayılan halidir.

2. Elektronik Tablo

Alfabetik tercihler. Ekip hiyerarşiden vazgeçmiş ve sıralamayı işletim sistemine bırakmış. Her anahtar aynı ağırlıkta, her satır aynı. Slack'in bildirim tercihleri burada yaşar. Ses, rozet, mobil, kanal, anahtar kelime, rahatsız etme, program, özel, hepsi hangisinin önemli olduğu hakkında hiçbir hikâye anlatmayan bir duvara yayılmış.

3. Çıkmaz Sokak

Görünür hiçbir şeyi değiştirmeyen ayarlar. Kullanıcı "Kompakt mod"u açar ve ekran aynı görünür. "Gelişmiş özellikleri etkinleştir"i açar ve hiçbir şey belirmez. Apple'ın macOS'taki Sistem Ayarları yeniden tasarımı bu türden bir nesil ürettiydi: başka ayarlar tarafından sessizce geçersiz kılınan ayarlar, ekranın asla bahsetmediği yeniden başlatma gerektiren ayarlar. Çıkmaz Sokak kullanıcılara ayarların işe yaramadığını öğretir ve ürünün geri kalanına da güvenmeyi bırakırlar.

4. Labirent

On seviye iç içe sekme. Ayarlar bir kategorinin, bir alt kategorinin, bir "Gelişmiş" açılımının, bir modalın altına gömülmüş. Kullanıcı anahtarın var olduğunu biliyor, daha önce çevirmiş ve hâlâ bulamıyor. Eski Jira kariyerini bunun üzerine kurdu: proje, pano, iş akışı, şema, izin şeması, bildirim şeması, hepsi ayrı ağaçlar.

5. Müze

Üç yıldır kimsenin dokunmadığı ayarlar. Kaldırmak riskli hissettirdiği için dururlar. 2023'te kapatılan özelliklere atıf yaparlar. Her eski SaaS ürününün bir Müze kanadı vardır ve bedeli, ekibin iki refactor önce öldürülmesi gereken kod yollarını sürdürme sözüdür.

Ayarlar bir ürün yüzeyidir, bir dolap değil

Çoğu ekip ayarları, ürünün geri kalanındaki dağınıklığın toplandığı yer olarak görür. Hata tam da bu çerçeve. Ayarlar ürünün en yüksek kaldıraçlı yüzeylerinden biridir ve en güçlü ekipler onu öyle tasarlar.

Ayarlar, ürünün kullanıcı hakkındaki dünya görüşünü ifade eder. Aynı anda dört şey iletir. Ekibin kullanıcıya ne kadar güvendiğini. Ekibin ne kadar kontrol paylaşmaya istekli olduğunu. Ekibin doğru varsayılanların ne olduğunu düşündüğünü. Ve ekibin, varsayılanları değiştiren %5'i için tasarım yapacak, değiştirmeyen %95'i cezalandırmayacak kadar kullanıcının zamanına saygı duyup duymadığını.

Linear ayarları tek bir arama yüzeyi olarak tasarladı, command-K ile yönetilen, neredeyse hiç iç içe sekme yok. Örtük mesaj: kullanıcı yetkin, arama hızlı, hiyerarşi işini ekip yaptı ki kullanıcı yapmak zorunda kalmasın. Notion ters yöne gitti ve aynı şekilde kazandı. Ayarlar etkiledikleri şeyin yanında yaşar. Sayfa ayarları sayfada. Veritabanı ayarları veritabanında. Bağlamsal ayarlar işin içinde kaybolur.

Vercel kapsamlı hiyerarşi kullanır: proje, takım ve hesap, her biri net etiketli, her biri yönettiği kaynağa kapsamlı. Stripe Dashboard eylem odaklı gider, her ekran "şunu yap" der, "şu tercihi yapılandır" demez. GitHub'ın repo ayarları kapsamı, repo, organizasyon ve hesap sahipliği arasındaki temiz ayrımla ustaca çözer.

Her ayarlar sayfasına karar veren altı kural

Bu kurallar birbirini katlar. Altıdan beşini tutturun, sayfa bir ürün yüzeyi gibi okunur. Üçünü tutturun, bir yıl içinde arketiplerden birine kayar.

Kural 1: Önce arama

Hiyerarşi bir yedektir, birincil değil. Kullanıcı bir ayarın adını, hangi sekmede olduğundan önce bilir. Linear'ın command-K'sı ayarları birinci sınıf bir sonuç türü olarak kapsar. Figma ayar aramasını ekledi ve anahtara ulaşma süresi anında düştü. Ayarlar sayfanızda arama çubuğu yoksa, kullanıcıların bilgi mimarinizi ezberleyeceğine bahse giriyorsunuz demektir. Ezberlemeyecekler.

Kural 2: Merkezi kayıt yerine bağlamsal yerleşim

Ayarlar etkiledikleri şeyin yanında yaşar. Bildirim ayarları bildirim panelinde. Sayfa ayarları sayfada. Merkezi bir ayarlar sayfası profil, faturalama ve oturumlar gibi hesap düzeyindeki konular için uygundur ve neredeyse başka hiçbir şey için değil. Notion altın standarttır. Figma'nın sağ paneli, katman, çerçeve ve bileşen özellikleri için aynı işi yapar.

Kural 3: Güven kazanan mantıklı varsayılanlar

Her varsayılan bir ürün kararıdır. Ekibin kullanıcıların %80'i için doğru cevap olduğuna inandığı şeyi ifade eder. Varsayılan yanlışsa anahtar bir yara bandıdır. Slack'in bildirim varsayılanları, sessiz değil, ulaşılabilir olmak istediğinizi varsayar. Bu bahis medyan kullanıcı için doğru. Çoğu ekip önce anahtarı tasarlar ve varsayılanın kendiliğinden çıkmasına izin verir. Bu sıra yanlış.

Kural 4: Düz yayılma yerine kademeli açılım

Kullanıcı, kullanıcıların %90'ının umursadığı beş ayarı görmeli. Diğer 50'si bir tık daha derinde, net bir "Gelişmiş" işaretinin arkasında durmalı. Vercel'in proje ayarları bunu çok iyi yapar. İlk ekran alan adını, ortam değişkenlerini ve dağıtım korumasını öne çıkarır. Build geçersiz kılmaları, fonksiyon yapılandırmaları ve rewrite'lar Gelişmiş'te yaşar.

Kural 5: Yetim yok

Her ayar bir gruba aittir. Her grubun bir adı vardır. Yetim testi: herhangi bir etiketi başka bağlam olmadan yüksek sesle okuyun. Ekibinizdeki bir tasarımcı anahtarın ne yaptığını söyleyemiyorsa, o bir yetimdir. Yetimler Müze'nin fidanlarıdır.

Kural 6: Her ayar yerini hak eder

Bir ayar bir sözleşmedir. Ekip onu sürdürmeyi, belgelemeyi, test etmeyi ve diğer tüm ayarlarla etkileşimlerini sonsuza dek düşünmeyi taahhüt eder. Çoğu ayar bu kirayı ödeyemez. Her yeni ayar için varsayılan tavır "hayır" olmalı. İyi ekipler yayınladıklarından fazla ayar öldürür.

Daha derin bir sorunun işareti olan anti-kalıplar

Üç kalıp, geri kalanın toplamından fazla ayarlar sayfasını öldürür. Her biri, sorunun ekran değil, arkasındaki ekip olduğunun belirtisidir.

Ürün kararlarının yerine geçen ayarlar. Ekip opt-in ya da opt-out üzerinde anlaşamadı, bu yüzden bir anahtar olarak yayına çıktı. Kullanıcı çözülmemiş tartışmayı miras alır. Stand-up'ta "yapılandırılabilir yapalım" duyuyorsanız, bu anti-kalıbın oluşumunu izliyorsunuz. Daha derin okuma bilerek sürtünme tasarlamak yazısında.

Kötü tasarımı telafi eden ayarlar. Varsayılan yoğunluk fazla gevşek olduğu için bir "kompakt mod" anahtarı. Marka renkleri erişilebilirlikte başarısız olduğu için bir "yüksek kontrast" anahtarı. Yeniden tasarım reddedildiği için bir "klasik görünüm" anahtarı. Her biri seçenek kılığına girmiş gerçek bir düzeltme. Çözüm, yoğunluğu, kontrastı ve görünümleri ilk seferde doğru tasarlamaktır.

Kimsenin tek cümleyle açıklayamadığı ayarlar. Bir tasarımcı ayarın ne yaptığını, çevrilince neyin değiştiğini ve kimin için olduğunu tarif edemiyorsa, ayar yayına çıkmamalı. Bu testi, herhangi bir yeni anahtar kod tabanına girmeden önce yapın.

Ayarlar sayfası denetimi

Her ayarlar sayfasını şu yedi sorudan geçirin. Altısında kendinden emin bir evet çıkmıyorsa sayfa bitmemiştir.

1. Kullanıcı herhangi bir ayarı beş saniyenin altında bulabilir mi? Hayırsa, sayfada arama eksik ya da hiyerarşi bozuk.
2. Her ayarın, mühendis olmayan birinin anlayacağı tek cümlelik bir açıklaması var mı? Etiketi açıklamak için bir mühendis gerekiyorsa, ürün yüzeyine ait değildir.
3. Anahtarı çevirmek görünür, anında bir etki yaratıyor mu? Gizli durum değişiklikleri güven katilleridir.
4. Ayarlar özellik ekibine göre değil, kullanıcı görevine göre mi gruplanmış? Özelliğin hangi ekibe ait olduğuna göre düzenlenmiş bir sayfa, ürüne sızan dahili bir artefakttır. Kullanıcı hedefine göre gruplayın.
5. Varsayılanlar bir yerde yazılı olarak savunuluyor mu? Ekip bir dokümanı, bir görsel hiyerarşi kararını ya da bir marka ilkesini gösterebilmeli. Varsayılan "mühendisin sprint sırasında ne ayarladıysa o" ise sayfa bitmemiştir.
6. Ayarların yarısını kullanıcı fark etmeden kaldırabilir misiniz? Evetse, yapın. Müze, ekibin düşündüğünden daha ağır.
7. Sayfa, ürünün geri kalanı gibi görünüyor ve hissettiriyor mu? Landing page tasarım ilkeleri ile yan yana okuyun. Marka dağılıyorsa, ayarlar sayfası marka dışıdır.

Bu denetimi yılda iki kez yapan bir ekip, kullanıcıların tepki vermediği bir ayarlar yüzeyi çıkarır. Hiç yapmayan ekip ise rakibe işe alım aracı olacak türden bir ayarlar sayfası çıkarır.

Önce ilkeyi seçin, sonra sayfayı budayın

Ayarlar, anahtarlara donmuş ekip dünya görüşüdür. İyi ekipler sayfayı birinci sınıf bir akış olarak ele alır, onboarding'e, dashboard'a ve pazarlama sitesine getirdikleri aynı işçilikle.

Bir ayarlar sayfasını düzeltmenin en hızlı yolu yeniden tasarlamak değil. Yarısını silmek. Yetim testinde, tek cümle testinde ve yerini hak etme testinde başarısız olan her ayarı kaldırın. Geriye kalan, gerçek bir ayarlar yüzeyinin omurgasıdır.

Boş durumlarla bağlantı tesadüf değil. İki ekran da, dikkati dağıtacak başka hiçbir şey ekranda yokken ekibin neye inandığını ortaya koyar. Aynı disiplin web tasarım ilkelerinde de görünür.

Sıkça sorulan sorular

Bir ürünün kaç ayarı olmalı?

Mümkün olduğunca az. Her ayar, ekibin sonsuza dek sürdürdüğü bir sözleşmedir. Her yeni ayar için varsayılan tavır "hayır" olmalı. Ekip ayarı tek cümleyle savunamıyorsa, hizmet ettiği kullanıcıyı adlandıramıyorsa ve çevrilince görünür şekilde neyin değiştiğini anlatamıyorsa, ayar yayına çıkmamalı.

Ayarlar üründe nerede yaşamalı?

Etkiledikleri şeyin yanında, merkezi bir ayarlar kanadında değil. Sayfa ayarları sayfada. Çalışma alanı ayarları çalışma alanında. Bildirim ayarları bildirim panelinde. Merkezi bir ayarlar sayfası faturalama, profil ve oturumlar gibi hesap düzeyindeki konular için uygundur ve neredeyse başka hiçbir şey için değil.

Yıllardır biriken anahtarlarla dolu bir ayarlar sayfasını nasıl temizlerim?

Denetimi çalıştırın, sonra silin. Her ayarı kullanıcı görevine göre gruplayın. Yetimleri, çıkmaz sokakları ve müze parçalarını belirleyin. İlk turda alttaki %30'u kaldırın ve destek taleplerini izleyin. Kimse şikayet etmezse bir %20 daha kaldırın.

Ayarlar sayfasını ana sayfa gibi tasarlayın

Ayarlar sayfası bir bodrum değil. İleri düzey kullanıcılarınızın yaşadığı ve yeni kullanıcılarınızın sizi yargıladığı bir oda. Ona ana sayfa, onboarding ve dashboard gibi davranın. Aynı işçiliği uygulayın. Aynı inançla yayına çıkarın.

Ayarlar sayfasını backlog'dan miras almak yerine ürünün geri kalanı gibi tasarlayan bir ekip istiyorsanız, Brainy'yi tutun. Ayarları birinci sınıf bir akış olarak tasarlıyoruz, sayfayı küçük ve anahtarları kirasını ödeyen halde tutan disiplinle.