UX research สำหรับ Agile Development cycle 1

ก่อนอื่นเลยต้องทำความเข้าใจการทำงานของยุคก่อนที่เหมือนกับ Waterfall หรือแบบ Manufactuing หรือการทำงานแบบเป็นลำดับขั้นตอน จาก 1 ไป 2 ไป 3 และเรื่อยๆ

Traditional process ค่อนข้าง Linear คือเริ่มจาก

1. Research process
2. Design process 
3. Development

จากประสบการณ์การทำงานกับ Software indrustries สองขั้นตอนแรกจะถูกลดคำตอบมากที่สุด เพื่อที่จะกระโดดไปสู่ขั้นตอน Development อย่างรวดเร็ว และให้ทันกับ Timeline ที่บีบรัดมากๆ 

ลูกค้าเองก็อยากจะได้ของไวๆ โดยในท้ายสุดก็ต้องกลับไปเริ่มต้นที่การออกแบบใหม่ เพราะไม่ตอบโจทย์เพียงพอ บางก็ก็ตีกลับในเรื่องของรสนิยมลูกค้านักออกแบบไม่ตรงกัน (ไม่มีใครพูดถึง User) แล้วก็ต้องย้อนกลับไปถามว่า แล้ว User(จริงๆแล้ว) ต้องการอะไร กลับไปสู่ขั้นตอนการ Research

Research Deficits

• Focus ที่ User ในขั้นตอนแรก แต่ลดความสำคัญของ User ลงในภายหลัง
• Conceptual และ Discovery research ในช่วงที่ทุกอย่างยังคงเป็นนามธรรม (ไม่ Solid พอ)
• Research ถูกลดความสำคัญเนื่องจากต้องแข็งขันกับเวลาที่ จะ Delivery Product

Design Deficits

• Interactive Focus -  Lacks opportunities for abstraction
• Atomized focus on interaction before data  
• ความคิดเห็นของ User อาจถูกลดความสำคัญไป

Implementation Deficits

• Developer ไม่ให้ความสนใจกับขั้นตอน Research และเห็นว่าไม่เกี่ยวข้องกับงาน
• ความคิดเห็นของ User อาจถูกลดความสำคัญไป

A Shift in Mindset

• เพื่อความสอดคล้องและประสาน(ไม่รู้จะใช้คำว่าอะไร) สำหรับการทำงาน 3 ส่วนที่กล่าวมา Research ต้องมีส่วนรวมตลอดทั้งกระบวนการ
• Research คือการออกแบบและการพัฒนาเครื่องมือเพื่อสร้าง User-Center-Design Product.
• ลืมเรื่อง Traditional Process ว่า Research ต้องมาก่อนแล้วจึงส่งต่อไปยังแผนกต่าง ๆ ต่อไป เพราะ Research ไม่จำเป็นต้องกระทบกับ Timeline ของ Project 
• จากนั้นก็เริ่มร่าง Rapid Agile Research โดยกำหนด Goal (Challenge, Timeline, Deliverable)

ที่มาUXPin 

•  Sprint Roadmap เจาะจงจุดที่ให้ความสำคัญ (Focus) และรายละเอียดของแต่ละส่วนที่เกี่ยวข้อง

ที่มาUXPin 

5 Practices fro agile research

• The Research Protocol - เป็นสิ่งที่แรกที่ทั้งสามส่วนต้องทำไปพร้อมๆกัน ระบุ Goals ของแต่ละ Task ที่ต้องการเรียนรู้หรือทำความเข้าใจ คล้ายๆกับ Outline หยาบๆว่าเรากำลังจะทำอะไรบ้าง

• The Observation Guide - เป็นเหมือน Manual สำหรับ Clients ที่มาเป็นผู้สังเกตการณ์ ให้เข้าใจตรงกันว่า Task นี้เรากำลัง Focus อะไร เพราะเนื่องจากหลายๆครั้งการสนทนาชักจูงเราออกนอกประเด็นบ่อยๆ ตรงนี้จะช่วยกระชับและ Focus ถูกจุดมากขึ้น

• The Pro-Testing Debrief - คล้ายกับการสรุปหลังจาก Usability-Testing ก็จะนัดประชุมทุกฝ่ายแม้กระทั้งฝั่ง Clients เพื่อทำการ Evaluate ผลที่ได้ ว่าอะไร Work ไม่ Work, อะไรต้องการการศึกษาเพิ่มเติม

• The Report - สรุปที่ช่วยให้ทุกฝ่ายสามารถเอากลับ work on และง่ายต่อการ Follow up
• The Refactoring Sprint - จากความหมายตรงตัวตามที่ Martin Folwer ได้กล่าวไว้คือ ทำการปรับปรุงโดยรักษาพฤติกรรมของการทำงานแบบเดิมไว้ ซึ่ง Allow ให้ Designer และ Developer เริ่ม Iterating จาก Direction ที่วางไว้
  สำหรับ Researcher สามารถระบุ บันทึกการตัดสินใจ หรือ Recommendation เพิ่มเติมที่เกิดจากการสังเกตหรืออะไรที่ค้นพบในขั้นตอนนี้ เพื่อให้สามารถกลับมาดูได้ตลอดเวลา ในกรณีที่โปรเจคสิ้นสุดแล้วแต่ต้องการพัฒนาบางอย่างเพิ่มเติม หรือแม้กระทั้งไว้เป็น Log ในการพูดคุยกับ Clients กรณีมีปัญหา

Research ใน week แรกๆ

ช่วงที่ทำการสัมภาษณ์ Stakeholders และ Users ฝ่าย Dev ก็จะศึกษาความเป็นไปได้ ของ technology ในขณะที่ฝ่ายออกแบบก็สำคัญในการเก็บ Insight จากลูกค้า ส่วนตัวตรงนี้ผมเคยทั้งเข้าไปนั่งในหลายๆฐานะทั้ง Dev, Designer, BA พบว่าแต่ละสถาณะการณ์มีข้อได้เปรียบเสียเปรียบแตกต่างกันไป คิดว่าควรเอาคนที่มีประสบกาณ์แต่ละฝ่ายไปดีกว่า เอาไปหลายๆคน จะทำให้การ Interview กระชับขึ้นด้วย

Researcher ในช่วงแรกอาจจะศึกษาคู่แข็งใน Aspect ต่างๆ รวมถึง Business model, Swot Analysis หรือด้านอื่นที่เป็นประโยชน์ต่อการทำงาน และสร้าง foudation ที่แข็งแรงในการ Support แนวคิดและเป็นข้อมูลสำหรับฝ่ายอื่นๆในช่วงที่ทำ Prototyping ก่อนจะนำ Prototype นั้นมาทำ Usability Testing ต่อไป