เผยเทคนิคการทำ Prototype สำหรับ Startup ที่ Designer อ่านได้ Developer อ่านดี​ โดยใช้ React

พฤศจิกายน 17, 2017 6:25 am โดย admin
0
16

บทความนี้ ถูกโพสครั้งแรกที่ https://medium.com/@ranatchai/แนวคิดการทำ-prototype-ด้วย-react-95bdd41bed0a


จากบทความที่ TURBO เคยเล่าไว้ใน Startup Weekend แค่ 3 วัน 2 คืน ก็เหมือนได้ลองสร้าง Startup จริงๆ เรื่อง Startup Weekend คืออะไรให้ไปอ่านในบทความนู่นนะ 555 พอมีคนถามมามากว่าทำไมถึงเขียนแอพได้เร็วจัง

ในบทความนี้ ผู้เขียนเลยจะมาเปิดเผยวิธีและเทคนิคทั้งหมดที่ใช้จากประสบการณ์ที่ได้มากจากการทำ Startup และใช้ ReactJS มากว่า 2 ปี มาสร้าง Prototype โดยใช้เวลาตั้งแต่เริ่มทำ Wireframe ถึงจบงานรวมแล้ว 14 ชม.

บทความนี้ อาจจะไม่ได้ลงลึก Technical มากนักแต่จะเน้นแปะลิ้งให้ไปอ่านเพิ่มเติมเอง ถ้าชอบบทความแนวนี้สามารถมาติดตามต่อได้ที่ https://medium.com/@ranatchai

Demo

ดูตัวอย่างคร่าวๆกันก่อน สามารถดูวิดิโอเต็มๆ จาก youtube ด้านล่างครับ หรือลองเล่นจริงได้ที่ https://costudy.firebaseapp.com/


 บทความนี้จะพูดถึงอะไรบ้าง

  1. ทำไมเราถึงต้องทำ Prototype กันนะ

    • บทนี้ ผู้เขียนอยากชี้ให้เห็นถึงเหตุผลก่อนว่าทำไม เราถึงต้องทำ Prototype
  2. ทำไมถึงไม่ใช้ Tool ที่ออกแบบมาเพื่อทำ Prototype โดยเฉพาะ

    • Tool สำหรับทำ Prototype โดยเฉพาะก็มีอยู่เยอะ ทำไมผู้เขียนถึงไม่ใช้
  3. การทำ Prototype ด้วย React และคำถามที่ถูกถามบ่อย

    • บทนี้เป็นบทความสำหรับ Developer แล้ว ว่าทำต้องเป็น React ถ้าไม่ Geek พอแนะนำให้ข้ามไป
  4. การทำงานเป็นทีมกับ designer และฝั่ง business

    • จะพูดการทำงานเป็นทีม Product ที่ได้ จะไม่มี hero แค่คนเดียว
  5. การบริหารเวลาการทำงาน

    • ปิดท้าย จริงๆแล้วผลลัพธ์ที่ดี เกินกว่า 50% เกี่ยวกับการบริหารเวลา

1. “Start With Why” ทำไมเราถึงต้องทำ Prototype กันนะ

golden-circle2

รูปภาพจาก https://blog.hubspot.com/customers/3-takeaways-from-start-with-why

ขอเปิดด้วยคำถามก่อนละกันครับ ว่าทำไมเราถึงต้องทำ Prototype กัน เราควรจะเข้าใจจุดประสงค์ของการทำกันก่อน แล้วเราจะสามารถตัดสินใจที่จะทำอะไรได้ดีขึ้น

  • เพื่อขายไอเดีย — Prototype ช่วนทำให้การไป pitching ขายไอเดียให้ลูกค้าได้ดีขึ้น การที่ลูกค้าสามารถสัมผัส website หรือ app จริงๆได้นั้น จะช่วยพิสูจน์ vision ได้ดีกว่าคำพูดนับพันๆ คำ
    • เพื่อทดสอบไอเดีย — Wireframes, mockups และไอเดียที่เป็นลมปาก นั้น มันไม่สมจริงการทำ Prototype นั้นจะช่วยให้ทีม ทดลองและทดสอบกับผลลัพธ์ที่เสมือนจริง เมื่อเจอปัญหาและจุดบอดของไอเดียหรือ Design จะทำให้แก้ไข ได้รวดเร็วกว่า และยังช่วยให้ทีมเข้าใจตรงกันด้วย ว่าสิ่งที่ทีมต้องการมันหน้าตาเป็นยังไง โดยที่ไม่ต้องรองานจริงเสร็จ
    • ผู้อ่านสามารถ เข้าไปอ่านบทความนี้เต็มๆ ได้ที่ How & Why Prototypes Are Mandatory for Good Design
