ขจัดปัญหาการใช้งาน Sketch File ร่วมกันกับทีมด้วย Abstract
เรียกสั้นๆว่า Git repository สำหรับนักออกแบบ
ยาวไปไม่อ่าน:
Abstract คือ Version Control สำหรับ Designer ที่ทำงานกันเป็นทีม ช่วยจัดการไฟล์ Sketch ได้ดีกว่า Google Drive หรือ Dropbox แถมยังทำงานร่วมกันกับทีมแบบไร้รอยต่อ พร้อมส่งให้หัวหน้างาน Approve ก่อนได้ด้วย ไม่ต้องตั้งชื่อไฟล์อย่างมีความหวังหลายรอบ เช่น “_v3.1_final-2” อีกต่อไป
ปัญหาหลักของ Designer เวลาทำงานกันเป็นทีมหนีไม่พ้นการใช้งานไฟล์ Sketch ใน Project เดียวกันแน่ ๆ ส่วนใหญ่อาจจะใช้ Google Drive หรือ Dropbox เป็นตัว Share ไฟล์ใน Project กัน
…ลองนึกภาพว่าโปรเจ็กต์นึงมีไฟล์ Sketch ซัก 3–4 ไฟล์ ไม่รวม Sketch Library อีกประมาณ 1–2 ไฟล์ เวลาทำงานร่วมกันต้องวุ่นวายตายแน่ ๆ
แน่นอนว่าปัญหาที่ตามมาคือ…
“ไฟล์อันไหนคือล่าสุดวะ”
“ใครใช้งานไฟล์นี้อยู่รึป่าว เปิดแก้ได้ใช่มั้ย”
“ใครเซฟทับไฟล์นี้เฮ้ย งานที่ทำไปหายหมดเลยไอ่🐃”
…
เราอาจจะต้องลองแก้ปัญหาด้วยการทำ Version Control สำหรับไฟล์ Sketch พวกนี้ซักหน่อย
Version Control คืออะไร?
Version Control คือ ระบบการจัดเก็บการเปลี่ยนแปลงของไฟล์หลาย ๆ ไฟล์ เป็นเวอร์ชั่นต่าง ๆ และสามารถเรียกเวอร์ชั่นใดเวอร์ชั่นหนึ่งกลับมาดูเมื่อไหร่ก็ได้ ใช้กับไฟล์ได้ทุกรูปแบบ
ถ้าในวงการ Coding คงไม่ใช่เรื่องใหม่อะไร เพราะมีเครื่องมือทำ Version Control มหานิยมอย่าง Git และมีผู้ให้บริการมากมาย อาทิ GitHub, GitLab, Bitbucket อยู่แล้ว
แต่สำหรับวงการ Design แล้วถือว่าเป็นเรื่องใหม่อยู่พอสมควร (จริง ๆ ก็มีมา 2–3 ปีแล้วแหละ) ผู้ให้บริการก็มีไม่เยอะมากเท่าไหร่ อาทิ Abstract, Folio, Kactus, Sympli, Plant
อ่าว… เยอะอยู่เหมือนกันนี่หว่า 😳
Abstarct ดียังไงล่ะ?
Abstract คือ Version Control ที่ออกแบบมาเพื่อให้ทีม Design ใช้งานโดยเฉพาะ ใช้งานร่วมกับโปรแกรม Sketch สามารถรวมไฟล์ทั้งหมดไว้ในโปรเจ็กต์ของ Abstract ได้เลย ไปบอกเลิก Google Drive กับ Dropbox ได้เลย
ใช้เป็น Version Control ได้
Abstract จะจัดการและจัดเก็บการเปลี่ยนแปลงไฟล์ต่าง ๆ ได้ ดูได้ว่าแก้เมื่อไหร่ แก้โดยใคร ช่วยให้คุณเปรียบเทียบการแก้ไขที่เกิดขึ้นในเวอร์ชั่นก่อนและหลัง และยังช่วยกู้คืนเวอร์ชั่นใด ๆ กลับมาได้อีกด้วย
โดยจะทำงานคล้าย ๆ กับ Git ของ Developer ก็คือจะมี Branch หลักเป็น Master
ถ้านาย A ต้องการทำ Feature ใหม่ขึ้นมา ก็แค่แตก Branch ออกไปจาก Master แล้วทำ ส่วนนาย B ต้องการปรับสีใหม่ ก็แตก Branch ออกไป Master อีก 1 เพื่อแก้งานของตัวเอง
เรียกได้ว่า…
“แตก (Branch) แล้วแยกทาง (ไปทำงาน) ได้เลย”
ทำงานแบบไม่ทับไลน์ไดม่อนกัน
ฟีเจอร์ในฝันของทีมดีไซน์ทุกที่ คือ แก้ไฟล์ได้อย่างอิสระใน Branch ของตัวเองตามที่บอกไปข้างต้น ทำเสร็จค่อย รวม (Merge) เข้าไปที่ Master จากนั้นทุกคนที่แก้ไขงานในโปรเจ็กต์เดียวกันอยู่ จะได้อัพเดตอัตโนมัติทั้งทีม สวรรค์ไหมล่ะ
ถ้าหากว่าทำงานชนกัน เช่น สมมติไปแก้ Symbol ปุ่ม ๆ เดียวกันขึ้นมา นาย A ทำปุ่มสีดำ ส่วนนาย B ทำปุ่มสีเหลือง พอเวลา Merge เข้า Master จะเกิดปัญหาที่เรียกว่า Merge Conflict
Abstract จะฉลาดพอที่จะรู้ว่า Artboard หรือ Symbol ไหนที่เราทำชนกัน คนที่ Merge ที่หลังจะต้องเลือกว่าจะใช้อัพเดทของใคร ซึ่งตรงนี้ต้องไปคุยกันในทีมแล้วเลือกกันเอาเอง อย่านึกไปเองว่าต้องใช้ของใคร อาจจะได้ต่อยกันภายหลัง
จัดการ Sketch Library ได้เลย
หลาย ๆ ทีมคงใช้งาน Sketch Library กันบ้างแล้ว (ถึงจะไม่รู้ว่ามันทำงานกันยังไงก็เหอะ) แต่ Abstract จะช่วยให้เราเข้าใจการใช้งาน Library ได้ง่ายขึ้นกว่าเดิม
สามารถสร้าง Library ที่ใช้ในโปรเจ็กต์ได้เลย และทุกไฟล์ที่อยู่ในโปรเจ็กต์จะได้ Link กับ Library อัตโนมัติ และสามารถ Link Library ข้ามโปรเจ็กต์ได้อีกด้วย
ส่งเป็น Review Request และ Approve ได้
เราสนับสนุนให้คุยกันดีกว่าต่อยกัน ฉะนั้น เวลาแตก Branch ไปทำกันเสร็จแล้ว ตอน Merge กลับมาก็ต้องมีขั้นตอนป้องกันการต่อยกันนั่นก็คือส่ง Review Request
Review Request คือการส่งให้ทีมหรือหัวหน้างานรีวิวก่อนจะ Merge เพื่อป้องกันการ Merge แบบไม่ถามไถ่ทีมนั่นแหละ และเมื่อหัวหน้างาน Approve แล้วค่อย Merge ได้ ลดอัตราการต่อยกันภายในทีม
ทำงานร่วมกับ Dev และ Stakeholder อย่างลงตัว
Abstract มีฟีเจอร์ Inspect ถ้าใครใช้ Zeplin มาก่อนก็ไม่ต้องอธิบายเพิ่มแล้ว ก็คือสามารถ Inspect UI ดูระยะห่าง โค้ดสี Spec ต่าง ๆ ได้เหมือน Zeplin ทุกอย่าง
แต่…ดีกว่าตรงที่สามารถดูเป็น Layer ได้ด้วย! เหมือนเปิดดูใน Sketch อย่างไงอย่างงั้นเลย
สรุป
ดีมาก ใช้เหอะ จะไม่เป็นภาระของลูกหลานที่มาทำงานต่อ
.
.
.
รักษาสุขภาพ(จิต)กันด้วยนะครับ เจอกันบทความหน้า บาย 👋
