Warning: Illegal string offset 'src' in /home/minhhong/domains/minhhong.com/public_html/wp-content/plugins/jetpack/functions.opengraph.php on line 293

Archive for NHoang

Vội…

voi

Hệ thống quản lý OKR

g22re
Một phương pháp rất hay, dễ áp dụng thực hiện với mọi cấp độ công ty. Phương pháp này gần giống với Agile Result , rất hiệu quả khi kết hợp cả 2 để giữ sự ổn định vào mục tiêu đã chọn , không bị chệch hướng.
Tóm gọn lại phương pháp này là đi từ trên xuống (từ tập doàn -> cty -> lãnh đạo -> quản lý -> nhân viên), ở mỗi cấp sẽ đề ra các mục tiêu  phù hợp, hỗ trợ hoàn  thành yêu cầu của cấp cao hơn.
Một bộ bao gồm:
  • một mục tiêu chính
  • 3 kết quả then chốt cần đạt được.
  • Kết quả đánh giá: k0 được  quá thấp (<0.5 -> quá khó , cần điều chỉnh lại mục tiêu và kết quả then chốt) hoặc quá cao ( > 0.9 -> mục tiêu quá dễ)

Read more

Các cổng thanh toán phổ biến và chi phí

Tổng hợp các cổng thanh toán phổ biến và chi phí .

Một số ước lượng chi phí qua giá trị đơn hàng và số lượng đơn hàng khi sử dụng với từng cổng. Hy vọng giúp được bạn nào mới làm TMĐT có thông tin nhanh hơn

DownloadPayment Gateway

UX layers

*Một bài viết rất hay của lou.vn, xin về khi nào cần đoc lại

Thỉnh thoảng Phowr nhận được một số câu hỏi như sau: “Sản phẩm của em cần cải thiện UX chỗ nào?”, “Nhờ đánh giá giúp UX của sản phẩm này”, “Em cảm thấy sản phẩm chưa tốt lắm nhưng chưa biết bắt đầu từ đâu?”, “Em đã tối ưu giao diện hết mức như goodui.org rồi nhưng kết quả vẫn chưa như kì vọng”…

Những câu hỏi bên trên xuất phát từ việc chưa có guideline (chi dẫn) chuẩn nào trong tiếp gia tăng trải nghiệm người dùng. Bài viết này sẽ cung cấp một trong số các guideline tiếp cận dưới hình thức UX layers để các bạn tham khảo.

Read more

Inbound Marketing vs Outbound Marketing

Từ trước đến nay, chúng ta vẫn thường vung tiền ra để mua quảng cáo khắp nơi như đặt banner trên các website, book bài PR, quảng cáo trên TV, radio, treo pano; hay tiêu tốn nhiều tiền để mua các database email, số điện thoại để tiến hành các biện pháp email marketing, telesale, SMS; thậm chí tổ chức các buổi hội thảo giới thiệu sản phẩm, các event trade show nhằm quảng bá cho sản phẩm của mình. Thế nhưng, chúng ta quên mất rằng liệu người xem có muốn thấy quảng cáo đó không? Người nghe có muốn chúng ta nói về sản phẩm của mình không? Hay họ tắt luôn trang web khi thấy quảng cáo gây khó chịu? Họ chuyển kênh TV khi thấy quảng cáo? Xoá email ngay khi chưa cần mở ra và cúp điện thoại khi đầu dây bên kia mới chỉ nói được câu giới thiệu?

Nhờ có internet, ngành Maketing đã có thay đổi rất nhiều. Người dùng không còn phụ thuộc vào các quảng cáo trên tivi để tìm hiểu về các dịch vụ, sản phẩm mớ nữa., web đã trao quyền đó cho người dùng. Khách hàng giờ có thể chủ động tìm kiếm, mua hàng, nghiên cứu kỹ về sản phẩm-thương hiệu qua mạng.

Read more

“tĩnh khí”

“Đối diện với mỗi việc lớn cần phải “tĩnh khí””, đây là câu nói mà thầy giáo của hai vị Hoàng đế cuối đời nhà Thanh đã dạy bảo học trò của mình.

