Hế lô mọi người, hôm trước bạn mình xem video Sketch UI/UX của mình xong mới ồ lên, hoá ra UI/UX là cái này à, lần trước đi học trung tâm xong thấy mọi người cứ gọi UI/UX nhưng không hình dung được nó là gì.
Với BA, UI/UX hiểu đơn giản là cái màn hình của hệ thống mà bạn cần vẽ và mô tả lại.
Để chi tiết hơn, tại bài viết này, mình sẽ thống kê lại những điều xung quanh việc mô tả màn hình nhằm mang đến cái nhìn tổng quát cho các bạn về công việc này. Với các bạn đang tìm hiểu về BA, bạn có thể hiểu thêm về công việc của tụi mình. Với các bạn đang làm BA rồi, hãy cùng tham khảo xem có cái nào bạn đã biết, chưa biết hay có thêm comment cho mình nha ^^ 1. KHÔNG PHẢI DỰ ÁN NÀO BA CŨNG CẦN PHÂN TÍCH MÀN HÌNH
Với các dự án chuyên về API, ví dụ, API để đẩy dữ liệu khách mua hàng về hệ thống giao hàng, nhiệm vụ của BA là phân tích dữ liệu đẩy về. Dữ liệu đẩy về có đúng định dạng, có những validation nào,...Do vậy, không cần màn hình cho user tương tác và BA không phải làm task mô tả màn hình trong những dự án này. 2. CÓ NHỮNG DỰ ÁN KHÁCH HÀNG CUNG CẤP SẴN MÀN HÌNH
Trong một số dự án outsource (Khách hàng đã định sẵn giải pháp, thuê đội dự án để làm chi tiết thêm và xây dựng phần mềm), có thể khách hàng sẽ cung cấp luôn màn hình. Nhiệm vụ của BA là phân tích lại màn hình, trao đổi lại với khách hàng nếu có điểm nào bất hợp lý, sau đó mô tả từng chi tiết trên màn hình cho đội dev xây dựng lại và tester kiểm định. 3. CÓ NHỮNG DỰ ÁN BA CẦN VẼ MÀN HÌNH
Với những dự án khách hàng chỉ đưa ra yêu cầu, BA cần phân tích và đưa ra giải pháp phù hợp. Bạn sẽ cần vẽ màn hình để khách hàng hình dung giải pháp và xác nhận lại xem đã đáp ứng yêu cầu chưa.
Với các dự án không có designer, màn hình của BA vẽ ra sẽ là căn cứ cho dev và test, do vậy BA cần chi tiết các thông tin trên màn hình, về vị trí, dấu chấm, dấu phẩy, viết hoa hay viết thường. Tuy nhiên, sản phẩm thực tế tạo ra có thể chỉ giống màn hình BA thiết kế ban đầu tương đối. Do tài liệu của BA có thể chỉ đảm bảo yêu cầu khách hàng về các trường, validation, thao tác của user và mang tính tương đối cho vị trí, màu sắc, cỡ chữ,.... Dev sẽ xây dựng màn hình đảm bảo được nghiệp vụ khách hàng và tự quyết về chi tiết vị trí, màu sắc, cỡ chữ của các thành phần trên màn hình. 4. VỚI NHỮNG DỰ ÁN CÓ DESIGNER ĐI CÙNG BA
Với những dự án này, BA sẽ làm việc với Designer để ra được màn hình. Nhờ sự tham gia của Designer, màn hình sẽ được thiết kế đẹp hơn, đem đến trải nghiệm người dùng tốt hơn. Màn hình của Designer thiết kế cũng sẽ là căn cứ cho dev, test từng chi tiết về vị trí, mã màu, cỡ chữ để xây dựng màn hình chính xác.
Nếu Designer làm việc song song với BA, bạn chỉ cần liệt kê các trường, định dạng, vị trí mong muốn và trao đổi trực tiếp với Designer. Trong trường hợp Designer đi sau BA, bạn lại cần vẽ màn hình để dev, test xây dựng trước và sửa lại sau khi Designer đã update. 5. CÓ DỰ ÁN CẦN MÀN HÌNH Ở DẠNG PROTOTYPE
Trong trường hợp đặc biệt như cần dự án chứng minh năng lực, hay màn hình quá phức tạp, khách hàng có thể yêu cầu xây dựng Prototype, tức màn hình mà họ có thể tương tác như thật.
Chỉ sau khi tương tác, họ mới có thể xác nhận màn hình đã đạt yêu cầu để xây dựng. 6. SITEMAP - SƠ ĐỒ MÀN HÌNH
Khi thiết kế toàn bộ hệ thống, BA có thể vẽ sơ đồ các màn hình để nhìn bức tranh tổng thể. Sơ đồ này gọi là Sitemap, thể hiện đơn giản các màn hình mở ra theo thứ tự từ menu. Ví dụ về Site Map7. CÁC CÔNG CỤ VẼ MÀN HÌNH THƯỜNG DÙNG
Công cụ phổ biến nhất BA thường dùng có lẽ là Balsamiq. Hồi xưa mình có dùng thêm Pencil và tham khảo cả thêm Draw.io. Theo cảm nhận của mình, Balsamiq vẽ khá nhanh, cũng có sẵn nhiều thành phần từ icon, text, container,... cho BA dễ dàng vẽ. Pencil thì vẽ khá đẹp. Hồi xưa mình còn nhầm hình vẽ là màn hình thật, bấm bấm Button như đúng rồi, hihi. 8. CÁC CÔNG CỤ ĐỂ CHỤP ẢNH MÀN HÌNH
Để mô tả màn hình cho dev, test, BA cần đánh số từng thành phần. Công cụ thường để chụp ảnh lại và đánh số từng item là Snagit. Gần đây thì mình hay dùng FastStone. Lúc nào màn hình đơn giản mà chưa kịp cài công cụ thì dùng luôn Paint để ghi từng số 1, 2, 3,... vào màn hình. 9. CÁC YẾU TỐ CẦN MÔ TẢ CHO MÀN HÌNH
BA cần mô tả từng field cho màn hình, các yếu tố cần nhắc thường sẽ là: Tên field, định nghĩa, độ dài, là trường bắt buộc hay không, user có thể tương tác field này hay không, dữ liệu lấy từ đâu,... 10. BA CÓ THỂ TẠO MÔ TẢ MẪU VỀ ĐỊNH DẠNG CHO CÁC FIELD
Với các field có định dạng quy định sẵn, ví dụ Date - định dạng DD/MM/YYYY, Email - định dạng theo chuẩn email (cần chứa @,...), Số điện thoại - Định dạng gồm bao nhiêu số,... BA có thể tạo mô tả mẫu trước cho các field này và refer khi mô tả cho các màn hình. 11. TRÊN HỆ THỐNG CÓ THỂ CÓ CÁC MÀN HÌNH TƯƠNG TỰ NHAU
Ví dụ các màn hình thuộc master data (thuộc loại danh mục), cấu trúc khá giống nhau và các chức năng đều thường là Tạo mới, Xem, Sửa, Xoá. BA có thể viết một mô tả mẫu và refer đến mô tả mẫu này khi mô tả một màn hình và chỉ ra điểm khác biệt so với mẫu, giảm effort khi mô tả màn hình. Dev cũng có thể dựa vào đó để xây dựng một mẫu dùng chung.
Hoặc với các màn hình nghiệp vụ, một phần của màn hình này có thể giống với các màn khác. Ví dụ như phần lịch sử thay đổi các thông tin màn hình, đều lưu tên người thay đổi, nội dung thay đổi, thời gian thay đổi,... Bạn có thể viết một mô tả chung để dùng đi dùng lại ở các màn hình khác nhau. 12. CÁC CẤP ĐỘ KHI THIẾT KẾ MÀN HÌNH
Theo mức độ phức tạp tăng dần, chúng ta có Sketch, Wireframe, Mockup và Prototype. BA có thể nhầm lẫn tên gọi của các loại nếu chưa hiểu định nghĩa và ngữ cảnh dùng từng loại. Về phần này, các bạn có thể tham khảo một bài viết của mình để hiểu rõ hơn tại: Sketch, Wireframe, Mockup và Prototype UI/UX trong công việc của BA
Cảm ơn bạn đã đọc bài, có ý kiến gì comment bổ sung thêm cho mình nha ^^
Great content! Keep up the good work!
Thanks so much ^^