Web Tasarım Revizyon Süreci Nasıl Yönetilir? Sonsuz Düzeltmeye Son

Web tasarım revizyon süreci, onaylanan tasarımın sınırlı sayıda ve planlı turlarla düzeltildiği aşamadır. Bu rehberde Talha Aslan ve ekibi olarak revizyon turlarını, toplu geri bildirimi, tek karar vericiyi, ekran görüntüsü üzerinde not almayı ve kapsam dışı istekleri nasıl yönettiğimizi anlatıyoruz. Amacımız basit: projeniz sonsuz düzeltme döngüsüne girmeden, takvimi ve bütçesi korunarak yayına çıksın.

Peki bu yapı pratikte neye benzer? Önce kaç tur revizyon hakkınız olduğunu yazılı olarak belirlersiniz. Ardından her turda tüm yorumları tek bir belgede toplarsınız. Son olarak karar verici kişi bu belgeyi onaylar ve ekibe gönderir. Böylece tasarımcı dağınık e-posta, mesaj ve telefon notlarıyla uğraşmaz.

Ayrıca revizyonu "beğenmedim, yeniden yapın" cümlesinden ayırmak gerekir. Revizyon, onaylanmış bir yönün içinde kalan düzeltmedir. Örneğin buton rengini, başlık boyutunu ya da bir görselin yerini değiştirmek revizyondur. Buna karşılık sayfa yapısını tamamen değiştirmek ya da yeni bir bölüm eklemek kapsam meselesidir. Bu ayrımı baştan konuşursanız, ilerleyen haftalarda tartışma yaşamazsınız.

Sonsuz düzeltme döngüsü neden oluşur?

Sonsuz düzeltme döngüsü çoğu zaman tasarımın kötü olmasından değil, sürecin tanımsız olmasından doğar. Saha tecrübemizde en sık gördüğümüz neden, geri bildirimin parça parça gelmesidir. Pazartesi bir yönetici logoyu büyütmek ister, çarşamba başka biri küçültmek ister. Sonuçta tasarımcı iki zıt talimat arasında kalır.

İkinci neden, hedefin yazılı olmamasıdır. Projenin başında neyi çözmeye çalıştığınızı belirlemezseniz, her yorum kişisel zevke dayanır. Bu yüzden "bence daha modern olsun" gibi ölçülemeyen talepler çoğalır. Üçüncü neden ise karar yetkisinin belirsiz olmasıdır; kimin son sözü söylediğini bilmeyen ekip, onayı sürekli erteler.

• Geri bildirim farklı kanallardan ve farklı günlerde gelir.
• Proje hedefi ve hedef kitle yazılı değildir.
• Son onayı verecek kişi belirlenmemiştir.
• Tur sayısı sözleşmede yer almaz.
• Ekip kapsam dışı istekleri revizyon gibi ele alır.

Üstelik bu nedenler birbirini besler. Hedef yazılı olmadığında karar verici de neye dayanarak onay vereceğini bilemez; bu durumda her yeni yorum yeni bir tur doğurur. Dolayısıyla tek bir kuralı düzeltmek yetmez, birkaç basit kuralı birlikte kurmanız gerekir.

Kısacası döngüyü kırmak için daha iyi tasarımcıdan çok daha iyi kurallara ihtiyacınız vardır. Aşağıdaki bölümlerde bu kuralları tek tek ele alıyoruz.

Revizyon ile kapsam dışı istek arasındaki fark nedir?

Revizyon, anlaşılan kapsamın içinde kalan düzeltmedir; kapsam dışı istek ise projeye yeni iş ekleyen taleptir. Bu ayrımı netleştirmezseniz her yeni fikri bedava revizyon sanırsınız. Dolayısıyla takvim kayar ve iki taraf da yorulur.

Aşağıdaki tablo, ekibimizin projelerde kullandığı basit ayrımı gösteriyor. Siz de kendi projenizde aynı mantıkla bir tablo hazırlayabilirsiniz.

