Ürün Tasarım Belgeleriyle Daha İyi Belgeleme ve Ekip İletişimi

Bir şirkette veya startup'ta ürün tasarımcısı olarak çalışmanın tipik süreci size tanıdık gelebilir: tasarım çözümü sağlayacak yeni bir ürün geliştiriliyor. Daha sonra bazı tasarım önerileri üzerinde çalışıyorsunuz ve geri bildirim toplamak için bunları 1-3 kişinin önüne getiriyorsunuz.

Bazen bu süreç gayet iyi çalışır, ancak bazı zamanlarda çalışmaz. Örneğin, bazı insanlar kendi işlerini bitirmeye dikkat etmekle meşguller ve tasarım teklifiniz için net ve özlü geri bildirim sağlamak için yeterli zaman harcamazlar.

Ayrıca, süreciniz iyi olsa da, özellikle COVID19 nedeniyle kendimizi uzaktan çalışırken bulduğumuz mevcut zamanlarda, kararları yazarak, yinelemeleri ve genel olarak tasarım sürecini takip ederek süreci resmileştirmek isteyebilirsiniz.

Süreci belgelemenin birçok faydası vardır. Örneğin, çalışmanızı daha görünür kılar, daha fazla insandan geri bildirim alma fırsatları yaratır, genel iletişimi geliştirir ve bir özelliğin nasıl tasarlandığına dair tüm bağlam ve düşüncelerle birlikte net bir resim sağlar.

Kahraman Tasarımcının Düşüşü

2018 civarında, Latin Amerika'da faaliyet gösteren bir şirkette Madrid'den uzak bir Ürün Tasarımcısı olarak çalışıyordum ve bu sürece Meksika ve Sao Paulo, Brezilya'dan diğer ekipleri dahil ettim.

Bu şirkette çalışmaya başlamadan önce, haber medyası, tasarım stüdyoları, sosyal ağ, mobil işletim sistemi gibi birçok farklı sektörden küçük ve büyük ölçekli ortamlarda çalışarak kariyerimde birçok farklı deneyim yaşadım, bir e-bakkal girişimi kurdum. ve hatta diğer küçük girişimlerle bazı serbest işler yaptı.

Ben de aynı yaklaşımı takip ettiğim o yıllarda, aynı odada oturan bazı insanlar var, çözümünüzü sunuyorsunuz, bazı ekranlar sağlıyor, akışlar sağlıyor, geri bildirim alıyor ve tekrar sunuyorsunuz. Bazı iterasyonlardan sonra çalışmanız geliştirme aşamasına gelmeye hazır olacaktır.

Ancak, bu aynı yaklaşım çalışmayı durdurdu. Ekibe katıldıktan kısa bir süre sonra, tasarımlarımı yalnızca görüntülü görüşmede sunmanın yeterli olmadığını fark ettim. Çok fazla teklif oluşturuyordum, ancak paydaşlarımdan ve ekip arkadaşlarımdan nihai onaya ulaşamadım. Kafam karıştı ve kendime sormaya devam ettim: Ne oluyordu? Mümkün olan en iyi çözümü tasarlamamış mıydım? Kaliteli iş çıkarmamış mıydım? Bu soruların her biri kendime olan güvenimi kaybetmeme neden oluyordu. Sorun, sürecimi bu ortama uyarlamam gerektiğiydi.

Sürecimin işlemediğini fark eder etmez, bir tasarımcı olarak uzaktan nasıl çalışılır, martı etkisi (işinize biri girdiğinde sert bir şekilde eleştirir ve sonra uçup gider), nasıl olduğu hakkında birçok makale okumaya başladım. diğer şirketler uzaktan işbirliğine yaklaşıyorlardı ve süreçlerini yazarak nasıl resmileştirdiler. Tüm bu materyali okuduktan sonra, geliştiricilerin aynı sorunla nasıl karşı karşıya olduğunu merak ettim. Neredeyse eşzamansız bir şekilde uzak ortamlarda nasıl işbirliği yapıyorlar? Nihai anlaşmaya nasıl varıyorlar? Aslında, geliştirici topluluğunun kendileri için oldukça iyi çalışan bir sürece sahip olduğunu keşfettim: Buna çekme istekleri denir.

