Kullanıcı rolleri ve izinleri: uygulamayı inşa etmeden önce planlayın

Önce rolleri neden belirlemelisiniz

Kullanıcı rolleri ve izinleri, tek bir ekran oluşturulmadan önce planlamak çok daha kolaydır.

Başlangıçta herkese aynı erişimi vermek daha hızlı gibi gelebilir. Ancak pratikte bu karar neredeyse hemen sorun yaratır. Bir sahip, bir personel üyesi, bir müşteri ve bir yönetici aynı ekranlara, aynı eylemlere veya aynı verilere ihtiyaç duymaz.

Erişim çok geniş olunca, insanlar işlerine yaramayan şeyleri görür ve bazen kesinlikle görmemeleri gerekenler görünür hale gelir. Bir müşteri iç notları görebilir. Bir personel faturalama ayarlarına erişebilir. Bir sahip raporlar ve kontroller beklerken ön büro çalışanı için kullanılan aynı sade görünüme düşebilir. Hiç gizli bir şey açığa çıkmasa bile, her ekran herkese hizmet etmeye çalıştığı için uygulama dağınık hissedilir.

Bu problem hızla yayılır. Roller menüleri, panoları, formları, onayları, raporları, dışa aktarımları ve saklanan verilerin arkasındaki kuralları etkiler. "Personel siparişleri görüntüleyebilir ama iade yapamaz" gibi küçük görünen bir kural genellikle bir düğmeden çok daha fazlasını değiştirir. İş akışlarını, bildirimleri, kayıtları ve ürün genelindeki düzenleme kurallarını etkileyebilir.

İçine yanlış erişim eklenmişse, sonradan yapılan izin düzeltmeleri nadiren küçüktür. Yanlış erişim kurulduktan sonra sadece ayar değiştirmiyorsunuz; ekranları yeniden tasarlıyor, verileri taşıyor, iş akışlarını tekrar test ediyor ve yeni kuralları eskisini öğrenmiş gerçek kullanıcılara açıklıyorsunuz.

Biraz ön planlama çoğunun önüne geçer. Roller baştan netse, uygulama ilk günden daha temiz bir yapıya sahip olur. Sahipler iş ayarlarına ve üst düzey raporlara ulaşabilir. Personel günlük işleri hesapları değiştirmeden yapar. Müşteriler yalnızca kendi bilgilerini görür. Yönetici erişimi gerçekten ihtiyaç duyan kişilerle sınırlı kalır.

Koder.ai ile inşa ediyorsanız, bu daha da önem kazanır çünkü ilk versiyon sohbetten hızla üretilebilir. Net rol tanımları platforma daha iyi talimat verir, böylece uygulama işin gerçekten ihtiyaç duyduğu şeye daha yakın başlar.

Erken haritalamanız gereken dört rol

Çoğu ilk sürüm için dört rol yeterli olur: sahip, personel, müşteri ve yönetici. Gerekirse daha sonra ayırabilirsiniz, ama buradan başlamak sağlam bir temel verir.

Sahip

Sahip, iş hesabından sorumlu kişidir. Bu rol genellikle faturalamayı, abonelik değişikliklerini, yasal ayarları, sahiplik devrini ve en hassas hesap kararlarını kontrol eder.

Bu rolü erken ve net tanımlayın. "Sahip" belirsiz kalırsa, ekipler işi ilerletmek için bu gücü kazara diğer kullanıcılara verebilir.

Personel

Personel, günlük işleri yürütür. Kayıtları günceller, müşterilere yanıt verir, sipariş oluşturur, durum kontrol eder, içeriği yönetir veya görevleri ilerletir.

İşlerini hızlı yapabilmeleri için yeterli erişime ihtiyaçları vardır, ancak genellikle hesap çapında tüm kontrolleri gerektirmez. Basit bir test şudur: bir hata tüm işletme hesabına zarar verebilecekse, muhtemelen o eylem bir yöneticiye veya sahibe ait olmalıdır.

Müşteri

Müşterilerin en dar görünümü olmalıdır. Çoğu uygulamada, kendi profilleri, rezervasyonları, satın alımları, mesajları veya ilerlemeleri gibi yalnızca kendi verilerini görmelidirler.

Ekiplerin en çok hata yaptığı yer burasıdır. Müşterilerin neleri yapabileceğine karar verirken çok zaman harcarlar ama müşterilerin asla neleri görmemesi gerektiğini tanımlamayı unuturlar.

Yönetici

Yönetici ve sahip genellikle aynı rol gibi muamele görür, ama her zaman aynı değildirler.