Özellikle hata düzeltmeyi revizyondan ayırmak önemlidir. Çünkü mobilde bozulan bir alan sizin tercihiniz değil, ekibin sorumluluğudur. Bu tür düzeltmeler tur hakkınızı tüketmemelidir.

Web tasarım revizyon sürecinde kaç tur olmalı?

Tur sayısı projenin büyüklüğüne göre değişir; yine de çoğu kurumsal sitede her ana aşama için iki ya da üç tur yeterlidir. Bu, saha tecrübemize dayalı bir başlangıç aralığıdır, garanti değildir. Önemli olan sayının kendisi değil, her turun neyi kapsadığının yazılı olmasıdır.

Örneğin ilk tur genel yapıyı ve hiyerarşiyi düzeltir. İkinci turda renk, tipografi ve görsel detaylara bakarsınız. Üçüncü tur ise yalnızca ince ayar ve son kontrol içindir. Böylece her tur bir öncekinden daha dar bir alana bakar.

Öte yandan tur sayısını çok düşük tutmak da risklidir. Tek turda her şeyi bitirmeye çalışan ekip, aceleyle karar verir ve yayından sonra yeni düzeltmeler ister. Bu nedenle biz tur sayısını teklif aşamasında konuşur, sözleşmeye yazarız. Teklifleri karşılaştırırken bu maddeye bakmak için web tasarım teklifi nasıl değerlendirilir yazımıza göz atabilirsiniz.

Ek tur gerekirse ne olur? Bu durumda ek turu ayrı bir iş kalemi olarak planlarsınız. Böylece proje durmaz ve iki taraf da neye onay verdiğini bilir.

Karar verici kim olmalı ve neden tek kişi?

Karar verici, tüm geri bildirimi toplayıp son onayı veren tek kişidir. Bu kişi şirket sahibi, pazarlama müdürü ya da proje sorumlusu olabilir. Önemli olan, ekibin ondan gelen notu nihai talimat olarak kabul etmesidir.

Neden tek kişi? Çünkü birden fazla kişi doğrudan tasarımcıya yazdığında çelişkili talimatlar oluşur. Ayrıca kimse sorumluluk almadığı için herkes onayı sürekli erteler. Tek karar verici ise iç tartışmayı şirket içinde bitirir ve ekibe tek, tutarlı bir liste gönderir.

Bu kişi her şeyi tek başına bilmek zorunda değildir. Tersine, satış, destek ve yönetim ekiplerinden görüş toplar. Ancak bu görüşleri birleştirir, çelişkileri çözer ve öncelik sırasına koyar. Yani karar verici bir filtre görevi görür.

• Karar vericinin adını proje başında yazılı olarak belirleyin.
• Yedek bir kişi atayın; izin ya da yoğunluk dönemlerinde süreç durmasın.
• Diğer paydaşların tasarımcıya doğrudan yazmamasını rica edin.
• Onayın hangi kanaldan verileceğini netleştirin.

Bir de şunu unutmayın: karar verici fikrini değiştirebilir, bu doğaldır. Ancak her değişikliğin gerekçesini yazılı olarak paylaşması, ekibin aynı hatayı tekrar etmemesini sağlar. Örneğin "satış ekibi bu bölümün fazla teknik olduğunu söyledi" gibi tek bir cümle bile tasarımcıya yön verir.

Toplu geri bildirim nasıl toplanır?

Toplu geri bildirim, bir turdaki tüm yorumların tek belgede ve tek seferde iletilmesidir. Bu yöntem tasarımcının bağlamı kaybetmesini önler. Üstelik çelişkili notları teslimden önce görmenizi sağlar.

Pratikte şöyle ilerleyebilirsiniz. Önce taslağı ilgili kişilere bir son tarihle gönderirsiniz. Ardından herkes yorumunu ortak bir belgeye ya da tasarım aracındaki yorum alanına yazar. Son tarih geldiğinde karar verici listeyi okur, tekrar eden maddeleri birleştirir ve çelişkileri çözer. Daha sonra temiz listeyi ekibe iletir.

