ฉันจะย้ายลูกค้าจากการจำลอง UI ไปยังชุดข้อกำหนดที่แท้จริงได้อย่างไร

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

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

ฉันไม่แน่ใจว่าจะขออะไรฉันพยายามระบุและถามถึงข้อกำหนดและความเข้าใจในเป้าหมายโดยรวม แต่ฉันไม่รู้ว่าควรจะขออะไร ถ้าฉันเพิ่งเริ่มตอนนี้เวลาส่วนใหญ่จะสูญเปล่าข้อมูลทั้งหมดที่นำไปสู่ ​​UI และในช่วงนี้ด้วยเหตุผลสำคัญหลายประการที่ลูกค้าต้องสูญเสียไป

ฉันจะทำให้ผู้คนเข้าใจได้อย่างไรว่าเราไม่สามารถล็อคความต้องการตาม UI mock-ups โดยขอสิ่งที่สามารถสร้างได้ให้ฉัน

สิ่งที่คุณจะเริ่มต้นด้วยความนึกคิดเพื่อดำเนินงานพัฒนาแอพพลิเคชั่นสำหรับผู้ใช้อย่างเหมาะสม?

สิ่งอื่น ๆ ที่คุณอาจต้องการคือ:

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

• คำอธิบายระบบระดับสูง: บางสิ่งบางอย่างอธิบายถึงสิ่งที่ทั้งระบบที่หน้าจอ 25 เหล่านี้มีไว้สำหรับและสิ่งที่พวกเขาทำ

• ตัวแบบข้อมูล: เป็นไปได้ไหมที่จะอนุมานตัวแบบข้อมูลจากหน้าจอเหล่านี้ มีรูปแบบข้อมูลที่ต้องใช้หรือคุณมีอิสระในการออกแบบของคุณเองเพื่อให้งานสำเร็จหรือไม่?

• ข้อกำหนดทางเทคนิค: เป็นเทคโนโลยีเฉพาะที่ต้องใช้เพราะใบอนุญาตหรือด้วยเหตุผลการรวม?

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

• ข้อกำหนดด้านความปลอดภัย: แอพพลิเคชั่นเก็บข้อมูลที่มีความอ่อนไหว / ข้อมูลส่วนบุคคลหรือไม่และหากเป็นเช่นนั้นข้อมูลประเภทใดและต้องทำอย่างไรเพื่อให้ปลอดภัย คุณจำเป็นต้องปฏิบัติตามข้อกำหนดระดับหนึ่ง (เช่นการปฏิบัติตาม PCI สำหรับการชำระเงินด้วยบัตรเครดิต) หรือไม่

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

วิธีทำให้คนเข้าใจว่า UI mocks ไม่เพียงพอที่จะสร้างโปรแกรมทำงาน:

ฉันจะจัดการกับสิ่งนี้ด้วยการเปรียบเทียบ เนื่องจากฉันเป็นรถน๊อตฉันก็เลยไปทางนั้น

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

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

จากนั้นคุณสามารถอธิบายการเปรียบเทียบ การมอบนักพัฒนาของหน้าจอ mocks เท่านั้นบอกพวกเขาว่ามันดูเหมือนไม่ใช่สิ่งที่มันทำ นักพัฒนาจำเป็นต้องรู้ว่าโปรแกรมแก้ปัญหาหรือวิธีการใช้งาน (เช่นการรู้ว่ารถยนต์ทำอะไรได้ง่ายกว่าในการออกแบบรถยนต์และทำการเดาการศึกษาเกี่ยวกับสิ่งที่ควรทำ) พวกเขาจำเป็นต้องรู้ชนิดของสิ่งที่พวกเขาคาดว่าจะใช้ (เช่นเครื่องยนต์รถกอล์ฟกับเครื่องยนต์รถสปอร์ต) และข้อกำหนดอื่น ๆ ที่ไม่ใช่ของ UI ที่มีอยู่ (รถควรวิ่งเร็ว)

สิ่งที่ฉันต้องการ:

คำอธิบายปัญหาทั่วไป / ระดับสูง

ใช้กรณี / เรื่องราวของผู้ใช้

ต้องการประสิทธิภาพการทำงาน

เทคโนโลยี / แพลตฟอร์มที่ต้องการ (Windows, Linux, Web)

ทุกอย่าง FrustratedWithForms มีคำตอบของเขา

