11 สิ่งที่ฉันได้เรียนรู้ในช่วงปีแรกของการทำงานในฐานะนักออกแบบ UX/UI ในซอฟต์แวร์เฮาส์

เป็นเวลากว่าหนึ่งปีแล้วที่ฉันเริ่มงานแรกในฐานะนักออกแบบ UX/UI ที่บริษัทซอฟต์แวร์แห่งหนึ่ง ในขณะที่บางคนคิดว่านี่ไม่ใช่สถานที่ที่ดีที่สุดในการเริ่มต้นประสบการณ์ UX/UI ของคุณ เนื่องจากมีโปรเจ็กต์ที่หลากหลายและต้องการความเป็นอิสระ แต่ฉันก็ไม่ได้มีปัญหากับมันมากนัก ฉันทำงานเป็นผู้ช่วยด้านสถาปัตยกรรมสำหรับสตูดิโอที่ค่อนข้างใหญ่และเป็น "อิสระ" ให้กับองค์กรนักศึกษาด้านประชาสัมพันธ์และการออกแบบกราฟิก

อย่างไรก็ตาม มันไม่ใช่แสงแดดและสายรุ้งทั้งหมด ฉันใช้เวลาน้อยกว่าสี่เดือนระหว่างการตัดสินใจรีแบรนด์และเริ่มงานแรกของฉัน และด้วยเหตุนี้ฉันจึงไม่ได้เรียนรู้และเข้าใจทุกด้านที่จำเป็นสำหรับตำแหน่งนี้ โดยทั่วไปแล้ว รุ่นน้องจะไม่ได้รับการสอนมากนักเกี่ยวกับความสำคัญของความร่วมมือระหว่างทีมต่างๆ ในบริษัท ส่วนใหญ่เป็นเรื่องของธุรกิจและการขายของโครงการ

ต่อไปนี้เป็นปัญหาที่ฉันพบในช่วงปีแรกในการออกแบบ UX/UI:

1.MVP และ KPI

นี่เป็นแนวคิดต่างประเทศเกือบทั้งหมดที่ฉันพบในขณะที่ทำงานในโครงการแรกของฉัน เป็นที่ยอมรับว่าเป็นโครงการภายใน แต่งานเป็นแบบสบาย ๆ และฉันสามารถถามผู้เข้าร่วมโครงการทุกคนเกี่ยวกับปัญหาต่าง ๆ นั่นคือตอนที่ฉันรู้จักนักวิเคราะห์ธุรกิจและบทบาทของพวกเขาในโครงการ ฉันได้เรียนรู้เกี่ยวกับด้านธุรกิจของผลิตภัณฑ์ ซึ่งกลายเป็นส่วนที่สำคัญที่สุดของผลิตภัณฑ์ในซอฟต์แวร์เฮาส์ จากประสบการณ์ในอุตสาหกรรมก่อนหน้านี้ MVP และ KPI อาจซ่อนอยู่ภายใต้ชื่ออื่น แต่ความตั้งใจจริงระหว่างการประชุมเชิงปฏิบัติการกับลูกค้าคือสิ่งที่ผมได้รับจากที่นี่

2. ข้อกำหนดทางธุรกิจ การรวบรวมข้อกำหนด การยืนยันกับลูกค้า การยืนยัน