Yönetici genellikle uygulama içindeki operasyonları yönetir. Bu, personel eklemek, izinleri sıfırlamak, etkinliği gözden geçirmek veya destek konularını ele almak gibi işleri içerebilir. Pek çok üründe yönetici faturalama, sahiplik devri veya en hassas iş ayarlarını kontrol etmemelidir.

Dört rolü ayırmanın basit bir yolu şöyledir:

• Sahip iş hesabını kontrol eder.
• Yönetici iç operasyonları yönetir.
• Personel günlük işleri yapar.
• Müşteri hizmeti kullanır.

Bu temel ayrım sonraki kararları çok daha kolaylaştırır.

Görünürlük ve eylemler farklı şeylerdir

Rol sadece bir etiket değildir. İki ayrı soruyu yanıtlar:

1. Bu kişi neyi görebilir?
2. Gördükten sonra ne yapabilir?

Bunlar aynı şey değildir.

Bir personel üyesi müşteri siparişlerini görüntüleyebilir ama silemez. Bir yönetici iadeleri onaylarken, müşteri sadece iade talep edebilir. Görünürlük ve eylem hakları karışırsa, insanlar ya işlerinden engellenir ya da sahip olmamaları gereken erişimi kazanır.

Çoğu uygulama izinleri küçük bir eylem setiyle tanımlayabilir: görüntüle, oluştur, düzenle, sil, onayla ve bazen dışa aktar. Bu eylemler basit görünür ama ekran ve veriye göre değişir.

Bir kişi kendi profilini düzenleyebilir ama şirket faturalamasını düzenleyemez. Bir destek bileti oluşturabilir ama indirim onaylayamaz. Bir siparişi ödeme alınmadan önce güncelleyebilir, sonrasında güncelleyemez.

Hesap ayarlarını iş verilerinden ayırmak da yardımcı olur. Hesap ayarları genellikle şifreler, profiller, bildirimler, faturalama, ekip üyeleri ve giriş güvenliğini içerir. İş verileri ise siparişler, projeler, faturalar, mesajlar, randevular veya stok gibi uygulama içindeki günlük bilgileridir.

Bu ayrım önemlidir çünkü "düzenleme erişimi" her iki durumda çok farklı şeyler anlar. Telefon numaranızı düzenlemek bordroyu, müşteri kayıtlarını veya sistem kurallarını düzenlemekle aynı değildir.

Basit bir izin haritası oluşturun

İyi bir izin haritası gerçek işlemlerle başlar, iş unvanlarıyla değil.

Ekranları veya veritabanlarını oluşturmadan önce, uygulamada insanların her gün yapması gereken ana şeyleri yazın. Eylemler üzerinden düşünün: bir sipariş oluşturmak, iade onaylamak, müşteri kaydını güncellemek, raporları görüntülemek, fatura ayarlarını değiştirmek. Bu, izin planlamasını tahmine değil, gerçek kullanıma bağlar.

Basit bir süreç genellikle iyi çalışır:

1. Ana iş akışlarını sade dille listeleyin.
2. Her iş akışını adımlara bölün.
3. Her adımda kimlerin görüntüleyebileceğini, oluşturabileceğini, düzenleyebileceğini, onaylayabileceğini, silebileceğini veya dışa aktarabileceğini işaretleyin.
4. "Personel siparişleri düzenleyebilir ama ödeme alındıktan sonra düzenleyemez" gibi istisnaları not edin.

Üç ila beş iş akışıyla başlayın. Küçük bir işletme için bu, bir müşteriyi kaydetme, ödeme alma, destek yönetme ve performans kontrol etme olabilir. Sonra her iş akışında ana kararları kim veriyor diye sorun.

Bunlar netleşince, ekran ekran ilerleyin. Her sayfa için iki soru sorun: bunu kim görebilir ve burada ne yapabilirler?

Bir pano hem sahip hem personel tarafından görülebilir ama sadece sahip gelir toplamlarını görür. Bir müşteri profili sayfası müşterilerin kendi iletişim bilgilerini düzenlemesine izin verirken personel sadece görüntüleyebilir. Bir iade ekranı destek personeli tarafından görülebilir, ama onay yine bir yöneticinin sorumluluğunda olabilir.

Burada bir rol matrisi de yararlı hale gelir. Çok şatafatlı olmasına gerek yok. Hangi rolün ürünün hangi bölümünde hangi eylemi yapabildiğini gösteren basit bir tablo veya kısa bir belge yeterlidir.

