Lean UX สร้างขึ้นจากหลักการสำคัญที่ครอบคลุมกระบวนการ การทำงานร่วมกัน และการจัดการ หลักการเหล่านี้มาใช้จะเปลี่ยนแปลงวัฒนธรรมองค์กร ทำให้มีการทำงานร่วมกันมากขึ้น หรือการทำงาน cross-functional ได้ดีขึ้น ทุกหลักการล้วนมีส่วนช่วยในการสร้าง Product และ Service
Disclaimer — ผมค่อนข้างเชื่ออย่างยิ่งว่า ทุกที่ ทุกบริษัท ต่างมีวิธีการทำงานของตัวเอง อาจจะทดลองมาหลายอย่างแล้ว หลายวิธี หลายความเชื่อ ฉะนั้น มันอาจะขึ้นอยู่กับหลายอย่าง เช่น stage ของทีม, ของบริษัท หรือของ Product/Service ของเราด้วย และยังรวมหมายถึงความเชื่อและความร่วมมือแต่ละคนด้วย เพราะฉะนั้น ทดลองอะไรแล้ว หมั่นสังเกต เก็บ feedback อย่างต่อเนื่อง และค่อยๆ ปรับจูนกันไป
ต้องบอกที่มาอีกนิดนึงว่า เนื้อหาบทความนี้ได้จากการเอาประสบการณ์ที่ผมเจอ เคยฟัง เคยทำ มาเล่ารวมกับ Principles ซึ่งเป็น Chapter ที่ 2 ของหนังสือ Lean UX (ที่อ่านจบบาง Chapter บ้าง ดองบ้าง) เอามาเล่าสู่กันอ่านนะครับ
The Three Foundations of Lean UX
3 หลักการที่ Lean UX นำเอามาผูกรวมความเชื่อไว้ด้วยกัน มาลุยกัน
1st Foundation— Design Thinking
Tim Brown ซึ่งเป็น CEO และ President ของ IDEO เป็นบริษัทที่ผมนิยามเองว่า Creative Consultancy เลยก็ว่าได้ หลายท่านอาจจะรู้จักว่าเป็นบริษัทที่เป็นเจ้าพ่อเจ้าแม่ของ Design Thinking เลย เค้าได้นิยามไว้ว่าแบบนี้ครับ
innovation powered by…direct observation of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold, and sup-ported…[It’s] a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”!
ถ้าแปลแบบสำนวนผมเองก็จะได้ประมาณว่า
Innovation หรือนวัตกรรมมันจะถูกขับเคลื่อนได้ หรือเกิดขึ้นได้ ด้วยการสังเกตโดยตรงกับผู้คน ว่าเค้าต้องการอะไร อะไรที่จำเป็นต่อชีวิตพวกเขา และ อะไรที่เค้าชอบ หรือไม่ชอบบ้าง กับ Product (ซึ่งถ้าผมคิดเองก็คงรวมๆ physical และ digital product ด้วย), Packaging หรือพวกบรรจุภัณฑ์, การตลาด หรือการขาย ซึ่งพวกนี้มันต้องเป็นวินัยที่เกิดขึ้นกับนักออกแบบ ที่ต้องใช้ทั้งความรู้สึกและวิธีการ เพื่อให้ตรงใจกับความต้องการของผู้คน เข้ากับความเป็นไปได้ใน Tech และ Strategy ในฝั่ง Business ให้เกิดเป็น Customer Value (ส่งมอบคุณค่าให้ลูกค้า) และ Market Opportunity (โอกาสทางการตลาด) ด้วย
ส่วนตัวผมแล้ว ผมค่อนไปทางเชื่อว่า Design Thinking คือช่วงเวลาของการจมเข้าไปกับปัญหา ดิ่งและรู้สึกกับมันให้มากที่สุด จากนั้นมา balances กับ business ด้วย ซึ่งไม่ใช่แค่ Empathize คนที่เป็น User อย่างเดียว แต่อาจจะต้องเข้า Business หรือทีมงานที่ทำภายใน Customer Journey ด้วย (ขยายภาพออกมาเป็น Service Blueprint)
และเมื่อเราเอาปัญหาที่เราพบใน Design Thinking มากองแล้ว จะพบว่า การแก้ปัญหาให้กับลูกค้า อาจจะเป็นการแก้ปัญหาภายในองค์กรก่อนเลย แล้วมันจะส่งผลให้ประสบการณ์ของลูกค้าเราดีขึ้น
2nd Foundation — Agile Software Development
“Software developers have been using Agile methods for years to reduce their cycle times and deliver customer value in a continuous manner.” คือในหนังสือเนี่ย เค้าเขียนไว้ค่อนข้างล่อแหลมครับ (และคิดว่าบางท่านอาจจะเข้าใจว่าแบบนั้นด้วย)
เอาเป็นว่าจากประสบการณ์ผมแล้วกัน มันค่อนข้างจะสวนทางเสียมากกว่า ถ้าเอามาใช้แล้ว มันไม่ได้ลดเวลาในการผลิต แต่ผมคิดว่า “ลดเวลาของการเจอและเข้าใจปัญหาให้เร็วขึ้น” อาจจะใช่มากกว่า เพราะมันคือการเปลี่ยนแปลงวิธีการทำงานใหม่ค่อนข้างเยอะ และอาจจะต้องปรับให้เข้ากับบริบทด้วย (ถ้าเราทำงานกันบน waterfall หรือ project based) แต่ถึงกระนั้น สำหรับผมแล้ว ให้มองว่า รู้ไว้มาปรับใช้ น่าจะดีกว่า
เรามาทาง Manifesto for Agile Software Development อธิบายกันแบบนี้ครับ
- Individuals and interactions over processes and tools — ให้ความสำคัญกับการพูดคุยแลกเปลี่ยนกันอย่างอิสระและความถี่ที่บ่อยด้วย มากกว่าที่จะต้องผ่านกระบวนการขั้นตอนหรือเครื่องมือ
- Working software over comprehensive documentation — ให้เกิด Software ที่ใช้งานได้จริง โดยเฉพาะการใช้งานได้ในระยะแรก เพื่อทดสอบการใช้งานและประเมินความเหมาะสมในตลาด มากกว่าความครอบคลุมในเนื้อหาของเอกสาร
- Customer collaboration over contract negotiation — ทำงานร่วมกันในทีมงานและกับลูกค้า เพื่อให้สร้างความเข้าใจร่วมกัน หรือได้เห็นวิธีในการคิด ตัดสินใจ ของการทำงานหรือปัญหานั้นๆ ยังเป็นการลดการพึ่งพาเอกสารด้วย มากกว่าที่จะมาต่อรองเรื่องสัญญา
- Responding to change over following a plan — แม้ว่าจะการทำงานแบบไหนก็แล้วแต่ จะ Lean UX หรือ Agile ยังไงความผิดพลาดก็เกิดขึ้นเสมอ ถ้า “ทีม” หรือทุกคนที่เกี่ยวข้อง เห็นข้อผิดพลาด อะไรใช้งานได้ อะไรไม่เวิร์ค ก็ปรับปรุงและทดสอบกันต่อไป จะทำให้เราไปกันถูกทางขึ้นเรื่อยๆ ซึ่งผมชอบประโยคนี้มาก “nudging us in a “more right” direction.”
3rd Foundation — Lean Startup
Lean Startup ที่เกิดขึ้นโดย Eric Ries โดยใช้ feedback loop ที่เรียกกัน(น่าจะคุ้นหูกันดีเลย) “Build — Measure — Learn” เพื่อลดความเสี่ยงของโปรเจค และทำให้ทีมได้ สร้าง+เรียนรู้ ให้เร็ว โดยทีมจะสร้าง MVP (Minimum Viable Products) เพื่อให้เกิดการเรียนรู้ให้เร็วที่สุดเท่าที่จะเป็นไปได้
Remark: จากประสบการณ์แล้วที่เคยเจอ MVP มันจะชอบพูดกับเรื่องระยะเวลาของการผลิตเข้ามาด้วย ซึ่ง ระยะเวลาของคำว่า MVP อาจจะไม่ได้เท่ากัน และยิ่งคาดหวังจาก theory ใดๆ อย่างหนังสือนี้ที่ใช้คำว่า “เร็ว” อยู่บ่อยครับ มันก็ไม่ได้เร็วเท่ากันกับในใจทุกคน หรือพูดได้ว่า “เร็วของเราไม่เท่ากัน” เอาเป็นว่า ปรับใช้นะ อย่ายึดติด และ คุยกันให้เยอะๆ ตกลงร่วมกัน
ตรงนี้สปอยล์ก่อนว่า ตอนท้ายจะมี video เนื้อหาเสริมกับเรื่องนี้ครับ
“Lean Startup initially advocates the creation of rapid prototypes designed to test market assumptions and uses customer feedback to evolve them much faster than more traditional software engineering practices…Lean Startup processes reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible.”
การสร้าง rapid prototype เพื่อไปทดสอบ assumption หรือสมมติฐานในตลาดและเก็บ feedback จาก user ให้เร็ว จะช่วยลดความเสี่ยงใช้เวลาไปเยอะจากการทำของออกมาไม่ตรงใจลูกค้าได้ (ซึ่งบางคน บางทีม บางบริษัท อาจจะนิยาม MVP ต่างกันไป บ้างอาจจะบอกว่าเป็น Working Software แต่ยังไม่เน้นความสวยงาม บ้างก็อาจจะบอกว่า ถ้าคนรู้จักเราแล้วก็ต้องทำให้ดี ซึ่งมันก็เลยตามมาของการใช้ระยะเวลา และยังไม่เสร็จ เพราะอาจจะเกิดจากการที่ระแวดระวังคู่แข่งไปด้วย — ซึ่งก็เข้าใจได้ว่ามีหลายมุมที่ต้องตัดสินใจ แต่นั่นแหละ ก็ตัดสินใจร่วมกันว่าจะเดินทางไหน — และผมย้ำว่า จะมีเนื้อหาช่วงท้ายครับ รอฟัง video ที่ผมแนบมาได้เลย)
แล้วจะทำไงได้บ้าง? — จากประสบการณ์ จะใช้ User Research Method หรือเครื่องมือต่างๆ เพื่อใช้ในการประเมินเบื้องต้น เช่น
- การทำ Usability Testing ก็จะช่วยลดความเสี่ยงทำของออกมาใช้งานยาก
- หรือทำ Concept Testing ณ ตั้งแต่ตอนแรกเพื่อเห็นแนวทางว่าจะเวิร์คไหม
- หรือๆๆ ทำ Existing Analysis ก่อนเลย ไม่ว่าจะ Contextual Inquiry หรือ In-depth Interview เพื่อให้เข้าใจสถานการณ์ปัจจุบัน ไม่ทำผิดพลาดซ้ำรอยเดิม (ต้องบอกว่าตรงนี้บริษัท KO-EXPERIENCE เราเริ่มทำแบบนี้กับลูกค้าเกือบทุกเจ้าที่เราทำด้วยเสมอ เพื่อให้แก้ปัญหาถูกจุด และตอบโจทย์ลูกค้าให้ได้มากที่สุด)
- ซึ่งการทำ Existing Analysis อาจจะให้ Specialist ในทีมประเมินด้วย จากประสบการณ์ตัวเองด้วยเครื่องมือต่างๆ เช่น Heuristic UI Design, Visual Design Principles, Laws of UX และรวมถึงจากการลองเล่นหรือใช้งานเอง (Put in the users’ shoes)
แต่ความสนุกมันอยู่ตรงนี้ครับ
ผมก็คิดว่า เอะ แล้วคนอื่นเค้าทำกันยังไง เพราะประสบการณ์เราก็อาจจะไม่ได้ครอบคลุมทุกเคส ซึ่งผมก็ไปเจอครับ “Why MVP Is the Antithesis of Good UX” การนิยามและพูดถึง MVP ใน NN/g บอกว่า
Pursuing a “minimum viable product” (MVP) as a design strategy may work for startups, but usually leads to poorly integrated user experience for established design team working in traditional product categories.
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F9Swz0LJAEdY%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9Swz0LJAEdY&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F9Swz0LJAEdY%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube
ซึ่งตอนนึงใน video นี้ที่ Kara Pernice (ปัจจุบันคือ President และ CEO of Nielsen Norman Group) ได้บอกว่า
So there are many issues with MVP and a few of the most common problems are these: There is no usability testing at all, or it’s done on the live product.
แถมท้ายยังบอกไว้ด้วยว่า
Today, if you work in an MVP-driven world that happens to be unproductive for your team, try to redefine what “minimum viable” means to you. Consider suggesting that it be researched and made to be most realistic, useful, usable, and engaging before it goes live and reaches a paying customer.
ฟังเต็มๆ ครับ อาจจะมีสะอึกได้สำหรับหลายๆ คน
ต้องบอกว่านี่เป็นเพียงเกริ่นเริ่มต้นของ Principles จาก Chapter 2 ในหนังสือ Lean UX เท่านั้นนะครับ ในบทความหน้าผมจะเล่า Principles Part I มาแบ่งเล่าให้ก่อน
ขอบคุณที่อ่านมาถึงตรงนี้นะครับ หวังว่าจะช่วย reflection ได้แม้ว่าคุณอาจจะเคยผ่านร้อนหนาวมาบ้าง และหากคิดว่าบทความนี้เป็นประโยชน์ อย่าลืมแบ่งปันเพื่อนๆ ของคุณที่ทำงานด้วยนะครับ ไม่ต้องเป็น UX จะเป็น Dev, QA หรือ Product Manager, Product Owner, Project Manager (หรือหัวหน้าของคุณ บริษัทของคุณ) ก็น่าจะเป็นประโยชน์ หรือใช้เพื่อพูดคุยกันได้หลังอ่านนะครับ
บทความนี้ publish ที่นี่