Bir yazılım evinde UX/UI Tasarımcısı olarak çalıştığım ilk yıl boyunca öğrendiğim 11 şey

Bir yazılım evinde UX/UI Designer olarak ilk işime başlayalı aslında bir yıldan fazla oldu. Bazı insanlar, projelerin çeşitliliği ve gerekli bağımsızlık nedeniyle UX/UI deneyiminize başlamak için en iyi yer olmadığını düşünse de, bu konuda pek bir sorun yaşamadım. Oldukça büyük bir stüdyoda mimari asistanlık ve bir öğrenci derneğinde halkla ilişkiler ve grafik tasarım alanında “freelance” olarak çalışıyordum.

Ancak, hepsi güneş ışığı ve gökkuşakları değildi . Yeniden markalaşmaya karar vermem ile ilk işime başlamam arasında dört aydan az bir süre geçti ve sonuç olarak, pozisyon için gereken her alanı öğrenemedim ve anlamadım. Genel olarak, küçüklere şirketlerdeki farklı ekipler arasındaki işbirliğinin önemi, özellikle de projenin iş ve satış kısmı hakkında pek bir şey öğretilmiyor.

UX/UI tasarımındaki ilk yılımda karşılaştığım bazı sorunlar:

1.MVP ve KPI'lar

Bunlar ilk projem üzerinde çalışırken karşılaştığım neredeyse tamamen yabancı kavramlardı. Kabul etmek gerekir ki, bu dahili bir projeydi, ancak iş gelişigüzeldi ve her proje katılımcısına çeşitli konular hakkında soru sorabildim. İşte o zaman iş analistlerini ve projedeki rollerini tanıdım. Yazılım evlerinde en önemli parça olduğu ortaya çıkan ürünlerin iş tarafını öğrendim. Daha önceki bir sektörden deneyim sahibi olarak, MVP'ler ve KPI'lar başka isimler altında gizlenmiş olabilir, ancak burada deneyimlediğim şey, müşterilerle yapılan çalıştaylarda bunların pratik olarak belirlenmesiydi.

2. İş gereksinimleri, gereksinimlerin toplanması, müşteri ile teyit edilmesi, onayların alınması

Bence bir ürün tasarımcısının işinin en önemli kısmı bu. Şirkette, gereksinimleri toplamaktan ve bunları müşteriyle doğrulamaktan kısmen veya tamamen sorumluydum - bazen müşterinin yapısına nazikçe giren ve iş gereksinimlerini toplayan bir iş analistiyle ortak olarak. Bu aşamada, müşterinin sektörü ve süreçleri hakkında bilgi edinmek, müşteriye bunu neden yaptığımızı açıklamak (eğer bilmiyorlarsa) ve aslında, tasarlanan ürün hakkında bu bilgileri tutarlı bir şekilde toplamak çok önemlidir. Bunu, kullanıcı öykülerini, kabul kriterlerini ve potansiyel riskleri yazarak yaptım. Müşteri için bizden sipariş ettiği ürünün görsel yönü zaten bu aşamada önemlidir, bu nedenle bu tür ihtiyaçları toplamanın en çekici yolu mid-fi mockup yani mid-fi maket yapmaktır. kısmen önerilen içeriğe sahip maketler. Bunun sunulabilecek birçok tekliften biri olduğunu hatırlamak önemlidir, bu nedenle projenin böyle bir versiyonuna bağlanmaya değmez. Bu aşamada, bilgi akışının netliğini de aklınızda bulundurmanız gerekir - gereksinimlerin müşteri tarafından nasıl toplanıp onaylandığını belirler. Bu aşamayı kapatmadan, proje zamanlamasını etkileyen alınan kararları değiştirmek veya yeni gereksinimler eklemek gibi potansiyel riskler nedeniyle geliştirmede ilerleyemezsiniz. Ayrıca, bir ürün oluşturduğumuz, gereksinimleri topladığımız, belki de zaten belgeleri kabul etme ve hatta geliştirme aşamasındayız ve birdenbire işletme (yani kullanıcılar) süreci anlamadıklarını beyan eder.

3. Tahmini süre — hafife alma veya fazla tahmin etme

