iUXUI Journey X — get Requirement Process
ได้อ่านบทความของ Designil สองบทความด้วยกัน แล้วเห็นว่าเกี่ยวเนื่อง จึงขอสรุปและเรียบเรียงเพื่อไว้เตือนใจตัวเอง ตอนไปเก็บ requirement หน่อย
4 หัวข้อต้องเตรียมก่อน
1) ขึ้นต้นด้วย introduction script เสมอ
ต้นฉบับอาจจะทางการไปหน่อย ถ้าปรับมาใช้ ก็เป็นการเตรียมบทพูดนำ เพื่อสรุปวิธีการสอบถาม เช่นจะมีการอัดเสียงหรือบันทึกวิดีโอไหม หัวข้อที่จะสอบถามมีเรื่องอะไรบ้าง ซึ่งหัวข้อพวกนี้ควรจะส่งเมล์แจ้งเพื่อให้ทางผู้ใช้เตรียมเอกสารหรือข้อมูลให้ก่อนล่วงหน้า เพื่อความครบถ้วนและรวดเร็ว หรือถ้ารอบนั้นเป็นการนำเสนอ demo หรือ prototype ก็แจ้งไป
2) ต้องการรู้เนื้อหาเรื่องอะไรบ้าง
หากเป็นการเก็บ requirement รอบแรก สิ่งที่ต้องถามจากผู้ใช้ก่อนคือ scope คร่าวๆ ของงาน เพื่อที่เราจะได้หาข้อมูลอ้างอิง เพื่อไปนำเสนอไอเดีย และหารูปแบบร่วมกัน จากนั้นในรอบต่อๆ มา จะเป็นการลงรายละเอียดในแต่ละฟีเจอร์หลังจากที่เราได้ไปออกแบบมาแล้ว หรือนำเสนอ progress ของตัวระบบ
สรุปออกมาเป็นหัวข้อ ตรงไหนจะถามก็โน้ตไว้ ต้องหารือกันในทีมก่อน ก่อนที่จะไปเจอผู้ใช้ และอย่าลืมส่งเมล์แจ้งผู้ใช้ล่วงหน้าก่อนจะไปประชุมเสมอ
3) คนจด คนถาม นั่งสัมภาษณ์ด้วยกันอย่างไรดี
ในส่วนนี้ วิธีที่ทีมใช้อยู่เราจะเน้นคุยจนได้ความเข้าใจตรงกันกับผู้ใช้ และก็จะโน้ตสรุป ใครจะจดส่วนที่สรุปก็ได้ ไม่ได้แบ่งหน้าที่ชัดเจน แต่จะใช้เครื่องมือที่ทุกคนช่วยกันจดได้ ส่วนนี้จะใช้สรุปกับผู้ใช้ตอนท้ายประชุม แต่จะมีอีกส่วนหนึ่งที่จะขอให้แต่ละคนในทีมแยกกันจด เพราะเราอาจมองไม่เหมือนกัน ซึ่งจะใช้สำหรับหารือไอเดียกันในทีม
บางคนอาจจะบอกว่าไม่ดี เพราะอาจจะสับสนกับข้อสรุปที่ได้ วิธีนี้เราแก้ปัญหาโดยการถามกลับไปที่ผู้ใช้ตรงๆ เลยว่าจริงๆ แล้วเป็นแบบไหน เพราะประชุมรอบแรก หัวข้อสุดท้ายที่เราจะทำคือ ชี้แจงว่าเราจะพัฒนาระบบแบบที่ให้ผู้ใช้มีส่วนร่วมในกระบวนการพัฒนามากที่สุด ไม่ว่าจะในเรื่องของการปรึกษาหารือเพื่อออกแบบหรือกระบวนการทดสอบ และก็สร้างไลน์กลุ่ม ที่จะปรึกษากันได้ตรงๆ ตลอดเวลา (แต่เฉพาะในเวลางานเท่านั้นนะ 😁)
ส่วนข้อดีของการต่างคนต่างจด ก็คือ ได้มุมมองที่หลากหลาย ตอนสรุป requirement กับเสนอไอเดียนี่มันส์มาก ซึ่งถ้าอยากได้ทีมแบบนี้ แนะนำว่า ตอนที่เสนอไอเดีย ต้องไม่บอกว่าของใครดีของใครแย่ แต่ให้เหมือนแข่งกัน ทุกคนเสนอได้ และทุกคนช่วยกันโหวด ฉะนั้นถ้าอยากให้คนในทีมโหวดให้ ก็ต้องขายกันหน่อย ต้องตอบทุกคำถามที่ทีมสงสัยว่าทำไมคิดแบบนี้ แต่มันก็มีบ้างที่หลุดกรอบไป อันนี้ก็ต้องคุมกันดีๆ ครับ
4) จดอย่างไรให้นำข้อมูลกลับไปทำงานต่อได้เลย
หัวข้อนี้ ต้นฉบับจะเน้นที่เครื่องมือที่ใช้จด เพื่อนำไปจัดการต่อได้ง่าย ซึ่งที่ทีมใช้อยู่ก็มีเกริ่นๆ ไปบ้างในหัวข้อที่แล้ว แต่ก็ใช้หมด บางคนก็สมุดปากกา บางคนก็ notepad++ บางคนก็สรุปใส่ gitlab ใน google doc ก็มี ซึ่งทั้งหมดก็จะขอให้สรุปใน gitlab อีกรอบ เพื่อไว้สำหรับอ้างอิง
7 ข้อที่ไม่ควรทำ สำหรับ UX Designer
1) เชื่อในสิ่งที่ยังไม่ได้รับการพิสูจน์
อันนี้เป็นกับดักที่มักจะพลาดบ่อยๆ มันคือการที่ถามว่าผู้ใช้ต้องการอะไร และก็เชื่อคำตอบที่ผู้ใช้ตอบมาทันที โดยไม่ได้ไปดูเหตุผลเบื้องหลังในการตอบ โดยเฉพาะคำถามประเภทใช่ไม่ใช่ ชอบอันไหนมากกว่ากัน พวกนี้อันตรายมาก
วิธีแก้คือการถามแบบที่ให้รู้ถึงสิ่งที่ผู้ใช้ต้องการ ทำเพื่ออะไร และก็พฤติกรรมของผู้ใช้เป็นแบบไหน ให้เขาได้เล่าถึงกระบวนการ สังเกตุสิ่งที่เขาทำ เพราะบางการกระทำผู้ใช้ทำโดยไม่รู้ตัวจากจิตใต้สำนึก ต้องเน้นจับประเด็นที่สิ่งที่เขาทำ ไม่ใช่สิ่งที่เขาเล่า
2) เชื่อว่าเราใช้เครื่องมือที่ถูกต้อง
หัวข้อนี้จะเน้นที่การเลือกใช้เครื่องมือเพื่อทำวิจัยกับความต้องการของผู้ใช้ ซึ่งทีมไม่ได้ใช้ 😆 แต่สนใจสองประโยคนี้
Quantitative data ข้อมูลเชิงปริมาณ จะบอกเราว่า WHAT คนกำลังทำอะไร
Qualitative data ข้อมูลเชิงคุณภาพ จะบอกเราว่า WHY ทำไมคนถึงทำสิ่งนี้อยู่
และสรุปตอนท้ายว่า ไม่มีเครื่องมือใดที่ดีที่สุด มันแค่เหมาะกับงานบางอย่าง สำคัญที่เราต้องเลือกใช้ให้เป็น
ตรงนี้ส่วนตัวมองไปถึงไอเดียที่จะมาแก้ปัญหา (การสร้างเครื่องมือให้ user ใช้) บางครั้งฟุ้งกันไปไกล flow อลังการ สุดท้าย user ไม่ใช้ ฉะนั้นเราควรเสนอไอเดียไปให้ user เลือก หมั่นเอางานไปให้เขาดูบ่อยๆ ซึ่งมันก็จะย้อนกลับไปที่ข้อ 1) ก่อนหน้านี้ด้วยว่า อย่าตัดสินแทน user ว่าเขาจะใช้ พิสูจน์ก่อน
3) Bias
Bias แปลว่า ความลำเอียง ลำเอียงในการตั้งคำถาม และลำเอียงในการเสนอผลลัพธ์
ลำเอียงในการตั้งคำถามก็แก้ที่คำถาม เช่น ถามว่า “คุณชอบนอนตื่นสายก็เลยไปทำงานช้าใช่หรือไม่” เป็น “คุณมาทำงานช้าเพราะอะไร” ถามเพื่อเข้าใจ ไม่ใช่จับผิดหรือแปะป้ายว่าเขาเป็นคนแบบไหน
ลำเอียงในการเสนอผลลัพธ์ ต้องแก้ที่ตัวเรา อย่าหลอกตัวเอง ต้องยอมรับความจริงให้ได้ ทำแล้วผู้ใช้ใช้ไม่ได้ หรือมีปัญหา ก็แก้ก็ปรับปรุงให้มันดีขึ้น
4) เก็บข้อมูลที่ได้ไว้ที่เราเพียงคนเดียว
ปัญหาของพวก one man show รู้ครบจบคนเดียว ซึ่งไม่ดี ทีมแก้ปัญหาโดย เน้นให้ทุกคนในทีมมีส่วนร่วมในทุกขั้นตอน เก็บ requirement ก็ยกกันไปทั้งทีม เพราะหลายหัวดีกว่าหัวเดียว และทุกคนต้องเข้าใจ insight ของผู้ใช้ ถึงจะเสนอไอเดียที่ตอบโจทย์ได้ ขั้นตอนออกแบบก็ช่วยกันระดมสมอง ตอนพัฒนาก็พยายามให้จับคู่กันทำ แต่ถ้าไม่ได้จริงๆ ก็ให้ทำเอกสารไว้ให้ทีม และก็นำเสนอเป็นระยะๆ เพื่อที่องค์ความรู้จะได้ไม่หาย กรณีที่คนนั้นหายไปจากทีม
5) ความขี้เกียจ
หัวข้อนี้พูดถึงการนำผลการวิจัยเก่ามาใช้ ถ้ามองในประเด็นที่คล้ายๆ กันของทีมคือการที่เรานำ design เก่ามาใช้ เพราะสถานการณ์ที่ทีมเจอคือวางแผนว่าจะทำโปรเจ็คนี้ช่วงนี้ ก็ไปเก็บ requirement จากนั้นก็ design ระบบกันไว้ แล้วก็โดนงานแทรก จนต้องเบรคงานเก่าไป พองานใหม่เสร็จ จะกลับมาทำโปรเจ็คเก่าก็มาหยิบที่ design กันไว้มาปัดฝุ่นทำต่อ ซึ่งก็มีบางงานที่ต้องไปถามความต้องการกับผู้ใช้ใหม่ เพราะบางครั้ง policy ก็มีการเปลี่ยน
แต่ถ้าพูดถึงความขี้เกียจโดยทั่วไป เชื่อว่าใครๆ ก็มีกันบ้างแหละ เอาเป็นว่ามีแต่พองามละกันนะ ในเรื่องที่ขี้เกียจไม่ได้ก็ขออย่าให้มีกันเลย เดี๋ยวความซวยจะมาเยือน
6) การทำรีเสิร์ชที่คลุมเครือ
หัวใจสำคัญคือความตรงประเด็น คุยกันสองสามชั่วโมงแล้วก็สรุปอะไรไม่ได้เลย อย่าทำ หรือตั้งโจทย์ที่จะถามไปเยอะเกินจนไม่รู้ว่าถามไปเพื่ออะไร นี่ก็อย่าทำ
หารือกันในทีมก่อนว่าจะถามอะไรบ้าง เราอยากได้คำตอบนี้ เพื่ออะไร ถามตอบให้เข้าใจกันทีละประเด็น
7) นำเสนอสิ่งสำคัญของการรีเสิร์ชออกมาไม่ได้
ต่อเนื่องจากข้อที่แล้ว สุดท้ายของกระบวนการสัมภาษณ์หรือเก็บ requirement ก็คือการสรุปความต้องการของผู้ใช้ ต้องสรุปประเด็นให้ทุกคนเข้าใจได้ เห็นภาพ อย่าใส่พวกประเด็นจากคำบ่นมาเป็นฟีเจอร์ให้มันเยอะ มันลำบากคนออกแบบ
จากหัวข้อใน UX Researching ลองบิดๆ มามองในมุมของคนที่ไปเก็บ requirement ทั่วๆ ไป ก็ได้ประมาณนี้แล