เมื่อเราได้ backlog หรือเรื่องราวของผู้ใช้งานแล้ว เราจะต้องนำมาออกแบบ (design) สำหรับนำไปพัฒนาต่อไป การออกแบบในเบื้องต้น (high level design) จะเป็นการแยกย่อย (decomposing) เรื่องราวของผู้ใช้งานว่าเราต้องมีส่วนต่างๆของโปรแกรมอะไรบ้างและเพื่อทำหน้าที่อะไร ตัวอย่างเช่น ในการเขียนโปรแกรมเชิงวัตถุ จะเป็นการกำหนดว่าโปรแกรมต้องมีคลาส เมธอด และฟิลด์อะไรบ้าง และแต่ละคลาสจะมีความสัมพันธ์กันอย่างไร การแปลงจากเรื่องราวของผู้ใช้งานไปสู่การออกแบบสามารถทำได้หลายวิธี เพื่อให้เห็นภาพในการทำเรื่องราวของผู้ใช้งานและการแยกย่อยข้อมูลออกมาเป็นการออกแบบแบบคร่าวๆ สมมุติว่าเราต้องการสร้างเกมส์ pacman แบบง่ายๆ โดยผู้เล่นจะต้องบังคับตัวละครในเกมส์ด้วยคีย์บอร์ดให้วิ่งไปตามทางเพื่อกินจุดโดยต้องหลบหลีกผีและเมื่อเล่นชนะในแต่ละฉากก็จะเปลี่ยนไปยังฉากถัดไป
ในการเขียนเรื่องราวของผู้ใช้งานอาจจะใช้แนวคิดง่ายๆคือระบุว่าใคร ทำอะไร ได้ผลลัพธ์เป็นอย่างไร (role-gole-benefit) โดยเริ่มจาก ผู้เล่น(ใคร – role)เคลื่อนที่แพกแมน (ทำอะไร – goal) ไปตามทางเพื่อกินจุดและหลบหลีกผี (ผลลัพธ์-benefit) จากนั้นเรามาดูเรื่องข้อจำกัด (limitation) ซึ่งในที่นี้คือการเล่นโดยใช้คีย์บอร์ดเท่านั้น ถ้ามาดูในมุมมองของผู้พัฒนา (engineering note) จะพบว่าความยากคือในแต่ละฉากจะมีองค์ประกอบมากมายรวมถึงต้องมีการติดตามสถานะต่างๆขณะเล่น เช่น การชนกันระหว่างแพกแมนและผี การกินจุดและได้คะแนน จำนวนแพกแมนที่เหลืออยู่ และอื่นๆ ดังนั้นเราอาจจะสรุปคุณค่า (validation) ได้เป็น 3 หัวข้อคือ การควบคุมด้วยคีย์บอร์ด การเคลื่อนที่ การชนกัน ซึ่งทั้งหมดนี้จะต้องทำงานร่วมกัน
จากรายละเอียดด้านบนเราสามารถแยกย่อยเรื่องราวของผู้ใช้งานได้อีก คือ (1) ผู้เล่นเคลื่อนที่แพกแมนด้วยคีย์บอร์ด (2) ผีเคลื่อนที่อย่างอิสระไปตามเส้นทางในฉาก (3) แพกแมนชนกับผีทำให้ทั้งแพกแมนและผีตาย ทีนี้จากเรื่องราวของผู้ใช้งานที่เราคิดว่าแยกย่อยมาได้เพียงพอแล้ว เราจะนำมาเปรียบเทียบกับหลักเกณฑ์ INVEST จะพบว่า (1) ในมุมของความเป็นอิสระจากกันอาจจะไม่ผ่านเพราะสุดท้ายแล้ว ทุกฟีเจอร์ต้องทำงานร่วมกันเพื่อให้เป็นเกมส์ที่สมบูรณ์ (2) ในมุมของการหารือร่วมกัน ทีมพัฒนามีอิสระในการออกแบบการทำงานของเกมส์ตราบใดที่เนื้อหาของเกมส์ยังคงเป็นตามที่ต้องการ (3) ในมุมของความคาดหวังชัดเจนว่าได้เกมส์ตรงตามความต้องการ (4) ในมุมของการประเมินต้นทุนเราแยกย่อยเรื่องราวของผู้ใช้งานจนสามารถประเมินได้ง่ายขึ้น (5) อย่างไรก็ตามเนื่องจากทั้ง 3 ส่วนต้องทำงานด้วยกันไม่ได้เป็นอิสระจากกัน ดังนั้นจึงไม่เป็นการแยกย่อยที่เล็กที่สุด (6) แน่นอนว่าเราสามารถกำหนดเงื่อนไขในการทดสอบได้
ในการแยกย่อย (decomposing) เรื่องราวของผู้ใช้งานมาเป็นการออกแบบเพื่อนำไปพัฒนาไม่ได้มีขั้นตอนที่ตายตัวโดยจะขึ้นอยู่กับลักษณะโครงการ ลักษณะของเรื่องราวของผู้ใช้งาน และความรู้ของทีมงาน และอาจจะต้องทำซ้ำไปซ้ำมาจนกว่าจะได้ตามที่ต้องการ และยิ่งระบบงานซับซ้อนมากขึ้นความยากในการแยกย่อยก็มากขึ้น เราสามารถแบ่งการแยกย่อยออกเป็น (1) Find Entities เป็นการระบุสิ่งที่เป็นตัวตน (2) Link Entities ระบุการเชื่อมต่อระหว่างแต่ละตัวตน (3) Bind Actions ระบุพฤติกรรมที่จะเกิดขึ้นกับแต่ละตัวตน (4) Prototype สร้างต้นแบบขึ้นมา (5) Formalize อธิบายต้นแบบด้วยแผนภาพ (diagram) (6) Implement ลงมือพัฒนา
สำหรับเกมส์แพกแมนการระบุสิ่งที่เป็นตัวตนสามารถระบุได้เป็น คีย์บอร์ด แพกแมน ผี และฉาก ดังนั้นเราจะมีคลาสที่เกี่ยวข้องกับตัวตนคือคลาส Key สำหรับคีย์บอร์ด คลาส Scene สำหรับฉาก คลาส Pacman สำหรับตัวแพคแมน และคลาส Ghost สำหรับผี การเชื่อมต่อของแต่ละคลาสคือคลาส Key ส่งค่าที่กดคีย์บอร์ดให้คลาส Scene ซึ่งจะไปสั่งให้คลาส Pacman เคลื่อนที่ ส่วนคลาส Ghost จะเคลื่อนที่อัตโนมัติแต่การเคลื่อนที่ของทั้งแพกแมนและผีจะขึ้นอยู่กับฉากด้วยว่าไปทางใดได้บ้าง ดังนั้นทั้งคลาส Pacman คลาส Ghost และคลาส Scene จะต้องคุยกัน ทีนี้เรามีแพกแมน 1 ตัวและผี 4 ตัวซึ่งการเคลื่อนที่พื้นฐานจะเหมือนกันดังนั้นเราสามารถทำเป็นแอบแสตรคคลาส Character และให้ตลาสของแพกแมน และผี สืบทอดคลาสดังกล่าว ทีนี้เนื่องจากคลาส Character เป็นผู้เคลื่อนที่แพกแมน ดังนั้นคลาส Character จะเป็นผู้ตรวจสอบการชนกันด้วย
ในการระบุพฤติกรรมของแต่ละคลาส เริ่มจากการกดคีย์บอร์ดเราต้องการเมธอดเพื่อมารับค่าจากการคีย์ดังนั้นคลาส Key จะมีเมธอด keypress() เพื่อรับค่าคีย์มาดำเนินการ แต่เพื่อให้ผู้เล่นสามารถปรับแต่งคีย์ได้ตามต้องการสำหรับการเคลื่อนที่ไป บน ล่าง ซ้าย ขวา ดังนั้นเราจะไม่ส่งค่าคีย์ที่ได้ให้กับฉาก แต่จะส่งเป็นคำสั่ง บน ล่าง ซ้าย ขวา ไปแทนเพื่อให้เป็นอิสระจากคีย์ ดังนั้นคลาส Scene จะต้องมีเมธอดเพื่อรับคำสั่งคือเมธอด input เมื่อคลาส Scenen รับคำสั่งมาแล้วก็จะส่งต่อให้คลาส Character เพื่อเคลื่อนที่แพกแมน ดังนั้นคลาส Character จึงมีเมธอด move เพื่อรับทิศทางที่ต้องการเคลื่อนที่มา จากนั้นคลาส Character ตรวจสอบการชนกันด้วยเมธอด collision และปรับปรุงข้อมูลกลับไปยังคลาส Scene ดังนั้นคลาส Scene จะมีเมธอด update เพื่อรับค่ามาปรับปรุงข้อมูล ดังนั้นเราสามารถถ่ายทอดทั้งหมดออกมาเป็นต้นแบบ (prototype) อย่างง่ายๆ ดังภาพด้านล่าง
เราจะพิจารณาต้นแบบซ้ำแล้วซ้ำอีก และถ้าเราพอใจกับต้นแบบแล้ว เราจะอธิบายให้เป็นทางการมากขึ้นด้วยการใช้รูปแบบ Unified Modelling Language (UML) ซึ่งเป็นภาษาที่เอาไว้อธิบายสิ่งต่างๆเป็นแผนภาพ (diagram) โดยแบ่งได้คร่าวๆเป็น activity diagram, class diagram, sequence diagram และ use case diagram
ตัวอย่าง activity diagram
ตัวอย่าง class diagram
ตัวอย่าง sequence diagram
ตัวอย่าง use case diagram
จากต้นแบบที่ได้เราจะนำมาอธิบายด้วยแผนภาพ (diagram) โดยเริ่มจากการอธิบายด้วย class diagram เริ่มจากคลาส Key ซึ่งรับการกดคีย์บอร์ดมาแปลงเป็นคำสั่งเพื่อส่งแต่ไม่มีการเก็บค่าใดๆ ดังนั้นคลาส Key จะไม่มีฟิลด์ แต่จะมีเมธอด keypress ซึ่งรับค่าการกดคีย์ (event) เพื่อมาแปลงเป็นคำสั่ง คลาส Scene จะต้องมีข้อมูลของทุกอย่างที่อยู่ในฉากดังนั้นคลาส Scene จะมีฟิลด์ pacman ที่เก็บชนิดข้อมูล Pacman และเนื่องจากผีมีหลายตัวเราจะเก็บผีในอาเรย์ของชนิดข้อมูล Ghost และมีเมธอด input เพื่อรับคำสั่งเข้ามา ส่วนเมธอด update จะรับข้อมูลจากคลาส Character มาปรับปรุงและตอบสนองตามสถานะต่างที่เปลี่ยนไป คลาส Character จะมีเมธอด move เพื่อรับคำสั่งมาดำเนินการและมีเมธอด collision เพื่อตรวจสอบการชนกันซึ่งจะถูกถ่ายทอดไปยังคลาส Pacman และคลาส Ghost
และเราอธิบายลำดับการทำงานด้วย sequence diagram โดยเริ่มจากผู้เล่นกดคีย์ซึ่งเมธอด keypress ของคลาส Key จะแปลงจากค่าที่กดเป็นทิศทางที่ต้องการแล้วส่งต่อไปยังเมธอด input คลาส Scene ซึ่งจะส่งต่อไปยังเมธอด move ของคลาส Pacman ซึ่งคลาส Pacman จะตอบกลับผ่านเมธอด output ของคลาส Scene ซึ่งจะปรับปรุงตำแหน่งของ Pacman และคำนวนคะแนนหากแพกแมนกินจุดได้ด้วย จากนั้นจึงวนลูปเพื่อย้ายตำแหน่งของผีแต่ละตัวซึ่งพารามิเตอร์ direction ของเมธอด move ของคลาส Ghost จะมาจากโปรแกรม จากนั้นจึงวนลูปตรวจสอบว่าแพกแมนชนกับผีหรือไม่ด้วยเมธอด collision
จากตัวอย่างข้างต้นลำดับในการพัฒนาสามารถทำตามลำดับการทำงานตามที่แสดงใน sequence diagram ได้เลย