comic

ที่มา https://designshack.net/articles/graphics/how-why-prototypes-are-mandatory-for-good-design/

2. ทำไมถึงไม่ใช้ Tool ที่ออกแบบมาเพื่อทำ Prototype โดยเฉพาะ

ยกตัวอย่างเช่น InVision, Origami หรือ FramerJS ออกตัวไว้ก่อนว่า แต่ละ Tool นั้นต่างก็มีข้อดีเสียต่างกัน ซึ่งผมลองใช้งานมาหมดแล้ว ถ้าให้ Review ให้ฟังทั้งหมดนั้นคงเขียนเป็นบทความใหม่ได้เลย ถ้าผู้อ่านสนใจ Tool เหล่านี้ สามารถไปอ่านเองได้ที่ Five app prototyping tools compared ส่วนผมจะขอสรุปเอาแค่สั้นๆละกัน

screenshot-1080@2x

ข้อดีของการ Prototype ด้วย Code

  • ผลลัพธ์สมบูรณ์เหมือนกับแอพจริงๆ มากกว่า และสามารถส่งให้คนอื่นลองเล่นได้ โดยไม่ต้องบอกวิธีใช้อย่างละเอียด
  • การ Prototype ด้วย Code นั้นมี Flexibility สูงกว่า สามารถ Custom รายละเอียดหรือเพิ่ม Feature ได้ดีกว่า ทำให้รองรับการเปลี่ยนแปลง Requirement ได้ดีกว่าด้วย ผมจึงสามารถเริ่มทำไปพร้อมๆ กับ Wireframe ที่ฝั่งทีม Design ยังทำได้ไม่สมบูรณ์ได้เลย
  • เหมาะกับการแสดง flow การทำงานที่เยอะ หรือเป็น feature ที่ extend ต่อจากงานเดิม

ข้อเสีย

  • ต้องการความคล่องแคล่วในการ code สูง เพื่อที่จะกำหนดได้ว่างานจะออกมาเสร็จได้ตามเวลาแค่ไหน
  • ถ้า flow ของผลลัพธ์น้อยจะไม่ค่อยคุ้มเวลาที่ใช้เท่าไหร่ ยกเว้นเป็นการ extend ต่อจากของเดิม
  • ต้องทำงานเป็นทีม ต้องประกอบด้วย Project Owner, Developer และ Designer แทบจะไม่สามารถทำออกมาได้ด้วยตัวคนเดียวได้เลย เพราะฝั่งนึงต้อง Focus ในทาง Design อย่างเดียวและอีกฝั่งก็ Focus ด้าน Develop อย่างเดียวและต้องมีคนคอยคุมภาพรวมอีก
  • ซึ่งถ้าใช้พวก InVision, Origami หรือ FramerJS Designer จะสามารถทำได้ด้วยตัวคนเดียวได้เลย

3. ทำไมถึงเลือก React ในการทำ Prototype

[GEEK ZONE] คำเตือนสำหรับคนที่ไม่ใด้สนใจเรื่อง Coding ให้ข้าม Section นี้ไป

บทที่แล้วเป็นการเปรียบเทียบระหว่าง การ Prototype ด้วย Code หรือ Tool สำเร็จรูป ส่วนบทความนี้เป็นบทความสำหรับ Developer แล้ว ว่าทำต้องเป็น React

  • พอผลลัพธ์เป็น web เราสามารถที่จะแชร์ผลลัพธ์ออกให้คนดูได้โดยง่าย
  • React มีความสามารถในการแบ่งเป็น component ย่อยได้ดี โดย component ที่ถูกสร้างด้วย React จะมี scope การทำงานอย่างชัดเจน จึงเพิ่มอิสระในการทำงาน ทำให้ผู้เขียนสามารถนำ components ต่างๆ ที่เคยเขียนไว้ใน Project เก่าๆ กลับมา reuse ใช้ได้
  • React hot reload อีกหนึ่งตัวช่วย ให้เราสามารถ Live-editing ได้ โดยหลังจากสั่ง save จะทำให้ผลลัพธ์ใน Browser เปลี่ยนไปตามนั้นทันที ผู้อ่านสามารถเลื่อนลงไปดู ตัวอย่างการใช้งานจากด้านล่างจะเข้าใจได้ทัน และเรื่องนี้ทำให้เราทำงานได้เร็วขึ้น 2–3 เท่า มันหมดยุคเขียนโค้ดเสร็จที ต้องรอรันเป็นนาทีแล้วครับ 😀
  • ผู้เขียนมีความชำนาญและความมั่นใจจากการใช้ประจำ 🙂

