Abstraction Hub

IA, UX, UI, User Experiences, Usability, Web Design, Information Architect, HCI

Tìm hiểu IA – Slide shared

Ôn lại khái niệm IA qua slide của Perter Morville

IA slide

(Ảnh: Understanding IA – nguồn: Peter Morville)

IA (Information Architect) không phải là khái niệm mới, đây thậm chí là khái niệm cơ bản với những ai muốn học và làm về UX. Trong mô hình The Elements of User Experience của JJG (Jesse James Garrett) thì IA đứng ở lớp thứ 3 từ dưới lên.

IA – kiến trúc thông tin – là một môn học khó, đòi hỏi người tiếp cận nó có tư duy hệ thống, hiểu cách tìm kiếm và xử lý thông tin của người dùng, rồi từ đó xây dựng nên kiến trúc thông tin của sản phẩm (web hoặc mobile).

Cuốn sách tham khảo về IA nổi tiếng là cuốn OReilly – Information Architecture for the WWW, 3rd Ed (2007) của Peter Morville (mới tái bản năm 2015) là một tài liệu căn bản và cũng rất phổ biến với dân làm UX, IA. Tuy nhiên, để giúp bạn tiếp cận với kiên thức căn bản nhanh gọn hơn và dễ hiểu hơn, Morville đã giới thiệu một slide tổng hợp với tựa đề “Understanding Information Architecture” mà qua đó ban sẽ có cái nhìn tổng quan về các vấn đề mà Morville đề cập trong cuốn sách của ông.

Nếu bạn thích học UX bài bản, thì IA là một trong những bước đi đầu tiên và là một trong những kỹ năng quan trọng trong việc xây dựng và phát triển hệ thống thông tin, điển hình là website mà hàng tỷ người dùng đang sử dụng, khai thác hiện nay.

Về IA, tôi sẽ lần lượt giới thiệu các kỹ năng, kỹ thuật trong các blog sau này.

Happy learning! 🙂

Findability Tiki

Bug noted – lỗi cấu trúc thông tin của Tiki

0

(Hình 1: Tiki.vn – nguồn Tiki.vn)

Từ trước tới giờ, thỉnh thoảng tôi vẫn viết về các lỗi thiết kế (UI, service) của các website, việc này không nhằm chê bai hay “tự sướng”, mà là để chỉ ra những thứ ta có thể làm tốt hơn, và bản thân tôi cũng học hỏi từ đó.

Trở lại với Tiki.vn sau sự cố bị từ chối cộng điểm vì ban quản trị nghĩ rằng tôi “copy” bình luận sách từ trên Internet. Sau khi chứng minh là tôi copy từ chính… blog của mình, tôi đã được bổ sung “tiki xu” trở lại. Nhưng sau đó thì cũng không engage với website này nữa, một phần vì muốn đi lượn phố Nguyễn Xí hơn, và một phần Tiki mở rộng sang đa ngành nghề (tôi biết áp lực tăng trưởng là phải vậy). Tuy nhiên hôm nay cần mua một cuốn mà lười ra phố, nên tôi lại truy cập website này.

Về cơ bản thì hệ thống website Tiki.vn vẫn vậy, ngoài những tính năng cơ bản thì có nhiều không gian được thiết kế lại để dành cho quảng cáo hơn. Cấu trúc thông tin top-down vẫn như cũ, nghĩa là danh mục chính, rồi các cấp danh mục nhỏ hơn qui hoạch bên trong.

00

(Hình 2: on top banner của Tiki )

Tuy nhiên, đi sâu vào phần tìm kiếm sách, tôi nhận thấy 2 vấn đề “cản trở” người dùng tìm được thông tin mình cần trước khi ra quyết định mua sách:

Vấn đề #1  Cover to detail: Nghĩa là cấu trúc thông tin bên ngoài và thông tin chi tiết bên trong không có sự đồng nhất. Mặt này có 2 điểm: một là mental model của cá nhân tôi nghĩ rằng hình ảnh thumbnail của 1 category sẽ được lựa chọn từ 1 trong những sản phẩm thuộc category đó. Cụ thể là cuốn REWORK đáng ra phải nằm trong phần “Kỹ năng sống – Làm việc” như hình bên dưới:

Tiki1