Koder.ai kullanıyorsanız, bu adım size çok daha iyi istemler (prompts) verir. "Bir yönetici paneli oluştur" belirsizdir. "Sahip planları ve iadeleri yönetebilir, personel hesapları görüntüleyip biletlere cevap verebilir, müşteriler yalnızca kendi profillerini ve siparişlerini düzenleyebilir" gibi cümleler sisteme somut bir şey verir.

Her şeyi kesinleştirmeden önce haritayı birkaç gerçek senaryoyla test edin. Bir personelin bir siparişi iade etmesi, bir müşterinin adres değiştirmesi veya bir sahibin aylık satışları incelemesi gibi basit görevleri deneyin. Herhangi bir adım belirsiz hissediyorsa, izinler hâlâ çok muğlaktır.

Örnek: bir salon rezervasyon uygulaması

Küçük bir salon rezervasyon uygulaması iyi bir örnektir çünkü ürün basit görünür ama kimin neye erişmesi gerektiğine bakınca işler karmaşıklaşır.

Maya sahip. İşin tam görünümüne ihtiyaç duyar: rezervasyonlar, personel takvimleri, müşteri geçmişi, hizmet fiyatları ve satış toplamları. Personel ekleyip çıkarabilir, çalışma saatlerini güncelleyebilir, tatil bloklayabilir, iadeler verebilir ve erişim kurallarını değiştirebilir.

Leo bir stilist. Günlük işinde ona yardımcı olanları görmeli. Sadece kendi randevularını, temel müşteri notlarını ve yapabileceği hizmetleri görmeli. Bir randevuyu tamamlandı olarak işaretleyebilir, ziyaret sonrası not ekleyebilir ve Maya'nın belirlediği kurallar çerçevesinde rezervasyonu taşıyabilir.

Fiyatları değiştirememeli, tam iş raporlarını görememeli, diğer personel takvimlerini düzenleyememeli veya müşterileri sistemden kaldıramamalıdır. Bunlar sahip eylemleri, günlük iş eylemleri değildir.

Nina müşteri. Görünümü en basit olmalı. Açık bir zamanı rezerve edebilir, yaklaşan randevuları görebilir, geçmiş ziyaretleri inceleyebilir ve kesme süresinden önce kendi rezervasyonunu değiştirebilir veya iptal edebilir. Telefon numarasını veya e-postasını güncelleyebilir ama diğer müşterileri, iç notları veya sadece personele ait takvim ayrıntılarını göremez.

Bu uygulamada yönetici rolü hâlâ bulunabilir, ama farklı bir amaç için hizmet eder. Yönetici hesap kurtarma, faturalama sorunları veya güvenlik ayarlarıyla ilgilenebilir. Bu rol salonu yönetmekle aynı değildir.

İşte bu yüzden "sahip, personel, müşteri ve yönetici erişimi"yi inşa etmeden önce haritalamak önemlidir. Herkes ortak bir rezervasyon ekranından başlarsa, personel gizli gelir verilerini görebilir veya müşteriler asla dokunmamaları gereken ayarlara ulaşabilir. Bunu sonradan düzeltmek ekranları, kuralları ve testleri yeniden yapmak demektir; oysa tek bir erken planlama kararıyla önlenebilir.

Yeniden çalışmaya yol açan hatalar

Çoğu izin problemi kestirmelerle başlar.

İlk yaygın hata çok erken aşamada çok fazla erişim vermektir. Sadece personel araçlarına ihtiyaç duyan biri, kurulum sırasında işleri kolaylaştırmak için tam yönetici yetkisi alır. Bu bir süre iş görür, sonra ayarları gizlemek, verileri kilitlemek ve doğru rol için ekranları yeniden oluşturmak gerektiğinde temizleme işi ortaya çıkar.

İkinci hata tüm personel üyelerini aynı görmek. Gerçekte, bir satış temsilcisi, destek ajanı, depo çalışanı ve finans sorumlusu genellikle aynı araçlara ihtiyaç duymaz. Hepsi tek bir geniş "personel" rolünü paylaşıyorsa, uygulama hızla kafa karıştırıcı olur. İnsanlar kullanmamaları gereken düğmeleri görür ve basit görevler riskli hale gelir.

Üçüncü hata uç durumları görmezden gelmektir. Ekipler siparişleri görüntüleme veya profilleri güncelleme gibi yaygın eylemleri planlar ama iadeler, dışa aktarımlar, hesap kapatma, abonelik kurtarma veya kayıt silme gibi hassas eylemleri unuturlar. Bu eylemler genellikle daha sıkı kurallar, onay adımları veya kim ne yaptı kaydı gerektirir.

