11 hal yang saya pelajari selama tahun pertama saya bekerja sebagai UX/UI Designer di software house

Sebenarnya sudah lebih dari setahun sejak saya memulai pekerjaan pertama saya sebagai Desainer UX/UI di sebuah software house. Sementara beberapa orang berpikir itu bukan tempat terbaik untuk memulai pengalaman UX/UI Anda karena berbagai proyek dan kemandirian yang diperlukan, saya tidak memiliki banyak masalah dengan itu. Saya bekerja sebagai asisten arsitektur di sebuah studio yang cukup besar dan “freelancing” untuk sebuah organisasi kemahasiswaan di bidang kehumasan dan desain grafis.

Namun, tidak semua sinar matahari dan pelangi . Saya membutuhkan waktu kurang dari empat bulan antara keputusan untuk mengubah citra dan memulai pekerjaan pertama saya, dan akibatnya, saya tidak dapat mempelajari dan memahami setiap area yang dibutuhkan untuk posisi tersebut. Secara umum, junior tidak diajari banyak tentang pentingnya kerja sama antara tim yang berbeda di perusahaan, terutama bagian bisnis dan penjualan proyek.

Berikut adalah beberapa masalah yang saya temui selama tahun pertama saya dalam desain UX/UI:

1.MVP dan KPI

Ini adalah konsep yang hampir sepenuhnya asing yang saya temui saat mengerjakan proyek pertama saya. Memang, itu adalah proyek internal, tetapi pekerjaannya biasa saja, dan saya dapat bertanya kepada setiap peserta proyek tentang berbagai masalah. Saat itulah saya mengenal para analis bisnis dan peran mereka dalam proyek tersebut. Saya belajar tentang sisi bisnis produk, yang ternyata merupakan bagian terpenting dari mereka di rumah perangkat lunak. Memiliki pengalaman dari industri sebelumnya, MVP dan KPI mungkin tersembunyi dengan nama lain, tetapi penentuan praktisnya selama lokakarya dengan klien adalah apa yang saya alami di sini.

2. Persyaratan bisnis, mengumpulkan persyaratan, mengonfirmasinya dengan pelanggan, membuat konfirmasi

Menurut saya, ini adalah bagian terpenting dari pekerjaan seorang desainer produk. Di perusahaan, saya bertanggung jawab sebagian atau seluruhnya untuk mengumpulkan persyaratan dan mengonfirmasinya dengan klien — terkadang bermitra dengan analis bisnis yang dengan lembut menembus struktur klien dan mengumpulkan persyaratan bisnis. Pada tahap ini, penting untuk mempelajari tentang industri dan proses klien, menjelaskan kepada klien mengapa kami melakukan ini (jika mereka tidak tahu) dan sebenarnya, secara konsisten mengumpulkan informasi ini tentang produk yang sedang dirancang. Saya melakukan ini dengan menuliskan cerita pengguna dan kriteria penerimaan serta potensi risiko. Bagi klien, aspek visual dari produk yang mereka pesan dari kami sudah penting pada tahap ini, jadi bentuk pengumpulan persyaratan yang paling menarik adalah dengan membuat maket mid-fi, yaitu maket dengan sebagian konten yang diusulkan. Penting untuk diingat bahwa ini adalah salah satu dari banyak proposal yang dapat disajikan, jadi tidak ada gunanya melampirkan versi proyek seperti itu. Pada tahap ini, Anda juga perlu mengingat kejelasan aliran informasi — menetapkan bagaimana persyaratan dikumpulkan dan dikonfirmasi oleh klien. Tanpa menutup tahap ini, Anda tidak dapat melanjutkan pengembangan karena potensi risiko — mengubah keputusan yang dibuat atau menambahkan persyaratan baru, yang memengaruhi jadwal proyek. Kebetulan kami membuat produk, mengumpulkan persyaratan, mungkin kami sudah pada tahap penerimaan dokumentasi atau bahkan pengembangan, dan tiba-tiba bisnis (yaitu pengguna) menyatakan bahwa mereka tidak memahami prosesnya.

3. Memperkirakan waktu — meremehkan atau melebih-lebihkan