(Hình 3Category “Kỹ năng sống – Làm việc” nhìn từ bên ngoài với hình ảnh cover là cuốn REWORK)

Nhưng khi click vào bên trong, category này hoàn toàn không có sản phẩm REWORK như tôi hình dung:

Tiki1b

(Hình 4: Bên trong category “Kỹ năng sống – Làm việc”)

Bên cạnh đó, khi vào xem chi tiết category nêu trên, toàn bộ phần thông tin của tên category, menu thứ cấp breadcrumb đều tự động chuyển sang tiếng Anh. Điều này một lần nữa sẽ khiến người dùng “bối rối” bởi không biết “có phải mình vừa chọn sai category hay không?”. Vậy tôi phải làm gì đây? Tất nhiên là phải nhờ tới chức năng “tìm kiếm”, một thành phần cơ bản của IA, và điều này cho thấy vấn đề tiếp theo.

Vấn đề #2  deep organize & breadcrumb: Tôi chủ động gõ từ khóa “reworkd” vào ô tìm kiếm, phần gợi mở (suggestion) hiển thị ra cuốn REWORK nhưng khi gõ “enter” để tìm kiếm thì kết quả không tìm thấy. Ok, tôi sửa lại từ khóa thành “rework” và tìm thấy thông tin sản phẩm mình mong muốn:

Tiki2

(Hình 5: Hình ảnh sản phẩm REWORK)

Từ vị trí này, tôi để ý lên phần menu breadcrumb. Tại sao tôi phải làm vậy? một lần nữa, nó là logic theo mental modal của user’s brain. Lý do là ở các bước đã nêu ở trên, tôi là một người dùng đã tìm sản phẩm (hoặc đã được định hướng tìm sản phẩm) tại một category không chính xác.  Chính vì thế nên tôi mới thắc mắc là sản phẩm này nằm ở category nào ? và làm sao để tìm thấy nó?

Theo thứ tự, tôi bắt đầu tìm theo chiều cấu trúc từ trong ra ngoài để tìm category chính thức của sản phẩm. Thứ tự này bao gồm:

  • Trang chủ ->
    • English books ->
      • Business – Investing ->
        • Entrepreneurship – Small Business

Vậy là có tới 4 cấp category dẫn tới sản phẩm tôi muốn tìm mua. Tới đây, tôi lần lượt bấm vào các category theo thứ tự từ trong ra ngoài, từ dưới lên trên với mong muốn trở về đúng category listing của sản phẩm. Nhưng kết quả tôi nhận được lại là các category không có dữ liệu bên trong:

3-1

(Hình 6: category Entrepreneurship – Small Business không có dữ liệu bên trong)

Tiki3

(Hình 7: category Business – Investing không có dữ liệu bên trong)

Sau cùng, không biết làm thế nào để tìm được đúng category cần thiết, tôi bấm vào “English book” thì hệ thống đưa tôi trở về trang chuyên các sản phẩm sách tiếng Anh, mà trong đó, tôi gặp lại category “Kỹ năng sống – Làm việc” ở Hình 3 phía trên. Là một người dùng, tôi hoàn toàn mất phương hướng (completely lost).

Nhìn ở góc độ tổng thể, website vẫn vận hành bình thường. Các đơn hàng có lẽ vẫn đều đặn và thỏa mãn chỉ tiêu KPI của đội ngũ kinh doanh, nhưng không chắc thời gian tìm kiếm trung bình đối với một sản phẩm rồi từ đó dẫn đến hành vi đặt hàng, mua hàng của người dùng là bao lâu? Sẽ ảnh hưởng tới conversion rate có đáng kể hay không? Có thể, mọi thứ là không đáng kể.

Bài viết này tôi muốn chỉ ra một điều đơn giản: IA luôn có thể làm kỹ lưỡng hơn nữa để sản phẩm phục vụ người dùng tốt hơn, trải nghiệm qua đó cũng tăng lên, bởi e-Commerce, nói một cách khác, là để tiết kiệm thời gian.

Findability is a critical success factor for overall usability. If users can’t find what they need through some combination of browsing, searching, and asking, then the system fails. – IA definition, Peter Morville

Có 1 designer lâu năm nói với tôi rằng “Người làm thiết kế có nghề thì có thể nhìn ra vấn đề sau vài bước quan sát”. Bản thân tôi cũng đang luyện rèn kỹ năng đó.

