Adlandırma kuralları, ekipler büyüdükçe oluşturulan uygulamaların anlaşılır kalmasına yardımcı olur. Durumları, rolleri ve eylemleri daha kolay istemler ve devretmeler için nasıl adlandıracağınızı öğrenin.
Adlandırma sorunları nadiren büyük bir kararla başlar. Küçük kestirmelerle başlar.
Bir ekranda "Açık" yazar, bir düğme "Başlat" der ve başka bir istem daha sonra "Aktif" öğeleri ister. Üçü aynı duruma işaret ediyor olabilir, ama şimdi uygulama bunları farklı fikirler gibi ele alıyor. İlk başta zararsız görünen şey, ekip ve kullanıcılar için kafa karışıklığına dönüşüyor.
Bu durum sohbet tabanlı ürünlerde sık görülür çünkü insanlar zaman içinde aynı şeyi biraz farklı şekilde tanımlar. Pazartesi bir kurucu bir role "yönetici" der. Çarşamba bir ekip üyesi "admin" görünümü ister. Bir hafta sonra biri "takım lideri" ekler. Kimse bir etiket seçmek için durmazsa, uygulama bir kavramı birkaç sürüme böler.
Hasar iki yerde birden ortaya çıkar. İstemler yazmak zorlaşır çünkü oluşturucu her zaman iki kelimenin aynı anlama gelip gelmediğini anlayamaz. Ekranlar kullanımı zorlaştırır çünkü benzer eylemler, durumlar veya izinler için farklı etiketler görünür.
Küçük ekipler bunu ilk hisseder. Bir kişi hâlâ "onaylandı", "yayınlandı" ve "canlı" kelimelerinin eşleştiğini hatırlayabilir. Yeni bir ekip üyesi hatırlamaz. Her kelimenin ne anlama geldiğini, nerede göründüğünü ve bir etiketi değiştirmenin diğerlerini de değiştirip değiştirmemesi gerektiğini tahmin etmek zorunda kalır.
Desen tanıdıktır. Bir özellik hızlıca adlandırılır ki iş ilerlesin. Sonra istemler farklı ama yakın bir kelime kullanır. Ekranlar, filtreler ve bildirimler her iki terimi göstermeye başlar. Sonra biri bir etiketi günceller ve geri kalanları kaçırır.
Artık basit düzenlemeler gerektiğinden daha uzun sürer. Bir düğmeyi yeniden adlandırma isteği, o düğme metni bir duruma, iş akışı adımına ve rapor filtresine bağlı olduğu için daha büyük bir değişikliğe dönüşür.
Koder.ai gibi ekiplerin doğal dille uygulama şekillendirdiği bir platformda, ifade farkları daha da önem kazanır. Net etiketler, değişiklik isterken istemlerin kaza ile çoğaltılmasını önlemeyi kolaylaştırır.
Uygulama adlandırma kuralları gösterişli olmak için değildir. Kafa karışıklığını yayılmadan durdurur. İsimler tutarlı kaldığında istemler yazmak kolaylaşır, ekran güncellemeleri daha güvenli olur ve devri bellekten daha az bağımlı yapar.
Seçtiğiniz ilk isimler uygulamanızın her yerde tekrar edeceği kelimeler olur: ekranlar, düğmeler, filtreler, bildirimler ve gelecekteki istemler. Bu kelimeler yer yer değişirse, insanlar yavaşlar, daha çok soru sorar ve daha fazla hata yapar.
Kullanıcıların her gün göreceği terimlerle başlayın.
Durumlar erken adlandırılmalı çünkü listelerde, raporlarda ve otomasyonlarda görünürler. Taslak, Aktif ve Kapalı gibi küçük ve net bir etiket seti seçin, sonra her birinin ne anlama geldiğini tanımlayın. Bir kişi Kapalı derken, başka biri Tamamlandı ve üçüncü kişi Bitti derse, uygulama hızla tutarsız hissettirir.
Roller de aynı özeni gerektirir. Admin, Yönetici ve Görüntüleyici açık gibi görünse de ekipler aynı kelimeye farklı izinler atayabilir. Bir uygulamada bir yönetici talepleri onaylarken, başka bir uygulamada aynı rol sadece gözden geçirme yapabilir. İsim, sorumluluğa uymalıdır.
Eylemler de en az bunun kadar önemlidir. Oluştur, Onayla, Ata, Arşivle ve Sil gibi eylemler dikkatle seçilmelidir çünkü kullanıcıların sonraki adımda ne bekleyeceğini belirlerler. Örneğin Arşivle ve Sil, insanlar veriyi kazayla kaybetsin istemiyorsanız asla aynı anlama gelmemelidir.
Çekirdek kayıtlarınızın baştan itibaren sabit isimleri olmalı. Uygulamanızın siparişleri, potansiyel müşteri (lead), hesapları, talepleri, projeleri veya başka bir şeyi takip edip etmediğine karar verin. Aynı kayıt için bir menüde "Müşteri" diğerinde "Hesap" gibi iki kelime kullanmaktan kaçının, ancak gerçekten farklı şeyleri ifade etmiyorlarsa.
Menülerde ve filtrelerde paylaşılan terimler birçok ekibin beklediğinden daha fazla önem taşır. Eğer bir kenar çubuğunda "Açık" yazıyorsa, bir filtrede "Aktif" ve bir gösterge panelinde "Güncel" yazıyorsa kullanıcılar bu etiketlerin eşleşip eşleşmediğini anlamak için zaman kaybeder.
Basit bir erken adlandırma seti genellikle beş şeyi kapsar: durumlar, roller, eylemler, çekirdek kayıtlar ve paylaşılan menü terimleri. Koder.ai gibi istem tabanlı bir araçla inşa ediyorsanız, bu etiketler gelecekteki istemleri de netleştirir. Modelin yorumlaması gereken terim sayısı azalır, böylece uygulama büyüdükçe daha tutarlı kalır.
Bir adlandırma sisteminin gösterişli olması gerekmez. Sadece net olması yeterlidir.
Temel kural basittir: bir kavram, bir etiket. Bir ekranda "istemci" yazıyor, başka bir ekranda "müşteri" ve daha sonra bir istemde "hesap sahibi" kullanılıyorsa, insanlar kelimelere güvenmeyi bırakır.
Ekibinizin normal konuşmasında zaten kullandığı terimleri seçin. Kısa, tanıdık etiketler hatırlaması ve daha sonra tekrar kullanması daha kolaydır. "Onaylandı" "idari doğrulama yapıldı" gibi ifadelerden daha iyidir. "Yönetici" insanlara açıklama gerektiren bir başlıktan daha iyidir.
Eylem adları açık fiillerle başlamalıdır. Düğmeler ve menü öğeleri, kullanıcıya tam olarak ne olacağını söylediğinde en iyi şekilde çalışır: "Fatura Oluştur", "Hatırlatma Gönder", "Projeyi Arşivle". Bu, oluşturulan uygulama istemlerinde daha da önemlidir; çünkü "İşle" veya "Yönet" gibi belirsiz etiketler daha sonra kafa karıştırıcı güncellemelere yol açar.
Sayı stilinde de tutarlı olun. Tekil mi çoğul mu kullanılacağına karar verin ve ona bağlanın. Ana menü "Siparişler" diyorsa, bir yerde "Sipariş listesi" ve başka yerde "Benim siparişim"e geçmeyin, gerçek bir neden olmadıkça.
Son kural ekiplerin en sık atladığıdır: önemli terimleri düz dilde tanımlayın. Her anahtar kelime için bir kısa satır yazın. Bir lead ne sayılır? Bir öğe ne zaman kapandı sayılır? Bir gözden geçiren ne yapabilir? Yeni bir ekip üyesi tanımı saniyeler içinde anlamalı.
Koder.ai veya başka bir sohbet tabanlı araçla inşa ediyorsanız, bu kurallar istemleri daha stabil hale getirir. Etiketler tutarlı kaldığında, uygulama genişletmesi daha kolay olur ve ekip hangi kelimelerin ne anlama geldiğini açıklamakla daha az vakit harcar.
Adlandırma, ekranlar, iş akışları ve istemler çoğalmadan önce düzeltmesi en kolay olan şeydir. İlk günde basit paylaşılan bir not açın ve uygulamanın çekirdek öğelerine hangi isimleri vereceğinize karar verin. O ilk saat, daha sonra yapılacak temizliğin çoğunu kurtarır.
Kullanıcıların oluşturacağı, görüntüleyeceği veya düzenleyeceği ana öğelerle başlayın. Bir satış uygulamasında bu Lead, Hesap, Anlaşma, Görev ve Fatura olabilir. Her öğe için tek bir ad seçin ve her yerde kullanın: istemlerde, menülerde ve iç notlarda.
Sonra her öğenin alabileceği durumları adlandırın. Bir anlaşma bir ekranda "Açık", başka bir yerde "Aktif" ve bir istemde "İlerliyor" olmamalıdır; bu etiketler farklı anlam taşımıyorsa. Aynı anlama geliyorlarsa, birini seçin ve belgeleyin.
Roller de aynı disiplini gerektirir. İnsanların zaten anladığı sade kelimeleri kullanın: Admin, Yönetici, Temsilci veya Müşteri. Süsleyici başlıklar ilginç gelebilir ama devri zorlaştırır çünkü izinleri açıklamayı güçleştirir.
Eylemler en hızlı şekilde tutarsızlığa yol açan yerdir. Kullanıcıların "oluşturduğunu" mu yoksa "eklediğini" mi, "arşivlediğini" mi yoksa "kapattığını" mı, "atadığını" mı yoksa "gönderdiğini" mi karar verin. Düğme metinleri, menü etiketleri ve istemler aynı fiilleri kullanmalı ki insanlar ne olacağını bilsin.
Basit bir ilk gün kurulumu yeterlidir:
Bu kuralları tüm ekibin görebileceği tek bir yerde tutun. Bir sayfa, öğe adlarını, onaylı durumları, rolleri ve eylem adlarını gösteriyorsa yeterlidir. Koder.ai ile inşa ediyorsanız, bu planlama notlarında ana değişikliklerden önce saklanabilir.
Böylece bir sonraki istem yazmak daha kolay olur, yeni ekip üyesinin tahmini azalır ve uygulama adlandırma çatışmaları olmadan büyür.
Küçük bir ekip iş taleplerini takip etmek için dahili bir uygulama geliştirir. Destek lideri her öğeye "bilet" der. Operasyon yöneticisi aynı şeye "talep" der. Sohbetle uygulamayı şekillendiren kurucu her iki terimi de karıştırır. Kısa sürede ürün ekranlarda, filtrelerde ve bildirimlerde iki terimi de kullanır.
İlk başta zararsız görünür. Sonra ekip basit bir soruyu yanıtlamaya çalışır: "Kaç tane açık biletimiz var?" Başka biri sorar: "İnceleme bekleyen taleplerden mi bahsediyorsun, yoksa beklemedeki tüm işlerden mi?" Bir etiket iki anlama dönüşmüştür.
Aynı şey durumlarla da olur. Bir kişi her bitmemiş şey için Beklemede kullanır. Başka biri yönetici bekleyen öğeler için İncelemede kullanır. Kısa sürede her iki durum da aynı aşama için kullanılmaya başlanır. İnsanlar panoya güvenmeyi bırakır çünkü işin engellendiğini, beklediğini veya gerçekten kontrol edildiğini ayırt edemezler.
Roller de karışır. Bir istemde uygulama Detayları kontrol eden kişi için "Gözden Geçiren" kullanır. Başka bir yerde nihai onay veren için "Onaylayan" kullanır. Ama bu ekipte bir yönetici her iki işi de yapıyordur. Sonra yeni bir ekip üyesi bu rollerin ayrı olduğunu varsayar ve kimsenin gerek duymadığı ekstra adımlar ekler.
Kısa bir adlandırma sayfası bunu çoğu ekipten daha hızlı düzeltir. Parlak olması gerekmez. Sadece ana kelimeleri bir kez basitçe tanımlaması yeterlidir.
Bu isimler belirlendikten sonra gelecekteki istemler daha net olur. "Onay için bir bilet aşaması ekle" demek yerine ekip "Onaylayan doğruladığında talebi İncelemeden Onaylandı'ya taşı" diyebilir. Bu, tahminleri ortadan kaldırır.
Sonraki devretme de kolaylaşır. Yeni bir kişi beş satırı okuyup uygulamanın nasıl çalıştığını anlayabilir.
İyi isimler sonraki istemleri daha kısa ve net yapar. Uygulamanızda durumlar, roller ve eylemler için sabit etiketler varsa, aynı şeyi tekrar tekrar açıklamanıza gerek kalmaz.
İşte adlandırma kurallarının kazandırdığı yer burasıdır. "Onaylanmış talepler için yalnızca yöneticiye özel eylemleri göster" gibi bir istem işe yarar çünkü her kelimenin tek bir açık anlamı vardır.
Bu ortak kelime hazinesi yoksa, istemler çabucak uzar. Sürekli olarak "yönetici derken takım lideri kastediliyor, hesap sahibini değil" veya "onaylandı nihai durum, incelendi değil" gibi ek notlar eklemek zorunda kalırsınız. Bu küçük düzeltmeler işi yavaşlatır ve sistemin yanlış tahmin etme olasılığını artırır.
Net isimler ayrıca ekran yeniden üretilirken yardımcı olur. Uygulama hep Taslak, İncelemede ve Yayınlandı kullanıyorsa, sonraki sürüm muhtemelen bu etiketleri korur. Bir ekranda Beklemede diğerinde Onay bekleniyor yazarsa, oluşturucu bunları farklı durumlar sanıp etrafına yeni şeyler inşa edebilir.
Bir adlandırma sistemi ayrıca düzeltme turlarını azaltır. "Personel"i "Temsilci"ye, "bitti"yi "çözüldü"ye ve "gönder"i "talep gönder"e ayrı ayrı düzeltmek yerine, zaten var olan terimler üzerine inşa edebilirsiniz.
Bu, başka bir kişi devraldığında daha da önem kazanır. Bir ekip üyesi, serbest çalışan veya müşteri etiketleri okuyup uygulamayı daha hızlı anlar. Her ekranın gerçekte ne demek olduğunu uzun uzun açıklamaya gerek kalmaz çünkü isimler işi yapar.
Örneğin bir destek uygulaması Müşteri, Temsilci ve Admin rollerini ve Yeni, Atandı, Müşteri Bekleniyor ve Kapandı durumlarını kullanıyorsa, gösterge panoları, filtreler veya mobil sürüm talepleri tanımlamak çok daha kolay olur. Koder.ai gibi sohbet tabanlı oluşturucularda sabit dil, platformun ne istediğinizi yanlış anlamasını zorlaştırır.
Karışıklık yaratmanın en hızlı yolu bir şeye birkaç isim vermektir. Uygulamanız aynı kayıt için "istemci", "müşteri" ve "hesap" kullanıyorsa, insanlar tahminde bulunmaya başlar. Gelecekteki istemler de daha az güvenilir olur çünkü ekip ve ürün aynı dili konuşmaz.
Bu genellikle zararsız görünen eşanlamlılarla başlar. Bir ekip üyesi "onaylandı", diğeri "kabul edildi" ve üçüncüsü "doğrulandı" yazar. Her etiket tek başına makul görünür ama birlikte filtreleri, raporları ve devretmeleri gereksiz yere zorlaştırırlar.
Bir diğer yaygın hata da iç jargonun üründe kalmasıdır. Bir destek ekibi "bunu ops'a kaydet" veya "tier two'ya gönder" diyebilir, ama kullanıcılar bunun ne demek olduğunu bilmeyebilir. İç kısaltmalar özel notlarda olabilir. Kullanıcıya görünür etiketler sade ve açık olmalı.
Ekipler ayrıca bir etiketi uygulamada güncelleyip eski istemleri, şablonları ve belgeleri unutunca sorun yaşar. Sonra ekran yeni düğme adını gösterirken saklı talimatlar eski ifadeyi kullanmaya devam eder. Birisi istemi takip eder, eylemi bulamaz ve uygulamanın bozuk olduğunu varsayar.
Roller özellikle kolay karışır. "Yönetici" gerçek bir iş unvanı olabilirken "Admin" uygulamada bir izin seviyesidir. Biri kişinin şirketteki konumunu, diğeri sistemde neler yapabileceğini tanımlar. Bu fikirler karıştığında erişim kuralları açıklaması ve bakımı zorlaşır.
Eylem adları da aynı netliği gerektirir. "İşle" gibi bir düğme neredeyse hiçbir şey söylemez. Ne işleniyor ve sonra ne olacak? "Faturayı Onayla", "Lead Ata" veya "Projeyi Arşivle" gibi net fiiller şüpheyi ortadan kaldırır.
Oluşturulan uygulama istemleriyle çalışıyorsanız, her belirsiz veya tutarsız isim daha sonra daha fazla temizlik gerektirir. Bugünkü küçük bir adlandırma hatası, ileride tuhaf ekranlara, karışık istemlere ve önlenebilir ekip sorularına dönüşebilir.
İyi bir adlandırma sistemi neredeyse sıkıcı hissettirmeli. Yeni bir ekip üyesi ürünü açıp birkaç ekran okuduğunda terimlerin anlamını tercüme etmeden anlamalıdır.
Etiketleri kilitlemeden önce birkaç basit soru sorun:
Hızlı bir test yardımcı olur. Etiketlerinizi projeye uzak birine verin ve her durum, rol ve düğmenin ne işe yaradığını açıklamasını isteyin. Yanlış tahmin ediyorsa, isim üzerinde çalışılması gerekir.
Bu, hızlı inşa ederken daha da önemlidir. İstemler, UI etiketleri ve ekip notları aynı kelimeleri kullandığında, gelecekteki değişiklikler istemeyi, gözden geçirmeyi ve göndermeyi kolaylaştırır.
Eğer kontrol listeniz tek bir zayıf etiket buluyorsa, erken düzeltin. Küçük adlandırma boşlukları daha fazla ekran, iş akışı ve ekip eklenince hızla yayılır.
Adlandırma sistemi yalnızca tüm ekip kolayca kullanırsa işe yarar. En kolay sonraki adım kısa bir referans sayfası oluşturmak ve bunu ortak bir kural kitabı gibi tutmaktır. Kurucu, tasarımcı, geliştirici veya operasyon ekip üyesinin iki dakikada okuyabileceği kadar basit olsun.
O sayfa en sık kullanılan kelimeleri kapsamalıdır; özellikle durumlar, roller ve eylemler. Bu terimler her gün istemlerde, ekranlarda, tablolarda ve ekip sohbetlerinde görünür. Bir kişi "onaylandı" yazarken başka biri "kabul edildi" yazarsa, karışıklık küçük başlar ama çabuk yayılır.
İyi bir başlangıç sayfası genellikle onaylı durum adlarını, izinlerle ilgili kısa notlu rol etiketlerini, standart eylem fiillerini ve tekil/çoğul ya da başlık biçimi gibi birkaç stil kuralını içerir. Bir veya iki gerçek örnek de yardımcı olur; özellikle terimlerin bir ekranda veya istemde nasıl kullanıldığını gösteriyorsa.
Sayfa oluşturulduktan sonra yeni özellik eklemeden önce ona bakın. Adlandırma sorunları genellikle ilk inşa sırasında değil, aceleyle yapılan güncellemeler sırasında ortaya çıkar. Yeni bir modül, form veya iş akışı eklemeden önce hızlı bir kontrol, yinelenen terimlerin sızmasını engelleyebilir.
Sayfayı herkesin yeni bir tercih sunduğunda yeniden yazmayın. Bir terimin anlamı gerçekten değiştiğinde veya eski ad gerçek bir karışıklığa neden olduğunda güncelleyin. Sabit adlar, mükemmel adlardan daha önemlidir.
Eğer ekibiniz Koder.ai ile inşa ediyorsa, bu kuralları planlama aşamasında tutmak gelecekteki istemlere daha net bir sözlük sağlar. Bu da uygulamanın büyüdükçe ekranları, rolleri ve akışları tutarlı tutmayı kolaylaştırır.
Uygulama adlandırma kuralları marka çalışması değildir. İstemleri netleştiren, devri kolaylaştıran ve gelecekteki değişiklikleri çok daha az acı verici hale getiren pratik bir alışkanlıktır.
Kullanıcıların en çok göreceği ve kullanacağı kelimelerle başlayın: çekirdek kayıtlar, durumlar, roller, eylemler ve paylaşılan menü terimleri. Bunlar erken net olursa, sonraki ekranlar ve istemler çok daha tutarlı kalır.
Gerçek iş akışını kapsayan küçük bir kümeyle başlayın; genellikle üç ila beş durum yeterlidir. Az ve net durum, ekranlarda, filtrelerde ve otomasyonlarda tutarlılığı korumayı kolaylaştırır.
Her zaman değil. Bir iş unvanı kişinin şirket içindeki rolünü tanımlar; uygulama rolü ise sistemde ne yapabileceğini gösterir. Uygulamadaki yetkileri yansıtan basit rol adları kullanın.
Hayır. Bir kavram için tek bir etiket kullanın. Aynı kayıt için bir yerde "müşteri", başka yerde "istemci" yazıyorsa insanlar bunların farklı şeyler olduğunu varsayar ve istemler daha az güvenilir olur.
Kullanıcıya sonraki adımda ne olacağını kesin olarak söyleyen açık fiiller kullanın: "Faturayı Onayla" veya "Projeyi Arşivle" gibi. "İşle" veya "Yönet" gibi belirsiz etiketler sonucu gizler ve kafa karışıklığı yaratır.
Onaylanmış adlar ve düz tanımlarla kısa, paylaşılan bir sayfa tutun. Ana kayıtlarınızı, durumları, rollerinizi ve eylem fiillerinizi kapsamalı; ekip değişiklik yapmadan önce buraya bakabilmelidir.
Sabit adlar, istemleri kısaltır ve netleştirir çünkü oluşturucu daha az tahmin yapmak zorunda kalır. "Manager", "Approved" ve "Request" gibi terimler tek anlamlıysa, gelecekteki değişiklikleri doğru tarif etmek kolaylaşır.
Öncelikle en etkili terimleri düzeltin: çekirdek kayıtlar, durumlar ve rol adları. Ardından ekranları, istemleri, şablonları ve belgeleri güncelleyerek eski ifadelerin tekrar karışıklık çıkarmasını engelleyin.
Her iki yaklaşım da işe yarar ama bir stil seçin ve tutarlı kalın. Menü "Siparişler" diyorsa, başka yerde gereksiz yere "Sipariş listesi" veya "Benim siparişim" gibi farklı formlar kullanmaktan kaçının.
Etiketleri projede olmayan birine gösterin ve her birinin ne anlama geldiğini sorun. Tereddüt eder veya yanlış tahminde bulunursa, ad muhtemelen çok belirsizdir ve sadeleştirilmeli.