Ông cho rằng: Từ xưa đến nay, các bậc thánh nhân, càng gặp phải những việc lớn kinh thiên động địa, việc nguy hiểm thì càng có thể tĩnh tâm như nước, không hề sợ hãi. Từ xưa đến nay, phàm là người làm được việc lớn nhất định phải là người có “tĩnh khí”.

Read more

Một số phương pháp đánh giá năng lực nhân viên

Ðịnh nghĩa và mục đích của việc đánh giá.

Ðịnh nghĩa.

Ðánh giá năng lực thực hiện công việc hay còn gọi là đánh giá thành tích công tác (performance appraisal) là một hệ thống chính thức được duyệt xét và đánh giá sự hoàn thành công tác của một cá nhân theo định kỳ.

Qua định nghĩa cho ta thấy đây là một hệ thống chính thức, như vậy phải hiểu rằng nó bao gồm cả một tiến trình đánh giá khoa học, có tính hệ thống và phải được thực hiện theo định kỳ tùy theo tính chất công việc, quy mô kinh doanh của doanh nghiệp.

Mục đích của đánh giá       .

Ðánh giá năng lực thực hiện công việc của nhân viên là một hoạt động quan trọng của quản trị nhân sự, giúp doanh nghiệp có cơ sở để hoạch định, tuyển chọn, đào tạo và phát triển nhân sự. Ðể đánh giá đúng năng lực thực hiện công việc của nhân viên, nhà quản trị cần phải hiểu được mục đích của việc đánh giá:

     – Nâng cao khả năng thực hiện công việc và cung cấp những thông tin phản hồi cho nhân viên biết được mức độ thực hiện công việc, từ đó có biện pháp nâng cao và hoàn thiện hiệu năng công tác.

     – Ðánh giá năng lực thực hiện công việc giúp doanh nghiệp có những dữ liệu cho biết khả năng thăng tiến của nhân viên. Nhờ sự đánh giá này doanh nghiệp có thể có cơ sở để hoạch định tài nguyên nhân sự.

     – Giúp nhân viên điều chỉnh, sửa chữa các sai lầm trong quá trình làm việc, đồng thời làm cơ sở để khuyến khích  động viên họ.

     – Ðánh giá năng lực thực hiện công việc giúp cho doanh nghiệp có cơ sở dự báo về nhân sự trong tương lai, từ đó có kế hoạch đào tạo, bồi dưỡng phát triển nguồn nhân sự.

     – Thông qua đánh giá năng lực thực hiện công việc của nhân viên, nhà quản trị có thể điều chỉnh việc bố trí sử dụng nhân viên cho phù hợp với công việc, phát hiện những tiềm năng còn ẩn giấu trong nhân viên giúp họ phát triển.

Tiến trình đánh giá thực hiện công việc

Read more

15 tác phẩm nghệ thuật độc đáo từ đồ tái chế

Tái chế đồ cũ ngoài lợi ích bảo vệ môi trường, nó giờ còn trở thành một bộ môn nghệ thuật mới dành cho những người thích sáng tạo. Sẽ thật thú vị khi có thể biến những vật dụng không cần thiết quanh ta trở nên mới vẻ và đôi khi còn hữu dụng hơn nhiều trước kia.
Cùng chiêm ngưỡng những tác phẩm nghệ thuật độc đáo được tạo ra từ đồ tái chế sau đây và biết đâu bạn có thể áp dụng cho chính ngôi nhà của mình.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che3

Những chai nhựa bỏ đi có thể trở thành một chiếc thuyền “không bao giờ chìm”.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__2

Một chiếc piano cũng có thể biến thành một giá sách ấn tượng…

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__3

…hay một đài phun nước “có một không hai”.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__4

Nếu có thể, hãy tận dụng chiếc vali cũ làm tủ đựng thuốc cho gia đình.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__5

Một chiếc thuyền gỗ cũ sẽ trở thành chiếc ghế sofa ngoài trời lý tưởng.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__6

Bạn sẽ ghi điểm với đối tác bằng một chiếc bàn họp làm từ động cơ cánh máy bay

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__7

Chiếc giường êm ái được tái chế từ một con thuyền mục nát

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__8

Khi em bé của bạn lớn, hãy tận dụng chiếc nôi ngày nào thành một bàn học cho trẻ

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__9