Gerçek şu ki, çoğu zaman örnekler oluşturmaya, mevcut kitaplıkları özelleştirmeye veya özel olanları oluşturmaya ve belgeleri yazmaya harcanıyor. Acemi tasarımcıların buna harcayacakları zamanı tahmin etmeleri genellikle çok zordur ve bir şekilde yapmak zorundadırlar. Birkaç kez belirli bir görev için harcanan zamanı hafife aldım ve hatta bir kez abarttım, ama bence bu beceri deneyimle birlikte geliyor. Böyle bir durumda belirli bir süreye sahip olmak iyidir - bir şeyi geç teslim etmekten her zaman daha hızlı teslim etmek daha iyidir.

4. Dümen, yelken ve gemi — özgüven

Şimdiye kadar edindiğim deneyime göre, otel odalarının ve koridorların tavanlarındaki koordinasyon kurulumları veya Evin Arkası denilen kısımlar gibi projelerin yalnızca daha küçük yönlerinin kontrolünü ele almak zorunda kaldım. Resmi olarak ilk projeme atandıktan sonra bir UX/UI tasarımcısı olarak, proje ekibindeki tek tasarımcı olduğum için üründen çok daha sorumluydum. Bir yandan bu benim için asalet vericiydi, ancak diğer yandan şirketten gelen çok fazla sorumluluk ve genel güvendi. Şimdiye kadar bana uygun olup olmadığını bilmiyorum, belki de sektörde çok az deneyime sahip bir kişi olarak üründen tamamen sorumlu olmak için çok erken. Benim için oldukça zorlu bir sınavdı ama bildiğim kadarıyla hem müşteri hem de ekip benden memnundu, bu yüzden sanırım bu proje görevlerini o an için iyi yürütmeyi başardım sonuçta

5. UX aşamasında araştırma veya daha doğrusu eksikliği

Müşteriler genellikle tasarım aşamasında UX araştırması yapmanın amacı hakkında hiçbir bilgiye sahip değildir (ve eğer yaparlarsa, bu kadar bilgili bir müşteri için satış departmanınıza teşekkür edin!). Bu, yazılım evlerinin genel dezavantajıdır. Ürün şirketlerinde, toplantı ve konferanslardaki konuşmalarımdan, tasarım sürecinde maalesef bunun da standart olmadığı açıktı. Bununla birlikte, müşteriye UX araştırması hakkında sunum yapmak ve bunun neden önemli olduğunu ve zamandan ne kadar tasarruf sağlayabileceğini sunmak her zaman değerlidir. Kıyıdan ilk örnek - ortaya çıktığı gibi, iş sürecini anlamak oldukça karmaşık olan bir ürün geliştiriyordum - sadece benim için değil, çünkü kullanıcılar onu iyi anlamadı. Müşteri ile birlikte gereksinimleri toplama aşamasına geri dönmek zorunda kaldık, süreç hakkında daha fazla bilgi edindikten sonra onları tekrar toplayın, maketleri iyileştirin ve geliştirmeye devam edin. Modellerin prototipini oluşturmak ve gelecekteki kullanıcılarla (müşterideki ekiplerden birinin çalışanları) kullanılabilirlik testleri yapmak için biraz zamanımız olsaydı, bu durum önlenebilirdi. O zaman bile ortaya çıkan sorunları çok sonra tespit etmiş olurduk.

6. Dokümantasyon oluşturma

Bu gerçekten müşterinin doğrulaması için gereken bir iştir. UX dokümantasyonu oluşturmak için, Autentika'nın dokümantasyon hazırlama hakkındaki detaylı makalesini kullandım (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/Lehçe).

Oluşturmada benim için çok faydalı oldu ama %100 yeterli olmadı. O sırada oluşturduğum üründeki süreç şemaları ÇOK karmaşıktı, bu nedenle analistlere gitmemin bir nedeni vardı ve onların yardımıyla bir kullanım durumu spesifikasyonu ve bunun yerine kabul kriterleri ile daha ayrıntılı süreç gereksinimleri oluşturdum. Tabii ki, şimdi bu tür belgeleri biraz daha farklı yapardım ama o noktada bundan oldukça memnun kaldım.

7. Metodolojiler? Onlar var mı?(Hayır)