Noted:

  • IA (Information Architect ): Kiến trúc thông tin.

Crowd testing, a kind of…

Thực hiện phương pháp test bởi nhóm người dùng khách quan (alternative focus group)

(Ảnh: Pixel Art Suits – Nguồn: blog.smartbear.com)

Crowd testing không phải topic mới, bởi nó khả phổ biến trên thế giới, đặc biệt là các công ty chuyên làm dịch vụ testing. Có 1 tên gọi khác mà bạn cũng hay gặp, đó là “crowd-source testing”, với nôm na ý tưởng là sử dụng 1 nhóm người dùng nhất định để test sản phẩm của bạn (hoặc công ty bạn) làm ra. Ở góc độ chuyên nghiệp, crowd testing nhằm giải quyết những vấn đề cụ thể như:

  • Cross-culture: Sản phẩm được thực hiện ở 1 nước, nhưng phục vụ global users, cũng có nghĩa là target users của bạn ở nhiều đất nước khác nhau, văn hóa, ngôn ngữ, tôn giáo và nhận thức / tư duy khác nhau. Chính vì thế mà nếu sản phẩm chỉ được test bởi 1 nhóm tester ở trong công ty của bạn là không đủ.
  • Alternative view: Với một nhóm được chọn ngẫu nhiên bao gồm những người chuyên nghiệp lẫn không chuyên, bạn sẽ có số liệu usability test có tính trung thực cao hơn. Bởi nếu bạn và những thành viên trong nhóm cùng test sản phẩm với nhau thì “tính khám phá” sẽ không còn do nhóm đã tham gia phát triển sản phẩm được 1 thời gian nhất định. Vd: nếu test phần registration thì sau vài lần self-test bạn / hoặc developer trong nhóm sẽ thao tác rất nhanh để đi qua bước đó. Cảm quan về layout, color, first feeling cũng không còn mới nữa.v.v..
  • Quick failure, quick rebuild: Khi đưa sản phẩm dạng MVP (Most Valuable Product) cho nhóm crowd testing, bạn có cơ hội kiểm chứng tính đúng đắn, hiệu quả của tính năng cũng như giao diện nhanh hơn. Điều này giúp giảm thiểu sự “tranh cãi” trong nội bộ nhóm, cũng như giảm thiểu lỗi usability tới end-user thực sự của bạn.
  • Improve personas: Personas là một công việc khá nặng nhọc nếu làm cẩn thận vả kỹ lưỡng, tuy nhiên trong nhiều dự án có thời gian phát triển ngắn, việc interview người dùng để phát triển nghiên cứu personas là khá khó khăn cũng như tốn nhiều thời gian và chi phí. Crowd-testing với sự lựa chọn của nhóm “rộng” hơn và “tập trung” hơn vào thị phần bạn hướng tới sẽ giúp bạn có phản hồi tích cực.
  • Ego is good: Ego (cái tôi), trong nhiều trường hợp bị tẩy chay, nhất là làm việc nhóm, nhưng trong testing lại là 1 điều tích cực. Tại sao? Bởi Ego là bản chất của con người. Khi được mời test 1 sản phẩm, bạn sẽ nghĩ gì? OK, sản phẩm này có phục vụ cho “tôi” đạt được cái “tôi” muốn hay không? Để xem họ làm ăn ra sao, kiểu gì chả có lỗi? và “tôi” thích thú khi tìm ra lỗi, và cảm giác đó giúp “tôi” thấy mình thật cool. (may mà có “tôi” không thì sản phẩm bị lọt lỗi ra ngoài nhé!).v.v…
  • v.v.. và nhiều lợi ích khác nữa (lúc nào rảnh mình chém tiếp).

crowd-test

(Ảnh minh họa crowd testing, nguồn Applause)

nhóm của tôi, crowd testing được thực hiện đơn giản hơn và mục tiêu hướng tới usability nhiều hơn. Thay vì phân loại crowd testing thành từng phần chuyên nghiệp như: Functional, Security, UI, Performance.v.v.. thì tôi hướng tới việc để các bạn test tự phát (un-educated users). Mục đích là để tôi và nhóm phát triển có cái nhìn trung thực về end-users’s feeling.