Khu vườn cổ tích được làm từ một bình hoa vỡ

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__10

Đèn bàn làm từ  một thứ không liên quan như…ống nước.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__11

Những chiếc mắc áo cũ có thể trở thành một chiếc ghế vô cùng thoải mái

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__12

Bàn bi-a độc đáo làm từ xe ôtô cũ

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__13

Một chiếc đèn ngủ lạ mắt làm từ chai rượu vang đã qua sử dụng.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__14

Đồng hồ làm từ bánh xe đạp cũ.

15_tac_pham_nghe_thuat_doc_dao_tu_do_tai_che__15

Đuôi một chiếc xe được tận dụng làm xích đu.

SCRUM – Một số quy tắc trong quy trình thực hiện

ScrumMaster là người chịu trách nhiệm đảm bảo tất cả những ai liên quan đến dự án, kể cả “gà” và “heo”, đều phải tuân thủ theo những quy tắc đặt ra của Scrum. Những quy tắc này được đút kết qua quá trình thực hiện thành công của hàng nghìn dự án trước đó.

Sprint Planning Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 8 giờ, bao gồm 2 phần, mỗi phần cố định 4 giờ. Phần thứ nhất là xác định Product Backlog, phần thứ hai là dành cho việc chuẩn bị một Sprint Backlog.

– Những người tham gia là ScrumMaster, Product Owner và Scrum Team. Ngoài ra, có thể mời thêm những người khác tham dự (nếu cần thiết khi cần thêm thông tin hoặc tư vấn về nghiệp vụ hoặc công nghệ). “Gà” không có chỗ trong cuộc họp này.

– Product Owner phải chuẩn bị trước Product Backlog. Trong trường hợp vắng Product Owner hoặc thiếu Product Backlog, ScrumMaster phải thực hiện xây dựng trước Product Backlog và đảm nhiệm vị trí của Product Owner.

– Mục tiêu của phần đầu, của 4 giờ đầu tiên, là để cho Scrum Team chọn các Product Backlog item mà họ cảm thấy đó tính năng quan trọng trong sản phẩm cần thực hiện. Scrum Team sẽ chứng minh cho Product Owner và các stakeholder tại Sprint Review Meeting và cuối Sprint về những gì mà họ đã chọn.

– Team có thể đưa ra các gợi ý, nhưng quyết định chọn Product Backlog nào để thực hiện trong Sprint là trách nhiệm của Product Owner.

– Team chịu trách nhiệm xác định có bao nhiêu Product Backlog mà Product Owner muốn thực hiện trong suốt Sprint.

– Phần thứ hai của cuộc họp, 4 giờ tiếp theo, Product Owner phải luôn có mặt để trả lời các câu hỏi về Product Backlog của Scrum Team.

– Kết quả của phần thứ 2 của cuộc họp này là một danh sách, được gọi là Sprint Backlog, bao gồm các công việc, ước lượng của từng công việc, và phần chỉ định.

Daily Scrum Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 15 phút bất kể có bao nhiêu thành viên của Scrum Team lúc đó.

– Tổ chức cuộc họp tại cùng địa điểm vào cùng thời điểm mỗi ngày làm việc. Cuộc họp nên được tổ chức vào đầu ngày làm việc để Scrum Team có thể tổng kết lại những gì đã làm được ngày hôm trước và vạch ra kế hoạch thực hiện ngày hôm nay.

– Thành phần tham dự là tất cả thành viên của Scrum Team. Nếu vì lý do nào đó mà thành viên không thể tham dự, người đó phải tham gia theo hình thức khác (như qua điện thoại, chat voice, live meeting,…), hoặc nhờ 1 thành viên khác báo cáo về tình trạng vắng mặt của mình.

– Các thành viên của nhóm phải được nhắc nhở. ScrumMaster bắt đầu cuộc họp vào thời gian đã thông báo, bất kể lúc đó có thành viên nào hiện diện. Bất kỳ thành viên nào trễ đều phải bị phạt ngay lập tức Smile.

– ScrumMaster bắt đầu cuộc họp bằng việc chọn một thành viên nào đó trong Team để báo cáo, và xoay vòng cho đến khi tất cả thành viên đều đã báo cáo.