Çoğu yazılım evi, müşteriye bireysel bir yaklaşımla yinelemeli olarak çalışmaya çalışır. Bu tür durumlarda kitap süreçlerini planlamak zordur, özellikle de “zaman olmadığı” için ya da tek tasarımcı olarak çalıştığınız için tahtadan tahtaya araştırma nadiren yapıldığından. Sonuç olarak, tasarım metodolojisi Çevik'e dayanmaktadır, ancak çerçeveler birbirine oldukça benzerdir ve daha ziyade Keşfet, Tanımla, Tasarla, Geliştir ve Teslim Et/Dağıt aşamalarına bölünebilir (Double Diamond'dan bir aşama ile çok genişletilmiş bir 5D) .

8. Müşteriyi anlamak

Bu, uygulama tasarımı düzeyinde müşteri ile işbirliğinin özüdür. Genellikle müşteriler (özellikle BT dışı sektörlerden), UX'in ne olduğunu, ne hakkında olduğunu, projenin ilk aşamalarında hangi sorunları ortadan kaldırabileceğini bilmezler. İş gereksinimlerini tamamlamak için lo-fi maketleri sunarken yaşadığım deneyimden iyi bir örnek olabilir. Toplantıya müşterinin lo-fi maketlerinin tasarımı konusunda kararsız olan pazarlama ekibi de dahildi. Hepsi aynı sayfada olmadığı için maketlerin sadece işlevsellik ve ürünün nasıl çalışması gerektiği hakkında konuşma fırsatı verdiğinden tekrar bahsettim. Ne yazık ki bu, pazarlamanın maketlerde kullanılan ve projenin o noktasında uygulamanın tasarımı üzerinde hiçbir etkisi olmayan yazı karakterleri hakkında yorum yapmasını engellemedi . Sonunda, konu oldukça hızlı bir şekilde çözüldü ve anlaşıldı, ancak hemen çözülmemiş olması, UX konusunun şirketlerde tamamen bilinmediğini gösteriyor. Tasarım aşamasının en başında müşteriye nasıl çalıştığımız, neyi sunacağımız ve müşteriden ne ölçüde girdiye ihtiyacımız olduğu hakkında bir tartışma ile kısa bir sunum yapmaya değer. Ve elbette, neden onun için buna değer.

9. Geliştiricilerle çalışmak

Çözümler söz konusu olduğunda genellikle geliştiricilerin çok iyi girdileri olur ve çok teknik ve mantıklı sorular sorarlar, bu da çoğu kez bana bir çözüm hakkında düşünmem için iyi bir konu verdi. Bununla birlikte, bazen kendileri için daha basit olan ve kullanıcının bakış açısından iyi olmayan çözümler önerirler, bu nedenle burada neyin değiştirilmesini önermeye değer olduğunu ve nerede onları durdurmaya ve alınan kararları açıklamaya değer olduğunu doğru bir şekilde dengelemek gerekir.

10. API, JSON, LDAP, orkestratörler ve diğer garip kelimeler

Bunlar, bir UX olarak bilmeniz gereken uygulama geliştirme için temel kavramlardır çünkü geliştiriciler ve tüm BT topluluğu bunları kullanır. Onları tanıyın ve mühendislerle daha iyi konuşabileceksiniz. Bilmiyorsunuz - tercihen başlangıçta sorun, ancak benim için bu kavramların anlaşılması yalnızca geliştiricilerin oluşturduğu uygulama belgelerini inceledikten sonra geldi - uygulamanın dahili iletişim şemaları, konu söz konusu olduğunda çok şeyin anlaşılmasına izin verdi. çalışıyor.

11. Sprintlerde çalışma, günlük proje, sprint planlama ve retro(spec)

Projede olup bitenler üzerinde tam kontrol sağlayan değerli toplantılardır. Gerektiğinde (örneğin, müşteri düzenlemeleri değiştirmeye çalıştığında) müdahale eden Proje Yöneticileri ve çevik çalışıyorsak (neredeyse tüm projeler) Scrum Masters burada önemlidir.

Gördüğünüz gibi, BT'ye katıldığımda öğrendiğim pek çok şey vardı. Umarım onları ilginç bulursunuz ve belki de bu liste, UX/UI kariyerini düşünenler ve hatta bu sektörde çalışan insanlar için faydalı olabilir!