Hế lô 500 anh emmmm 🙂
Hằng ngày đi làm, chắc hẳn anh em hay nghe những thứ như Wireframe, Mockup, hay Prototype.
Mình tin là ai cũng biết mấy thứ này nói về gì. Nhưng để hiểu rõ từng loại một, đặc tính và mục đích sử dụng của từng loại thì không phải anh em nào cũng nắm.
Bài note này mình sẽ chém gió một số thứ về UI, hi vọng giúp anh em phân biệt rõ: Như thế nào là Sketch, Wireframe, Mockup và Prototype? 😎
1. Khác biệt cơ bản
Thật ra lúc đầu mình cũng thấy hơi rối ở mấy khái niệm này. Gì mà tùm lum tùm la, ông nào cũng như ông nào, chả thấy khác gì nhao.
Nhưng để đơn-giản cu-te hột-me hơn thì anh em cứ hình dung như sau.
Có ông kiến trúc sư, người ta thuê ổng thiết kế một ngôi nhà. Ổng sẽ nghiên cứu, vẽ vời các kiểu để ra được một thứ, gọi là: BẢN THIẾT KẾ.
Vẽ xong, ổng mới đưa bản thiết kế này cho mấy anh kỹ thuật 3D, phác thảo ngôi nhà ra hình – ra dáng, để đưa cho khách hàng xem và duyệt..
Rõ ràng cả 2 bản: Bản thiết kế và Bản phác thảo khác nhau quá đúng không anh em?
- Một cái là thiết kế sơ khởi, chỉ gồm những phần chính, và thể hiện tổng quan ngôi nhà.
- Còn một cái thì lên màu, nội thất, chi tiết 3D đẹp đẽ các kiểu.
Đó là đi từ “thiết kế sơ bộ >> thiết kế chi tiết”.
Mỗi loại đều thể hiện một nội dung khác nhau, và truyền tải một thông điệp khác nhau.
Sketch, Wireframe, Mockup, hay Prototype trong phần mềm cũng vậy.
Về cơ bản, để xây một phần mềm thì anh em cũng phải đi từ thiết kế sơ bộ >> thiết kế chi tiết.
Và khoảng cách giữa “thiết kế sơ bộ >> thiết kế chi tiết” chính là nằm gói gọn trong 4 chữ: Sketch >> Wireframe >> Mockup >> Prototype, với mức độ chi tiết tăng dần theo từng loại.
Phần dưới đây anh em mình sẽ cùng tìm hiểu từng loại và mỗi loại nó khác gì nhau? Lét sờ gâuuuu!
2. Sketch
SKETCH đơn giản là PHÁC HỌA. Phác họa nghĩa là vẽ nhanh, phác thảo nhanh một hình ảnh nào đó. Keyword ở đây là nhanh, rất nhanh nhé anh em. Hoàn toàn không thể hiện tiểu tiết.
Vì sao lại vẽ nhanh?
Mục đích của Sketch là để capture nhanh những ý tưởng lúc anh em ngồi tư duy một mình hoặc đang brainstorm với nhau.
Đó là những lúc anh em ngồi trao đổi với nhau theo kiểu:
“Thế này, chỗ này có cái lưới, gồm n dòng ở đây, được chưa…
Chắc nút X để chỗ này, bấm vào cái bặccccc, là ra popup như thế này;
Đây đây, popup sẽ hiện chỗ này, một cục ngay đây nha…, cạnh lưới hình ảnh lúc nãy, ở đây nè, sao, ổn chưa……”
(đại loại vậy)
Thường mình hay dùng bút lông vẽ lên bảng trắng để trao đổi với đồng bọn. Ít khi dùng giấy bút như mấy hình Sketch đẹp đẹp trên mạng.
Vì khi anh em dùng giấy bút, lúc vẽ nhầm thì khó bôi lắm >> mà không bôi được thì xóa tới xóa lui >> xấu.
Mà không xóa tới xóa lui >> vẽ lại cái khác >> tốn thời gian >> đứt mạch suy nghĩ
Do đó, best nhất là cứ dùng bút lông vẽ lên bảng trắng. Sai tới đâu, vẽ lại tới đó. Nếu lỡ có sai thì quẹt một phát vẽ là trắng trơn ngay, cứ đà đó mà vẽ tiếp.
Và thường thì mình hay dùng Sketch để trao đổi về những tính năng enhancement. Tức system hiện tại đã có, khách hàng muốn làm thêm cái này, cái kia. Giờ bê cái đó lên hệ thống thì nó sẽ chạy ra sao?
Phương pháp Sketch không chỉ giúp anh em “hườm hườm” được màn hình của chức năng đó ngay tức thì, mà còn giúp cả team cùng suy nghĩ đúng-thứ-mình-đang-nói*.
*Tức, thay vì mình chỉ nói: “à à, cái nút đó ở trên, cái lưới ở dưới. Bấm vô cái nút thì popup hiện lên, cạnh cái lưới zậy nè….”. Thì rất có thể, mỗi người sẽ hiểu một kiểu khác nhau. Tới lúc confirm, ông thì hiểu A, bà thì hiểu Á >> lộn xì ngầu lên hết.
Nên, tóm gọn ở mục này:
SKETCH là bản phác thảo nhanh UI của phần mềm, nhằm ghi nhận nhanh ý tưởng về một chức năng nào đó.
3. Wireframe
Ô kê, sang cấp độ thứ 2, đó là Wireframeeeeeeee!!!
Wireframe thì chi tiết hơn Sketch đôi chút. Và sự “chi tiết hơn” ở đây thể hiện rõ được cấu trúc của giao diện phần mềm.
Cấu trúc là sao? Tức Wireframe sẽ giúp anh em thể hiện được:
- Luồng đi cơ bản của user (User Flows)
- Và cấu trúc nhóm thông tin gồm những gì?
Thường khi vẽ wireframe cho website hay web apps, mình sẽ luôn cấu trúc các phần consistent như sau:
- Header: gồm nhóm thông tin tổng quan như: Name, Owner, và Status.
- Body: gồm “X” section (các phần dữ liệu => thể hiện thông tin của wireframe này muốn mô tả về cái gì)
- Footer: thường mình sẽ để các trường thông tin cơ bản như: Created By, Created On, Modified By, và Modified On.
Theo mình, Wireframe là bước quan trọng nhất, vì nó chính xác là bộ khung của UI. Không cần quan tâm đến màu sắc, font chữ, to nhỏ, hiệu ứng thế nào; cái quan trọng nhất của Wireframe là ở cấu trúc và nhóm thông tin mà nó thể hiện.
Wireframe là bố cục của UI, mặc dù không quá chi tiết nhưng nó thể hiện rõ được luồng thao tác của người dùng và cấu trúc các nhóm thông tin có trên UI đó.
Một trong những công cụ tốt nhất để anh em vẽ Wireframe là Balsamiq. Trực quan, dễ học, dễ xài, tính năng đơn giản, thao tác nhanh gọn. Đủ để capture nhanh cấu trúc của một màn hình.
Wireframe phải luôn được design ở mức Low Fidelity và thường là output của các UX Designer. Đôi khi có thể là BA, do họ hiểu expectation của người dùng về User Flows. Nhưng nếu áp dụng đúng chuyên môn và trách nhiệm thì người làm Wireframe ngay từ đầu phải là UX Team.
Như mình nói ở trên, Wireframe phải thể hiện được: luồng thao tác của người dùng, và cấu trúc các nhóm thông tin ra sao. Nên phần nào nó sẽ định hình bộ khung cho tất cả màn hình có trong sản phẩm.
Do đó để làm tốt Wireframe, đòi hỏi anh em phải thật sự hiểu User và vấn đề mình giải quyết ở đây là gì. Thường chúng ta sẽ phải làm User Research rất kỹ để ra được các bộ User Personas. Để từ đó ra các quyết định về luồng thao tác và các component có trên UI của mình.
Sau khi chốt được bộ khung, anh em sẽ qua một thứ nhiều chi tiết hơn, đó là…
4. Mockup
Nhiều anh em hay đánh đồng Wireframe với Mockup là một về độ chi tiết của nó. Nhưng không, Mockup chi tiết hơn Wireframe rất, rất, và rất nhiều.
Chi tiết hơn, cả về: màu sắc, vị trí field, kích cỡ, font chữ, hình ảnh, đường kẻ, phân lô, phân luồng. Thậm chí là cả validation của các trường dữ liệu.
Tức trường nào thì được input, trường nào thì bị disable. Các trường phụ thuộc với nhau như thế nào. Khi trường A có giá trị 1, thì trường B có giá trị gì… đại loại vậy.
So với Wireframe chỉ thể hiện bố cục, cấu trúc của màn hình là chủ yếu. Thì Mockup lại thể hiện rõ màn hình nó có gì ở trỏng, chi tiết đến từng field, dấu chấm, dấu phẩy.
Mockup chính là Wireframe, nhưng ĐẦY ĐỦ thông tin và thể hiện được NHIỀU CHI TIẾT HƠN
Trong 4 loại: Sketch, Wireframe, Mockup và Prototype, độ chi tiết trên màn hình của Mockup và Prototype là cao nhất. Do đó khi làm Mockup, anh em đã phải rất rõ User Requirement.
“Rất rõ” là sao, là phải nắm được:
- Màn hình này thuộc chức năng/ nhóm chức năng nào?
- Màn hình này có nằm trong Business Process Flow nào không?
- Màn hình này thể hiện nội dung gì?
- Input/ Output trên màn hình này là gì?
- Những validation có trên màn hình này?
Thì chỉ khi nắm được những thông tin này, anh em mới đủ dữ kiện để làm Mockup khớp với requirement được. Chính khách hàng sẽ dựa vào các Mockup này để sign-off cho anh em làm tiếp. Để đảm bảo rằng: khách hàng sẽ nhận được đúng cái họ cần.
Hoặc ngầu lòi hơn, họ có thể yêu cầu không chỉ Mockup. Không chỉ là những màn hình tĩnh, vô tri vô giác – đơn điệu – nhạt nhẽo – chán òm này.
Mà họ cần một thứ gì đó: sống động hơn, linh hoạt hơn, thực tế hơn, và thể hiện một cách chính xác – chân thật đến từng mi-li-mét, thứ mà khách hàng muốn.
Khi đó, thứ anh em cần làm chính là… 😎
5. Prototype
Dòm bên ngoài thì Prototype không khác Mockup là mấy. Nhưng thứ làm Prototype trở nên vi diệu hơn đó là khả năng tương tác của nó.
Tức thay vì những màn hình tĩnh, thì với Prototype, người dùng hoàn toàn có thể tương tác trực tiếp với nó. Tức sờ mó, à nhầm… tức nhấn nút, kéo thả, trượt lên, trượt xuống, bung mở popup… các kiểu đều được.
Điều này sẽ giúp khách hàng mường tượng rõ hơn về sản phẩm họ sẽ nhận được.
Prototype là “mẫu thử đầu tiên” của phần mềm/ hoặc một chức năng của phần mềm, và người dùng có thể tương tác được ngay trên màn hình của chức năng/ phần mềm đó.
Thay vì Mockup chỉ thể hiện góc nhìn không gian: có những element nào trên màn hình.
Thì Prototype thể hiện luôn được góc nhìn theo thời gian: hiện tại màn hình như vầy, sau khi nhấn A, màn hình sẽ như vầy, sau khi kéo B, màn hình sẽ chuyển qua như vầy, hoặc nhấn nút C, 5 giây sau, thông báo này sẽ hiện ra…
Tức là rất có thể, khách hàng dòm vô cũng không biết cái nào hàng thật, cái nào hàng giả 😆
Nếu dịch ra tiếng Việt thì Prototype nghĩa là “mẫu thử đầu tiên”. Nghe hơi thô nhưng khá sát nghĩa.
Nghĩa là thay vì làm nguyên 1 phần mềm từ đầu tới cuối, anh em chỉ cần chọn ra 1-2 tính năng nổi trội nhất để làm Prototype mà thôi.
Nổi trội có thể là thứ quan trọng nhất. Hoặc thứ khó nhất, tức là làm để chứng minh năng lực. Chứng minh rằng: tụi tui hoàn toàn có thể làm được theo đúng như những gì mấy anh muốn, thậm chí… ngon lành hơn!!!
Thường Prototype được làm trong giai đoạn pitching dự án. Hoặc cũng có thể làm để làm rõ requirement với khách hàng. Thường áp dụng cho những requirement phức tạp, cần thể hiện một cách trực quan.
Một điểm nữa mình muốn nói, đó là: Prototype hoàn toàn khác với khái niệm “phiên bản beta”.
Bản beta là bản đầy đủ chức năng, đã có thể được sử dụng của một sản phẩm. Còn prototype chỉ là “phần mặt tiền trông có vẻ là hàng thiệt” của một sản phẩm nào đó thôi. Hoàn toàn không có code front-end và back-end phía sau.
Khác với Wireframe, Mockup hay Prototype sẽ do các anh em UI Designer lãnh đạn, à nhầm, lãnh trách nhiệm. Tức nhiệm vụ này sẽ do UI Team làm.
Họ sẽ dùng các chuyên môn riêng biệt của mình về: Interaction Design, Visual Design, hay bộ Design System của công ty… để cụ thể hóa wireframe bên trên do team UX thiết kế.
Còn đứng ở khía cạnh BA, chúng ta cũng có thể deliver những bản thiết kế này. Tùy vào cấu trúc team, budget, hoàn cảnh, hoặc cả kỹ năng và khả năng của anh em.
Nhưng anh em cũng nên lưu ý, thường trong dự án thì Prototype là thứ làm tốn nhiều effort, và tốn nhiều tiền nhất. Nên nếu sử dụng đúng lúc sẽ hiệu quả. Còn nếu làm dụng thì sẽ rất dễ bị “ô-vờ”, từ over budget, over time, overexpectation của khách hàng, không đáng!!!
Hiện thị trường có rất nhiều tool để làm Prototype. Nhưng một trong những món “powerful” nhất mình từng xài đó là AxureRP. Một trong những tool khủng mà anh em có thể configure điều kiện if else để mô tả những luồng tương tác phức tạp.
Anh em có tool gì ngon ngon thì còm men bên dưới để mình bắt chước nhé.
6. Tạm kết
Mình sẽ note vài gạch đầu dòng để anh em dễ lưu tâm như sau:
- Sketch: là bản phác thảo nhanh UI của phần mềm, nhằm ghi nhận nhanh ý tưởng về một chức năng nào đó.
- Wireframe: là bố cục của UI, mặc dù không quá chi tiết nhưng nó thể hiện rõ được luồng thao tác và cấu trúc nhóm thông tin có trên UI đó.
- Mockup: chính là Wireframe, nhưng ĐẦY ĐỦ thông tin và thể hiện được NHIỀU CHI TIẾT HƠN
- Prototype: là “mẫu thử đầu tiên” của phần mềm/ hoặc một chức năng của phần mềm, và người dùng có thể tương tác được trên màn hình của chức năng/ phần mềm đó.
Nói về độ “tốn effort để làm” thì: Sketch >> Wireframe >> Mockup >> Prototype. Theo đó thì Prototype là thứ tốn tiền nhất để làm, giảm dần xuống Mockup, và Wireframe.
Nên nếu ai đó đặt hàng anh em làm Mockup hay Prototype thì phải clear rõ nhu cầu và chi phí của từng loại ngay từ đầu nhé.
Về mục đích sử dụng của BA thì:
- Sketch: khi cần brainstorm
- Wireframe: khi elicit requirement, hoặc làm User Flows
- Mockup: khi cần xác nhận requirement
- Prototype: khi pitching dự án, hoặc kiểm thử/ xác nhận requirement.
Về công cụ:
- Sketch: bút lông, bảng trắng…
- Wireframe: Balsamiq, Axure, Sketch, Adobe XD, Figma…
- Mockup: Axure, Adobe XD, Figma…
- Prototype: Axure, Figma, Adobe XD…
Chốt lại: nắm rõ khái niệm, anh em sẽ dùng nó đúng chỗ hơn, biết khi nào thì cần mỗi loại, và chi phí giữa các loại ra sao.
Hi vọng bài note này giúp ích được cho anh em. Nếu có gì thắc mắc hoặc cần trao đổi thì cứ để lại còm men bên dưới cho mình nhé 🙂
05/03/2020 at 3:02 chiều
cảm ơn bài viết của bác nha. Quá hay
09/03/2020 at 10:03 sáng
Thanks Tuyên
14/09/2020 at 4:30 chiều
Bài viết rất tuyệt vời. Thanks anh ạ!!!!!
14/09/2020 at 11:25 sáng
Cảm ơn em
14/09/2020 at 5:08 chiều
Như e thấy a viết thì bản mockup chính là bản design vậy, mà cái này thường designer sẽ làm chứ ạ?
14/09/2020 at 3:54 sáng
Hi Quỳnh, Mockup nhằm thể hiện user behaviour để làm 1 function nào đó nhé em => sẽ giúp rõ hơn cho development team thực hiện và dễ hình dung hơn cho user agree với giải pháp của mình.
Còn UI chi tiết trên từng màn hình Mockup thì như em nói sẽ do bạn designer làm. Sẽ cần nhiều hơn các yếu tố thẩm mỹ và UX Research để design 1 bản UI/UX hoàn chỉnh. Còn Mockup thì mình nhìn theo góc độ User Behaviour sẽ rõ ràng hơn em nhé.
10/11/2020 at 6:46 chiều
Mockup, có thể dùng thêm invision studio or marvelapp
Lúc nào Thịnh xây dựng bài cách dùng AxureRP từ thực tế của mình nhé, nhất là configure if…else để mô tả những luồng tương tác phức tạp.
22/11/2020 at 3:07 chiều
Cảm ơn bạn, mốt có thời gian mình sẽ note về kinh nghiệm dùng AxureRP của mình nhé 😀
13/07/2021 at 11:55 chiều
localize là 1 phần nhỏ trong wireframe có đúng k anh?
20/07/2021 at 10:20 sáng
Hi Khanh, anh chưa hiểu lắm “localize” em nói là gì, ý em là ngôn ngữ dùng trong wireframe hay sao?
21/07/2021 at 7:59 chiều
Em k rõ lắm anh, trước đây em được giao task về localize và validation, localize ở đây theo em hiểu là nội dung hiển thị trên ứng dụng. Em k biết cái em đã làm là thuộc về wireframe hay prototype.
20/07/2021 at 1:08 sáng
Cám ơn bạn, bài viết rất bổ ích cho những người mới vào nghề UI/UX.
14/09/2021 at 3:39 sáng
Cảm ơn Yến
27/07/2021 at 1:51 chiều
Cảm ơn anh nhiều ạ!
14/09/2021 at 8:01 chiều
Thanks em nhé
10/08/2021 at 2:36 sáng
Mình có thắc mắc: mình thấy từ giai đoạn writeframe -> prototype là 2 giai đoạn chi tiết. BA sẽ là người vẽ hay nếu có team UI thì họ sẽ vẽ dựa trên bản Mock-up của mình.
14/09/2021 at 4:57 sáng
Hi Mạnh, BA sẽ ko làm prototype hay hi-fi wireframe nhé. Công việc này sẽ do UI Designer làm, BA hoặc UX Desiner (hoặc both) cùng phân tích & thiết kế ra cái flow người dùng rồi từ đó UI Designer phát triển thành những thứ còn lại.
17/08/2021 at 7:34 sáng
Thanks Anh. Bài viết khai sáng cho em rất nhiều. Khi làm dự án phần mềm em đang bị confuse giữa 03 loại documents là: Proposal; Blueprint; Userguide. Và mối quan hệ giữa proposal document với prototype. Anh có thể viết 01 bài khai sáng sự khác biệt của các loại document này được không? Hehe
17/08/2021 at 11:51 sáng
Thanks Kevin. Có thời gian anh sẽ viết về các loại docs này nhé
17/08/2021 at 3:48 chiều
Bài viết hay quá <3 Cảm ơn anh nhiều ạ
14/09/2021 at 3:06 chiều
Cảm ơn em nhé
17/08/2021 at 7:54 chiều
vô tình đọc được vài bài viết và cảm thấy mình rất bắt nội dung với kiểu viết ở trang này , bài viết rất bổ ích . mong sẽ được xem nhiều bài hơn từ anh.^^
14/09/2021 at 11:36 chiều
Thanks em nhé
14/09/2021 at 3:12 sáng
Cảm ơn bài viết của anh nhé.
14/09/2021 at 4:51 sáng
Bài viết của anh hay và rõ ràng miễn chê luôn!
14/09/2021 at 3:51 sáng
Thanks Huy nhé
14/09/2021 at 4:59 chiều
cảm ơn bài viết của bác nha. Quá hay
14/09/2021 at 1:55 sáng
thanks bác
19/09/2021 at 4:03 chiều
Sẽ rất có lỗi nếu em cứ đọc chùa mà ko nói là em rất biết ơn content của anh. Rất dễ hiểu cho beginner chập chững học BA như em ạ, cảm ơn anh nhiều!
28/11/2021 at 5:17 sáng
Cảm ơn em
10/10/2021 at 8:17 chiều
Anh ơi , sao anh làm về mảng BA mà rành về này quá vậy ?
17/10/2021 at 11:36 sáng
BA ít nhiều cũng phải làm các phần này chứ em
28/11/2021 at 4:23 sáng
Bài viết khai sáng và làm rõ rất nhiều điều cho những beginner.Cảm ơn bạn rất nhiều.
28/11/2021 at 12:03 chiều
Thanks bạn nhé
19/12/2021 at 3:02 chiều
Làm prototype để đi pitch là một trong những thứ hãm nhất trong cái vũ trụ này 🙂
22/12/2021 at 6:44 chiều
Em chào anh ạ. Em có một câu hỏi về phần prototype ạ.
Ở trên anh có nói, prototype là mẫu thử của sản phẩm hoặc một chức năng nổi trội nào đó mà người dùng có thể tương tác được.
Vậy cho em hỏi là, mẫu này sẽ ở dưới định dạng nào để có thể tương tác được ạ? Nếu chưa có code front – end hay back – end thì tại sao người ta vẫn có thể tương tác được ạ?
Rất mong anh có thể dành chút thời gian giải đáp thắc mắc này ạ.
Em cảm ơn anh ạ.
23/12/2021 at 1:48 chiều
Em chào anh ạ.
Hôm qua em có hỏi về việc tương tác của bản prototype, thì em đã hiểu vì sao người ta vẫn tương tác được khi chưa có front- end hay back – end rồi ạ.
Em cảm ơn anh vì đã có một bài viết rất chi tiết và logic để phân biệt các khái niệm trên ạ.
25/12/2021 at 3:30 chiều
Sr Hằng, a bị miss tin nhắn của em mất. Nếu có thắc mắc gì cứ cmt hoặc gửi email cho anh nhé. Merry christmas em 🙂
28/09/2022 at 8:38 chiều
Hi Thịnh, nếu không biết vẽ Mockup mà chỉ Wireframe thì có được không? Mockup thấy khá là mất thời gian để BA có thể làm chi tiết
23/10/2022 at 5:05 chiều
Tùy vào scope of work của BA trong mỗi công ty, mỗi team, mỗi dự án là khác nhau nhé Oanh. Không có 1 one size fits all cho scope of work của BA đâu. Ngoài ra, còn tùy vào điểm mạnh và mức độ hứng thú của từng bạn nữa.
06/03/2023 at 2:15 sáng
Em hay vẽ wireframe và mockup bằng lucid web app, anh có biết về app này không và đánh giá nó so với các app còn lại như thế nào ạ?
18/03/2023 at 3:33 chiều
Thường anh dùng Miro hoặc PowerPoint là chủ yếu để vẽ wireframe, Figma thì dùng để lên UI thật. Còn nếu project nào đòi hỏi prototype động thì anh hay dùng Axure. Nhưng thường thì anh dùng PowerPoint, hoặc Miro là chủ yếu vì nó tiện và dễ dùng. Còn các tool khác thì anh chưa, nên em cứ thoải mái sharing trải nghiệm của em khi dùng các tool này cho anh & mọi người biết thêm thông tin nhé.
21/03/2023 at 2:05 chiều
Hi anh cảm ơn bài viết của anh, nhưng anh có thể chỉ cho em cách take note trong meeting hiệu quả được không ạ. Em cảm ơn anh
18/06/2023 at 10:23 chiều
Em có thể tham khảo các template để viết meeting note, r follow theo guide của từng loại nhé. Em tham khảo cái này trên mạng có khá nhiều hướng dẫn. Hoặc đọc thêm bài note này về cách não mình suy nghĩ để tránh confuse khi cần ghi lại thông tin trong buổi meeting nhé: https://thinhnotes.com/chuyen-nghe-ba/nguyen-tac-nao-trai-nao-phai-khi-lay-yeu-cau/
02/04/2023 at 2:02 chiều
Cảm ơn bài viết rất hữu ích của anh ạ
18/06/2023 at 10:21 chiều
Cảm ơn em nhé
31/05/2024 at 2:04 chiều
Em rất có tài năng, không những là BA mà em còn có khả năng truyền cảm hứng rất tốt, rất tinh tế.
02/08/2024 at 9:52 chiều
Em cảm ơn chia sẻ của anh ạ. Anh cho em hỏi là khi vẽ wireframe, mình chỉ vẽ ra những giao diện chính, chức năng chính thôi hay phải vẽ ra tất cả, và ví dụ như trong 1 danh sách thả xuống có những mục nhỏ, giá trị khác trong đó thì có cần thể hiện rõ trong mockup luôn không ạ hay mình sẽ thể hiện thế nào? Em cảm ơn anh rất nhiều
09/08/2024 at 11:57 sáng
BA thì chỉ cần vẽ high fidelity wireframe thôi em, ko cần tiểu tiết. Chủ yếu là thể hiện được bố cục và luồng thông tin em muốn truyền tải là được