– Mỗi thành viên chỉ nên trả lời 3 câu hỏi sau đây:

+ Bạn đã làm gì từ sau cuộc họp trước mà liên quan đến dự án này?

+ Bạn sẽ làm gì sau khi cuộc họp này kết thúc?

+ Điều gì cản trở bạn thực hiện công việc của mình?

– Các thành viên không nên lạc đề khỏi 3 câu hỏi trên vào các lỗi, thiết kế, thảo luận cách giải quyết vấn đề, hoặc nói linh tinh. ScrumMaster chịu trách nhiệm luân phiên việc báo cáo từ người này sang người khác.

– Trong suốt cuộc họp, chỉ duy nhất 1 người nói vào 1 thời điểm. Người đó là người đang thực hiện việc báo cáo tình trạng của mình, những người còn lại lắng nghe. Không ai được lên tiếng hoặc làm việc riêng lúc này.

– Sau khi một thành viên nào đó báo cáo về một điều gì đó gây thích thú cho các thành viên còn lại, hoặc cần sự trợ giúp của các thành viên khác, bất kỳ thành viên nào cũng có thể ngay lập tức sắp xếp tham gia cùng nhau sau khi cuộc họp kết thúc.

– “Gà” không có “tiếng nói” trong cuộc họp này. “Gà” đứng ở khu vực ngoại vi của Team để không gây ảnh hưởng đến cuộc họp này.

– Nếu có quá nhiều “gà” tham dự cuộc họp này, ScrumMaster có thể giới hạn lại số lượng người tham dự để đảm bảo sự ổn định và tập trung.

– “Heo” hoặc “gà” người mà không thể hoặc không theo những quy tắc ở trên sẽ bị loại khỏi cuộc họp (“gà”) hoặc loại khỏi nhóm (“heo”).

Sprint Review Meeting

Cuộc họp được cố định thời gian diễn ra trong vòng 4 giờ.

– Team không nên mất hơn 1 giờ để chuẩn bị cho cuộc họp.

– Mục đích của cuộc họp là để cho Team trình bày cho Product Owner và stakeholder về những gì mà họ đã làm được.

– Những phần chưa hoàn thành xong sẽ không được trình bày.

– Những phần không thuộc về chức năng có thể không được trình bày ngoại trừ khi nó được dùng để hỗ trợ. Những thành phần không được trình bày chẳng hạn như những work product, và việc sử dụng của chúng phải được tối giản nhất để tránh gây nhầm lẫn cho stakeholder hoặc yêu cầu họ hiểu việc phát triển các hệ thống làm việc như thế nào.

– Chức năng nên được trình bày trên máy trạm của thành viên trong nhóm và được thực thi từ máy chủ gần nhất để release – thông thường là một máy chủ môi trường đảm bảo chất lượng (quality assurance environment server).

– Cuộc họp bắt đầu với một thành viên trong nhóm trình bày về mục tiêu của Sprint, Product Backlog đã cam kết và Product Backlog đã hoàn thành. Những thành viên khác sau đó có thể tham gia thảo luận về những gì đã làm được và những gì chưa làm được trong Sprint đó.

– Vào cuối những bài trình bày, các stakeholder được biểu quyết để lấy ý kiến, cũng như những thay đổi mong muốn và độ ưu tiên của chúng.

– Product Owner thảo luận với stakeholder và Team về việc xếp lại Product Backlog dựa trên đánh giá phản hồi.

– Stakeholder có thể xác định tính năng nào không được giao hoặc không được giao như mong đợi và yêu cầu tính năng thay thế trong Product Backlog.

– Stakeholder có thể xác định bất kỳ tính năng mới xuất hiện khi họ xem phần trình bày và yêu cầu bổ sung tính năng mới vào trong Product Backlog.

– ScrumMaster nên “cố gắng” xác định số lượng mong muốn tham dự cuộc họp và tổ chức cộc họp để phù họp với họ.

– Vào cuối cuộc họp, ScrumMaster công bố thời gian và địa điểm của cuộc họp kế tiếp cho Product Owner và stakeholder.

Theo blog của bạn Huy Tran

10 Mẹo Mobile UX

