Google Design Sprint in 5 days

สวัสดีครับทุกคน วันนี้ผมมีเรื่องเจ๋งๆมาแชร์ จากการไปงาน TechJam Mixer Event นั่นก็คือ Google Design Sprint ซึ่งเป็นหลักการที่ Google เลือกใช้เพื่อให้งานที่ออกมานั้นมีประสิทธิภาพและตอบโจทย์ความต้องการของผู้ใช้งานมากที่สุด ทีมพัฒนาระบบก็แก้ไขงานน้อยและมีข้อผิดพลาดน้อยมาก พร้อมทั้งใช้เวลาในการพัฒนาน้อยมากๆอีก อยากรู้แล้วใช่ไหมครับว่า Google Design Sprint เป็นอย่างไร ตามมาดูได้เลยครับ

Google Design Sprint คืออะไร

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

โดยปกติเวลาเราพัฒนาระบบๆหนึ่ง Process Flow แบบคร่าวๆนั่นก็คือ Idea >Build > Launch > Measure & Learn โดยใช้เวลาประมาณ 3-6 เดือนหรือหากเป็นระบบใหญ่ๆอาจจะใช้เวลาเป็นปีเลยทีเดียว แต่กว่าเราจะรู้ว่าระบบหรือโปรแกรมเราที่ทำออกมามันดีหรือไม่ดี ก็ต้องรอกันถึงช่วง Lanuch แล้วค่อยมา Measure & Learn ว่าผู้ใช้นั้นใช้งานจริงแล้วดีจริงๆหรือไม่ ถ้าไม่ดีก็กลับมาเริ่มต้น Process ที่ Idea กันใหม่

ทีนี้ทาง Google บอกว่า เวลาตรงนี้ใช้เวลามากเกินไป โดยเวลาที่ใช้เป็นจำนวนมากจะอยู่ในช่วง Build และ Launch นั่นเอง แถมใช้ cost มากๆไหนจะค่า Server ค่าโฆษณาให้ผู้ใช้มาใช้งาน ซึ่งยังไม่รู้ว่ามันจะ work จริงๆหรือเปล่าอีก งั้นเรามาตัดมาเหลือแต่ Idea แล้ว Test Idea ก่อนจะ Build ดีกว่าไหม

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

 

เริ่มต้น Day1 วันแห่งการวางแผน

1. List รายชื่อผู้ที่เกี่ยวข้องกับระบบ และขั้นตอนการทำงานของแต่ละคนว่าทำงานอย่างไร งานของแต่ละคนเกี่ยวข้องกันอย่างไร งานชิ้นนี้ต้องรองานนั้นเสร็จก่อนหรือเปล่า เพื่อให้เห็นแผนที่ภาพรวมก่อนให้ได้

2. เมื่อรู้ภาพรวมแล้ว ก็ตั้งคำถามขึ้นมาเป็นแกนหลักเพื่อให้เป็นเป้าหมายที่เราจะทำ เช่น ทำอย่างไรกระบวนการทำงานถึงจะเร็วขึ้น? ทำอย่างไรถึงลดข้อผิดพลาด? เป็นต้น

3. ให้ทุกคนเขียนไอเดียลงในกระดาษ post it มาแปะในกระดาน ซึ่งเป็นหลัก How Might We (HMW concept) นั่นเอง ใครคิด Idea อะไรได้ก็มาแปะๆเอาไว้แบ่งปัน Idea

4. ให้แต่ละคนออกมาอธิบาย Idea ของตนเองให้ทุกคนฟัง

 

Day 2 วันแห่งการลงรายละเอียด

1. Wrap up คำถามที่เป็นเป้าหมายของเมื่อวานและภาพรวมการทำงาน

2. แต่ละคนแยกย้ายลงรายละเอียดของ Idea ตัวเองอย่างเต๋มที่ โดยวาดแนวคิดตัวเองเป็นภาพๆ ว่าแต่ละหน้าจอจะเป็นอย่างไร ซึ่งเป็นการ working alone together เพราะลงรายละเอียดด้วยตัวเอง จะทำให้ Focus กับของตัวเองได้มากกว่ามาคุยพร้อมๆกันเพราะจะถูกรบกวนจาก Idea ของคนอื่น

 

Day 3 วันแห่งการตัดสินใจ

1. เราจะเปลี่ยนจากแต่ละคนมาอธิบายไอเดียของตัวเอง และรอ feedback จากผู้อื่น มาเป็น เอาไอเดียทุกคนนี่แหละมาแปะที่กระดานก่อนเลย

2. ทุกคนเดินมาดู Idea ของผู้อื่นแบบคร่าวๆจนครบทุกคน

3. หากเราชอบไอเดียไหน หรือส่วนไหน หน้าจอไหน ก็ให้เราเอาปากกามาแต้มจุดที่ไอเดียนั้นๆ จะทำให้รู้ว่าทีมสนใจสิ่งไหนเป็นพิเศษ

4. คนชี้นำจะถาม ไอเดียที่โดนจุดเยอะที่สุดกับทุกคนยกเว้นเจ้าของไอเดีย ว่าทำไมถึงชอบสิ่งนี้จนครบหมด เจ้าของไอเดียแต่ละคนจึงออกมาพูดเสริมเพิ่มเติมในส่วนที่คนอื่นยังไม่ทราบหรือเข้าใจผิด

5. เมื่อครบหมดแล้ว แต่ละคนเขียนไอเดียเพิ่มเติม หรือปรับแก้ ของตัวเองลงไปอีกครั้ง

6. ถึงเวลา Vote ให้ทุกคนมา Review ไอเดียแต่ละคนอีกครั้ง ถ้าชอบไอเดียไหน ให้เอาสติ๊กเกอร์มาแปะๆๆ ถ้าหากชอบของตัวเองก็สามารถแปะของตัวเองได้ ย้ำว่าไม่ต้องสนใจคนอื่นว่าแปะอะไร ให้มันมาจากความรู้สึกตัวเองอย่างเดียว เพราะอิทธิพลการเลือกของคนอื่น จนอาจทำให้ Idea ที่ดีไม่ได้ถูกเลือกนั่นเอง

7. ขั้นตอนสุดท้าย!! ผู้ใหญ่หรือผู้ที่มีอำนาจต้องมาตัดสินใจว่าจะเอา Idea ไหน อาจจะรวมไอเดียหลายๆคนมาเป็นสิ่งใหม่ก็ได้ ซึ่งสามารถแบ่งเป็นสองส่วนก็ได้คือ ชุด Idea ที่ Win และ อีกชุดเป็น May be later

 

Day 4 วันแห่งการวาดฝันให้เกิดขึ้นจริง

1. วันนี้เริ่มเอา Idea ที่ตัดสินใจมาสร้างเป็น Prototype คือต้นแบบนั่นเอง ต้นแบบในที่นี้ไม่จำเป็นต้องทำงานได้จริงๆ ทำวาดลงใน Paper เป็นหน้าจอให้สมจริงที่สุด ทำเป็น Step การทำงานของแต่ละหน้าจอ ลายละเอียดต่างๆเช่น เมื่อกดปุ่มแล้วจะมีแท่งโหลดขึ้นมา การเปลี่ยนหน้าจอเคลื่อนจากขวาไปซ้าย เรียกง่ายๆว่าให้ผู้ใช้รู้สึกว่ากำลังใช้งานอยู่จริงๆ ถึงแม้ว่าเป็นเพียงกระดาษ

2. แต่ต้องยกเว้นไว้หนึ่งคนนั่นคือ คนที่จะ Present วันพรุ่งนี้ ห้ามให้คนนี้เข้ามาช่วยทำ Prototype เลย เพราะเมื่อทดสอบกับผู้ใช้งานจริง คนนี้จะมีความรู้สึกเป็นเจ้าของร่วมกับตัว Prototype นั่นเอง แล้วจะทำให้ผู้ทดสอบไม่กล้าแสดงความรู้สึกจริงๆของตนเองนั่นเอง

3. คนที่ Present นำการทดสอบต้องยึดถือเสมอว่า การทดสอบนี้เป็นเพียงเพื่อให้รู้ว่าสิ่งที่คิดออกมานั้นดีจริงๆหรือไม่ และต้องการความมั่นใจมากๆถึงจะค่อยลงทุนทั้งแรงและเวลานั่นเอง

 

Day 5 วันแห่งผลลัพธ์

1. ทุกคนที่ทำมาต้องเปิดใจให้กว้างและยอมรับกับผลลัพธ์ไม่ว่าจะเป็นอย่างไร

2. การสัมภาษณ์ควรเป็นแบบเดี่ยว เพื่อลดความกดดันของผู้ใช้โดยการให้คนอื่นๆรออยู่ห้องอื่นไปก่อน

3. ผู้สัมภาษณ์ ต้องพูดให้ผู้ถูกสัมภาษณ์สบายใจในการทดสอบนี้ เช่น การสัมภาษณ์นี้ไม่ได้เป็นทางการ เพียงต้องการอยากรู้ความคิดเห็นและการปรับปรุงของเรา ถ้าส่วนไหนทำไม่ได้ไม่ถือว่าเป็นความผิดของคุณนะครับ เพราะต้องปรับปรุงต่อไปภายหลัง เป็นต้น

4. ผู้สัมภาษณ์จะขอสัมภาษณ์ข้อมูลเพื่อให้ทราบคร่าวๆว่า ทำงานอยู่แผนกไหน ตำแหน่งอะไร เพื่อให้เราเข้าใจว่าทำไมผู้ใช้งานถึงมีปฎิกริยาแบบนั้น

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

6. เมื่อทดสอบจนเสร็จ เราควรถามคำถามด้วยว่า คุณคิดว่าโปรแกรมนี้ใช้สำหรับทำอะไร เพื่อเป็นการทดสอบการรับรู้ว่าเข้าใจในโปรแกรมเราแบบไหน และง่ายในเรื่องการประชาสัมพันธ์ในภายหลังอีกด้วย

7. เมื่อจบการทดสอบ ให้ทีมงานแต่ละคนเขียนสิ่งที่เจอลงในกระดาษ Post it แล้วเอามาแปะรวมๆกันอีกครั้ง เพื่อรู้ว่าปัญหาไหนที่เห็นเหมือนกันมากที่สุด เราจึงปรับแก้ได้อย่างตรงจุด แต่ถ้าผลการทดสอบเลวร้ายมากอาจจะเอา plan ที่  backup ไว้มาทดสอบอีกครั้ง หรือกลับไปเริ่มที่คิด Idea ใหม่เลยก็ได้

ลองดู Video ตัวอย่างการทดสอบจากตัวอย่างนี้เลยครับ

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

No Comments

Leave a Comment