Qua thời gian thử nhiệm 1 năm, tôi rút ra kinh nghiệm thực hiện crowd testing cho nhóm với các bước đơn giản như sau:

  • Thời điểm: Sau khi sản phẩm được QA test xong, các lỗi đã được xử lý, tôi gửi email cho cả công ty (khoảng 60 người) và yêu cầu họ hỗ trợ “dùng thử” sản phẩm.
  • Đối tượng: Tất cả mọi người, từ em lễ tân tới kế toán hay những nhóm chuyên môn (PM, QA, PHP, Front-end, Managers..) khác.
  • Thời gian test: 30 phút (bạn có thể để dài hơn nhưng thực ra theo mình thấy để dài hơn sẽ không hiệu quả, thời gian ngắn, bạn sẽ chỉ test những thứ mà bạn thích test nhất, hoặc 30 phút cũng cho bạn thấy với newbie users, thời gian đó có đủ để họ biết dùng sản phẩm hay không?)
  • Xử lý phản hồi / ý kiến đóng góp: Nên làm đơn giản nhất có thể. Tránh sử dụng những nhứ professional như JIRA, Trello, Basecamp… nó quá xa vời với người không chuyên và cũng “mất thời gian” để log bug. Với tôi, tạo 1 file Google excel hoặc 1 shared folder để mọi người kéo thả screen shots lên đó là đủ.
  • Sử dụng online chat tool: Cứ thử đi, xem có ai dùng không? có ai hỏi bạn cách sử dụng không? Zopim là 1 tool miễn phí tốt cho bạn.
  • Stop and review: Bạn phải kiên quyết giữ qui tắc 30 phút. Hết thời gian là ngắt truy nhập 🙂 để sau đó nhóm của bạn tiến hành review, thiết lập ưu tiên cho những bug / hay đóng góp quan trọng và lên kế hoạch hoàn thiện sản phẩm. Quyền quyết định vẫn nằm ở nhóm của bạn, nhưng hãy tập trung vào những ý kiến khách quan và có tính cụ thể cao. Tránh những ý kiến kiểu như “liệu tăng scale lên 1000 concurrent users thì sẽ thế nào?”, hoặc “Ứng dụng khó dùng quá..!”,v.v.. Nói chung là cần tỉnh táo, khách quan.

Crowd testing ở góc độ của tôi có phần nào giống Sprint Demo của Scrum, nhưng thay vì demo theo tuần (cái mà ít hiệu quả ở 1 công ty mà ai cũng bận rộn) thì nhóm của tôi demo ở giai đoạn sản phẩm đã có thể dùng được đối với user. Nghĩa là người dùng có thể chạy hết một user journey.

Bạn có thể áp dụng gamification như giải thưởng cho người test tốt nhất, lỗi tìm ra nhiều nhất, đóng góp về mặt usability hay nhất.v.v.. để tăng tính sôi nổi của cuộc chơi.

Khi sản phẩm được đem ra crowd testing, cũng có nghĩa là cả nhóm phải cố gắng làm thật tốt, chỉn chu hơn. Tester cũng cố gắng test cẩn thận hơn và vì thế bạn có cơ hội kiểm nghiệm nhiều hơn một chút.

Living UX, Are you?

Nếu bạn là 1 người làm về UX, CX, bạn có nên lưu ý hơn trong cuộc sống?

driving-bad-5

(Ảnh: bad driving – nguồn: drivingbad.vn)

Có một lần nói chuyện với Kiên 44 và mấy bạn làm graphic design mình có nghe được idea rằng “dân làm UX thì thông thường sẽ mang lại cuộc sống dễ chịu hơn cho những người xung quanh”. Ngẫm nghĩ ra thì thấy cũng có lý, nhưng chắc là ít người để ý điều này, hoặc là họ có làm về UX, nhưng lại chưa thực sự để ý tới việc mang UX vào cuộc sống?

Vậy Living UX là gì?

Nói một cách đơn giản, đó là tạo ra phong cách sống của chính bạn, mà qua đó bạn có thể mang lại cho những người xung quanh (bạn bè, gia đình, đồng nghiệp…) sự tiện lợi, am hiểu, và hỗ trợ tốt nhất. Nghe vẫn có vẻ mơ hồ, nhưng đôi khi đó là những điều đơn giản mang lại cảm giác, “trải nghiệm” thích thú, thoải mái cho mọi người.