Khi kênh mobile ngày càng tăng trưởng cùng với công nghệ, lĩnh vực nghiên cứu tương tác người dùng mobile (Mobile UX) cũng phát triển theo. UX tốt là điểm khác biệt chính giữa app thành công và không thành công, làm những ứng dụng mới chiến thắng những tên tuổi lớn bằng cách tạo ra những ứng dụng hấp dẫn hơn. Tôi xin chia sẻ 10 mẹo để tạo bản thiết kế tuyêtk vời dành cho mobile. Ngay cả nếu bạn không trực tiếp làm thiết kế, những mẹo này cũng sẽ giúp bạn có các khái niệm tốt hơn để trao đổi với ngừoi làm thiết kế cũng như kiểm thử các ứng dụng. Những mẹo này theo tôi cũng có thể áp dụng với bản web mobile

1. Đi từ cơ bản

Mặc dù thiết kế UX cho mobile về lý thuyết có một số điểm chung với thiết kế web và phần mềm, nhưng việc đi từ bản thiết kế của phần mềm, thu gọn lại để ra bản app sẽ không hiệu quả. Để thiết kế bản app tốt, cần bắt đầu từ những trải nghiệm người dùng từ mức cơ bản, thêm dần từ những thành phần riêng của bạn. Một bản thiết kế app tuyệt vời sẽ là độc nhất vì vậy cần được xây dựng một cách riêng, không giống với bất kỳ cái nào khác đã có

2. Xác định người dùng

Người dùng di động hiện tại có thể chia làm 2 kiểu: kiểu thợ săn (kiểu tìm kiếm thông tin hoặc làm việc xác định rõ thật nhanh) và kiểu hái lượm (đi lòng vòng thu thập thông tin). Nếu đối tượng người dùng của bạn là kiểu thợ săn, bạn cần tập trung vào các tính năng cho phép họ hoàn thành mục tiêu với ít bước nhất, giảm thiểu các chức năng không thực sự cần thiết. Nếu đối tượng của bạn là kiểu hái lượm, hãy tìm cách giúp họ truy cập nhanh nhất vào các mục thông tin, sau đó xác định cách giữ họ ở lại trong app. Bạn cũng có thể làm cả 2 cách nhưng nên thận trọng, nhiều khi ít hơn là nhiều hơn.

3. Ghi nhớ luật 80/20

Thông thường 80% người dùng app chỉ dùng 20% chức năng của app. Nếu bạn đã có bản online thì cách đơn giản để xác định là nhìn vào cách ngừoi dùng tương tác với bản online của bạn. Có thể xem cụ thể trong dữ liệu với người dùng bản mobile bằng google analytics. Xác định chức năng được sử dụng nhiều nhất, sử dụng dữ liệu này để xác định khoảng 20% kia và đưa vào app để có thể dễ dùng và thuận tiện nhất.

4. Thiết kế theo mục đích sử dụng

Ngừoi dùng mobile muốn hoàn thành mục tiêu nhanh nhất, dù là việc xem lướt (như xem sản phẩm mới) hay có mục tiêu cụ thể (mua hàng). Mọi chức năng trong app nên hướng đến việc giúp người dùng xác định và hoàn thành mục tiêu. Mọi vấn đề râu ria khác nên được bỏ qua. Xu hướng của người dùng mobile là ít thời gian và không gian thiết kế của bạn cũng rất nhỏ, vì vậy không thể để lãng phí không gian và thời gian. Cố gắng phán đoán mục tiêu của người dùng, sau đó xây dựng các khả năng có liên quan có thể xảy ra. Như vậy người dùng có thể nhanh chóng hoàn thành mục tiêu một cách mượt mà.

5. Giữ sự đơn giản

Người dùng mobile không mong muốn đọc các hướng dẫn sử dụng. Các nhắc nhở ngắn cũng tốt nhưng nếu bạn thấy mình phải đưa cả các hướng dẫn dạng FAQ vào thì có nghĩa là không ổn. Hãy ghi nhớ rằng bản mobile không có không gian cho các chú thích kiểu trên web nên việc suy nghĩ sử dung các biểu tượng là cần thiết để tiết kiệm không gian. Về lâu dài, app càng đơn giản càng tốt, dễ bảo trì, nâng cấp hơn. Ghi nhớ câu thần chú:  tính năng càng nhiều người dùng càng ít.