ข้อเสียที่พบจากการใช้ React ทำ Mobile Prototype

  • ผู้ใช้ต้องมีความคล่องแคล่วและประสบการณ์จาก HTML, CSS และ React สูง ถึงจะสามารถคิดทางออกและสร้าง Prototype ออกมาได้อย่างไม่ติดขัด
  • Component ที่ถูกสร้างมาเพื่อ Mobile ยังน้อยเกินไป ส่วนใหญ่ผู้เขียนสร้างขึ้นมาเองด้วย HTML และ CSS โดยเลือกทำแต่ component ที่ไม่ยากจนเกินไป
  • เพราะสร้าง Mobile Specific Component ขึ้นมาเอง ตอนนำไปรันบน device จริงมี bug ในการแสดงผลประปรายเพราะ device จริงมาจาก browser และ OS ที่หลายหลาย ไม่ได้ดีเท่าเวลาทำใน Chrome Emulator
  • ที่จริงตอนนั้นมีอีกตัวเลือกคือใช้ React-Native ข้อดีคือเขียน Syntax เหมือน React ทุกประการ livereload ก็มี Component ก็เป็น Native Component คุณภาพสูง
  • แต่สุดท้ายก็เลือก React ธรรมดา เพราะมีความคล่องกว่ามั่นใจกว่า และยังสามารถ Share ให้คนอื่นดูได้ ตรงกับจุดประสงค์หลักมากกว่า 🙂

ตัวอย่าง Code เทคนิคที่ใช้และ Source Code

จะนำเสนอตัวอย่างคร่าวๆ รวมถึงเทคนิคที่ใช้นะครับ ส่วน code ตัวเต็มก็มี link ให้โหลดอยู่ด้านล่าง

ใช้ Chrome Inspector เพื่อจำการทำงานของมือถือ

ใช้ Chrome Inspector เพื่อจำลองการทำงานของมือถือ

การใช้ React hot reload ทำให้สามารถทำ Live-editing ได้จากการ Code สามารถ ดูรายละเอียดเต็มๆ ได้ที่ https://vimeo.com/100010922

Generate Data เพื่อใช้ในการ Prototype

Generate Data เพื่อใช้ในการ Prototype

สั่ง load image ทันทีที่เปิด เวลาที่เรา navigate ไปหน้าอื่นๆ จะได้พบรูปที่เสร็จหมดแล้ว

สั่ง load image ทันทีที่เปิด เวลาที่เรา navigate ไปหน้าอื่นๆ จะได้พบรูปที่เสร็จหมดแล้ว

แบ่ง Component ใหญ่ๆ เป็น Page Component แล้วสร้าง Page Transition ด้วย ReactCSSTransitionGroup

แบ่ง Component ใหญ่ๆ เป็น Page Component แล้วสร้าง Page Transition ด้วย ReactCSSTransitionGroup

สำหรับ code โดยละเอียด ผู้อ่านสามารถลองเข้าไปโหลด Source code มาแกะและลองรันเองได้ด้วยขั้นตอนง่ายๆ ได้ตามลิ้งนี้ https://github.com/Ranatchai/co-study-prototype

คำถามที่ถูกถามบ่อย

section นี้จะตอบคำถามที่ผมมักจะโดนถาม เมื่อผมใช้ React ในการทำ Prototype

ปกติ React เค้าใช้ร่วมกับ Redux, React-Router นิ?

  • Redux และ React-Router ต่างก็เป็นสิ่งที่ดีและจะยิ่งเห็นผลชัดเจนกับโปรเจ็คขนาดใหญ่ แต่การใช้ของเหล่านี้ จะทำให้เสียเวลาเพิ่มขึ้น 2–3 เท่า
  • อย่าลืม จุดประสงค์หลักเราคือการสร้างขึ้นมา เพื่อนำไปทดสอบไอเดีย อะไรก็ตามที่ไม่ fit กับเป้าหมายนี้ ก็ไม่ควรทำทั้งนั้น