Faktanya adalah sebagian besar waktu dihabiskan untuk membuat maket, menyesuaikan perpustakaan yang ada atau membuat yang khusus, dan menulis dokumentasi. Seringkali sangat sulit bagi desainer pemula untuk memperkirakan waktu yang akan mereka habiskan untuk ini, dan entah bagaimana mereka harus melakukannya. Beberapa kali saya meremehkan waktu yang dihabiskan untuk tugas tertentu, dan bahkan pernah melebih-lebihkannya, tetapi menurut saya keterampilan ini datang dengan pengalaman. Adalah baik untuk memiliki buffer waktu tertentu dalam situasi seperti itu — selalu lebih baik mengirimkan sesuatu lebih cepat daripada terlambat.

4. Kemudi, layar dan kapal — kemandirian

Sejauh ini dalam pengalaman saya, saya hanya perlu mengendalikan aspek proyek yang lebih kecil, seperti mengoordinasikan instalasi di langit-langit kamar dan koridor hotel atau yang disebut bagian Back of House. Sebagai desainer UX/UI setelah saya secara resmi ditugaskan ke proyek pertama saya, saya jauh lebih bertanggung jawab atas produk tersebut, karena saya adalah satu-satunya desainer di tim proyek. Di satu sisi, itu memuliakan bagi saya, tetapi di sisi lain, itu adalah tanggung jawab yang besar dan kepercayaan keseluruhan dari perusahaan. Sampai sekarang saya tidak tahu apakah itu cocok untuk saya, mungkin terlalu dini untuk sepenuhnya bertanggung jawab atas produk sebagai orang dengan sedikit pengalaman di industri ini. Itu adalah ujian yang cukup bagi saya, tetapi sejauh yang saya tahu, klien dan tim senang dengan saya, jadi saya rasa saya berhasil menjalankan tugas proyek ini dengan baik untuk saat itu

5. Penelitian di tahap UX, atau lebih tepatnya, kekurangannya

Klien sering kali tidak memiliki pengetahuan tentang tujuan melakukan penelitian UX pada tahap desain (dan jika ya, terima kasih kepada departemen penjualan Anda untuk klien yang begitu berpengetahuan!). Ini adalah kelemahan umum dari software house. Di perusahaan produk, dari percakapan saya di pertemuan dan konferensi, jelas bahwa sayangnya, ini juga bukan standar dalam proses desain. Namun demikian, selalu bermanfaat untuk melakukan presentasi kepada klien tentang penelitian UX dan menunjukkan mengapa itu penting dan seberapa banyak hal itu dapat menghemat waktu. Contoh pertama dari pantai - saya sedang mengembangkan produk yang proses bisnisnya cukup rumit untuk dipahami, ternyata - tidak hanya untuk saya, karena pengguna tidak memahaminya dengan baik. Bersama dengan klien, kami harus kembali ke tahap pengumpulan persyaratan, kumpulkan mereka lagi setelah mempelajari lebih lanjut tentang prosesnya, tingkatkan maket, dan lanjutkan pengembangan. Hal ini dapat dihindari jika kami memiliki waktu untuk membuat prototipe maket dan melakukan uji kegunaan dengan pengguna di masa mendatang (karyawan salah satu tim di klien). Meski begitu, kami akan mengidentifikasi masalah yang muncul jauh kemudian.

6. Pembuatan dokumentasi

Ini benar-benar pekerjaan yang diperlukan klien untuk memverifikasi. Untuk membuat dokumentasi UX, saya menggunakan artikel detail Autentika tentang menyiapkan dokumentasi (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/dalam bahasa Polandia).

Itu sangat berguna bagi saya dalam membuatnya, tetapi itu tidak cukup 100%. Diagram proses dalam produk yang saya buat pada saat itu SANGAT rumit, jadi saya pergi ke analis karena suatu alasan, dan dengan bantuan mereka, membuat spesifikasi kasus penggunaan dan persyaratan proses yang lebih rinci dengan kriteria penerimaan sebagai gantinya. Tentu saja, sekarang saya akan melakukan dokumentasi semacam itu sedikit lebih berbeda, tetapi pada saat itu, saya cukup puas dengannya.

7. Metodologi? Apakah mereka ada? (Tidak)