6. Đừng bỏ qua UX của nền tảng hệ thống

Apple, Google và các hãng khác đã bỏ ra hàng tỷ  USD để đào tạo người dùng biết chính xác điều gì tiếp theo khi họ ấn 1 nút, swipe màn hình hay chạm vào 1 icon. Tạo ra các giao diện không theo các chuẩn này có thể làm đội thiết kế vui nhưng sẽ làm người dùng bị bối rối, giảm khả năng tương tác. Thay vào đó, nên tuân theo các chuẩn đã có của hệ thống, thêm các tinh chỉnh của bạn mà không cần thay đổi các chức năng cơ bản. Đọc các hướng dẫn của hệ thống (platform guidelines) để chắc chắn bạn đang dùng đúng thành phần của UI cho 1 chức năng , cũng như nên tuân theo các hướng dẫn ở các vấn đề liên quan khác .  Những hướng dẫn này đều có lý do của nó. Nên dùng một thiết bị bạn đang thiết kế app cho nó trong ít nhất 1 tháng để hiểu và cảm nhận những hướng dẫn này.

7. Người dùng có nhiều hơn một hành động đơn lẻ

Người dùng có thể tương tác với thiết bị nhiều hơn so với bản mô tả. Rất nhiều yếu tố tác động cùng lúc tới người dùng mobile như : âm thanh, sự chuyển động, thông tin từ các cảm ứng trong thiết bị, từ các ứng dụng khác đang chạy… Hãy suy nghĩ về việc bạn sẽ cải thiện trải nghiệm của người dùng một cách thông minh như thế nào, sử dụng các dữ liệu mà người dùng thậm chí không nghĩ đến là cách rất tốt để tạo ra những kết quả ngạc nhiên và đáng nhớ.

8. Thiết kế theo giai đoạn

Một vấn đề không may với các sản phẩm mobile (vốn dĩ có thể di chuyển đến bất kỳ đâu và làm rất nhiều thứ) là có vấn đề gì đó ngắt quãng sử dụng của người dùng. Nguyên nhân có thể đến từ cuộc sống thực của người dùng hoặc đến từ chính chiếc điện thoại. Giữ giao diện app đơn giản và rõ ràng sẽ giúp giảm thời gian nhận thức lại vấn đề của người dùng khi phải quay lại app sau khi bị ngắt quãng sử dụng. Đồng thời , cần hỗ trợ người dùng quay lại vị trí bị ngắt quãng trước đó , điều rất dễ xảy ra khi dùng điện thoại (nhận cuộc gọi , tin nhắn, có việc gấp cần xử lý…)

9. Nhớ rằng bản thiết kế của bạn không phải là hoàn hảo

Ngay cả những người cẩn thận nhất cũng sẽ bỏ sót một vài vấn đề UX. Thậm chí những vấn đề này có thể phát sinh ngay cả khi đã được tính trước. Trong quá trình xây dựng app, một vài ý tưởng về mặt kỹ thuật là bất khả thi, đừng vội bỏ nó đi mà nên quay lại từ đầu, tìm cách thay thế nó bằng cách gần tương tự nhất. Với sự phát triển của công nghệ hiện nay, việc không làm được hôm nay hoàn toàn có thể thực hiện được trogn tương lại gần. Đưa app của bạn vào vòng lặp tiến hóa, sử dụng dữ liệu từ analytics, phản hồi của người dùng, ứng dụng các công nghệ mới để đánh giá lại và cải thiện.

10.   Hơn tất cả ,hãy theo các kinh nghiệm thực tế và trải nghiệm của riêng bạn

Sự khác biệt giữ thiết bị trên mobile và thiết kế thông thường nằm ở chỗ có rất ít không gian dành cho các tính năng và giao diện. Thậm chí nếu bạn không có kinh nghiệm gì trong thiết kế mobile, việc bị ép phải phù hợp với yêu cầu này cùng với trải nghiệm của riêng bạn sẽ giúp bạn có bản thiết kế một cách tự nhiên , tuy nhiên sẽ phải dành nhiều thời gian hơn để cải tiến sản phẩm.