ในความคิดของฉัน นี่เป็นส่วนที่สำคัญที่สุดในการทำงานของนักออกแบบผลิตภัณฑ์ ที่บริษัท ฉันมีหน้าที่รับผิดชอบบางส่วนหรือทั้งหมดสำหรับการรวบรวมข้อกำหนดและยืนยันกับลูกค้า บางครั้งก็ร่วมมือกับนักวิเคราะห์ธุรกิจที่เจาะเข้าไปในโครงสร้างของลูกค้าอย่างนุ่มนวลและรวบรวมข้อกำหนดทางธุรกิจ ในขั้นตอนนี้ สิ่งสำคัญคือต้องเรียนรู้เกี่ยวกับอุตสาหกรรมและกระบวนการของลูกค้า อธิบายให้ลูกค้าทราบว่าเหตุใดเราจึงทำเช่นนี้ (หากพวกเขาไม่ทราบ) และที่จริง รวบรวมข้อมูลนี้อย่างสม่ำเสมอเกี่ยวกับผลิตภัณฑ์ที่กำลังออกแบบ ฉันทำสิ่งนี้โดยการเขียนเรื่องราวของผู้ใช้และเกณฑ์การยอมรับและความเสี่ยงที่อาจเกิดขึ้น สำหรับลูกค้า มุมมองของผลิตภัณฑ์ที่พวกเขาสั่งซื้อจากเรามีความสำคัญอยู่แล้วในขั้นตอนนี้ ดังนั้นรูปแบบที่น่าสนใจที่สุดในการรวบรวมข้อกำหนดดังกล่าวคือการสร้างแบบจำลองกลางไฟ เช่น แบบจำลองที่มีเนื้อหาที่เสนอบางส่วน สิ่งสำคัญคือต้องจำไว้ว่านี่เป็นหนึ่งในข้อเสนอมากมายที่สามารถนำเสนอได้ ดังนั้นจึงไม่คุ้มที่จะแนบไปกับเวอร์ชันของโครงการดังกล่าว ในขั้นตอนนี้ คุณยังต้องคำนึงถึงความชัดเจนของการไหลของข้อมูล — กำหนดวิธีการรวบรวมและยืนยันข้อกำหนดจากลูกค้า หากไม่ปิดขั้นตอนนี้ คุณจะไม่สามารถเดินหน้าพัฒนาได้เนื่องจากมีความเสี่ยงที่อาจเกิดขึ้น — การเปลี่ยนแปลงการตัดสินใจหรือการเพิ่มข้อกำหนดใหม่ ซึ่งส่งผลต่อกำหนดการของโครงการ นอกจากนี้ยังเกิดขึ้นที่เราสร้างผลิตภัณฑ์ รวบรวมข้อกำหนด บางทีเราอาจอยู่ในขั้นตอนของการยอมรับเอกสารหรือแม้แต่การพัฒนา และจู่ๆ ธุรกิจ (เช่น ผู้ใช้) ก็ประกาศว่าพวกเขาไม่เข้าใจกระบวนการ

3. เวลาโดยประมาณ — ประเมินค่าต่ำไปหรือสูงไป

ความจริงก็คือเวลาส่วนใหญ่ใช้ไปกับการสร้างแบบจำลอง ปรับแต่งไลบรารีที่มีอยู่หรือสร้างไลบรารีแบบกำหนดเอง และเขียนเอกสารประกอบ มักจะเป็นเรื่องยากมากสำหรับนักออกแบบมือใหม่ในการประมาณเวลาที่พวกเขาจะใช้ไปกับสิ่งนี้ และด้วยวิธีใดพวกเขาก็ต้องทำ หลายครั้งที่ฉันประเมินเวลาที่ใช้ในงานหนึ่งๆ ต่ำเกินไป และครั้งหนึ่งฉันเคยประเมินมันสูงเกินไปด้วยซ้ำ แต่ในมุมมองของฉัน ทักษะนี้มาพร้อมกับประสบการณ์ เป็นเรื่องดีที่มีบัฟเฟอร์ช่วงเวลาหนึ่งในสถานการณ์เช่นนี้ การส่งของเร็วกว่ากำหนดย่อมดีกว่าเสมอ

4. หางเสือ ใบเรือ และเรือ — การพึ่งพาตนเอง

จากประสบการณ์ของฉัน ฉันต้องควบคุมส่วนเล็กๆ ของโครงการเท่านั้น เช่น การประสานงานการติดตั้งบนเพดานห้องพักในโรงแรมและทางเดิน หรือส่วนที่เรียกว่า Back of House ในฐานะนักออกแบบ UX/UI หลังจากที่ฉันได้รับมอบหมายอย่างเป็นทางการให้ทำงานในโครงการแรก ฉันมีความรับผิดชอบมากขึ้นสำหรับผลิตภัณฑ์ เนื่องจากฉันเป็นนักออกแบบคนเดียวในทีมโครงการ ในแง่หนึ่ง สิ่งนี้ทำให้ฉันรู้สึกดีขึ้น แต่ในทางกลับกัน มันเป็นความรับผิดชอบและความไว้วางใจโดยรวมจากบริษัทเป็นอย่างมาก จนถึงตอนนี้ฉันไม่รู้ว่ามันเหมาะกับฉันไหม บางทีมันอาจจะยังเร็วเกินไปที่จะรับผิดชอบผลิตภัณฑ์ทั้งหมดในฐานะผู้ที่มีประสบการณ์น้อยในอุตสาหกรรมนี้ มันค่อนข้างเป็นการทดสอบสำหรับฉัน แต่เท่าที่ฉันรู้ ทั้งลูกค้าและทีมงานมีความสุขกับฉัน ดังนั้นฉันเดาว่าฉันสามารถทำงานโครงการเหล่านี้ได้ดีในช่วงเวลานั้น

5. การวิจัยในขั้นตอน UX หรือมากกว่านั้นยังขาดอยู่