ทำไมถึงไม่ใช้ CSS Framework เช่น Bootstrap หรือ Foundation

  • ถ้าเราทำงานคนเดียว การหา CSS Framework มาใช้จะเหมาะสม เพราะเราจะได้ไม่ต้องเปลี่ยนหัวไปมาระหว่าง design mode กับ dev mode บ่อยๆ
  • แต่เมื่อเราทำงานกับคนอื่น (Designer) การที่จะให้เค้าทำงานภายใต้กรอบของ CSS Framework จะทำให้สร้างสรรค์ผลงานออกมาได้ไม่สุด และสุดท้าย เค้าก็จะทำงานออกมาใน style ของตัวเอง การใช้ CSS Framework จะกลายตัวถ่วงแทน
  • เว้นแต่ว่าถ้าตัว Designer มี UI Kits ที่ fit กับตัวเองอยู่แล้ว ผมก็ยินดีที่จะใช้งาน

4. การทำงานเป็นทีมร่วมกับ Designer และกับฝั่ง Business

เพราะ Product ที่ได้จะไม่มี hero แค่คนเดียว skill ในการประสานงานกับคนอื่น เป็นสิ่งที่สำคัญมากถ้าอยากได้ผลลัพธ์ที่ดี นอกจากเราที่จะใน state ที่สมบูรณ์ที่สุดแล้ว เราต้องทำให้คนอื่นในทีมได้ทำในสิ่งที่ตัวเองถนัดที่สุดอย่างเต็มที่ด้วย

costudy-wireframe

การใช้ Sketch ช่วยลดเวลาถึง 2–3 เท่าในส่วนที่ทำเกี่ยวกับ design

จุดประสงค์ของารเขียนโค้ดคือการแปลงจาก Static Prototype ไปเป็น Interactive Prototype เพื่อให้การทดสอบไอเดีย สมจริงมากยิ่งขึ้น

  • จากการได้รับคำแนะนำที่ดีจาก mentor พี่ดาริน เราเลยร่วมกันสร้าง User Journey ที่เราจะนำไป Pitch ก่อน โดยเริ่มจากหน้าแรกไปถึงหน้าสุดท้ายผลลัพธ์ที่ได้ จะเป็นภาพร่างคร่าวๆในกระดาษ
  • แยกกันไปทำงานโดยอีกฝั่งเริ่มเอาภาพร่างจากกระดาษไปทำเป็น Wireframe ด้วยโปรแกรม Sketch แล้วค่อยๆเพิ่มรายละเอียดลงไป ส่วนผมก็เริ่มทำงานโดยเริ่มจากในกระดาษเหมือนกัน แต่ก็จะค่อยๆได้ Wireframe ที่ยังไม่ละเอียดนักมาเรื่อยๆ ผมก็จะเลือกทำส่วนที่เป็นโครงที่ไม่น่าจะเปลี่ยนแปลงก่อน
  • ผมชอบการทำงานกับคนที่ใช้ Sketch มาก เพราะตัว Sketch เองถูกออกแบบมาสำหรับการทำ UI โดยเฉพาะ ด้วย Feature ที่ใช้บ่อยๆ อย่างการ Export Assets, Copy CSS Style โดยพบว่าจะช่วยลดเวลาถึง 2–3 เท่าเทียบกับเมื่อก่อนที่ทำงานกับ Photoshop
  • พอผม Focus ที่จะเขียนโปรแกรมแล้ว ผมจะหยุดรับ Requirement จากฝั่ง Business โดยตรง โดยจะฝาก Designer ที่ทำหน้าที่เป็น Project Owner ด้วยในการคิดและตรวจสอบว่าการเปลี่ยน Requiement ในตอนนั้นจะมีผลดีผลเสียแค่ไหน และจะต้องแก้อะไรบ้าง

5. จริงๆ แล้วสิ่งที่สำคัญที่สุดคือ การบริหารเวลา

สิ่งที่ผู้เขียนคิดว่าช่วยในการทำ prototype ให้เร็วที่สุด ไม่ใช่ Sketch หรือ React เลย แต่คือการบริหารเวลา

  • ผมเริ่มจากการสอบถามเพื่อนที่เคยมางานแบบนี้แล้ว ว่า timeline ของงานจะเป็นประมาณไหน เพื่อที่จะได้สามารถบริหารเวลาได้ดีขึ้น
  • ไม่รีบเร่งที่จะเริ่มเขียน code แต่พยายามที่จะเก็บข้อมูล เข้าใจปัญหา และเข้าใจจุดประสงค์ที่เรากำลังสร้าง สุดท้ายได้ช่วยกันทำ User Journey มาก่อนถึงเริ่มต้นเขียน code จริง Starting Slow In Order to Go Fast ครับ
  • กว่าผมได้เริ่มเขียน code ก็ 5 โมงเย็นเสาร์แล้วครับ โดยในช่วงแรก จะเน้นใช้เวลาไปกับการขึ้นโปรเจ็ค ทำตั้งแต่หน้าแรกไปจนถึงหน้าสุดท้าย โดยที่ยังไม่เก็บรายละเอียดให้ครบทุก flow และเน้นทำเฉพาะสิ่งที่ตัวเองมั่นใจว่าจะไม่เปลี่ยน อันนี้เสร็จตี 1 วันอาทิตย์รวมแล้วประมาณ 8 ชม.
  • แล้วคุยกับ Designer ว่า เก็บแรงไว้เผื่ออีกวันดีกว่า เพราะทีม Business กลับไปหมดแล้ว ไม่มีคนช่วยดูว่า ผลลัพธ์ไปถูกทิศทางรึเปล่า
  • วันที่สอง 9 โมงเช้าวันถัดมา ก็เริ่มจากการเอาผลลัพธ์ของเมื่อคืนให้ทีมดูก่อน พร้อมรับ feedback ต่างๆ ดูว่ามาถูกแนวทางไหม แล้วก็โฟกัสไปที่การแก้ไข Design และเก็บรายละเอียด รวมๆแล้วประมาณ 6 ชม.
  • สรุปว่าใช้เวลาตั้งแต่เริ่มเขียน code รวมแล้ว 14 ชม. ยังไม่หักเวลาคุยงานและเวลากินข้าว

สรุป

  • ในบทความ ผมจะพูดซ้ำหลายรอบมาก ถึงเป้าหมายของในการสร้าง Interactive Prototype ขึ้นมา นั่นคือการทดสอบไอเดียที่มีความสมจริง มีน้ำหนักสูง
  • แต่ถ้า idea นั้นๆ มีวิธีอื่น ที่จะ validate ผลลัพธ์ได้เร็วกว่าและได้ผลลัพธ์ที่เพียงพอ เราก็ไม่จำเป็นที่ต้องเขียน Code ออกมาเลยด้วยซ้ำ
  • หากเริ่มเขียนแล้ว เราไม่สามารถหลีกเลี่ยงการแก้งานได้ แต่สามารถลดมันได้ ด้วยการบริหารเวลาและการคุยงานที่ดี
  • ในเวลาที่จำกัด เราไม่ควรใช้วิธีที่หวือหวา หรือวิธีที่คนอื่นแนะนำแต่เราไม่คุ้นเคย แต่เราควรจะใช้วิธีที่เราถนัดที่สุด มั่นใจ ฝึกมาแล้วซึ่งคาดการณ์เวลาที่ใช้ได้โดยคร่าวๆ มากกว่า ซึ่งจริงๆ แล้ว Project ที่นำมาใช้ทำ Prototype ในงานนี้ ก็คือ Project ที่ผู้เขียนนำมาใช้ทำ Prototype หลายๆรอบแล้ว ในงานของตัวเอง หลายๆอย่าง จึงถูกปรับแต่งมาเป็นอย่างดีแล้วนั้นเอง
  • แต่ในช่วงที่เราไม่มีอะไรเร่งด่วน เราควรหาวิธีใหม่ๆ และปรับปรุงวิธีทำงานให้เร็วขึ้นเสมอ Always optimize your workflow ครับ
  • ใครสนใจศาสตร์แห่งการทำ Product หรือ Prototype ขอแนะนำหนังสือเล่มนี้ครับ Inspired: How To Create Products Customers Love
  • ปล. บทความนี้เป็นบทความแรกของผม แต่จะไม่ใช่บทความสุดท้าย ถ้าชอบก็อย่าลืมเข้า ไปกดติดตามได้ที่ https://medium.com/@ranatchai ครับ ขอบคุณครับ 🙂



แสดงความคิดเห็น