Khi kênh mobile ngày càng tăng trưởng cùng với công nghệ, lĩnh vực nghiên cứu tương tác người dùng mobile (Mobile UX) cũng phát triển theo. UX tốt là điểm khác biệt chính giữa app thành công và không thành công, làm những ứng dụng mới chiến thắng những tên tuổi lớn bằng cách tạo ra những ứng dụng hấp dẫn hơn. Tôi xin chia sẻ 10 mẹo để tạo bản thiết kế tuyêtk vời dành cho mobile. Ngay cả nếu bạn không trực tiếp làm thiết kế, những mẹo này cũng sẽ giúp bạn có các khái niệm tốt hơn để trao đổi với ngừoi làm thiết kế cũng như kiểm thử các ứng dụng. Những mẹo này theo tôi cũng có thể áp dụng với bản web mobile

1.       Đi từ cơ bản

Mặc dù thiết kế UX cho mobile về lý thuyết có một số điểm chung với thiết kế web và phần mềm, nhưng việc đi từ bản thiết kế của phần mềm, thu gọn lại để ra bản app sẽ không hiệu quả. Để thiết kế bản app tốt, cần bắt đầu từ những trải nghiệm người dùng từ mức cơ bản, thêm dần từ những thành phần riêng của bạn. Một bản thiết kế app tuyệt vời sẽ là độc nhất vì vậy cần được xây dựng một cách riêng, không giống với bất kỳ cái nào khác đã có

2.       Xác định người dùng

Người dùng di động hiện tại có thể chia làm 2 kiểu: kiểu thợ săn (kiểu tìm kiếm thông tin hoặc làm việc xác định rõ thật nhanh) và kiểu hái lượm (đi lòng vòng thu thập thông tin). Nếu đối tượng người dùng của bạn là kiểu thợ săn, bạn cần tập trung vào các tính năng cho phép họ hoàn thành mục tiêu với ít bước nhất, giảm thiểu các chức năng không thực sự cần thiết. Nếu đối tượng của bạn là kiểu hái lượm, hãy tìm cách giúp họ truy cập nhanh nhất vào các mục thông tin, sau đó xác định cách giữ họ ở lại trong app. Bạn cũng có thể làm cả 2 cách nhưng nên thận trọng, nhiều khi ít hơn là nhiều hơn.

3.       Ghi nhớ luật 80/20

Thông thường 80% người dùng app chỉ dùng 20% chức năng của app. Nếu bạn đã có bản online thì cách đơn giản để xác định là nhìn vào cách ngừoi dùng tương tác với bản online của bạn. Có thể xem cụ thể trong dữ liệu với người dùng bản mobile bằng google analytics. Xác định chức năng được sử dụng nhiều nhất, sử dụng dữ liệu này để xác định khoảng 20% kia và đưa vào app để có thể dễ dùng và thuận tiện nhất.

4.       Thiết kế theo mục đích sử dụng

Ngừoi dùng mobile muốn hoàn thành mục tiêu nhanh nhất, dù là việc xem lướt (như xem sản phẩm mới) hay có mục tiêu cụ thể (mua hàng). Mọi chức năng trong app nên hướng đến việc giúp người dùng xác định và hoàn thành mục tiêu. Mọi vấn đề râu ria khác nên được bỏ qua. Xu hướng của người dùng mobile là ít thời gian và không gian thiết kế của bạn cũng rất nhỏ, vì vậy không thể để lãng phí không gian và thời gian. Cố gắng phán đoán mục tiêu của người dùng, sau đó xây dựng các khả năng có liên quan có thể xảy ra. Như vậy người dùng có thể nhanh chóng hoàn thành mục tiêu một cách mượt mà.

5.       Giữ sự đơn giản

Người dùng mobile không mong muốn đọc các hướng dẫn sử dụng. Các nhắc nhở ngắn cũng tốt nhưng nếu bạn thấy mình phải đưa cả các hướng dẫn dạng FAQ vào thì có nghĩa là không ổn. Hãy ghi nhớ rằng bản mobile không có không gian cho các chú thích kiểu trên web nên việc suy nghĩ sử dung các biểu tượng là cần thiết để tiết kiệm không gian. Về lâu dài, app càng đơn giản càng tốt, dễ bảo trì, nâng cấp hơn. Ghi nhớ câu thần chú:  tính năng càng nhiều người dùng càng ít.