ลูกค้ามักไม่มีความรู้ในประเด็นของการวิจัย UX ในขั้นตอนการออกแบบ (และหากพวกเขารู้ ก็ขอขอบคุณฝ่ายขายของคุณสำหรับข้อมูลที่แจ้งแก่ลูกค้า!) นี่คือข้อเสียทั่วไปของซอฟต์แวร์เฮาส์ ในบริษัทผลิตภัณฑ์ จากการสนทนาของฉันที่งานมีตติ้งและการประชุมต่างๆ เห็นได้ชัดว่าโชคไม่ดีที่สิ่งนี้ไม่ใช่มาตรฐานสำหรับกระบวนการออกแบบ อย่างไรก็ตาม การนำเสนอต่อลูกค้าเกี่ยวกับการวิจัย UX นั้นคุ้มค่าเสมอ และนำเสนอว่าเหตุใดจึงสำคัญและประหยัดเวลาได้มากเพียงใด ตัวอย่างแรกจากฝั่ง — ฉันกำลังพัฒนาผลิตภัณฑ์ที่กระบวนการทางธุรกิจค่อนข้างซับซ้อนที่จะเข้าใจ ซึ่งปรากฏว่าไม่ใช่สำหรับฉันเท่านั้น เพราะผู้ใช้ไม่เข้าใจดีพอ เราต้องกลับไปที่ขั้นตอนการรวบรวมข้อกำหนดร่วมกับลูกค้า รวบรวมพวกเขาอีกครั้งหลังจากเรียนรู้เพิ่มเติมเกี่ยวกับกระบวนการ ปรับปรุงแบบจำลองและพัฒนาต่อไป สิ่งนี้สามารถหลีกเลี่ยงได้หากเรามีเวลาสักครู่ในการสร้างต้นแบบแบบจำลองและทำการทดสอบการใช้งานกับผู้ใช้ในอนาคต (พนักงานของหนึ่งในทีมที่ลูกค้า) แม้ว่าเราจะระบุปัญหาที่เกิดขึ้นในภายหลัง

6. การสร้างเอกสาร

นี่เป็นงานที่จำเป็นสำหรับลูกค้าในการตรวจสอบ สำหรับการสร้างเอกสาร UX ฉันใช้บทความโดยละเอียดของ Autentika เกี่ยวกับการเตรียมเอกสาร (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/ในภาษาโปแลนด์)

มันมีประโยชน์มากสำหรับฉันในการสร้างมัน แต่ก็ยังไม่เพียงพอ 100% ไดอะแกรมกระบวนการในผลิตภัณฑ์ที่ฉันสร้างขึ้นในขณะนั้นมีความซับซ้อนมาก ดังนั้นฉันจึงไปหานักวิเคราะห์ด้วยเหตุผล และด้วยความช่วยเหลือของพวกเขา ได้สร้างข้อกำหนดกรณีการใช้งานและข้อกำหนดกระบวนการที่มีรายละเอียดมากขึ้นพร้อมเกณฑ์การยอมรับแทน แน่นอน ตอนนี้ฉันจะทำเอกสารดังกล่าวให้แตกต่างออกไปเล็กน้อย แต่ ณ จุดนั้น ฉันค่อนข้างพอใจกับมัน

7. วิธีการ? มีอยู่จริงหรือไม่(ไม่มี)

บริษัทซอฟต์แวร์ส่วนใหญ่พยายามทำงานซ้ำๆ ด้วยวิธีการแบบรายบุคคลต่อลูกค้า เป็นเรื่องยากที่จะวางแผนกระบวนการทำหนังสือในสถานการณ์เช่นนี้ โดยเฉพาะอย่างยิ่งเนื่องจากการค้นคว้าแบบกระดานต่อกระดานมักไม่ค่อยทำเนื่องจาก "ไม่มีเวลา" หรือคุณทำงานเป็นนักออกแบบเพียงคนเดียว ท้ายที่สุดแล้ว วิธีการออกแบบจะขึ้นอยู่กับ Agile แต่เฟรมเวิร์กค่อนข้างคล้ายกันและสามารถแบ่งออกเป็นสเตจ Discover, Define, Design, Develop และ Deliver/Deploy (เช่น 5D แบบขยายที่มีสเตจจาก Double Diamond) .

8. เข้าใจลูกค้า

