ตอนที่ 2 วางแผนก่อนการพัฒนา

สิ่งแรกที่ต้องเริ่มสำหรับการออกแบบคือการ plaining โดยเน้นว่าจะสร้างไปทำไม และจะสร้างไปเพื่อใคร

เราต้องบอกได้ว่ากลุ่มผู้ใช้มีพื้นฐานอย่างไร มีประสบการณ์อย่างไร เคยใช้งานคอมพิวเตอร์หรือเปล่า มีความรู้ความเชียวชาญในสายงานใด มากน้อยแค่ไหน ยกตัวอย่างเช่น โปรแกรม iphoto ออกแบบมาสำหรับคนทั่วไป ไม่ได้มุ่งเน้นไปที่กลุ่มผู้เชียวชาญ (pro) ดังนั้นคำศัพท์ที่ใช้ ขนาดของ icon รูปร่างและสีสัน จะไม่เหมือนกับ aperture ที่ออกแบบสำหรับ pro

Aperture

iPhoto

จะเห็นว่าหน้าจอปกติของ iphoto ไม่ได้เป็นสีดำโดยพื้นฐาน และไม่มี menu ที่ใช้งานได้เอนกประสงค์แต่เน้นว่าทำความเข้าใจได้ง่ายๆ

ถ้ามาดูว่าสิ่งที่ต้องคำนึงในการวางแผนมีอะไรบ้าง ก็คงเรียงออกมาตามนี้

1. เข้าใจผู้ใช้ของเรา
2. เข้าใจโปรแกรมของเรา
3. เข้าใจความต้องการของตลาด (market’s need)
4. เข้าใจลำดับความสำคัญของตลาด (market’s priority)
5. Final steps

เข้าใจผู้ใช้ของเรา

เข้าใจคนที่จะใช้ว่าอะไรที่เค้าให้ความสำคัญ

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

ไม่มีประสบการณ์

• BECOME กำลังจะเป็นผู้ชำนาญเฉพาะทาง
• GRADUATE ทำงานที่ซับซ้อนได้มากขึ้น

มีประสบการณ์มาก่อน

• MASTER เป็นผู้เชียวชาญ
• NOVICE เป็นผู้เชียวชาญสาขาอื่น
• FRUSTRATED เคยใช้โปรแกรมแล้วไม่ได้ดั่งใจ

เข้าใจโปรแกรมของเรา

เข้าใจว่าโปรแกรมของเราเอาไว้แก้ปัญหาอะไรเป็นสำคัญ โดยให้วิเคระห์สิ่งที่เราช่วยผู้ใช้ เอาสิ่งที่เป็น value-add และเป็นจุดเข็งของโปรแกรมของเรา (core strength) ออกมาชัดๆ จากนั้นก็ออกแบบให้เหมาะกับการใช้งาน โดยคำนึงถึงการใช้งาน (Design for usability)

• workflow ว่ากระบวนการคิดของผู้ใช้เป็นอย่างไร โปรแกรมก็ควรจะช่วยลดเวลา หรือเพิ่มประสิทธิภาพแต่ไม่ใช่พยายามไปเปลี่ยน flow

• การเชื่อมต่อกับโปรแกรมอื่นๆ (ผ่าน file, ผ่าน framework) เพราะไม่มีโปรแกรมรองรับความต้องการได้ทุกรูปแบบ แต่โปรแกรมจะสามารถรองรับได้มากขึ้นถ้าสามารถคุยกับโปรแกรมอื่นได้ เช่นการเปิด web services ของ google map หรือ การที่เรา เรียกใช้ totem ผ่านทาง command line ได้ หรือการที่โปรแกรมมากมายบน apple พยายามให้สร้าง function ให้โปรแกรมอื่นๆ เรียกผ่าน automator หรือ apple script เป็นต้น

ให้นำเสนอ solution แทนที่จะเป็น feature

• บอกให้ชัดเจนว่าโปรแกรมทำออกมาเพื่อแก้ปัญหาอะไร แล้วนำเสนอ solution ในการแก้ปัญหา
• ระลึกว่าไม่ควรทำให้ผู้ใช้สับสนเพราะฟังก์ชันที่ไม่สำคัญ (ถ้าใส่แล้วสับสนก็ตัดทิ้งเลยดีกว่า) ดูตัวอย่างชัดๆ จาก MS Power point ที่มี icon มากมายจนเราหาปุ่ม start presentation ไม่เจอ
• ผู้ใช้ไม่สามารถแยกออกว่า feature ไหนสำคัญกว่ากัน อย่าไปถามเค้าเพราะทุกอย่างดูจะสำคัญหมด ดังนั้นตอนที่เราเก็บ requirement ต้องถามหาปัญหาและนำเสนอ solution เมื่อเรามี solution เราก็รู้ได้ว่า feature ใดสำคัญและอะไรตัดทิ้งได้
• Simplify then simplify again — less is more

พึงระลึกว่า โปรแกรมที่ดีจะทำให้เราไม่รู้สึกว่ากำลังต้องใช้โปรแกรมอยู่

เข้าใจความต้องการของตลาด (market’s need)

เข้าใจความต้องการของตลาด (market’s need) รู้ว่าผู้ใช้ต้องการใช้โปรแกรมของเราไปทำแก้ปัญหาอะไร และอะไรเป็นปัญหาที่เราต้องการจะแก้ให้เค้า ถ้าโปรแกรมของเราทำออกมาสำหรับตกแต่งภาพทางการแพทย์ ก็ต้องเข้าใจว่าปัจจุบันผู้ใช้มีปัญหาอะไรที่ photoshop, gimp, acdsee แก้ให้เค้าไม่ได้

เข้าใจลำดับความสำคัญของตลาด (market’s priority)

เข้าใจลำดับความสำคัญของตลาด (market’s priority) การพยายามเขียนโปรแกรมที่สามารถแก้ได้ทุกปัญหาจะทำให้โปรแกรมซับซ้อน หรืออาจใช้งานไม่ได้เลย ถ้าอยากให้โปรแกรมขายออกก็ให้แก้ปัญหาใหญ่ที่สุดที่คนส่วนมากเจอก่อน

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

Final steps

ก่อนเริ่มพัฒนาให้พิจารณาแล้วสำรวจตัวเองเป็นข้อๆ

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