บางสิ่งที่มีผลต่อ 80% ของความพยายามในการพัฒนาไปสู่ ​​20% ของกรณีการใช้ประโยชน์ ภาพหน้าจอจะไม่บอกคุณเกี่ยวกับกรณีการใช้งานดังนั้นคุณจะอยู่ในที่มืด 80% ของการพัฒนาที่ใช้งานอยู่

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

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

คุณไม่สามารถโยนข้อมูลข้ามกำแพงและคาดหวังที่จะได้รับความหวังและความฝันของคุณในรูปแบบของแพคเกจซอฟต์แวร์ การพัฒนาซอฟต์แวร์ใช้งานไม่ได้ด้วยวิธีนี้ ไม่ว่าคุณจะเป็นร้าน Agile หรือ Waterfall คุณจำเป็นต้องมีทิศทางลูกค้าที่มั่นคงต่อความสำเร็จหรือความล้มเหลวของโครงการ

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

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

คุณต้องทราบด้วยว่ามีข้อ จำกัด เฉพาะเกี่ยวกับข้อมูลที่ควรใส่ในแต่ละฟิลด์หรือไม่ มีค่าที่ต้องการหรือไม่ คุณจะไปรับจากที่ไหน พวกเขาจะได้รับการปรับปรุงอย่างไร คุณต้องรู้วิธีจัดการกับข้อผิดพลาด คุณจำเป็นต้องรู้ว่าฐานข้อมูลจำเป็นต้องมีการตรวจสอบหรือถ้าคุณต้องการที่จะสามารถสร้างข้อมูลจากมุมมองทางประวัติศาสตร์ (กลับไปที่รายงานที่น่ารำคาญ)

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

โดยส่วนตัวฉันจะขอประชุมครึ่งวันถึงวันยาวกับลูกค้าเพื่อผ่านการออกแบบ UI และเป้าหมายของพวกเขาและทำให้แน่ใจว่าทุกอย่างสอดคล้องกัน

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

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

ฉันขอแนะนำให้ใช้เทคนิคการพัฒนาแบบวนซ้ำและแบบเพิ่มหน่วยในกรณีนี้เนื่องจากคุณมีข้อกำหนดที่คลุมเครือไม่สมบูรณ์หรือไม่เข้าใจ ดูวิธีการต่างๆที่คล่องตัวพร้อมกับ Spiral Model เพื่อระบุที่อยู่การวางแผนวงจร

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

เมื่อคุณเข้าใจว่าวัตถุประสงค์คืออะไรคุณสามารถเริ่มทำงานกับ mockups การออกแบบ UI ที่คุณมีและ "reverse engineer" ใช้เคสและเรื่องราวของผู้ใช้จากพวกเขาตามหน้าจอที่หลากหลาย รูปแบบเรื่องราวของผู้ใช้น่าจะทำงานได้ดีในการจัดการกับผู้ชมที่ไม่ใช่ด้านเทคนิค รูปแบบของAs a <user type>, I want to <action> so that <reason>ผลงานในแง่ของการพัฒนาและลูกค้า / ผู้ใช้ที่พูดภาษาเดียวกัน เมื่อคุณสามารถเริ่มต้นเรื่องราวของผู้ใช้ได้ฉันจะนำแนวทางต้นแบบไปใช้ในการพัฒนา

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

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

ฉันจะขอแนะนำให้อ่านหนังสือสองเล่มโดยคาร์ล Wiegers - ต้องการซอฟต์แวร์และข้อมูลเพิ่มเติมเกี่ยวกับความต้องการของซอฟต์แวร์ ฉันคิดว่าสิ่งเหล่านี้จะช่วยคุณในด้านวิศวกรรมความต้องการและแนวทางปฏิบัติที่ดีที่สุดในด้านนี้

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

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

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

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

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

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

คุณจำเป็นต้องรู้ข้อ จำกัด และช่วงสำหรับแต่ละฟิลด์ในแอปพลิเคชัน ตัวอย่างเช่นหากฟิลด์เป็นหมายเลขโทรศัพท์พวกเขาคาดหวังให้คุณจัดการ +1 หรือไม่ ต้องการฟิลด์ใด พวกเขาต้องการให้แอปพลิเคชันทำอะไรถ้าผู้ใช้พิมพ์ "abc" ในช่องโทรศัพท์ #? มีทั้งหมด 25 หน้าจอตามลำดับที่ผู้ใช้ทุกคนต้องดำเนินการต่อไปหรือไม่?

มิฉะนั้นเพียงสร้างทุกอย่างเป็นฟิลด์ข้อความและเสร็จแล้ว! อยากเดิมพันที่จะไปเหมือนบอลลูนนำ?