Tôi sẽ chia sẻ một vài ví dụ, mà tôi tin rằng, ai trong chúng ta cũng đã từng làm như thế hoặc cảm thấy thoải mái khi đón nhận nó.

Ví dụ ở công ty

  • Sáng sáng đi làm, bạn có mỉm cười tươi tắn và nói “chào buổi sáng” với các đồng nghiệp? Lúc trước công ty mình có 1 bạn nữ làm lễ tân, sáng nào cũng vui vẻ chào đón mọi người, ai cũng thấy thoải mái và thân thiện, cảm giác vui vẻ khi bắt đầu 1 ngày mới. (Giờ thì bạn ấy stress vì công việc nên bỏ thói quen đó rồi )
  • Công ty có vài dụng cụ pha cafe (French press, Sunbeam..), mỗi lần sử dụng xong, bạn có bỏ bã cà phê và rửa sạch hay không? (Để người dùng sau bạn có thể sử dụng được luôn)
  • Công ty sử dụng Skype chat để trao đổi thông tin trong các dự án, theo thói quen, các đồng nghiệp sẽ đặt “book-mark” các group chat. Rồi 1 ngày tôi thấy 1 anh đồng nghiệp chat nhầm liên tục giữa 2 – 3 group chat dự án, để ý một chút thấy tên dự án khá giống nhau như: Willing donate website, Wendy website, Weird management… Tôi đoán hành vi sử dụng của bạn này là: Vào skype search, gõ “W…” và enter… Điều này dẫn tới khi thao tác nhanh, thường xuyên gõ nhầm “room” chat, tôi lẳng lặng đổi tên các group cho bạn ý rồi thông báo lại. Làm quen với 1 “group name” mới vẫn tốt hơn là nói chuyện “nhầm” với khách hàng.
  • QA vật lộn với phân loại bug trong JIRA, tôi nói chuyện và tạo thêm “custom field” cho họ.
  • Làm việc với khách hàng lệch múi giờ tới 3-4 tiếng đồng hồ, tôi dậy sớm hơn, kiểm tra email, trả lời và sắp xếp sẵn mọi thông tin để khi các đồng nghiệp khác tới văn phòng, mọi thứ đã sẵn sàng.
  • Khi bạn muồn nghỉ phép dài ngày (hơn 1 ngày), ngoài việc báo cho người quản lý, bạn có sắp xếp công việc và chuẩn bị các phương án dự phòng (plan B) để người khác có thể giúp bạn khi bạn ko có ở đó??
  • Có anh PM (Project manager) viết báo cáo hàng ngày cho khách hàng, trong email không bao giờ cách dòng giữa các ý chính, đọc rất nhức mắt, tôi đã góp ý để nội dung email “dễ đọc hơn”. Cũng có PM viết báo cáo quá dài, tôi cũng góp ý bởi khách hàng (các agencies) họ “không rảnh” để đọc báo cáo dài lê thê, cái họ cần là % completion, overall status, blocker issues… Tóm lại nếu là PM, bạn cần nghĩ rằng làm sao để khách hàng đọc báo cáo của bạn trong..1 phút là nắm đủ thông tin cơ bản của dự án. Bởi cũng như tôi, họ có 20-30 dự án cần theo dõi.
  • v.v…để ý 1 chút, có rất nhiều ví dụ phải ko?

Ví dụ trong cuộc sống

Trong cuộc sống thì nhiều vô kể, nhưng tôi ví dụ ở một số việc đơn giản, mà chắc rằng không ít lần bạn cảm thấy không thoải mái, vậy tại sao bản thân mình không “improve” nó?

  • Đi xe trong thành phố, bạn có bật đèn chiếu pha xa (đèn far) hay không? Nếu có, thì bạn nên điều chỉnh, bởi nó gây chói mắt và khó chịu cho người đi đối diện.
  • Khi dừng đèn đỏ, và khi chỉ còn 3-4 giây nữa là chuyển sang đèn xanh, bạn có bấm còi không? Và nếu đèn đỏ báo 50 giây, bạn có tắt máy?
  • Vẫn là khi dừng đèn đỏ, bạn có nhường đường ở những nơi cho phép xe rẽ phải?
  • Khi đứng chờ thang máy trong tòa nhà (chung cư, văn phòng) và khi thang đến, bạn có đứng sang 1 bên để dành chỗ cho người trong thang máy đi ra? Và nếu vào trước, bạn có bấm nút [<>] để cho những người khác đi vào không bị cửa sập vào người?
  • Khi bước qua cửa kinh cường lực và có người đi phía sau, bạn có dùng tay đỡ cánh cửa để giúp người đó đi qua thuận tiện hơn?
  • Đi chơi về muộn hoặc không về ăn cơm, bạn có gọi điện hoặc nhắn tin báo cho người thân? (a kind of informative feedback). Điều này cũng giống như khi bạn có hẹn ai đó và đến muộn, bạn cần “update” thông tin cho họ. Con người là đối tượng luôn “đói” thông tin và luôn “thiếu kiên nhẫn”, vì vậy việc cập nhật thông tin của bạn vô cùng hữu ích.
  • blah blah…

Đọc đến đây bạn thấy có rất nhiều ví dụ phải không? nó nhỏ nhặt, lắt nhắt? hay bạn cảm thấy phải để ý quá nhiều thứ? Hãy suy nghĩ đơn giản, bởi đó là cách giúp bạn thay đổi “thói quen” (building habit) và làm mọi thứ tốt hơn. Để làm được việc này, bạn phải “educate” chính bản thân mình.

Treat the client like 2-year-old child

(Mang lại cho khách hàng những thứ đơn giản, dễ hiểu)

Capture

(Hình 1: user’s guessing. Nguồn: www.satukyrolainen.com)

Làm việc trong lĩnh vực digital production  mà cụ thể hơn là offshore development hay outsourcing thì communication is the key. Mỗi dự án từ lúc lên ý tưởng, cho tới lúc bàn giao sản phẩm cho khách hàng luôn cần giao tiếp liên tục để chắc chắn rằng các bên tham gia hiểu ý nhau. Nghe thì đơn giản, nhưng đây luôn là nguồn gốc của mọi vấn đề. Mà thường là các bên không hiểu nhau. Users không hiểu phần mềm, nghiệp vụ (business process) dẫn đến bực tức và “ghét” phần mềm một cách tự nhiên. Lâu này thành định kiến là “phần mềm khó sử dụng”.

Case study: How to test?

 UX xuất hiện khắp mọi nơi, và nói một cách đơn giản là một người có UX mindset sẽ chú trọng vào bất cứ thứ gì mình đưa ra (kể cả là lời nói – UX có dính tới psychology cũng 1 phần là như vậy). Câu truyện của sáng nay rất đơn giản và phổ biến, nhưng tôi ấn tượng với câu nói của boss. Nôm na là như sau:

  • Boss: Khách hàng muốn test toàn bộ qui trình đăng ký, thanh toán credit card mà ko bị charge phí, nhận email confirmation. Mình có cung cấp được chưa?
  • PM (Project Manager): Mình đã làm 1 tools migrate khách hàng cũ, với khách hàng mới thì không cần lo vì hệ thống tự generate confirmation code, khách hàng cũ chạy tools, ngoài ra cần migrate data demo sang server staging, làm sạch dữ liệu test, by pass thẻ visa…
  • Boss: I don’t fucking care. Please treat me like 2-year-old child. Client even likes 1-year-old child. I don’t know and don’t understand whatever you do behind the scenes.
  • PM: Chúng ta sẽ cung cấp sandbox để test, migrate dữ liệu cần khách hàng confirm migrate những gì, blah blah..
  • Boss: Những thứ đằng sau đó không cần giải thích với người dùng, đưa cho họ cái họ cần để test được hệ thống như một người dùng cuối (end-user).

Cá nhân mình thấy hợp lý. Bởi đơn giản những thứ kỹ thuật, thiết kế.v.v… là việc của mình, khách hàng thuê mình vì điều đó, còn với họ, họ cần tiếp cận với sản phẩm như một đứa trẻ, tiếp cận và học hỏi, test một cách dễ dàng nhất. Điều muốn nói ở đây là giao tiếp. Communication is the key in UX. Lắng nghe, rồi hiểu đúng cái mà khách hàng cần, đưa cho họ thông tin/câu trả lời đơn giản và dễ hiểu nhất. Họ không quan tâm bạn là ai, thương hiệu của bạn là gì? bạn sử dụng công nghệ gì? All bullshit things. Cái họ cần là vấn đề của họ được giải quyết.