เบื่อไหม?
เวลาออกแบบอะไร ก็ต้องเจอกับตอที่ว่า
“ก็ระบบมาเป็นแบบนี้”

เบื่อไหม?
เวลาออกแบบอะไรให้ผู้ใช้ใช้งานง่ายๆ แต่ทำไม่ได้
เพราะหน่วยงานมันบอกว่า
“ไม่เปลี่ยนหรอก มันทำให้ฉันทำงานยาก”
“เอาแบบนี้ดีกว่า ฉันทำงานง่ายดี”

เบื่อไหม?
เวลาออกแบบอะไรไป
แล้วผู้รับเหมาหรือโปรแกรมเมอร์ไม่ทำ บอกว่า
“เอาง่ายๆแบบนั้นไม่ได้หรอ อันนี้ทำยาก เสียเวลา”

มีกฏๆหนึ่งที่น่าสนใจมาก และเราสนใจมานาน
แต่ทำหายไป พยายามอยู่นานทีจะหาให้เจอ
นั่นคือกฏของ Larry Tesler
ที่ว่าด้วยเรื่อง ความคงอยู่ของความซับซ้อน Conservation of Complexity นั่นเอง

ก่อนที่จะไปดูว่ากฏนี้มันทำไมอะไรยังไงกัน
ขอแนะนำบิดาแห่งวงการ Interaction อีกคนหนึ่ง, Larry Tesler กันก่อน

Larry Testler

ภาพจาก wikimedia.org

Larry Tesler เป็นนักวิทยาศาสตร์คอมพิวเตอร์จากมหาวิทยาลัยสแตนฟอร์ด 
(มหาวิทยาลัยที่เราชาบู ชาบู ที่สุดในโลก)
เคยทำงานอยู่ในถิ่นกำเนิดของศาสตร์ Interaction Design ยุคแรกๆ นั่นคือ ) Xerox PARC
ก่อนที่จะไปทำที่ Apple Computer, Amazon.com, และ Yahoo!
ในตำแหน่งที่เกี่ยวกับ User Experience เป็นหลัก

ในปี 1983-85 ยามที่คุณพี่ Larry เขากำลังพัฒนา Framework แบบ Object-Oriented ให้กับ MacApp
ซึ่งมี Layer หนึ่งประกอบขึ้นด้วยเมนู, หน้าต่าง, ชุดคำสั่ง
ซึ่งนักพัฒนาสามารถสร้าง Application ขึ้นมาด้วยการปรับจาก Generic Application ที่สร้างขึ้นได้
ซึ่งในการที่จะขายไอเดียที่ทำให้นักพัฒนาพัฒนา application ง่ายขึ้น ให้กับทางผู้บริหาร Apple และ Vendor ข้างนอก
พี่ Larry ได้นำเอากฏนี้มานำเสนอด้วย
โดยกฏแห่ง Conservation of Complexity นั้น มีคำอธิบายสั้นๆว่า

“Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.”
(จาก http://www.designingforinteraction.com/tesler.html)

แปลเป็นไทยแบบไอแอมไอเอ ได้ว่า
“App ทุกตัวน่ะ จะมีความซับซ้อนที่ไม่สามารถจะลดทอนลงไปกว่านี้ได้แล้ว
แต่คำถามก็คือ ใครฝ่ายไหนจะเป็นผู้แบกรับเจ้าความซับซ้อนนี้ล่ะ?”

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

User 60% / App 30% / OS 10%

แต่ต่อมา มันไม่ใช่แล้ว และ Application มันเขียนขึ้นครั้งเดียว
แต่ถูกใช้งานเป็นล้านๆครั้งจาก user เป็นพันๆหมื่นๆคน
ในสมัย MS-DOS ที่ประสิทธิภาพของคอมพิวเตอร์สูงขึ้น มีการประดิษฐ์ Graphic-User-Interface
สัดส่วนการแบกรับภาระก็น่าจะกลับกันเป็นอย่างน้อย

User 20% / App 40% / OS 40%

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

แปลว่าในอนาคต เราควรจะทำให้ User ไม่ต้องแบกรับภาระเลยจะดีที่สุดหรือ?

คำตอบคือ บ่แม่น

เช่นเดียวกับความ complexity เราลดภาระของแต่ละฝ่ายได้มากที่สุดถึงจุดหนึ่งและเราจะไม่สามารถลดไปได้มากกว่านี้แล้ว
ภาระและความซับซ้อนจะยังคงอยู่กับ User อย่างที่ Bruce Tognazzini เขาบอกเอาไว้ในกฏ Law of Commuting ของเขาว่า
The time of a commute is fixed. Only the distance is variable
นั่นหมายความว่า คนเราจะไม่มีวันที่จะทำอะไรได้ลดลง แม้ว่า มีระบบหรือสิ่งอำนวยความสะดวกช่วยลดภาระขนาดไหน
เปรียบเทียบได้กับว่า คนเราใช้เวลาในการเดินทางเท่าเดิม เพียงแต่จะไปไกลขึ้นหรือใกล้ขึ้น
ถ้าเมื่อก่อนถนนมันทำให้เราต้องใช้เวลาในการเดินทาง 3 ชั่วโมง ในการเดินทางไปสมุทรสงคราม
แต่เดี๋ยวนี้ถนนดีขึ้น เราสามารถวิ่งไปถึงสมุทรสงครามได้ใน 1 ชั่วโมง 
แต่เราก็ยังจะใช้เวลาในการเดินทาง 3 ชั่วโมงอยู่ดี
เพียงไม่ใช่เพื่อการไปสมุทรสงครามเหมือนเดิม แต่ไปในจุดหมายที่ 3 ชั่วโมงจะทำให้เราไปถึงในปัจจุบัน
ซึ่งอาจจะหมายถึงหัวหิน นั่นเอง

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

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

แต่ในขณะเดียวกันฝ่ายอื่นก็ต้องแน่ใจว่า ไม่ได้ผลักภาระอะไรให้ User ต้องทนรับ
เพราะอย่างไร แต่ละอย่างที่ User ทำ User ก็ต้องการรับภาระของตัวเองอย่างเดียว
ไม่ใช่ภาระการทำงานของนักพัฒนา หรือของใคร

Tesler’s law of Conservation of Complexity
จึงเป็นกฏที่คอยเตือนใจเราไว้เสมอว่า

ทุกที่ยังไงก็ต้องมีขี้ แต่ขี้นั้นจะอยู่ที่ใคร อย่างไรดีเอย

อ้างอิง
http://www.asktog.com/columns/011complexity.html
http://www.designingforinteraction.com/tesler.html
http://www.programmersparadox.com/2008/08/17/teslers-law/
http://www.nomodes.com/Larry_Tesler_Consulting/Home.html