1. Taslağı paylaşırken bir yorum son tarihi belirleyin.
2. Tüm yorumları tek bir belgede ya da tek bir araçta toplayın.
3. Her yorumu sayfa ve bölüm adıyla etiketleyin.
4. Tekrarlayan ve çelişen maddeleri karar verici ile ayıklayın.
5. Maddeleri "zorunlu" ve "tercih" olarak önceliklendirin.
6. Temiz listeyi tek seferde tasarım ekibine gönderin.

Bu düzen ilk bakışta yavaş görünebilir. Fakat parça parça gelen notlara kıyasla toplam süreyi kısaltır, çünkü tasarımcı her şeyi bir kerede ve tutarlı biçimde uygular.

Ekran görüntüsü üzerinde not almak neden işe yarar?

Ekran görüntüsü üzerinde not, yorumun tam olarak hangi öğeye ait olduğunu gösterir. "Üstteki yazı" gibi belirsiz ifadeler yerine işaretli bir alan görürsünüz. Dolayısıyla yanlış anlaşılma ve gereksiz yazışma azalır.

Örneğin "fiyat bölümündeki boşluk fazla" yazmak yerine ilgili alanı işaretleyip "bu iki blok arasındaki boşluğu azaltın" notunu düşersiniz. Böylece tasarımcı tahmin yürütmez. Ayrıca not, ekran görüntüsüyle birlikte arşivde kalır; sonraki turda neyin istendiğini kolayca hatırlarsınız.

Bu noktada cihaz bilgisini de ekleyin. Masaüstünde düzgün görünen bir alan mobilde farklı davranabilir. Bu yüzden notun yanına cihaz, tarayıcı ve ekran genişliği bilgisini yazmak işinizi kolaylaştırır. Tasarım dosyası üzerinde çalışıyorsanız, aracın kendi yorum özelliğini kullanabilirsiniz. Bu konuda Figma ile web arayüz tasarımı yazımız iş akışını ayrıntılı anlatıyor.

Kısacası görsel not, kelimelerin taşıyamadığı bağlamı taşır. Yorumunuz ne kadar somutsa, düzeltme de o kadar hızlı gelir.

İyi bir geri bildirim notu neye benzer?

İyi bir geri bildirim notu sorunu, nedenini ve beklenen sonucu birlikte söyler. "Bunu beğenmedim" bir duygu bildirir; "ziyaretçi bu butonu fark etmiyor, çünkü arka planla aynı tonda" ise bir sorunu tarif eder. İkinci not, tasarımcıya çözüm alanı bırakır.

Bu yüzden notlarınızı çözüm yerine sorun üzerinden yazmayı deneyin. Örneğin "butonu kırmızı yapın" demek yerine "buton yeterince öne çıkmıyor" diyebilirsiniz. Tasarımcı belki daha iyi bir çözüm önerir: kontrastı artırmak ya da butonu yukarı taşımak gibi.

• Konum: hangi sayfa, hangi bölüm, hangi öğe.
• Sorun: ne görüyorsunuz ve neden rahatsız ediyor.
• Hedef: bu değişiklik hangi proje hedefine hizmet ediyor.
• Öncelik: zorunlu mu, yoksa tercih mi.

Ayrıca olumlu notları da yazın. Neyin iyi çalıştığını bilmek, tasarımcının o kararları korumasını sağlar. Aksi halde bir düzeltme yaparken beğendiğiniz bir detay kaybolabilir. Metinle ilgili yorumlar için içerik ve tasarım uyumu yazımız iyi bir kontrol çerçevesi sunar.

Revizyon turları hangi aşamalara bölünmeli?

Revizyon turlarını tek bir büyük onay yerine aşamalara bölmek, maliyetli geri dönüşleri önler. Her aşama bir öncekinin üzerine oturur. Bu nedenle erken aşamada yaptığınız değişiklik ucuzdur, geç aşamada yaptığınız değişiklik pahalıdır.

Biz genellikle üç ana aşama kullanırız. İlk olarak tel çerçeve (wireframe, yani renksiz yerleşim taslağı) aşamasında sayfa yapısını ve içerik sırasını onaylarsınız. Ardından görsel tasarım aşamasında renk, tipografi ve görsel dili netleştirirsiniz. Son olarak geliştirme aşamasında çalışan site üzerinde işlev ve uyumluluk kontrolü yaparsınız.

