Teknik Bir İş Akışı Hareketli Grafiklerle Nasıl Anlatılır?

“Message received” ifadesinin yanında yeşil bir onay işareti beliriyor. Bir an sonra aynı işaret “Order complete” ifadesinin yanında görünüyor. Animasyon kendi içinde tutarlı görünüyor. Ancak anlattığı sistem öyle olmayabilir.

Bir isteği almak, kalıcı olarak kaydetmek, işlemek ve bir iş operasyonunu tamamlamak farklı olaylardır. Teknik animasyon, özellikle iş akışı brifinde “basit ve sorunsuz” bir anlatım istendiğinde, bunları güven veren tek bir harekette birleştirebilir. Ortaya çıkan film daha kolay izlenirken sistemin yanlış bir modelini öğretebilir.

Amaç, izleyicinin kararlarını etkileyen ayrımları koruyarak açıklamayı sadeleştirmektir. Bir entegrasyonu değerlendiren geliştirici, yanıtın neyi doğruladığını bilmelidir. İş akışını izleyen alıcı, hangi adımların otomatik olduğunu ve hangilerinin insan müdahalesi gerektirdiğini anlamalıdır. Destek ekibi de sürecin nerede durabileceğini bilmelidir.

Hareketin buradaki gücü, neden-sonuç ilişkisini görünür kılmasıdır. Bu yüzden sonuçları da önemlidir. Okların sırası, durumun değiştiği an ve hareket eden nesnenin kimliği, sistemin nasıl çalıştığına ilişkin birer iddiaya dönüşür. Bu kararları, metindeki teknik terimlere gösterdiğiniz özenle ele alın.

Mimariyi seçmeden önce soruyu seçin

Eksiksiz bir mimari diyagramı nadiren iyi bir açılış sahnesi olur. İzleyicinin henüz sormadığı soruları, henüz yorumlayamadığı ayrımlarla yanıtlayabilir. Önce açıklamanın hangi kararı desteklemesi gerektiğini belirleyin.

Bir mesajlaşma iş akışında soru şu olabilir: “Yayıncı, alındı onayı aldığında neyi bilir?” Belge iş akışında: “Dosya ne zaman inceleyen kişi için hazırdır?” Ödeme iş akışında ise: “Hangi durum, müşterinin işleminin gerçekten tamamlandığını doğrular?”

İlgili sistem sınırını soru belirler. Yayıncıya verilen onayı anlatan bir film, depolama ve teslim ilişkilerini gerektirebilir; ancak bütün dahili yönlendirme bileşenlerini göstermek zorunda değildir. Bir onay devrini anlatan film, teknik ekip servisler arası iletişime odaklanmayı tercih etse bile insanın verdiği kararı içermelidir.

Hedef kitleyi de belirtin. Kavramsal bir genel bakış, entegrasyon eğitiminden daha az uygulama ayrıntısı kullanabilir. Bu, yanlış neden-sonuç ilişkilerini kabul edilebilir kılmaz. Yalnızca yanıtın anlamını korumak için ne kadar ayrıntı gerektiğini değiştirir. Daha küçük bir model, tanımlanan kapsamı içinde kesin olabilir.

“Onaylandı” ifadesinde neyin onaylandığını belirtmenin gerçek bir örneği

Google Cloud’un Pub/Sub mimarisi açıklaması, yayıncıya verilen alındı onayıyla abonenin verdiği işleme onayını birbirinden ayırır. Açıklanan mesaj yaşam döngüsünde kalıcı kayıt, yayıncıya verilen onayın dayanağıdır; abonenin onayı ise işlemeyle ilgilidir. Kaynak ayrıca teslimin, tümüyle sıralı bir görsel zinciri zorunlu kılmak yerine depolama çalışmalarıyla eş zamanlı ilerlediğini anlatır.

Bu ayrımlar yararlı bir tasarım problemi yaratır. Animasyonun ortasında beliren genel bir “Başarılı” işareti, hangi olayın başarılı olduğunu izleyiciye söylemez. Bir onay okunun hem yönü hem anlamı olmalıdır. Yapımcı, izleyiciye servisin isteği almasının mı, abonenin işlemesinin mi, yoksa uygulamada daha sonraki bir sonucun mu gösterildiğine karar vermelidir.

Bu ders mesajlaşmanın ötesinde de geçerlidir. “Yüklendi”, “doğrulandı”, “onaylandı” ve “yayımlandı” da farklı durumlardır. Hepsini aynı simge temsil ettiğinde izleyici, ürünün neyi garanti ettiğini tahmin etmek zorunda kalır. Açık bir teknik anlatı, değişen olayı adlandırır ve görsel güven duygusunun anlamsal kesinliğin yerini almasına izin vermez.

Teknik iş akışı boyunca tek bir nesneyi izleyin

İzleyicinin baştan sona tanıyabileceği bir nesne seçin. Bu; A mesajı, 1042 numaralı sipariş, bir rapor veya tasarım revizyonu olabilir. Konumu ve durumu değişse de korunan sabit bir kimlik verin.

Kurgusal bir rapor işleme servisi düşünün. Kullanıcı rapor isteği gönderir; servis kabul eder; bir işleyici raporu oluşturur; tamamlanan dosya kullanıma açılır. Bu olaylar boyunca “Rapor A”yı izlemek, her sahnede farklı ve genel bir dikdörtgenin belirmesini izlemekten daha kolaydır.

Kimlik ve durum ayrı görsel özellikler olmalıdır. Raporun adı aynı kalırken etiketi “Kuyrukta”, “İşleniyor” ve “Hazır” olarak değişir. Durumu renkle belirtiyorsanız metin etiketini de koruyun. Mavi bir isteğin, aradaki bağı gösteren bir ipucu olmadan yeşil dosyayla değiştirilmesi, aynı işin ilerlemesi yerine yeni bir nesne oluşmuş gibi görünebilir.

Nesneyi uygulama ayrıntılarıyla doldurmayın. Küçük bir tanımlayıcı, veri yükünün tamamını göstermeden süreklilik sağlayabilir. Alanları yalnızca değerleri açıklamayı etkiliyorsa ekleyin. Örneğin yinelenen isteklerin nasıl ele alındığını anlatırken açık bir istek kimliği önemlidir; işleyicinin rolüne genel bir bakışta ise gerekmeyebilir.

Anlatım metninden önce durum değişikliklerini yazın

Her olayın ne anlama geldiğini gösteren kısa bir model oluşturun. Rapor örneğinde “Kabul edildi”, servisin belirtilen koşullar altında isteği ele almayı üstlendiği anlamına gelir. “İşleniyor”, bir işleyicinin çalışmaya başladığını gösterir. “Hazır”, çıktının mevcut olduğu ve gösterilen yoldan erişilebildiği anlamındadır.

Her etiketi doğruladığı koşulla eşleştirin. Gerçek bir üretim sisteminde, çağıran tarafın bundan sonra güvenle ne yapabileceği de dahil olmak üzere belgelenmiş durum tanımlarını kullanın.

Her değişiklik için öncesinde neyin doğru olması gerektiğini ve sonrasında neyin doğru hale geldiğini sorun. Bu, eksik adımları açığa çıkarır. Animasyon doğrudan “Gönderildi” durumundan “Hazır” durumuna geçiyorsa aradaki çalışma bilinçli olarak mı kısaltılmıştır, yoksa ürün gerçekten anında hazır bir dosya mı döndürür? Kısa bir açıklama, yavaş bir sahne eklemeden kısaltmayı açıkça belirtebilir.

Hareketin üslubuna geçmeden önce teknik bir inceleyenden bu durum modelini doğrulamasını isteyin. Yanlış bir garantiyi birkaç cümlede saptamak; aynı hata anlatıma, oklara, açıklamalara ve ses efektlerine yayıldıktan sonra saptamaktan daha verimlidir. Anlamı erken düzeltmek, yapımın geri kalanını korur.

Rapor servisi için uygulamalı bir akış

Rapor servisinde beş katılımcı vardır: isteği gönderen, kabul eden servis, kuyruk, işleyici ve sonuç alanı.

Kuyruktaki durum görünürken isteği gönderenin aldığı yanıtı da görünür tutun. Böylece kişi, yeni etiketin önceki garantinin yerini sessizce aldığını varsaymak yerine iki gerçeği aynı anda görebilir. İşleyici başladığında, bağlantısız bir dosya simgesi üretmek yerine aynı rapor tanımlayıcısını hareket ettirin.

Hata dalı, tamamlanmış “Hazır” durumundan değil, “İşleniyor” durumundan başlar. Böylece inceleyen kişi, kurtarmanın başka bir deneme mi, başka bir istek mi, yoksa aynı iş operasyonu mu ürettiğini sorabilir. Kurtarma yeni bir deneme oluşturabiliyorsa operasyonu ve denemeyi ayrı ayrı adlandırın.

Gerçek bir mesajlaşma sisteminde onayı abonenin kodunun verdiğini unutmayın. Bu sinyal, dış sistemlerdeki bütün iş etkilerinin başarıyla gerçekleştiğini kanıtlayan bağımsız bir denetim değildir. Animasyon, onayın tanımlanmış rolünü anlatmalı ve bunu daha geniş bir başarı garantisine dönüştürmemelidir.

Sıralamayla eş zamanlılığı ayırın

Soldan sağa bir düzen ilerlemeyi, öğelerin birer birer belirmesi ise bağımlılığı çağrıştırır. Bu gelenekler, eş zamanlı davranışı uydurma bir seri sürece dönüştürene kadar yararlıdır.

Bir sistemin olayı kaydettiğini ve bağımsız iki tüketiciye bildirdiğini varsayın. Basit bir animasyon, koreografisi daha kolay olduğu için ikinci tüketiciyi başlatmadan önce birincinin bitmesini bekleyebilir. İzleyici, ikincinin birinciye bağlı olduğunu düşünebilir. Gerçekte böyle bir bağımlılık yoksa görsel sıra, mimariye ilişkin bir iddia eklemiştir.

Eş zamanlı çalışmayı ekranı karmaşaya boğmadan anlatabilirsiniz. Ortak tetikleyiciyi belirleyin, dalların birlikte başlayabilecek hale geldiğini gösterin; ardından biri görünür kalırken diğerine odaklanın. “Bunlar birbirinden bağımsız ilerleyebilir” gibi bir ifade, başlangıç ve bitiş anlarının aynı olduğunu iddia etmeden ilişkiyi açıklayabilir.

Tersine, bir adım gerçekten diğerini gerektiriyorsa yalnızca hareket katmak için paralel hareket göstermeyin. Yayımlamayı koşula bağlayan bir doğrulama kararı, o koşulla görünür biçimde ilişkili kalmalıdır. Okların birlikte hareket edip etmemesi yalnızca bir üslup tercihi değil, açıklamanın parçasıdır.

Teknik anlamı ok etiketlerine taşıtın

Servisler arasındaki bir çizgi kendi kendini açıklamaz. İstek, yanıt, olay, onay, bağımlılık veya izin gösterebilir. Bu altı ilişkinin hepsinde aynı animasyonu kullanmak görüntüyü düzenli, anlamını ise belirsiz kılar.

Seçtiğiniz soruyla ilgili ilişkileri etiketleyin. Rapor örneğinde “İstek gönder”, “Kabul edildi” ve “Rapor hazır” ifadelerinin tümü, farklı yönlere giden etiketsiz noktalarla temsil edilmemelidir. Etiketler, yönün neden değiştiğini ve gönderenin sonrasında ne bildiğini izleyiciye anlatır.

Sınırlı bir görsel sözlük seçin. Kesintisiz bir ok ana istek yolunu, farklı biçimde etiketlenmiş bir dönüş yolu ise onayı temsil edebilir. Hangi sözlüğü seçerseniz seçin, tutarlı kullanın ve bilinmeyen kuralları açıklayın. Renk ayrımı güçlendirebilir, ancak anlamı taşıyan tek unsur olmamalıdır.

Okların uçlarını doğru yere bağlayın. Bir grubun sınırında biten çizgi, olayın grubun tamamına ulaştığını ima edebilir. Belirli bir işleyicide biten çizgi daha özel bir alıcıyı işaret eder. Otomatik yerleşimin veya dekoratif bir eğrinin, açıklanan ilişkinin kapsamını sessizce değiştirmesine izin vermeyin.

İzleyicinin anlayışını değiştiren tek bir hata gösterin

Kusursuz bir başarılı akış, en önemli soruyu saklayabilir: sonraki adım gerçekleşmezse ne olur? Olası her hatayı canlandırmanız gerekmez. Filmin amacıyla ilgili bir hata seçin.

Rapor servisinde yararlı bir örnek, işleyicinin dosya hazır hale gelmeden hata vermesidir. Yeniden deneme veya kurtarma yolu değerlendirilirken istek tamamlanmamış kalabilir. Görselin anlatması gereken, “Kabul edildi” ifadesinin “Hazır” anlamına gelmediğidir. Bu ayrım, açıklanmayan yeşil bir duruma dönüşüp kaybolan genel bir kırmızı uyarıdan daha yararlıdır.

Gerçek sistemin belgelenmiş bir yeniden deneme politikası varsa yalnızca bu politikanın desteklediği davranışı gösterin. Hikâyeyi güven verici kılıyor diye otomatik yeniden deneme uydurmayın. Manuel bir kurtarma adımı gayet makul olabilir; izleyicinin onun varlığını bilmesi gerekir. Benzer şekilde, tanımlanmış davranış bu değilse zaman aşımı otomatik olarak kalıcı hataya dönüşmemelidir.

Hata dalındaki nesneyi başarılı akışla tutarlı tutun. Yinelenen istek, yeniden yapılan deneme ve özgün iş operasyonu ilişkili olabilir; ancak mutlaka aynı şey değildir. Açıklama bu ayrıma dayanıyorsa bütün durumları kapsamak için döngülü bir ok kullanmak yerine ayrımı açıkça adlandırın.

Öğretim süresini sistem süresinden ayırın

Animasyon, anlaşılabilmesi için milisaniyelik bir olayı yavaşlatabilir veya uzun bir arka plan işini kısa bir sahneye sıkıştırabilir. İkisi de meşru editoryal tercihler olabilir. Sorun, film bu tercihleri ölçülmüş performans gibi gösterdiğinde ortaya çıkar.

Görünür bir saat iddiayı değiştirir. Sayaç “0.3 seconds” diyorsa izleyici haklı olarak bunun bir ölçüm dayanağı olmasını bekler. Ölçüm yapılmadıysa sayıyı kaldırın veya akışın temsili olduğunu belirtin. Hoş ve hızlı bir geçiş, düşük gecikmenin kanıtı değildir.

Gerçekten ölçülmüş bir gösterimde ortamı, girdileri, başlangıç olayını ve bitiş olayını kaydedin. “İsteğin kabul edilmesine kadar geçen süre” ile “raporun hazır olmasına kadar geçen süre” farklı ölçümlerdir. İlkini gösterip ikincisini ima etmek, kronometrenin kendisi doğru olsa bile yanıltıcıdır.

Öğretici ritmi, altta yatan iddiadan bağımsız tutun. Neredeyse anında tamamlanan bir olaya ait etiketi okumak için izleyicinin iki saniyeye ihtiyacı olabilir. Bu, okumaya ilişkin bir karardır. Metin, hareketi okunamayacak gerçek dünya hızında oynatmaya zorlamadan gerçek zaman ilişkisini açıklayabilir.

Ürün durumları için ekran görüntüsü, görünmeyen davranışlar için diyagram kullanın

Gerçek bir arayüz, kullanıcının belirli bir anda ne gördüğünü kanıtlayabilir. Diyagram ise doğrudan görünmeyen süreçleri açıklayabilir. Biri diğerinin yerine geçiyormuş gibi davranmamalıdır.

Ürün “Queued” durumunu gösteriyorsa güvenle yeniden oluşturabildiğinizde bu durumu kaydedin. Hikâyenin kullanıcıya görünen kısmını ekran görüntüsüne dayandırın. Ardından işleyiciyi veya mesajlaşma davranışını anlatmak için açıkça açıklama amacı taşıyan bir diyagrama geçin. Gerçek tamamlanmış duruma geri dönmek, modelle deneyim arasındaki bağı tamamlar.

Arayüzle süreç diyagramını görsel olarak ayırt edin. İzleyicinin görünen durumu arkasındaki çalışmayla ilişkilendirebilmesi için geçiş boyunca aynı rapor tanımlayıcısını koruyun.

Düzenlenebilir bir hareket projesinde diyagram etiketlerinin, ekran görüntülerinin ve durum tanımlarının aynı onaylanmış açıklamaya dayanmasını sağlayın. Sonradan yapılan bir terminoloji değişikliği üçünü de kapsamalıdır. Aksi halde arayüz “Ready”, anlatım ise “Delivered” diyebilir ve inceleme sırasında çözülen bir ayrım istemeden yeniden ortaya çıkabilir.

Düzenli güncellenen bir seride bu tanımları düzenlenebilir projenin yanında tutun. Gelecekteki editör, etiket değişikliğinin yalnızca sözcükleri mi, yoksa verilen garantiyi mi değiştirdiğini anlayabilmelidir. Bu küçük ayrım, kozmetik bir revizyonun kabul edilmiş isteği tamamlanmış iş iddiasına dönüştürmesini önler.

Önce zihinsel modeli, sonra dışa aktarılan filmi inceleyin

İnceleyen kişiye her onayın neyi doğruladığını, nelerin bağımsız gerçekleşebildiğini ve operasyonun nerede tamamlanmamış kalabileceğini sorun. Bu sorular animasyonun amaçlanan davranışı öğretip öğretmediğini sınar. Genel bir anlaşılırlık değerlendirmesinden daha çok şey ortaya çıkarırlar.

Ardından dışa aktarılan filmde görsel çelişkiler arayın. Başarı simgesi, koşulu gerçekleşmeden mi beliriyor? Bir dal, iptal edilmiş gibi görünecek kadar erken mi kayboluyor? Geçiş sırasında etiket yanlış nesneye mi bağlı kalıyor? Özgün sahne planı doğru olsa bile bunlar render veya kurgu hataları olabilir.

Karmaşık iş akışları için son bir sabit görseli veya kısa bir eşlik eden açıklamayı erişilebilir tutun. Animasyon hikâyeyi kurduktan sonra izleyici ilişkileri kendi hızında yeniden incelemek isteyebilir. Film daha büyük bir sistemde bilerek tek bir yolu izliyorsa bu referans özellikle değerlidir.

Ortaya çıkan sonuç, kişinin ürün hakkında akıl yürütebilmek için kullanabileceği bir model olmalıdır. Ne olduğunu, henüz ne olmadığını ve bir sonraki durumu hangi kanıtın doğrulayacağını bilmelidir. Teknik bir açıklayıcı, yalnızca oklar akıcı hareket ettiğinde değil, sadeleştirmesi bu sorular karşısında geçerliliğini koruduğunda ikna edicidir.