Dördüncü hata özel iç verileri müşteriyle görünen verilerle karıştırmaktır. Destek notları, dolandırıcılık bayrakları veya faturalama yorumları müşteri görebildiği alanların yanında duruyorsa, eninde sonunda biri yanlış şeyi açığa çıkarır. Bu olduğunda sadece bir ekranı düzeltmiyorsunuz; veri modelini de değiştirmeniz gerekebilir.

Bir diğer maliyetli alışkanlık ekranları önce inşa edip erişimi sonra belirlemektir. Arayüz ilk demoda iyi görünebilir, ama gerçek roller tanımlandığında bozulmaya başlar. Bir yönetici için çalışan bir pano personel veya müşteriler için farklı menü, farklı etiketler ve daha az eylem gerektirebilir.

İşte ekiplerin izinleri iki kez yeniden çalışmasına yol açan süreç: bir kez ilk inşa sonrası, bir kez gerçek kullanıcılar test etmeye başlayınca.

Bir şey üretmeden önce hızlı bir kontrol

İnşa etmeden önce durup birkaç sade soruyu yanıtlayın. Bu kısa gözden geçirme, sonrası yeniden çalışmasını önlemeye yardımcı olur.

• Her rol ana görevini birkaç adımda tamamlayabiliyor mu?
• Hassas veriler yanlış kullanıcılardan gizli mi?
• Onay eylemleri doğru kişide mi?
• Yeni bir ekip üyesi rolleri kolayca anlayabilir mi?
• Birisi rolü değiştirince veya ekipten ayrılınca ne oluyor?

Bu sorular sorunları erken yakalar.

Örneğin, bir personel üye mağaza yöneticisi olduğunda artık indirimleri onaylayabilir ve ekip takvimlerini görebilir. Bu, otomatik olarak faturalama ayarlarını veya tüm müşteri verilerini dışa aktarma yetkisi vermemelidir. Bir rol değişikliği gerekli yeni erişimi sağlamalı ve artık gerekmeyen erişimi kaldırmalıdır.

Bu aynı zamanda garip senaryoları kontrol etmek için doğru zamandır. Askıya alınmış bir kullanıcı hala neyi görebilir? Bir yönetici personel seviyesine düşürüldüğünde ne olur? Değişiklikten sonra eski veriler görünür kalıyor mu?

Bu soruları sade dille yanıtlayabiliyorsanız, kullanıcı rolleri ve izin planınız muhtemelen hazırdır. Yanıtlayamıyorsanız, değişiklikler hâlâ ucuzken rol haritasını şimdi düzeltin.

Planı kısa bir brife dönüştürün

Roller netleşince, ekibin bir iki dakikada anlayabileceği kısa bir belgeye dönüştürün. Resmi olması gerekmiyor. Sadece spesifik olmalı.

Her rol için neyi görebileceklerini, neyi değiştirebileceklerini ve asla dokunmamaları gerekenleri yazın. Pratik tutun. Bir sahip faturalamayı ve raporları görebilir. Personel siparişleri ve müşteri kayıtlarını güncelleyebilir. Müşteriler yalnızca kendi hesaplarını görüntüleyebilir. Yöneticiler kullanıcıları ve ayarları yönetebilir ama sahiplik kontrollerini devralmamalıdır.

Kısa bir brief genellikle dört şeyi kapsar:

• Uygulamadaki roller
• Her rolün alabileceği ana eylemler
• Her rolün görüntüleyebileceği veya düzenleyebileceği veriler
• Ek sınırlama gerektiren hassas alanlar

Bu brief'i ekranları, iş akışlarını ve veri kurallarını üretirken kullanın. İnşa sürecine baştan güvenlik şeritleri sağlar.

Koder.ai'de bu daha da önemlidir çünkü sohbetten web, sunucu ve mobil uygulamalar oluşturabilirsiniz. Üretim hızlı olduğundan, net bir izin brifi ilk versiyonun ekibin gerçekten ihtiyaç duyduğuna daha yakın çıkmasını sağlar.

İlerlemeden önce, her rol için bir gerçek senaryo kullanarak ilk versiyonu gözden geçirin. Sahip, personel, müşteri ve yönetici olarak oturum açın. Bir ortak görevi tamamlayın, hangi verilerin göründüğünü kontrol edin ve engellenmesi gereken bir eylemi deneyin.

Bu basit kontrol, planlamada kolay kaçırılan ve sonradan düzeltmesi pahalı olabilecek sorunları yakalar. Net bir rol haritası, tek sayfalık bir brief ve her rol için hızlı bir test genellikle çoğu erişim hatasını yeniden tasarıma dönüşmeden önce önler.