6.       Đừng bỏ qua UX của nền tảng hệ thống

Apple, Google và các hãng khác đã bỏ ra hàng tỷ  USD để đào tạo người dùng biết chính xác điều gì tiếp theo khi họ ấn 1 nút, swipe màn hình hay chạm vào 1 icon. Tạo ra các giao diện không theo các chuẩn này có thể làm đội thiết kế vui nhưng sẽ làm người dùng bị bối rối, giảm khả năng tương tác. Thay vào đó, nên tuân theo các chuẩn đã có của hệ thống, thêm các tinh chỉnh của bạn mà không cần thay đổi các chức năng cơ bản. Đọc các hướng dẫn của hệ thống (platform guidelines) để chắc chắn bạn đang dùng đúng thành phần của UI cho 1 chức năng , cũng như nên tuân theo các hướng dẫn ở các vấn đề liên quan khác .  Những hướng dẫn này đều có lý do của nó. Nên dùng một thiết bị bạn đang thiết kế app cho nó trong ít nhất 1 tháng để hiểu và cảm nhận những hướng dẫn này.

7.       Người dùng có nhiều hơn một hành động đơn lẻ

Người dùng có thể tương tác với thiết bị nhiều hơn so với bản mô tả. Rất nhiều yếu tố tác động cùng lúc tới người dùng mobile như : âm thanh, sự chuyển động, thông tin từ các cảm ứng trong thiết bị, từ các ứng dụng khác đang chạy… Hãy suy nghĩ về việc bạn sẽ cải thiện trải nghiệm của người dùng một cách thông minh như thế nào, sử dụng các dữ liệu mà người dùng thậm chí không nghĩ đến là cách rất tốt để tạo ra những kết quả ngạc nhiên và đáng nhớ.

8.       Thiết kế theo giai đoạn

Một vấn đề không may với các sản phẩm mobile (vốn dĩ có thể di chuyển đến bất kỳ đâu và làm rất nhiều thứ) là có vấn đề gì đó ngắt quãng sử dụng của người dùng. Nguyên nhân có thể đến từ cuộc sống thực của người dùng hoặc đến từ chính chiếc điện thoại. Giữ giao diện app đơn giản và rõ ràng sẽ giúp giảm thời gian nhận thức lại vấn đề của người dùng khi phải quay lại app sau khi bị ngắt quãng sử dụng. Đồng thời , cần hỗ trợ người dùng quay lại vị trí bị ngắt quãng trước đó , điều rất dễ xảy ra khi dùng điện thoại (nhận cuộc gọi , tin nhắn, có việc gấp cần xử lý…)

9.       Nhớ rằng bản thiết kế của bạn không phải là hoàn hảo

Ngay cả những người cẩn thận nhất cũng sẽ bỏ sót một vài vấn đề UX. Thậm chí những vấn đề này có thể phát sinh ngay cả khi đã được tính trước. Trong quá trình xây dựng app, một vài ý tưởng về mặt kỹ thuật là bất khả thi, đừng vội bỏ nó đi mà nên quay lại từ đầu, tìm cách thay thế nó bằng cách gần tương tự nhất. Với sự phát triển của công nghệ hiện nay, việc không làm được hôm nay hoàn toàn có thể thực hiện được trogn tương lại gần. Đưa app của bạn vào vòng lặp tiến hóa, sử dụng dữ liệu từ analytics, phản hồi của người dùng, ứng dụng các công nghệ mới để đánh giá lại và cải thiện.

10.   Hơn tất cả ,hãy theo các kinh nghiệm thực tế và trải nghiệm của riêng bạn

Sự khác biệt giữ thiết bị trên mobile và thiết kế thông thường nằm ở chỗ có rất ít không gian dành cho các tính năng và giao diện. Thậm chí nếu bạn không có kinh nghiệm gì trong thiết kế mobile, việc bị ép phải phù hợp với yêu cầu này cùng với trải nghiệm của riêng bạn sẽ giúp bạn có bản thiết kế một cách tự nhiên , tuy nhiên sẽ phải dành nhiều thời gian hơn để cải tiến sản phẩm.

Follow

Get the latest posts delivered to your mailbox: