จาก Jacob Greensphan, UX Coaching ระดับโลก!

สวัสดีค่ะ จากตอนที่แล้ว 4 เรื่อง UX ที่ Startup ทั่วโลกมักผิดพลาด Jacob บอกเราว่าควรเอา Product ของเราไปให้ User หรือผู้ใช้งาน ทดลองใช้งานจริง ๆ ด้วย เพื่อให้เราเรียนรู้ข้อผิดพลาดของเราจากการสังเกตเค้าตอนใช้งาน Product ซึ่งสิ่งหนึ่งที่ Jacob ยังเน้นย้ำมาก ๆ คือ อย่าลืมบอกให้เค้า “Think Aloud” คิดดัง ๆ ให้เราได้ยินด้วย หรือ การให้เค้าพูดสิ่งที่เค้าคิดออกมานั่นเอง แล้วเราจะทำยังไงให้เค้าพูดมันออกมา วันนี้เราจะมาขยายความวีธีการทำให้ User คิดดัง ๆ กัน…

เริ่มต้นจากการสร้างความสบายใจ

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

• จัดสภาพแวดล้อมให้เหมาะสม
  สภาพแวดล้อมค่อนข้างมีผลโดยตรงต่อพฤติกรรม ดังนั้น การตรวจสอบให้แน่ใจว่าสภาพแวดล้อม ห้องที่จะทำการสัมภาษณ์ หรือทำการทดสอบ User นั้น สะอาดและสะดวกสบายสำหรับ User อาจช่วยให้เค้ารู้สึกสบายใจ และพูดสิ่งที่เค้าคิดออกมากับเรามากขึ้นได้ (จริง ๆ หลายคนมองข้ามเรื่องนี้ แต่ Jacob ค่อนข้างให้ความสำคัญ สังเกตได้จากใน Workshop มีการส่งตัวแทนกลุ่มสลับกันทำ Usability Testing แล้วมีกลุ่มหนึ่ง เพื่อนเดินมายืนดู Product แล้วยืนคุยกันตรงนั้น Jacob ก็เดินมาบอกว่า หาเก้าอี้มาให้ User คุณนั่งสิ อย่าลืมทำให้เค้ารู้สึกสบายนะ)
• ต้อนรับอย่างเป็นมิตร
  สิ่งที่ง่ายที่สุดเลยของการเป็นมิตรกับคนที่เพิ่งเจอหน้ากันคือ การยิ้มอย่างจริงใจ สำหรับคนไทยแล้วเรื่องนี้ยิ่งทำได้อย่างง่ายดายมาก ๆ นอกจากการยิ้มตอนรับ แล้วเราอาจชวนเค้าคุยเรื่องทั่วไปเล็ก ๆ น้อย ๆ (Small Talk) เพื่อเป็นการเปิดบทสนทนาอย่างผ่อนคลาย เช่น ถามถึงเรื่องการเดินทางมายังสถานที่สัมภาษณ์ว่าเป็นอย่างไรบ้าง รถติดไหม เป็นต้น
• ย้ำว่าเราไม่ได้ทดสอบคุณ
  สิ่งสำคัญอีกหนึ่งอย่างก่อนเริ่มต้นการทดสอบ คือ เราควรชี้แจงให้ User เข้าใจว่า เราไม่ได้ทดสอบเค้านะ แต่เรากำลังทดสอบ Product, App หรือ Website ของเรา ดังนั้น หากระหว่างที่ทดสอบเค้ากดอะไรผิดพลาด ไม่เป็นอะไรเลย ไม่มีผลใด ๆ สบายใจได้ อีกหนึ่งอย่างที่ช่วยได้ คือ เราบอกเค้าว่า เราไม่ได้เป็นคนที่สร้างตัว Product นี้ขึ้นมา เราเป็นเพียงคนที่ช่วยสัมภาษณ์และทำทดสอบเท่านั้นก็ช่วยให้เค้าเปิดใจพูดกับเราได้มากขึ้น โดยที่เค้าไม่ต้องเกรงใจเรา (แม้ว่าจริง ๆ แล้วในบางครั้ง เราเป็นคนทำเองก็ตาม ฮ่า ๆ )

Think Aloud ไม่ได้มีวิธีเดียว

จริง ๆ แล้ว ถ้าเราหาข้อมูลเกี่ยวกับการทำ Usability Test เราจะพบว่า หลาย ๆ สำนักมักบอกให้ User พูดสิ่งที่เค้าคิดออกมาระหว่างทำการทดสอบ อันที่จริงแล้ว Jacob บอกว่า เราสามารถทำ Think Aloud ได้ 2 วิธี คือ…

1. Concurrent Think Aloud

เป็นวิธีที่คนที่ทำ Usability Testing บ่อย ๆ จะคุ้นเคยกันนี้ วิธีนี้คือการบอกให้ User พูดสิ่งที่คิดในระหว่างที่ทำทดสอบ ไม่ว่าคิดอะไรอยู่ พูดออกมาในตอนนั้นได้หมดเลย

2. Retrospective Think Aloud

วิธีนี้ต่างจาก Concurrent Think Aloud ตรงที่ Concurrent จะให้ User พูดสิ่งที่คิดออกมาระหว่างทำเลย แต่ Retrospective จะปล่อยให้ User ทำ task ที่กำหนด หรือปล่อยเค้าลองเล่นลองกด Prototype จนเสร็จก่อน แล้วจึงถามประสบการณ์ในการทำสิ่ง task นั้น ของเค้า ว่าเป็นอย่างไรบ้าง ให้เค้าพูดออกมาในภายหลัง

ทั้ง 2 วิธีด้านบนจะทำให้เราได้เห็นข้อผิดพลาดของเราจากการทดสอบได้แตกต่างกัน แต่แตกต่างกันอย่างไรนั้น ขออนุญาตพาไปรู้จักความผิดพลาดที่จะเกิดขึ้นในการทำ Usability Testing กันก่อน…

Slips & Mistakes

ในการทำ Usability Testing นั้นจะทำให้เรามองเห็นข้อผิดพลาดที่เกิดจากการที่ User ทดลองใช้งาน product ของเราได้ 2 แบบ…

• Slips
  คือ การที่ User มีความตั้งใจจะทำสิ่งหนึ่ง รู้ว่าตัวเองว่าต้องการจะทำอะไร แต่ไปกระทำอีกสิ่งหนึ่งโดยที่เค้าไม่ได้ตั้งใจ เช่น การพิมพ์คำผิด จาก ‘ขอบคุณครับ’ เป็น ‘ชอบคุณครับ’ เพราะมือไปโดนปุ่มตัวอักษร ‘ช’ ที่อยู่ใกล้กับ ‘ข’ โดยไม่ได้ตั้งใจ เป็นต้น
• Mistakes
  คือ การที่ User มีความตั้งใจที่ผิดตั้งแต่ต้น หรือ เรียกได้ว่า เข้าใจผิด เลยกระทำสิ่งนั้นด้วยวิธีการที่ผิด เช่น การตั้งใจพิมพ์คำว่า ‘นะค่ะ’ มีไม้เอก เพราะไม่รู้ว่าคำที่ถูกต้องคือ ‘นะคะ’ ไม่ต้องมีไม้เอก นั่นเอง (ใครอ่านบทความนี้แล้วยังเขียนผิด ตีมือ นะคะ 55555)

Concurrent vs. Retrospective Think Aloud

ตามที่ได้กล่าวไปข้างต้น ว่าสองวิธีนี้ จะทำให้เราเห็นข้อผิดพลาดที่แตกต่างกันคือ….

Concurrent think aloud จะทำให้เห็นข้อผิดพลาดที่เป็น Slips มากกว่า Mistakes และ feedback ที่เราได้จาก User ก็จะเป็นลำดับขั้นตอนตาม task และ flow ที่เรากำหนดมากกว่า ในขณะที่ Retrospective think aloud ทำให้เราเห็น Mistakes ที่จะเกิดขึ้นได้มากกว่า Slips และได้ feedback จาก User ที่เป็นภาพรวมของระบบ หรือ Flow มากกว่า

แล้วเลือกใช้ทั้ง 2 วิธี ยังไงดี

การเลือกใช้วิธี Think Aloud ทั้งสองแบบ ก็มีข้อดีข้อเสียต่างกัน ขึ้นอยู่กับว่า Usability Testing นั้น เราอยากจะรู้อะไร เลยขอสรุปเป็นข้อแนะนำในการใช้ Think Aloud ทั้ง 2 วิธีดังนี้…

Concurrent Think Aloud

เหมาะสำหรับการทดสอบที่ต้องการความเข้าใจการใช้งานของ User ในรายละเอียดแต่ละขั้นตอน แต่ละจุด หรือใน Usability Testing ที่เราอยากโฟกัสผลลัพธ์แบบ step-by-step

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

Retrospective Think Aloud

เหมาะสำหรับการทดสอบที่ต้องการความเข้าใจในการใช้งานของ User แบบภาพรวมการใช้งาน หรือ ภาพรวมของ Flow นั้น ๆ

• ข้อดี
  การปล่อยให้ User นั้นได้ลองผิดลองถูกด้วยตัวเองโดยไม่โดนขัดจังหวะ ทำให้เราเข้าใจระบบความคิด ความเข้าใจของเค้าที่มีต่อ Product และใกล้เคียงกับสิ่งที่จะเกิดขึ้นจริงเวลาที่ User ใช้ Product เราจริง ๆ ได้มากกว่า
• ข้อเสีย
  การให้เค้าพูดในสิ่งที่เค้าคิดและถามความคิดเห็นเค้าทีหลังจากจบ task หรือ flow อาจทำให้เค้าลืมสิ่งที่เค้าคิดหรือรู้สึกระหว่างที่ทำทดสอบได้เช่นกัน

Tips เพิ่มเติม

• ระหว่างที่ทำ Usability Testing นั้น เราต้องระวังเป็นอย่างมากที่จะไม่ชี้นำ Guide User หรือช่วยเหลือเค้า ว่าเค้าต้องกดหรือทำอะไรต่อ เพราะถ้าเราช่วยเค้าเราจะไม่ได้ผลลัพธ์ที่แท้จริงจากเค้า
• ถ้าหาก User เค้าเกิดติดขัดจริง ๆ ระหว่างการทดสอบ และไปไหนไม่ได้ ก็อย่าปล่อยเงียบจนเกิด Dead Air หรือ ทำให้เค้ารู้สึกอึดอัด หรือกลัว เราต้องทำให้เค้าสบายใจ ว่าไม่เป็นไรนะ อาจจะชวนเค้าคุย ว่าถ้าเหตุการณ์นี้เกิดขึ้นจริง และเค้าไปต่อไม่ได้จริง ๆ เค้าจะทำยังไงต่อ เพื่อให้เค้ารู้สึกว่าเค้าไม่ได้ผิดนะและเราอยากเข้าใจเค้าจริง ๆ ว่าเวลาแบบนี้เค้าจะใช้งานตัว Product ของเรายังไง
• หากเจอคนที่สงสัยและถามเยอะมาก ๆ ดูแล้วว่าเค้าต้องการคำอธิบายตอนนั้นจริงๆ พยายามอย่าเพิ่งอธิบาย ณ ตอนนั้น เราอาจจะถามย้อนกลับว่า แล้วเค้าคิดว่ามันเป็นแบบไหน คิดว่ายังไง โดยบอกว่า ความคิดเห็นของเค้าไม่มีถูกไม่มีผิดสามารถบอกมาได้เลย เราอยากเข้าใจว่าเค้าคิดเห็นอย่างไร แล้วเราจะขอไปเฉลยในตอนหลังจบการทดสอบแทน

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

Happy Designing : )

How to run think aloud? — บอกให้ User คิดดัง ๆ ทำยังไงดี was originally published in Hato Hub on Medium, where people are continuing the conversation by highlighting and responding to this story.

เมื่อไม่นานมานี้พี่ Darin Suthapong (Eng) CEO ของเรามีโอกาสได้สัมภาษณ์คุณ Jacob Greensphan ผู้เชี่ยวชาญด้าน UX/UI และยังเป็นโค้ชให้กับ Startup ชื่อดังระดับโลกมาแล้วทั่วโลก! ซึ่ง Jacob ได้พูดถึง 4 เรื่อง ทางด้าน User Experience ที่ Startup ทั่วโลกมักจะทำผิดพลาดกันบ่อย ๆ จะมีอะไรบ้างนั้น ตามไปดูกันเลยยย (ยาวหน่อยนะคะ 😅)

1. ไม่ไปทดสอบกับผู้ใช้งานจริง

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

Jacob เลยแนะนำเลยว่า เราควรพูดคุยกับ user อย่างสม่ำเสมอ และควรออกไปเจอ user ด้วย เอา Product ของเราไปให้เค้าทดลองใช้งานจริง ๆ (Usability Testing) เพื่อให้เรามั่นใจได้ว่า Product ของเรามีคนใช้งานที่ถูกคนจริง ๆ และเพื่อให้เราเรียนรู้ข้อผิดพลาดของเราจากการสังเกตเค้าตอนใช้งานด้วย

นอกจากนี้ Jacob ได้เสริมเรื่องการทำ Usability Testing เพิ่มเติมให้อีกด้วย อย่างแรกเลยเราต้องเข้าใจก่อนว่าการทำ Usability Testing นั้น ไม่ใช่การทำวิจัยอย่างในมหาวิทยาลัยทั่วไป แต่เป็นการทำวิจัยที่เน้นการลงมือปฏิบัติจริง ๆ และใช้เวลาอย่างมากก็เพียงแค่ 1–2 วันเท่านั้น (ไม่มากเลยเห็นมั๊ย) ซึ่งเราสามารถค้นหา Guideline ได้มากมายจากเว็บไซต์ต่าง ๆ แต่ส่วนใหญ่แล้วหลักที่สำคัญก็มักจะมีดังต่อไปนี้…

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

อันดับต่อมา ก็คือเราต้องเลือก task ที่เราอยากจะให้ user ทดสอบ โดย task ที่เราเลือกมานั้นก็ต้องครอบคลุมคำถามที่เราตั้งไว้ในตอนต้นด้วย

หลังจากนั้น เราก็ต้องเตรียมตัวเราให้พร้อม โดยการเตรียมแนะนำตัว คำอธิบาย และเตรียมคำถามที่เราจะถาม user ให้พร้อม

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

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

สุดท้าย อย่าลืมที่จะขอบคุณที่เค้าสละเวลามาให้เราด้วย แล้วก็ บ๊ายย บายย

อาจจะดูยาก แต่จริง ๆ แล้วไม่ยากเลย ถ้าเราทำอย่างถูกต้อง เราจะเรียนรู้อะไรได้มากเลยจากตรงนี้

2. ไม่มี Mental Model ที่ชัดเจน

Startup ส่วนใหญ่มักจะให้ความสนใจไปกับ Product ของตัวเองซะส่วนใหญ่ ผู้บริหารมักจะคิดว่าเค้ารู้จักและเข้าใจ Product ของตัวเองเป็นอย่างดี รู้ว่ามันทำงานยังไง รู้ดีว่า user ใช้งานยังไง ซึ่งจริง ๆ แล้ว user เค้าไม่รู้! 😵 แล้วมันไม่ได้เป็นอย่างที่เราคิด! ในทาง UX เราเรียกซึ่งนี้ว่า Mental Model ซึ่งก็คือ ความเข้าใจของ user เกี่ยวกับ Product ซึ่งโดยทั่วไปแล้ว Mental Model จะประกอบขึ้นมาจากความเข้าใจ 4 อย่าง คือ

1. How it’s built?
2. Why it’s built this way?
3. How it works?
4. Why it works this way?

หลังจากที่เราเข้าใจว่า user จะสร้าง Mental Model ขึ้นมา เราก็จะเข้าใจได้ทันที ว่า Mental Model ที่ user สร้างขึ้นมานั้น ตรงกับสิ่งที่เราคิดหรือไม่ เค้าเข้าใจตัว Product ของเรามากน้อยแค่ไหน หรือ ไม่เข้าใจเลย ซึ่งก็จะทำให้เราเข้าใจ Mental Model ของ user ด้วย

ดังนั้นการสร้าง Mental Model ที่ถูกต้องสำหรับ user เป็นสิ่งที่ดีมากกกกๆๆๆ แล้วเราจะสร้าง Mental Model ที่ดีได้อย่างไร​? Jacob ก็บอกว่า เมื่อเราเข้าใจ Mental Model ให้เราลองย้อนกลับไปดู Mental Model ของ Product เราดูว่าเป็นอย่างไร หรือลองให้ userใช้ app แล้วให้เค้าอธิบายกับเพื่อนหรือใครก็ได้ว่า Product นี้เกี่ยวกับอะไร ใน 40 วินาที หรือ 1 นาที การทำแบบนี้จะสะท้อนให้เราเห็นว่า user มี Mental Model เป็นอย่างไร ซึ่งถ้าเค้าสามารถอธิบายตัว Product ให้กับคนที่ไม่เคยใช้ ไม่เคยเห็น Product มาก่อนเลย ได้อย่างถูกต้องก็แสดงว่า Product ของเรามี Mental Model ที่ทำงานได้ดีใช้ได้เลยย

Jacob ยังยกตัวอย่าง Mental Model ให้เราเข้าใจได้ดียิ่งขึ้นด้วย เช่น Smartphone เราก็จะคิดว่า มันเป็นโทรศัพท์ที่ฉลาด (smart + phone ) ซึ่งจริงๆ แล้วมันแทบจะไม่ใช่โทรศัพท์แล้ว แต่ว่า Mental Model เรายังคิดว่ามันคือ smart + phone อยู่ คือ โทรศัพท์ที่ต่อกับอินเตอร์เน็ท แล้วเราก็สามารถใช้ App ได้ ทีนี้เรามาลองวิเคราะห์ Mental Model ของ smatphone กัน

1. How it’s built?
   มันสร้างมาจากโลหะซึ่งมีหน้าจอที่ฉลาดมาก และสัมผัสได้ (Touch Screen)
2. Why it’s built this way?
   เพื่อให้เราใช้ App ได้ ผ่าน Internet และอื่น ๆ
3. How it works?
   มันเป็นโทรศัพท์ที่ถูกพัฒนามาให้เชื่อมต่อข้อมูลกับสิ่งที่เรียกว่า Cloud ซึ่งข้อมูลจะไปและกลับจาก Cloud (เปรียบเทียบได้กับน้ำฝนที่ตกลงมาแล้วน้ำก็ระเหยขึ้นไปเป็นก้อนเมฆ เป็นท้องฟ้า)
4. Why it works this way?
   เพื่อให้เราทำหลายๆ อย่าง บนโทรศัพท์มือถือได้

แล้วมันเป็นโทรศัพท์อยู่มั๊ย?​ ทั้ง ๆ ที่ จริง ๆ แล้วส่วนใหญ่เราใช้มันไปทำอย่างอื่น เช่นใช้งาน Web และ App มากกว่าการใช้งานเป็นโทรศัพท์สำหรับการติดต่อสื่อสารด้วยซ้ำ (คือแทบจะเป็นคอมพิวเตอร์ได้แล้ว) แต่เราก็ยังเรียกมันว่าเป็นโทรศัพท์ smartphone อยู่ เพราะ Mental Model ของเราเข้าใจว่ามันคือ smart + phone และมันก็ยากที่จะเปลี่ยนแล้ว

โดยสรุปแล้ว Mental Model ก็คือการทำให้ user เข้าใจว่า Product เราคืออะไร และใช้งานยังไง ซึ่งถ้าเราเช้าใจมัน เราจะรู้ว่า Product หรือ Service เรามีคุณค่ายังไงกับ user บ้าง ถ้าเราไม่เข้าใจ เราก็ไม่รู้ว่าทำไมมันถึงดีสำหรับ user ของเรา แต่ถ้าเราเข้าใจมันอย่างชัดเจนมันจะมีประโยชน์มาก นั่นคือ เราก็จะเข้าใจว่ามันต้องใช้งานยังไงตาม Mental Model และเข้าใจว่าทำไมมันถึงดีสำหรับ user ของเราอีกด้วย เพราะฉะนั้นถ้า Mental Model ของเราตรงกันกับที่ user เขาใจ ก็จะได้ประโยชน์ทั้งสองฝ่าย

3. ไม่ใช้ data ที่มี

Startup ส่วนใหญ่ใช้ analytic tools ซึ่งมีอยู่มากมายอยู่แล้ว แต่มักจะไม่ค่อยดูมันอย่างจริงจัง มันหมายความว่าอะไร หมายความว่า พอเวลาเค้าคิดจะปรับปรุงตัวแอป ก็จะคิดเอาเองว่า pain point ของ user อยู่ที่จุดไหน สมมติคิดว่าอยู่จุด a, b และ c แต่ความจริงแล้ว พอเราไปดู data จริงๆ จะพบว่า user จะออกจากแอปไปที่จุด a และ f ซึ่งสำหรับ startup แล้วมันทำให้เราเสียทั้งเวลาและเงิน ตรงจุด b และ c ก็อาจจะมีปัญหาก็จริง แต่มันไม่ใช่ปัญหาหลัก ๆ ที่ควรจะแก้ไขก่อน Jacob เจอกรณีแบบนี้บ่อยมากเลย นั่นคือ pain point เหล่านี้ถูกมองข้ามไป เพียงเพราะไม่ได้ดู data ที่แท้จริง

จริงๆ แล้วหากย้อนกลับไปดู data ที่ว่า มันก็คือสิ่งที่เราเรียกว่า Funnel นั่นเอง สมมติว่าเราย้อนไปดู Funnel เราอาจจะพบว่า ในคน 100% ที่ดูเว็บของเรา จะมี 75–100% ที่ดาวน์โหลดแอป มี 50% ที่สมัครสมาชิก มี 23% กรอกข้อมูลบัตรเครดิต 22% สั่งสินค้าของเรา ซึ่งเราจะเห็นได้ชัดเลยว่าตรงจุดไหนที่จำนวน user ตกลงไปเยอะมาก และตรงไหนที่มีปัญหา ตรงไหนที่น่าจะเป็น pain point แต่ว่า startup ส่วนใหญ่ไม่ดู data ของตัวเองกัน ทั้งที่มันเป็นสิ่งที่มีอยู่แล้วและหาได้ง่ายมาก เพราะฉะนั้นอย่าลืมที่จะใช้มันซะ!

4. มองข้าม Emotion

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

ในทางกลับกันมันก็มีความรู้สึกในเชิงลบด้วยเช่นกัน หรือที่เรียกว่า Negative Emotion ซึ่ง Nagative Emotion นี้ หากเกิดขึ้นแล้วจะถูกจดจำไปนานกว่า Positive Emotion ซะอีก เพราะฉะนั้นพยายามหลีกเลี่ยงอะไรที่จะทำให้เกิด Negative Emotion กับ user ด้วย

Jacob ยังแนะนำให้ลองดูเพิ่มเติมเกี่ยวกับ Emotional Map ด้วย แล้วลองวิเคราะห์อารมณ์ของ user เพราะแม้ว่าเราทำแอปที่มี UX/UI ดีมากกกก ๆ ซึ่งแน่นอนว่า user จะต้องรู้สึีกดีมากแน่ ๆ แต่ว่าอารมณ์ของมนุษย์นั้นมันซับซ้อนมากกว่าดีหรือไม่ดี บางอย่างเรารู้สึกรัก บางอย่างไม่ชอบ บางอย่างรู้สึกกลัว บางอย่างรู้สึกโกรธ เป็นต้น ดังนั้นสำหรับ Startup แล้ว Jacob แนะนำว่าควรวิเคราะห์เรื่องอารมณ์มาก ๆ และยังเน้นย้ำให้ดีไซน์ออกมาในทางที่ดี อย่าใช้ในทางที่ผิด

สรุปก็คือ…

1. เราควรเอา Product ไปให้ user ลองใช้งานจริง ๆ และสังเกตการใช้งานของเค้า
2. หา Mental Model ของ Product ให้เจอ และต้องแน่ใจว่า user เข้าใจ Mental Model ของเราเหมือนกัน
3. ใช้ data ที่มีอยู่ให้เกิดประโยชน์ เอามาดูให้แน่ใจว่า pain point ของ user อยู่จุดไหน ของ funnel อย่าเดาเอาเอง
4. อย่าลืมว่าอารมณ์มีผลต่อการตัดสินใจมาก ๆ ดังนั้นจงวิเคราะห์อารมณ์ของ user ตอนใช้งาน product เราให้ดี และใช้ไปในทางที่เหมาะสม

จากคำแนะนำที่ Jacob กล่าวมาด้านบน ทั้ง 4 ข้อนั้น เป็นประโยชน์มาก ๆ สามารถนำไปใช้ได้จริง ไม่เพียงแต่ startup เท่านั้น บริษัททั่ว ๆ ไปก็สามารถนำไปประยุกต์ใช้ได้เช่นกัน ต้องขอบคุณ Darin Suthapong (Eng) อีกครั้งที่นำสาระดี ๆ จาก คนระดับโลกมาแบ่งปันให้ทุกคนได้ฟังค่ะ 😊

หากใครอยากติดตามเนื้อหาดี ๆ แบบนี้ สามารถไปติดตามฟังกันได้ที่ Podcast: Life Booster ได้เลยยย สามารถฟังได้หลายช่องทาง จิ้มเล้ยยย 😁👇

Soundcloud | Spotify | iTunes

Happy Designing :D

4 เรื่อง UX ที่ Startup ทั่วโลกมักผิดพลาด was originally published in Hato Hub on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

มาเข้าเรื่องกันเลย…

Persona คืออะไร

หลายคนอาจจะเคยได้ยินคำว่า Persona มาบ้างแล้ว แต่สำหรับคนที่กำลังสงสัยอยู่ว่ามันคืออะไร ถ้าพูดให้เห็นภาพกันง่าย ๆ ก็คือ การที่เราไปหยิบใครคนใดคนหนึ่งออกมาจากกลุ่ม Target User หรือกลุ่มลูกค้าของเรา เอามาตั้งเป็นตัวแทนของกลุ่ม โดยทั่วไปแล้วใน หนึ่ง Product ไม่จำเป็นจะต้องมี Persona แค่คนเดียว อาจมีหลาย Persona ได้ ขึ้นกับว่า Target User ของเรามีพฤติกรรมและความต้องการต่างกันแค่ไหน ซึ่งการสร้าง Persona ขึ้นมาก็จะคล้ายกับตอนที่เราสร้างตัวละครในเกมส์ The Sims นอกจากตัวตนรูปร่างหน้าตาแล้ว เราก็ต้องใส่ลักษณะนิสัยและคุณลักษณะอื่น ๆ ให้กับตัวละครของเราด้วย จะช่วยทำให้ Persona ของเรามีความชัดเจนมากยิ่งขึ้น

ทำไมเราต้องมี Persona

ในยุคที่หลาย ๆ บริษัทเริ่มหันมาให้ความสำคัญกับ User Experience และแข่งขันกันด้วยประสบการณ์ของผู้ใช้งานกันมากขึ้น เราจะทำอย่างไรถึงจะทำให้ Product ของเรามี Experience ที่ดีที่สุดให้กับผู้ใช้งาน คำถามแรก ๆ ที่เราควรตอบให้ได้เลยคือ…

เราทำ Product หรือ Service นี้ เพื่อใคร?

เรารู้จักเขาดีแล้วหรือยัง เขาทำอะไร?

แล้วทำไมเขาถึงต้องมาใช้ Product ของเรา?

หากคุณยังตอบคำถามเหล่านี้ไม่ได้ Persona คือ คำตอบค่ะ :)

เจ้า Persona ที่ว่านี้ จะช่วยทำให้เราเข้าใจ Target User ของเรามากยิ่งขึ้น แน่นอนว่ายิ่งเราเข้าใจลูกค้าของเรามากเท่าไหร่ เราก็จะสามารถออกแบบ Product หรือ Experience ที่ตอบโจทย์ความต้องการของลูกค้าได้มากขึ้นเท่านั้น ซึ่งจะทำให้ Product ของเรามีโอกาสที่จะประสบความสำเร็จสูงและสามารถคงอยู่ในตลาดได้นาน

แต่ในบางครั้ง Persona อาจไม่ได้ถูกให้ความสำคัญเท่าที่ควร ทั้ง ๆ ที่ความเป็นจริงแล้วจะเห็นได้ชัดว่า Persona ไม่ได้เป็นเพียงตัวอ้างอิงในแง่มุมของการออกแบบ Experience ให้กับกลุ่มผู้ใช้งานเท่านั้น แต่ยังเป็นส่วนสำคัญสำหรับฝั่ง Business และทีม Developer ด้วย โดยเจ้า Persona นี้จะช่วยทำให้ทุกคนในทีมเห็นภาพได้ตรงกันและชัดเจนมากยิ่งขึ้น ว่าบุคคลที่เป็นผู้ใช้งาน Product หรือ Service ของเราคือใคร และมีพฤติกรรมอย่างไร เมื่อทุกคนเห็นภาพตรงกันก็จะทำให้ทั้งทีมเห็นทิศทางของ Product ที่ชัดเจนและ move ไปข้างหน้าได้เร็วขึ้น นอกจากนี้เราอาจใช้ Persona เป็นตัวช่วยในการตัดสินใจที่จะทำหรือไม่ทำฟีเจอร์บางอย่างได้ เช่น ฟีเจอร์ที่ไม่ได้ตอบโจทย์ของ Persona ที่เรากำลังโฟกัสอยู่ตอนนี้ เราก็อาจจะยังไม่ต้องรีบทำและข้ามไปก่อนได้ ซึ่งก็ช่วยให้ฝ่าย Develop ไม่ต้องลงแรงเหนื่อยอีกด้วย

User Persona vs. Buyer Persona(Customer Persona)

จริงๆ แล้ว Persona ไม่ได้มีแค่ User Persona สำหรับฝั่ง Design อย่างเดียวเท่านั้น แต่ยังมี Persona ที่ฝั่ง Business หรือ Marketing ใช้อีกด้วย ซึ่งอันนั้นเราจะเรียกว่า Buyer Persona หรือที่บางครั้งก็เรียกว่า Customer Persona หรือ Marketing Persona ซึ่งความแตกต่างระหว่าง User Persona และ Buyer Persona ก็ตรงตัวตามชื่อเลย…

User Persona

เป็น Persona ของผู้ “ใช้ ” Product หรือ Service ซึ่งจะแบ่งตามพฤติกรรมการใช้งานเป็นส่วนใหญ่

Buyer Persona

เป็น Persona ของฝั่งผู้ “ซื้อ” Product หรือ Service โดย Buyer Persona อาจจะแบ่งตาม Market Segment ของฝั่ง Business

ในบางครั้งคนที่ซื้อ Product ก็อาจจะไม่ใช่คนที่ใช้งานจริง ๆ เช่น คอร์สสอนเด็กเล่นดนตรีออนไลน์ คนที่ใช้งานจริง ๆ จะเป็นเด็ก แต่คนที่จ่ายเงินซื้อจะเป็นผู้ปกครองของเด็ก จะเห็นว่าทั้ง Persona ทั้งสองฝั่งค่อนข้างแตกต่างกัน ดังนั้นเวลาเราจะออกแบบ Product เราก็จะยึด User Persona เป็นหลัก แต่ในบาง Product เช่น ใน Product ที่ฝั่ง Business แบ่ง Market Segment ด้วยพฤติกรรมของ User ก็จะทำให้ทั้ง User Persona และ Buyer Persona ก็มีความใกล้เคียงกันหรือแทบจะเป็นกลุ่มเดียวกันได้ ระวังสับสนนะคะ หากสามารถแยก User Persona กับ Buyer Persona ออกจากกันได้ ขอแนะนำให้แยกกันจะดีกว่า เพราะว่าเวลานำไปใช้เราจะใช้โฟกัสต่างจุดกัน และเวลาใช้งานก็มองจากคนละมุมอีกด้วย

Persona หน้าตาเป็นยังไง

ก่อนจะสร้าง Persona มาลองดูก่อน ว่าสิ่งที่เราจะสร้างหน้าตามันเป็นยังไง หากเราลอง Search คำว่า “Persona” ใน Google เราจะพบว่า Persona มีหลากหลายรูปแบบมาก และหัวข้อต่าง ๆ ที่อยู่ใน Persona นั้นก็มีความแตกต่างกัน ซึ่งจริง ๆ แล้ว Persona ไม่มีรูปแบบตายตัว ขึ้นอยู่กับว่าเราอยาก Focus ตรงจุดไหน หัวข้อไหนที่เกี่ยวเนื่องกับ Product เราบ้าง แต่หลัก ๆ แล้ว Persona ควรมีข้อมูล 2 ส่วนที่สำคัญดังนี้

Demographic

เป็นข้อมูลส่วนตัวพื้นฐาน เช่น ชื่อ อายุ เพศ อาชีพ การศึกษา รายได้ สถานภาพสมรส เป็นต้น ซึ่งข้อมูลนี้อาจรวมไปถึงลักษณะนิสัย พฤติกรรม และรายละเอียดเกี่ยวกับสภาพแวดล้อมของซึ่งอาจจะส่งผลต่อพฤติกรรมที่เกี่ยวข้องกับตัว Product เราด้วย

Psychographic

เป็นเรื่องของรายละเอียดเชิงจิตวิทยาซึ่งมีผลต่อพฤติกรรมที่เกี่ยวข้องกับตัว Product เช่น attitude, needs , motivation, pains หรือ gains เป็นต้น

แล้วจะเริ่มต้นสร้าง Persona จากตรงไหนดี

เคยเป็นหนึ่งคนที่ไม่รู้จะเริ่มทำ Persona ยังไงเหมือนกัน เลยขอสรุปมาเป็นขั้นตอนที่น่าจะได้ผลลัพธ์ที่ถูกต้องและเข้าใจง่ายมา 5 ขั้นตอนดังนี้

1. เก็บเกี่ยวข้อมูลที่เรามี

เริ่มต้นง่าย ๆ จากข้อมูลที่เรามีก่อน ซึ่งในโลกของข้อมูลนั้น ข้อมูลของ User จะถูกแบ่งออกเป็น 2 ประเภท คือ

• Quantitative Data เป็นข้อมูลเชิงปริมาณ ได้แก่ พวก จำนวน ตัวเลข เปอร์เซ็นต์ต่าง ๆ ซึ่งก็คือข้อมูลที่เป็น Demographic ทั่วไปและ Behavior ของ User โดยข้อมูลพวกนี้ เราสามารถหาได้จากระบบและการ Tracking Analytics ต่าง ๆ
• Qualitative Data เป็นข้อมูลเชิงคุณภาพ จะไม่สามารถบอกเป็นปริมาณตัวเลขได้ ส่วนมากจะเป็นข้อมูลที่เป็น Phychographic ซึ่งเราไม่สามารถดูได้จากระบบ อาจจะต้องทำ User Reseach เพิ่มเติมเพื่อหาข้อมูลตรงจุดนี้

หาก Product ของคุณมีการเก็บข้อมูล Analytics หรือ Tracking ต่าง ๆในระบบอยู่แล้ว นับว่าโชคดี เพราะเราสามารถใช้ข้อมูลที่มีนี้ ไปต่อยอดได้เลย

แต่ถ้าหาก Product ของคุณนับว่ายังใหม่อยู่มาก ก็ไม่ต้องกังวลไป เราสามารถเก็บข้อมูลที่เราเรียกว่า พอจะมี ได้จากทุกคนในทีมนั่นเอง เช่น อาจจะทำ User Segment คร่าว ๆ ภายในทีม โดยให้ทุกคนในทีมช่วยเขียนข้อมูลของ User ที่เขาคิดไว้ ลง post-it หลังจากนั้นนำข้อมูลมาจัดกลุ่ม จากภาพ User ที่ตอนแรกเราเบลอ ๆ เราจะมองเห็นภาพได้ชัดขึ้นว่า User ในใจเรามีลักษณะอย่างไร แต่นั่นก็ยังไม่ใช่ข้อมูลที่ถูกต้อง 100% นะคะ เราต้องนำข้อมูลที่ได้นี้ ไปตรวจสอบกับ user จริงๆ อีกครั้ง

2. เตรียมตัวให้พร้อม ตามหาข้อมูลที่เราไม่มี

จะเห็นว่าข้อมูลที่เราได้มาเบื้องต้นนั้น ยังมีข้อมูลบางส่วนที่เรายังขาดอยู่ เราจึงต้องออกไปทำ User Research หรือการสัมภาษณ์ User เพิ่มเติมเพื่อเก็บ Insight จาก User ของเราจริง ๆ ซึ่งการทำ User Research นั้น ก็จะคล้ายกับการทดลอง เราตั้งสมมติฐานขึ้นมา มีตัวแปรต้น ตัวแปรตาม และตัวแปรควบคุม ในที่นี่เพื่อไม่ให้ผลการทดลองของเราแกว่งไปมา เราจึงต้องกำหนดตัวแปรควบคุมให้กับการทำ Reseach ของเราสักหน่อย ซึ่งก็คือ User Screener นั่นเอง

โดยปกติแล้ว เราจะกำหนดให้ข้อมูล Quantitative เป็น User Screener หลัก เพราะเป็นข้อมูลเดียวที่ได้จากระบบและเป็นข้อมูลถูกต้องที่สุดที่เรามี ณ ขณะนั้น ส่วนพวก behaviour ต่าง ๆ ซึ่งอาจจะได้มาตอนทำ User Segment จะนำมากำหนดให้เป็น Screener รอง โดยทุก behavior ที่เราเลือกมาเป็นตัว Screener นั้น ต้องเป็นสิ่งที่มีอิทธิพลต่อ User ในการตัดสินใจว่าจะใช้หรือไม่ใช้ Product ดังนั้นเราก็จะได้ User Screener มาคร่าว ๆ เช่น User Screener ของ Spotify อาจจะเป็น ผู้ชาย, อายุ 25 ปี, เงินเดือน xx,xxx, มีบัตรเครดิต และชอบฟังเพลง เป็นต้น

เมื่อเราได้ User Screener มาแล้ว ขั้นตอนต่อไปคือ ใช้ User Screener นี้ไปคัดคนมาสัมภาษณ์ซึ่งจะทำให้เราได้คนที่เป็น Target User ของเราจริง ๆ นอกจากนี้ยังช่วยให้ผลลัพธ์ที่เราได้ถูกต้องและไม่กระจัดกระจายไปหลายทางอีกด้วย หลังจากที่ Screen แล้วก็สามารถสัมภาษณ์ User เพื่อหาข้อมูล insight ในส่วนที่เป็น Qualitative Data เช่น attitude, needs , motivation, pains หรือ gains ที่เรายังขาดอยู่ ได้เลย

การแบ่งข้อมูลเป็น 2 ส่วนที่ชัดเจน คือ ตัว User Screener และ ข้อมูล Qualitative Data ที่เราต้องการหา จะช่วยเช็คข้อมูลซึ่งกันและกัน ซึ่งจะทำให้จะรู้ว่า อะไรที่ยังขาดยังไม่ครบ หรือยังไม่แน่ใจ เช่น มี User 5 คนที่เราใช้ User Screener เป็นตัวเดียวกัน แต่ผลลัพธ์ออกมา มี Motivation ไม่เหมือนกัน แสดงว่า User Screener ของเราอาจจะยังไม่ละเอียดเพียงพอ ต้องแตกรายละเอียดข้อมูลของ Screener เพิ่มเติม เป็น Screener A และ Screener B หรืออาจหมายความว่าเราอาจยังสัมภาษณ์น้อยเกินไปหรือสัมภาษณ์แล้วได้ข้อมูลผิดก็เป็นได้ คือยังไม่เจอส่วนที่เหมือนกัน ๆ กัน นั่นเอง ก็อาจจะต้องสัมภาษณ์เพิ่มเติม

3. วิเคราะห์รูปแบบของพฤติกรรมและสรุปเป็น Persona

หลังจากที่ได้ผลลัพธ์มาแล้วทั้ง 2 ส่วน คือ ตัว User Screener และ ข้อมูล Qualitative Data ที่ได้มาจากการสัมภาษณ์ เราก็เอาทั้งสองส่วนมารวมกัน จะทำให้เรามองเห็นรูปแบบของพฤติกรรม หรือ Pattern อะไรบางอย่างของกลุ่มคน ที่มีความเหมือน ๆ กัน เช่น พบว่าคนที่มาจาก Screener A จะมี พฤติกรรม A ที่เหมือน ๆ กัน หรือ คนที่มาจาก Screener B จะมี Motivation B ที่เหมือน ๆ กัน เป็นต้น ซึ่งเราจะใช้ตัวนี้แหละ แบ่ง User ออกมาเป็น Persona ต่าง ๆ เมื่อหา Pattern เจอเรียบร้อยแล้วเราก็สรุปเป็นหน้าตา Persona ตามตัวอย่างด้านบนไว้ เพื่อนำไปใช้งานต่อไป

4. จัดลำดับความสำคัญให้ Persona กันหน่อย

ในหลาย ๆ Product นั้น Persona ไม่ได้มีแค่อันเดียวแต่มีหลาย Persona ซึ่งการจะนำ Persona ไปใช้ให้เกิดประโยชน์จริง ๆ นั้น เราควรจัดลำดับความสำคัญให้กับแต่ละ Persona เช่น นำมา Map กับ ตัว Technology Adoption Curve เพื่อดูว่าเราจะให้ Persona กลุ่มไหนเป็นพวก First mover กลุ่มไหนเป็น Follower หรือ กลุ่มไหนเป็นพวก Laggard การทำแบบนี้ จะช่วยทำให้ User ที่เราโฟกัสมีความชัดเจนมากขึ้น และทำให้ทั้งทีมมอง direction ไปที่คนกลุ่มนั้นโดยตรง

5. นำ Persona ไปแชร์กับคนอื่น ๆ ทีม

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

Persona เปลี่ยนได้ไหม

คำถามนี้เจอบ่อยพอสมควร ส่วนใหญ่แล้วการทำ Persona ครั้งนึง เราจะใช้ Persona นั้นไปได้ในระยะเวลาค่อนข้างนานพอสมควร ซึ่ง Persona ของ Product ถามว่าเปลี่ยนได้ไหม คำตอบ คือ เปลี่ยนได้ค่ะ เราจะเปลี่ยนแปลงหรืออัพเดต Persona ของเราก็ต่อเมื่อเราพบว่า Target User ของเราเป็นกลุ่มที่เปลี่ยนไปจากเดิม หรือเมื่อเราพบว่าพฤติกรรมอะไรบางอย่างที่เราอาจจะ Track ได้จากระบบว่ามีการเปลี่ยนแปลง ซึ่งนั้นอาจหมายความว่ามีกลุ่มผู้ใช้งานใหม่ ๆ เข้ามาในระบบเราก็เป็นได้ หากเจอจุดนั้นก็อาจจะต้องดูข้อมูล กำหนด User Screener แล้วลองทำ persona อีกครั้งนึงดู ว่า พวก motivation pains gains needs เปลี่ยนไปหรือเปล่า ถ้าเปลี่ยนไปก็ยินดีด้วยค่ะ คุณได้ Persona ใหม่ :)

จะเห็นว่า Persona มีความสำคัญมากเลยทีเดียว แต่เราอาจจะต้องลงทุนลงแรงกับมันหน่อย เพื่อให้ได้ข้อมูลที่ถูกต้องจริง ๆ ซึ่งถามว่าคุ้มไหม บอกเลยว่าคุ้มมากค่ะ หลัก ๆ แล้ว เราเพียงแค่หา User Screener ที่เป็นข้อมูล Demographic ให้เจอ และไปสัมภาษณ์ข้อมูลพวก Psychographic ซึ่งก็คือ attitude, needs , motivation, pains หรือ gains ที่เหลือเพิ่มเติม จาก User จริง ๆ เพียงเท่านี้เราก็จะได้ Persona ที่ถูกต้อง ใช้ได้จริงและรับประกันว่าไม่มโนแน่นอนค่ะ

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

Happy Designing :)

This is our second part of the series. In part one, we have already built the smallest parts which are called “Base styles” like typography, colors, icons, spacing and etc. Now, let’s build the bigger part in a basic design component!

What is a component?

Imagine that you want to build a lego house, what you will do first? We start from preparing the lego bricks, think about how many brick types and colors that you may need for building the house, right?. Yes, that is our base styles. And then, what you will do next? Just assemble it! It is the same idea here. Put simply, a component is a bigger part that assembled from small parts like you’re playing with the bricks. It sounds like fun, isn’t it?

Let’s start with a bird’s eye view

Before you create a component, I suggest you think about your final design from a bird’s eye view. You will get what you really need in a big picture. For example, let’s say we build a timeline page. We start from thinking about how it could be, how many conditions or states for this design component. and sketch it down. You can do it quickly as we don’t need a lot of details here, just cover all components we should have.

As you can see in the picture above, our timeline page has a list of timeline components which are almost the same components but there is a little thing that you should be careful of. Why?. Most of them are composed of icons and some typography styles but some of them have an arrow-right icon which tells the user that they can tap this row to navigate to another page and some are not. When you look at the big picture, you have to figure it out of how many components that you should create because sometimes we can reuse some component without creating a new one and that is helpful to the developers.

In this case, you can create two components. One has an arrow-right and exclude it from another one or just create one that can show or hide the arrow. But sometimes there are limitations in development which mean you should talk to your developers too.

Break it down

Now, look at your component and break it down. Think about what we can use from our base styles. In this example, you can see base styles that we used are as follows:

• Timeline icon: from the icon base style, please noted that this icon can be changed.
• Date: represented by the Caption style in our defined typography.
• Title: from the Title style in our defined typography as well.
• Description: same here, we use the Body 2 style in our defined typography
• Arrow-right icon: Also noted that this icon can be hidden in the component that doesn’t need the navigation.

Component vs Sketch symbols

If you are the ones who uses Sketch, I recommend creating a component as a Sketch’s symbol. As you can see, symbol can make it easier when you want to reuse icons or even change color.

In case you want to hide the arrow-right icon, just select “None” for that symbol. This is the same idea when developers are coding, they just hide the element as well and that makes them can reuse the component by-case basis, again and again.

For changing color in Sketch symbol, have you ever faced the problem that you want to change the symbol color but cannot do that? here is the solution. First of all, you have to create rectangles filled with color as a symbol. After that, just put the symbol color to our component symbol and change blending mode from Normal to Screen. This color will be blended with elements that have grayscale colors. So if you want it to be fully blended as a solid color, you should fill that element with black color before you blend it. As you see in this example, I want to make the change with an oval and the title text only. So I filled the oval and title text with black color and then just simply put the color symbol above them.

Reuse base styles in component with coding

In coding, we can make it much easier by defining all our base style elements in a javascript file and import that file to your component file when you want to use it. Finally, just call the base style that you defined and pick an element in your base style like a piece of cake.

Now, we have already got a component design so let’s put it all together next time.

Happy designing. :)

Jitta’s Design Language System | Part 2: Create a component was originally published in Jitta Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays, websites and apps are growing up rapidly. For developers and designers, we all need tools for developing sites or apps to deliver high-quality products to our customer as fast as possible as well as here, Jitta.

At Jitta, we build platforms that help investors create better return through simple investment methods which have both website and app. Therefore, as a design-driven company, we propose to build our new design language system for use across all our platforms since last year. And finally, we found that Airbnb is building their design language system as well which supports our idea. You can read their story here.

Why we need the design system?

Jitta is a start up company. So we would like to ship products to our customers, learn and fix it as fast as possible. So we need to find a way that could make things happen to all platforms at once. And the answer is to make it universal by dividing things into sub sections or “components” that are small enough to have the same look on each platform. Of course, this is a response to use React as the front-end development for all platforms as well.

Let’s start with base styles

From Airbnb’s story, they suggested laying the foundation first. Absolutely, we will do the same things here which are typography, colors, icons, and spacing. These base styles are really good guidelines to make all designers in your team working together in the same direction and style. Moreover, if you build and design components from these bases, it can also help decreasing redundant code in development too.

It is not that easy!

Yes, it is not. The difficult part is the typography. As Airbnb’s design has to support multi languages, we are on the same page. We have to design for supporting the Thai language too and most Thai fonts always have problems. For example, there is so much gap between Helvetica Neue and DB Helvethaica X that we use for Thai at the same font size. This can make a huge UI problem when you switch the languages on your site.

So what now? We have got our work around but it may not be the best solution. The solution is to scale the font size of Thai font as much as possible to make it closest to Helvetica Neue size by using web-font generator to fix X-height of the font.

In addition, you should be very careful about using font size across platforms. Some font sizes may be oversized in mobile phone or tablet. But that is not a big deal as you can multiply a factor to your base font size that should be work as well.

Now, we have already got our base styles so let’s build a component with this system next time.

Happy designing. :)

Jitta’s Design Language System | Part I was originally published in Jitta Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever tried to make a perfectly toasted bread? Hope it would be like the one you ordered from a bakery shop but finally got a failed one? If yes, what if I told you that there is a toaster that could make a perfectly toasted bread at home. Yes, it really exists in this world, BALMUDA The Toaster.

In Japan, the land of creativity, mostly Japanese-companies emphasize on a key factor in designing a successful product which is having empathy for users — understanding what they think, do or feel as well as Balmuda, a creative technology company.

The idea of the toaster occurred in 2014 during a particularly rainy afternoon. Gen Terao, CEO, and his employees were warming bread on a grill and realizing that they have just produced the perfectly toasted bread! Terao taught that humidity could keep the toasted bread moist. And that brought them to sell the toaster which costs ¥24,000 ($212), or almost five times the price of a regular device in Japan, with a wait list of at least three months in stores.

Why did they succeed?

Terao said that he doesn’t design products but he’s designing “experiences”. Customers didn’t buy the toaster because they want a toaster, but they are after the moment they get to taste the delicious toast they made. So that is why every time that Balmuda design, they start from the user’s experience. And this is the idea of a company that didn’t just design the product but also empathizes with the customer by giving them the best experiences.

“Consumers are embracing gadgets that do one thing well,” said Hiromi Yamaguchi, Euromonitor analyst in Tokyo. “Larger appliance makers are selling products with too many functions, and not a lot of people use them.”

Now, if you go to Balmuda site, you will see pictures of food that could make you hungry and want to test that experiences right away. So if you want to succeed in designing your product, find the right customer experience!

Happy designing :)

Worth reading?

Please click the 💚️ below to help others find it, and leave a comment. Thanks for reading! 👍

Learn UX Case Study from The Perfectly Toasted Bread! was originally published in Jitta Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is design? The design is a work process which finds solutions to solve your customer’s problems. But how to find the best solution and deliver it to your customer?

Here are 5 steps to deliver solutions your customer want!

1. Know your customers

First of all, you have to understand your target users. You can learn more about your customers through various methods, such as setting a persona profile, take user interviews, create user journeys or make an affinity map. Don’t forget to focus on their normal experiences in daily life and find out what is their need or what is their pain point.

2. Discover your customer’s problem

Now, you have already known what is your customer’s problems or their pain points. So pick the one that is the most important and the most valuable for your product and set a hypothesis. Don’t forget to make sure that you have set a clear hypothesis. This will be effected when you evaluate your design after launch the product to do the test.

3. Ideate

After you’ve already got your hypothesis. The next step is to find solutions to evaluate that. In this step, you can do it with all your team members which can produce as many solutions as possible by brainstorming, do the mind mapping, sketching etc.

4. Design the prototype

Actually, this is the design step but you can do it with your team as well. After you finalized your ideas, we will do the prototype to try out the possible solutions. The prototype should be something that users can experience e.g. paper prototyping or visual design prototyping. Now a day, there are a lot of prototyping tools for making and testing prototype with you target users. Such as InVision, UXPin, or Origami and etc.

5. Do the test

The last step is to test your design solution. Now it’s time to meet the users again and test it. You will learn more about the possible solutions and your customers’ experiences, what they like and what they don’t like. Again be focusing on their experiences too when you’re testing your prototype, notice and always ask for the reason why they click or tap on that button, why they don’t click or tap.

After you have completed all these steps, all you need to do is just learn and adjust your prototype and test it again to find the real solution for your customers. The more you know what your customer need, the more you can make great experiences for them.

Happy designing :)

Worth reading?

Please click the 💚️ below to help others find it, and leave a comment. Thanks for reading! 👍

5 steps to deliver solutions your customer want with UXDD! was originally published in Jitta Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.