Her aşamanın kendi tur hakkı olur. Örneğin tel çerçevede iki tur, görsel tasarımda iki tur, geliştirmede bir tur ince ayar planlayabilirsiniz. Önemli kural şudur: onaylanan bir aşamaya geri dönmek yeni iş anlamına gelir. Yani görsel tasarım onaylandıktan sonra sayfa yapısını değiştirmek isterseniz, bunu ayrı planlarsınız.

Bu aşamaların proje takvimindeki yerini görmek için kurumsal web sitesi tasarımı süreci yazımıza bakabilirsiniz. Orada aşamaların sırasını ve teslimleri genel hatlarıyla anlatıyoruz.

Kapsam dışı istekleri nasıl yönetirsiniz?

Kapsam dışı istekleri reddetmek yerine kayıt altına alıp ayrı planlarsınız. Proje sürerken yeni fikirler gelmesi doğaldır; sorun, bu fikirlerin sessizce mevcut takvime eklenmesidir. Bu yüzden her yeni talebi bir "bekleyen istekler" listesine yazmak işe yarar.

Sonra bu listeyi değerlendirirsiniz. Bazı istekler yayın öncesi zorunludur, bazıları ise yayından sonraki ikinci aşamaya kalabilir. Böylece ana proje zamanında biter ve yeni fikirler kaybolmaz. Ayrıca ek işin süresini ve maliyetini görmeden onay vermemiş olursunuz.

1. Talebi yazılı olarak alın ve bekleyen istekler listesine ekleyin.
2. Talebin kapsam içinde mi dışında mı olduğunu sözleşmeye göre kontrol edin.
3. Kapsam dışındaysa ekipten süre ve maliyet tahmini isteyin.
4. Karar verici ile "şimdi mi, sonra mı" kararını verin.
5. Onaylanan ek işi ayrı bir kalem olarak takvime ekleyin.

Bu yaklaşım iki tarafı da korur. Siz neye ödeme yaptığınızı bilirsiniz, ekip de hangi işi ne zaman teslim edeceğini bilir. Kapsamın baştan iyi tanımlanması için web projesinde brief nasıl hazırlanır rehberimizi öneririz.

Tasarım hedefleri geri bildirimi nasıl filtreler?

Tasarım hedefleri, her yorumu "bu değişiklik hedefe hizmet ediyor mu?" sorusuyla sınamanızı sağlar. Hedef yazılı değilse tartışma zevk üzerinden ilerler. Hedef yazılıysa tartışma kanıt ve gerekçe üzerinden ilerler.

Nielsen Norman Group'un tasarım eleştirisi (design critique) rehberi de benzer bir noktaya vurgu yapar: geri bildirimden önce çözülmek istenen problemi ve kullanıcı ihtiyacını netleştirmek gerekir. Ayrıca rehber, fikir bildiren yorumları tasarımın hedefleriyle bağlantılı sorulara dönüştürmeyi önerir.

Örneğin hedefiniz "teklif formunu dolduran ziyaretçi sayısını artırmak" ise, ana sayfadaki animasyon tartışması ikinci plana düşer. Buna karşılık formun görünürlüğü ve alan sayısı öncelik kazanır. Böylece karar verici neyi kabul edip neyi erteleyeceğini kolayca belirler.

Pratik bir öneri: revizyon belgesinin en üstüne üç cümlelik bir hedef özeti koyun. Her tur başlamadan önce bu özeti yeniden okuyun. Bu küçük alışkanlık, gereksiz tartışmaların önemli bir kısmını baştan keser.

Web tasarım revizyon sürecinde erişilebilirlik kontrolü nerede yer alır?

Erişilebilirlik kontrolü her turun içinde yer almalı, sona bırakılmamalıdır. Çünkü renk kontrastı, yazı boyutu ve odak sırası gibi konular tasarımın temel kararlarıdır. Son anda düzeltmeye çalışırsanız, onaylanmış birçok ekranı yeniden açmanız gerekir.

W3C'nin Web İçeriği Erişilebilirlik Yönergeleri (WCAG) sayfası, standardın algılanabilir, işletilebilir, anlaşılabilir ve sağlam olmak üzere dört ilke etrafında kurulduğunu belirtir. Bu ilkeleri revizyon notlarınıza basit sorular olarak ekleyebilirsiniz: metin arka planla yeterince ayrışıyor mu, butonlar klavyeyle kullanılabiliyor mu, görsellerin alternatif metni var mı?

Ayrıca erişilebilirlik notlarını "tercih" değil "zorunlu" olarak etiketlemenizi öneririz. Böylece estetik bir tercih uğruna okunabilirlik kaybolmaz. Örnek senaryo: açık gri metin şık durur, ancak birçok ziyaretçi için zor okunur. Bu durumda kontrast notu tartışmasız biçimde öne geçer.

Kısacası erişilebilirlik ayrı bir proje değil, revizyon kontrol listesinin doğal bir parçasıdır.

Revizyon takvimi ve yanıt süreleri nasıl planlanır?

Revizyon takvimi, her turun teslim ve geri bildirim günlerini önceden belirler. Ekip taslağı belirli bir günde paylaşır, siz de belirli bir süre içinde toplu geri bildirim gönderirsiniz. Böylece iki taraf da ne zaman ne bekleyeceğini bilir.

Yanıt süresini makul tutmak önemlidir. Çok kısa süre, paydaşların taslağı incelemesine izin vermez. Çok uzun süre ise projenin ivmesini kırar ve ekibin bağlamı unutmasına yol açar. Bu nedenle biz her turda birkaç iş günü gibi net bir aralık konuşuruz; kesin süreyi projenin büyüklüğüne göre birlikte belirleriz.

Peki geri bildirim zamanında gelmezse ne olur? Bu durumda takvim otomatik olarak kayar ve bunu yazılı olarak not edersiniz. Üstelik sözleşmede bir hatırlatma ve bekleme kuralı bulunması, kimsenin sessizce beklemesine izin vermez. Örneğin "geri bildirim gelmezse ekip hatırlatma gönderir, ardından takvimi günceller" gibi basit bir madde yeterlidir.

Son olarak tatil, kampanya ya da fuar gibi yoğun dönemleri takvime baştan işleyin. Karar vericinin müsait olmadığı haftada tur başlatmak, süreci gereksiz uzatır.

Revizyon sürecini sözleşmeye nasıl yazarsınız?

Revizyon kurallarını sözleşmeye yazmak, sözlü anlaşmaların yarattığı belirsizliği ortadan kaldırır. Bu madde tur sayısını, revizyon tanımını, kapsam dışı işin nasıl fiyatlanacağını ve onayın nasıl verileceğini içerir. Not: bu yazı hukuki danışmanlık değildir; sözleşme metni için hukuk danışmanınıza başvurun.

Sözleşmede şu başlıkları görmeyi öneririz. Ayrıntılı bir liste için web tasarım sözleşmesinde olması gereken maddeler yazımızı da okuyabilirsiniz.

• Her aşama için revizyon tur sayısı.
• Revizyon, hata düzeltme ve kapsam dışı istek tanımları.
• Karar vericinin adı ve onay kanalı.
• Geri bildirim için yanıt süresi ve gecikme durumunda yapılacaklar.
• Ek tur ve ek işin nasıl fiyatlanacağı.
• Onaylanan aşamaya geri dönüşün nasıl ele alınacağı.

Bu maddeler bir güvensizlik işareti değildir. Tersine, iki tarafın da işi ciddiye aldığını gösterir. Ayrıca proje sırasında bir anlaşmazlık çıkarsa, herkes aynı metne bakarak konuşur.

Revizyon toplantısı mı, yazılı geri bildirim mi daha iyi?

İkisi birbirinin alternatifi değil, tamamlayıcısıdır. Toplantı, gerekçeleri konuşmak ve çelişkileri hızla çözmek için idealdir. Yazılı geri bildirim ise kararları kayıt altına alır ve uygulanacak işi netleştirir. Bu yüzden biz önemli turlarda kısa bir toplantıyı yazılı listeyle birleştiririz.

Toplantıyı verimli tutmak için gündemi önceden paylaşın. Örneğin "bugün yalnız ana sayfa ve ürün sayfasını konuşuyoruz" demek, konunun dağılmasını önler. Nielsen Norman Group rehberi de eleştiri oturumunda kapsamı baştan belirlemeyi ve herkese söz hakkı tanımayı önerir. Ayrıca toplantının sonunda kimin hangi notu listeye ekleyeceğini netleştirin.

Toplantıdan sonra karar verici, konuşulanları aynı gün yazılı listeye çevirir. Böylece toplantıda söylenen ama yazılmayan bir fikir sonradan sürpriz talep olarak dönmez. Üstelik toplantıya katılamayan paydaşlar da kararları aynı belgeden okur.

Kısacası konuşmak anlamayı hızlandırır, yazmak ise uygulamayı güvenceye alır. İkisini birlikte kullandığınızda tur sayısı da kendiliğinden azalır.

Revizyon sürecinde hangi araçlar işinizi kolaylaştırır?

Doğru araç, geri bildirimi tek yerde toplar ve geçmişi kayıt altında tutar. Belirli bir ürünü önermek yerine aracın taşıması gereken özelliklere bakmanızı öneririz. Çünkü ekipten ekibe tercih değişir; önemli olan ilkedir.

İlk olarak tasarım dosyası üzerinde doğrudan yorum yapabildiğiniz bir ortam seçin. Böylece not, ilgili öğeye bağlı kalır. Ardından çalışan site aşamasında ekran görüntüsü alıp üzerine işaret koyabildiğiniz basit bir yöntem kullanın. Son olarak tüm maddeleri durumlarıyla izleyebileceğiniz bir görev listesi tutun: "açık", "uygulandı", "onaylandı" gibi.

Öte yandan çok fazla araç kullanmak da yeni bir dağınıklık yaratır. Bir kısmı e-postada, bir kısmı mesajlaşma uygulamasında, bir kısmı tasarım aracında kalan notlar kaybolur. Bu yüzden projenin başında "geri bildirimin tek adresi burası" diye bir kural koyun.

Ayrıca her turun sonunda kısa bir özet yazın: neler değişti, neler bekliyor, hangi kararlar verildi. Bu özet, bir sonraki turda aynı konuyu yeniden açmanızı engeller.

Örnek senaryo: üç turda tamamlanan bir kurumsal site nasıl ilerler?

Aşağıdaki akış gerçek bir müşteri vakası değil, yöntemi göstermek için hazırladığımız bir örnek senaryodur. Orta ölçekli bir üretim firması, beş sayfalık kurumsal site için çalışmaya başlıyor ve pazarlama müdürünü karar verici olarak atıyor.

İlk turda ekip tel çerçeveleri paylaşıyor. Pazarlama müdürü satış ve yönetim ekibinden yorum topluyor, çelişen iki notu kendi içinde çözüyor ve tek liste gönderiyor. Bu turda ana sayfadaki bölüm sırası değişiyor ve iletişim formu yukarı çıkıyor.

İkinci turda görsel tasarım geliyor. Karar verici yorumları ekran görüntüsü üzerinde işaretliyor; başlık boyutları, buton kontrastı ve ürün görsellerinin oranı düzeltiliyor. Bu arada genel müdür yeni bir "kariyer" sayfası istiyor. Ekip bu isteği bekleyen istekler listesine ekliyor ve ayrı teklif hazırlıyor.

Üçüncü turda ekip çalışan site üzerinde mobil ve masaüstü kontrolü yapıyor; geriye yalnızca küçük boşluk ayarları kalıyor. Sonuç olarak site planlanan takvimde yayına çıkıyor, kariyer sayfası ise ikinci aşamaya kalıyor.

Revizyon sürecinde sık yapılan hatalar nelerdir?

En sık hata, geri bildirimi taslağı ilk gören kişinin anlık tepkisine bırakmaktır. İlk izlenim değerlidir, ancak hedefle karşılaştırılmadan talimata dönüşmemelidir. Bu yüzden yorumları bir gün bekletip yeniden okumak çoğu zaman daha sağlıklı sonuç verir.

İkinci hata, gerçek içerik yerine yer tutucu metinle onay vermektir. Örnek metinle güzel görünen bir bölüm, gerçek ürün açıklamaları geldiğinde taşabilir ya da boş kalabilir. Dolayısıyla mümkün olan en erken aşamada gerçek içeriği taslağa yerleştirin.

• Farklı kişilerden gelen notları ayıklamadan iletmek.
• Onaylanan aşamayı sessizce yeniden açmak.
• Kapsam dışı istekleri revizyon gibi sunmak.
• Yalnızca masaüstü görünüme bakıp mobili atlamak.
• Erişilebilirlik notlarını "sonra bakarız" diye ertelemek.
• Olumlu geri bildirimi hiç yazmamak.

Bu hataların ortak noktası süreç eksikliğidir. Bir de genel kullanılabilirlik sorunlarını revizyon turunda yakalamak istiyorsanız, UX audit nedir, nasıl yapılır yazımızdaki kontrol başlıklarını revizyon belgesine ekleyebilirsiniz.

Web tasarım revizyon süreci için kontrol listesi nasıl olmalı?

Bir kontrol listesi, her turda aynı adımları atlamadan uygulamanızı sağlar. Aşağıdaki listeyi projenizin başında ekiple paylaşabilir, her turda yeniden kullanabilirsiniz.

1. Proje hedefi ve hedef kitle üç cümlede yazılı mı?
2. Karar vericiyi ve yedeğini belirlediniz mi?
3. Her aşamanın tur sayısı sözleşmede yer alıyor mu?
4. Geri bildirimin tek adresi ve son tarihi belli mi?
5. Notlar ekran görüntüsü ya da tasarım dosyası üzerinde işaretli mi?
6. Her not konum, sorun, hedef ve öncelik içeriyor mu?
7. Çelişen yorumları teslimden önce ayıkladınız mı?
8. Mobil ve masaüstü görünümü birlikte kontrol ettiniz mi?
9. Kontrast ve klavye erişimi gibi erişilebilirlik notlarını eklediniz mi?
10. Kapsam dışı istekler ayrı listede mi?
11. Tur sonu özetini yazdınız mı?
12. Onayı yazılı olarak aldınız mı?

Listeyi kendi projenize göre genişletebilirsiniz. Önemli olan, her maddenin evet ya da hayır ile yanıtlanabilmesidir. Belirsiz bir madde, belirsiz bir tur üretir.

Revizyon sürecini bizimle nasıl yürütürsünüz?

Talha Aslan ve ekibi olarak web projelerinde bu yapıyı baştan kurarız: tur sayısı, karar verici, toplu geri bildirim ve kapsam dışı istek listesi teklifin bir parçasıdır. Sitenizi bu düzenle hayata geçirmek isterseniz, web tasarım hizmetimiz sayfasından projenizi anlatabilirsiniz.

Süreç boyunca her turda size tek bir taslak bağlantısı, net bir son tarih ve tur sonu özeti göndeririz. Böylece kimin neye onay verdiğini, hangi isteğin hangi aşamaya kaldığını her an görürsünüz. Ayrıca erişilebilirlik ve mobil uyum notlarını revizyon listesinin sabit maddeleri olarak ele alırız.

Elbette her proje farklıdır. Bu yüzden tur sayısını ve takvimi işin kapsamına göre birlikte belirleriz. Sitenizi bu kurallarla biz kurarız; proje ayrıntılarınızı paylaşarak web tasarım teklifi alabilirsiniz.

Kısacası iyi bir web tasarım revizyon süreci, tasarımı sınırlamaz; tersine, ekibin enerjisini gerçekten önemli kararlara yönlendirir. Böylece siteniz zamanında ve herkesin arkasında durduğu bir onayla yayına çıkar.