Sebagian besar rumah perangkat lunak mencoba bekerja secara iteratif, dengan pendekatan individual kepada pelanggan. Sulit untuk merencanakan proses buku dalam situasi seperti itu, terutama karena penelitian board-to-board jarang dilakukan karena “tidak ada waktu” atau Anda bekerja sebagai desainer tunggal. Pada akhirnya, metodologi desain didasarkan pada Agile, tetapi kerangka kerjanya sangat mirip satu sama lain dan lebih dapat dibagi menjadi tahap Temukan, Tentukan, Desain, Kembangkan, dan Kirim/Deploy (seperti 5D yang diperluas dengan tahap dari Berlian Ganda) .

8. Memahami pelanggan

Inilah inti kerjasama dengan pelanggan pada level desain aplikasi. Seringkali klien (terutama dari industri non-IT) tidak tahu apa itu UX, tentang apa, masalah apa yang dapat dihilangkan pada tahap pertama proyek. Contoh bagus dari pengalaman saya adalah ketika saya mempresentasikan maket lo-fi untuk melengkapi kebutuhan bisnis. Pertemuan tersebut juga termasuk tim pemasaran klien, yang sangat tidak yakin… tentang desain maket lo-fi. Karena mereka tidak semuanya berada di halaman yang sama, saya kembali berbicara tentang fakta bahwa maket hanya untuk kesempatan berbicara tentang fungsionalitas dan bagaimana produk seharusnya bekerja. Sayangnya, ini tidak menghentikan pemasaran untuk mengomentari tipografi yang digunakan pada maket, yang tidak ada hubungannya dengan desain aplikasi pada saat itu dalam proyek . Pada akhirnya, topik diselesaikan dengan cukup cepat dan dipahami, tetapi fakta bahwa itu tidak langsung menunjukkan bahwa topik UX sama sekali tidak dikenal di perusahaan. Ada baiknya membuat presentasi singkat kepada klien di awal tahap desain dengan diskusi tentang cara kami bekerja, apa yang akan kami presentasikan, dan sejauh mana kami membutuhkan masukan dari klien. Dan, tentu saja, mengapa itu sangat berharga baginya.

9. Bekerja dengan pengembang

Seringkali pengembang memiliki masukan yang sangat bagus dalam hal solusi dan mengajukan pertanyaan yang sangat teknis dan logis, yang berkali-kali memberi saya topik yang bagus untuk dipikirkan tentang solusi. Namun, terkadang mereka mengusulkan solusi yang lebih sederhana untuk mereka dan belum tentu baik dari sudut pandang pengguna, jadi di sini perlu untuk menyeimbangkan dengan benar apa yang layak untuk diusulkan untuk diubah dan di mana perlu menghentikannya dan menjelaskan keputusan yang dibuat.

10. API, JSON, LDAP, orkestra, dan kata-kata aneh lainnya

Ini adalah konsep kunci untuk pengembangan aplikasi yang, sebagai UX, harus Anda ketahui karena pengembang dan seluruh komunitas TI menggunakannya. Kenali mereka, dan Anda akan lebih mampu berbicara dengan para insinyur. Anda tidak tahu — tanyakan, lebih disukai di awal, meskipun bagi saya, pemahaman tentang konsep-konsep ini datang hanya setelah meninjau dokumentasi implementasi yang dibuat oleh pengembang — diagram komunikasi internal aplikasi memungkinkan banyak pemahaman ketika menyangkut berfungsi.

11. Bekerja dalam sprint, project daily, sprint planning dan retro(spec)

Itu adalah pertemuan berharga yang memberikan kendali penuh atas apa yang terjadi dalam proyek. Manajer Proyek penting di sini, melakukan intervensi saat dibutuhkan (misalnya, saat klien mencoba mengubah pengaturan), serta Scrum Master jika kami bekerja dengan gesit (hampir semua proyek).

Seperti yang Anda lihat, ini cukup banyak hal yang saya ketahui ketika saya bergabung dengan IT. Saya harap Anda menemukan mereka menarik dan mungkin daftar ini akan berguna bagi mereka yang sedang mempertimbangkan karir UX/UI mereka atau bahkan untuk orang yang bekerja di industri ini!