Çekme istekleri, değişiklikleri belgeleyerek daha büyük bir kod tabanında sunmanıza ve kararlarınızı diğer kişilerin geri bildirimleriyle doğrulamanıza olanak tanır. Bu şekilde, yaptığınız değişiklikler, kodun halihazırda sahip olduğu tüm standartlar ve bağlantılarla mükemmel bir şekilde birleşir. Bu tam olarak başarmam gereken şeydi, ama elbette bir tasarım-moda yaklaşımıyla. Sizi Ürün Tasarım Belgesi ile tanıştırayım.

Ürün Tasarım Belgesi

Ürün Tasarım Belgesi (PDD) , çözmek istediğiniz sorunları, bağlamı ve nihai çözümü yineleme veya aşama tabanlı bir yaklaşıma dönüştüren bir belgedir.

Bu , tüm tasarım sürecinizi şirketinizdeki herkesle paylaşabileceğiniz tek bir belgede belgeleyebileceğiniz ve verdiğiniz ürün kararları için bir bilgi tabanı olarak yaşayacağı anlamına gelir. Kulağa hoş geliyor, ha? Ayrıntılara girelim.

Genel Kavramlar

Bir PDD 4 ana kavramda tanımlanabilir: Meta Veri, Bağlam, Aşamalar ve Geri Bildirim .

• Meta veriler , yalnızca başlık, tarih, durum vb. gibi belgeyle ilgili yararlı bilgilerdir.

  

• Bağlam , yaptığınız tasarım önerilerini anlamak için diğer insanların okuması gereken şeydir; bunu başarmanız gereken şeyin tanımı, sorunu, özeti veya hedefleri gibi düşünün.

• Aşamalar , tasarımınızın farklı yinelemeleridir ve genellikle daha geniş çözüme odaklanmaya başlar ve her aşamada daha spesifik ayrıntılara odaklanır. Her aşama bir öncekini temel alır ve alınan geri bildirimleri ele alır. Bu, çözülmüş sorunların tekrar ortaya çıkamayacağı bir nihai noktaya ulaşmanın yapılandırılmış bir yoludur.

• Geri bildirim , diğer insanlardan topladığınız tüm görüşler, yorumlar, istekler ve tavsiyeler anlamına gelir. Paydaşlarınızdan veya ekip üyelerinizden geri bildirim alabilirsiniz.

Bu dört konsept ile ihtiyaçlarınıza uygun farklı PDD varyasyonları oluşturabilirsiniz, her şirket/proje farklıdır ve benim için işe yarayan sizin için aynı şekilde çalışmak zorunda değildir. Ancak bu 4 ana kavramı PDD'nizde ele alırsanız, neredeyse her durumda çalışması muhtemel olacaktır.

Örnek Yapı

Ana kavramları anladıktan sonra, o şirkette geçirdiğim süre boyunca kullandığım yapıyı sizinle paylaşacağım. Aşağıdaki bölümlere sahiptir:

• Başlık kısa, net ve halihazırda sahip olduğunuz diğer PDD başlıklarından kolayca ayırt edilebilir olmalıdır.
• Durum , belgenizin şu anda hangi aşamada olduğunu gösterir:
• Taslak
  Hala Bağlamı tanımlamaya çalışıyorum. Geri bildirim için hazır değil.
• S30, S60, S90
  Çözümünüzün farklı aşamaları (%30, %60, %90) (aşamalar hakkında daha sonra ayrıntılı bilgi).
• Tamamlamak
  Tüm Geribildirimler ele alındı ​​ve eksik nokta yok. PDD bitti.
• Özet , genellikle sahip olabileceğiniz diğer yardımcı ilgili okumalara bağlantı vererek, tasarlamanız gereken sorunun açıklamasıdır.
• Hedefler , çözümünüzün odaklanması gereken kilit noktalardır; bu, doğru yolda olduğunuzdan emin olmak için sürekli gözden geçireceğiniz bir kontrol listesidir.
• S30 (veya Aşama %30 ), ayrıntılar yerine daha geniş çözüme odaklanan, belki de düşük kaliteli bir tel kafes veya benzeri bir teknik sağlayarak, özet ve hedeflere dayalı olarak yaptığınız ilk tekliftir. Bu, önerilen çözümün tamamen farklı bir yaklaşım alabileceği ve büyük geri bildirimlerin gerçekleşmesinin beklendiği aşamadır.
• S60 (veya Aşama %60 ) % 60 eksiksizliğe sahip çözümünüzdür ve S30'dan gelen geri bildirimi uygular. S90'dan daha az ayrıntıya sahiptir, ancak çözümünüzün amacını açıkça gösterir. Daha fazla vaka ve bazı akış tanımları içeren yüksek kaliteli bir tel kafes sağlarsınız. Çoğunlukla kaçırılan vakalara ve küçük beklenmedik senaryolara odaklanan bir tür geri bildirim alabilirsiniz.
• S90 (veya Aşama %90 ), çözüme %90 eksiksizlik sağlayan ve S60'tan gelen geri bildirimi uygulayan aşamadır. Bu aşama, tüm farklı senaryolar, köşe kasaları, görsel tasarım ve hatta prototipler dahil olmak üzere tasarımınızın en ince ayrıntılarına odaklanır. Bir tür küçük geri bildirim olması bekleniyor.

Kendinize soruyor olabilirsiniz, aynı sırayı ve aşamaları adlandırma kuralını izlemem gerekiyor mu? Hayır, yapmıyorsun. Sahne adını S30, S60 ve S90'dan yalnızca: Keşif, Teklif, Çözüm olarak değiştirebilirsiniz.

Ayrıca sıralamayı, en rafine çalışmanın (S90, Çözüm) belgenin en üstüne gelmesi ve okuma akışının son aşamadan ilk aşamaya (S30, Keşif) geçmesi için değiştirebilirsiniz.

şablonlar

En yaygın yazma platformları için sağlanan şablonlardan biriyle hızlı bir şekilde başlayın. Unutmayın: Bölümlerin adlandırma kuralları tamamen özelleştirilebilir. Özetten hoşlanmıyorsanız, Kısa , Hakkında veya ihtiyaçlarınıza uyan herhangi bir şeyi kullanın. Tutmanız gereken ana kavram, her aşamaya odaklanmak için farklı yinelemeler oluşturmakla ilgilidir, S30'u Keşif, S60'ı Öneri ve S90'ı Çözüm olarak yeniden adlandırabilirsiniz.

• Kağıt
• kavram
• Google Dokümanlar
• Gerçek hayattan örnek

PDD Kullanmanın Temel Faydaları

1. Her karar belgelenir.
   Bunun anlamı, şirketinizden/projenizden ayrıldığınızda bile (ve bu er ya da geç gerçekleşecektir), etrafta üretilen tüm bilgiler sonsuza kadar şirkette kalacaktır, böylece diğer insanlar ona bakabilir ve kaldığınız yerden yineleyebilir.

2. İletişimi geliştirir.
   Geri bildirim sağlamak için ekibinizden farklı kişileri PDD'ye almak, herkesin aynı sayfada kalmasına ve alınan kararlardan haberdar olmasına yardımcı olur.

3. Paydaşlardan gelen sonsuz değişiklikleri sınırlar.
   Her aşama, daha geniş çözümlerden dar çözümlere doğru, sorunun farklı bir açısına odaklanır. Bu, insanların aynı anda tek bir soruna odaklanmasını sağlayarak kapanış aşamalarında onlara yardımcı olur.

4. Ürün ortaklaşa inşa edilmiştir.
   Paydaşların belirli çözümleri tanımlaması yerine, mühendislik, tasarım ve diğer ekiplerin çözümün bir parçası haline getirerek çözümle ilgilenmesine izin veriyoruz.

Son Notlar

Bu uzak şirketle ilgili hikayeyi kapatarak, orada birkaç ay daha çalıştım ve Ürün Tasarım Dokümanlarını en az 5 farklı projede uygulayabildim. Hayal kırıklığım çok azaldı ve tasarım önerilerim üzerinde fikir birliğine varabildim, böylece ürün gelişmeye devam etti. O zamandan beri şirket çok büyüdü ve benim zamanımda yaptığım işlerin bir kısmı hala kullanılıyor.

Not: Bu makaleyi 2019'da yazmaya başladım, ardından 2021'de Abstract'ın tasarım sürecini belgelemek için bir ürün oluşturduğunu gördüm, bu yüzden tekrar yola çıkıp bitirmeye karar verdim. Hala oldukça alakalı bir konu gibi görünüyor.

bibliyografya

• Uzak Bir Ekipte Tasarım Alıştırmaları Nasıl Çalıştırılır, Hannah Hearth
• Martı Etkisinden Kaçının: Lauren Moon'dan 30/60/90 Geri Bildirim Çerçevesi
• Bir tasarım belgesini nasıl tasarlarsınız? John Saito tarafından
• Tasarım belgesinin gücü Brendan Fagan tarafından
• Matt Colyer'dan Defterler Tanıtımı