นี่คือแกนหลักของความร่วมมือกับลูกค้าในระดับของการออกแบบแอปพลิเคชัน บ่อยครั้งที่ลูกค้า (โดยเฉพาะจากอุตสาหกรรมที่ไม่ใช่ไอที) ไม่ทราบว่า UX คืออะไร มันเกี่ยวกับอะไร ปัญหาใดที่สามารถกำจัดได้ตั้งแต่ขั้นตอนแรกของโครงการ ตัวอย่างที่ดีจากประสบการณ์ของฉันคือตอนที่ฉันนำเสนอแบบจำลอง lo-fi เพื่อให้เป็นไปตามข้อกำหนดทางธุรกิจ การประชุมยังรวมถึงทีมการตลาดของลูกค้า ซึ่งไม่แน่ใจอย่างมาก... เกี่ยวกับการออกแบบแบบจำลอง Lo-Fi เนื่องจากพวกเขาไม่ได้อยู่ในหน้าเดียวกันทั้งหมด ฉันจึงพูดอีกครั้งเกี่ยวกับข้อเท็จจริงที่ว่าแบบจำลองมีไว้สำหรับโอกาสในการพูดคุยเกี่ยวกับฟังก์ชันการทำงานและวิธีการทำงานของผลิตภัณฑ์เท่านั้น น่าเสียดายที่สิ่งนี้ไม่ได้หยุดการตลาดจากการแสดงความคิดเห็นบนแบบอักษรที่ใช้ในแบบจำลอง ซึ่งไม่มีผลต่อการออกแบบแอปพลิเคชัน ณ จุดนั้นในโครงการ ในที่สุด, หัวข้อได้รับการแก้ไขค่อนข้างเร็วและเป็นที่เข้าใจกัน แต่ข้อเท็จจริงที่ว่ามันไม่ได้เกิดขึ้นทันทีนั้นบ่งชี้ว่าหัวข้อของ UX ไม่เป็นที่รู้จักอย่างสมบูรณ์ในบริษัทต่างๆ การนำเสนอสั้น ๆ แก่ลูกค้าในตอนเริ่มต้นของขั้นตอนการออกแบบนั้นคุ้มค่ากับการพูดคุยถึงวิธีการทำงานของเรา สิ่งที่เราจะนำเสนอ และขอบเขตที่เราต้องการข้อมูลจากลูกค้า และแน่นอนว่าทำไมมันถึงมีค่ากับเขา

9. ทำงานร่วมกับนักพัฒนา

บ่อยครั้งที่นักพัฒนามีความคิดเห็นที่ดีเมื่อพูดถึงวิธีแก้ปัญหาและถามคำถามทางเทคนิคและเชิงตรรกะ ซึ่งหลายครั้งทำให้ฉันมีหัวข้อที่ดีในการคิดเกี่ยวกับวิธีแก้ปัญหา อย่างไรก็ตาม บางครั้งพวกเขาเสนอวิธีแก้ปัญหาที่ง่ายกว่าสำหรับพวกเขาและไม่จำเป็นต้องดีจากมุมมองของผู้ใช้ ดังนั้นจึงจำเป็นต้องสร้างสมดุลอย่างเหมาะสมระหว่างสิ่งที่ควรค่าแก่การเสนอให้เปลี่ยนแปลงและจุดใดที่คุ้มค่าที่จะหยุดพวกเขา และอธิบายการตัดสินใจที่เกิดขึ้น

10. API, JSON, LDAP, orchestrator และคำแปลกๆ อื่นๆ

แนวคิดเหล่านี้เป็นแนวคิดหลักสำหรับการพัฒนาแอปพลิเคชันในฐานะ UX ที่คุณควรทราบ เนื่องจากนักพัฒนาและชุมชนไอทีทั้งหมดใช้แนวคิดเหล่านี้ ทำความรู้จักกับพวกเขา แล้วคุณจะสามารถพูดคุยกับวิศวกรได้ดีขึ้น คุณไม่ทราบ — ควรถามตั้งแต่เริ่มต้น แม้ว่าสำหรับฉันแล้ว ความเข้าใจในแนวคิดเหล่านี้จะเกิดขึ้นหลังจากตรวจสอบเอกสารการใช้งานที่นักพัฒนาสร้างขึ้นเท่านั้น — ไดอะแกรมการสื่อสารภายในของแอปพลิเคชั่นช่วยให้เข้าใจได้มากเมื่อพูดถึงมัน กำลังทำงาน

11. ทำงานใน sprints, project daily, sprint Planningและretro(spec)

เป็นการประชุมที่มีค่าซึ่งให้การควบคุมสิ่งที่เกิดขึ้นในโครงการอย่างเต็มที่ ผู้จัดการโครงการมีความสำคัญที่นี่ โดยจะเข้ามาแทรกแซงเมื่อจำเป็น (เช่น เมื่อลูกค้าพยายามเปลี่ยนการจัดเตรียม) เช่นเดียวกับ Scrum Masters หากเราทำงานอย่างคล่องตัว (เกือบทุกโครงการ)

อย่างที่คุณเห็น นี่เป็นหลายสิ่งหลายอย่างที่ฉันได้รู้เมื่อเข้าร่วม IT ฉันหวังว่าคุณจะพบว่ามันน่าสนใจและบางทีรายการนี้อาจเป็นประโยชน์สำหรับผู้ที่กำลังพิจารณาอาชีพด้าน UX/UI หรือแม้กระทั่งสำหรับผู้ที่ทำงานในอุตสาหกรรมนี้!