50.000 VND

September 10, 2020September 10, 2020 ~ binhtruong ~ Leave a comment

#app #mobileapp #digitalbanking #onboarding #citibank

Hôm nay mình nhận EDM của Citibank, khuyến khích + gift để cài mobile app citibank trên điện thoại. Ai cũng biết làm mobile app thì cái đau đầu nhất là growth, onboarding user, đặc biệt là bank. Vậy case của citi bank có gì đáng nói?

Incentives quá nhỏ

Thông điệp của EDM đến từ citibank là “Đăng ký ngay để nhận mã ưu đãi Lazada 50.000 VNĐ”, và nó có mấy vấn đề

Lazada không phải là brand phù hợp để Citibank đi cùng tại thời điểm này so với sale dữ dội 9.9 như Tiki.vn và Shopee.vn, tất nhiên, không loại trừ trường hợp Citibank thu hẹp mảng bán lẻ tại Việt Nam nên cũng có thể không còn đủ ‘tầm’ để hợp tác với các brand TMĐT lớn.
50.000 VNĐ không phải là thứ đáng để thử.

Chưa test app đầy đủ

Mặc dù không hứng thú với thông điệp, nhưng mình cũng thử cài, và kết quả là app không load được trên iPhone 6s. Điều này làm nổi bật 02 điểm khác:

App chưa được test với dòng iPhone 6s và iOS cũ, chắc lúc làm và go-live, họ chỉ test với iPhone X trở lên hoặc chỉ support trong vòng 3-4 dòng điện thoại mới nhất.
Không có thông báo rằng app của Citibank tương thích với dòng điện toại và hệ điều hành nào trên các kênh truyền thông của citibank

Tóm lại là, không dùng được.

Citibank có còn mặn mà với khách hàng cá nhân ở Hà Nội?

Theo phỏng đoán của cá nhân mình thì câu trả lời là: không.

Bằng chứng là họ bỏ đi rất nhiều dịch vụ tốt mà trước đây vẫn có.

Tháng 10/2019, khi làm visa đi EU, mình qua Citibank Hà Nội tại Cát Linh và đề nghị in sao kê thẻ tín dụng nhưng bị từ chối (2 năm trước đều được xử lý nhanh gọn). Lý do là văn phòng tại Hà Nội bây giờ không giải quyết việc này, và mời anh/chị về email, gọi hotline cho Citibank HCM.

OK, fine.

Và rồi nhân viên sale vẫn chăm chỉ gọi điện

Hầu như tháng nào cũng vậy, nhân viên sale Citibank vẫn gọi và đề nghị mình vay một khoản, giải ngân từ chính hạn mức thẻ tín dụng của mình vì lịch sử tín dụng tốt, và tất nhiên lần nào mình cũng tua lại 02 câu:

Câu 1: Thẻ tín dụng để anh đi nước ngoài hoặc ra đường anh quẹt, vay tạm ứng lãi vừa cao và anh không dùng được thẻ nữa thì phải làm sao?
Câu 2: Sao tháng nào cũng có 01 bạn gọi cho anh nói lại vấn đề này? Lần nào anh cũng hỏi vay 1 tỷ và không ai cho anh vay, em giải quyết được thì gọi lại nhé.

Sau cùng thì cũng không có nhân viên nào cho mình vay 1 tỷ.

Mình thì không biết bao giờ Citibank rút lùi hoàn toàn mảng bán lẻ tại Việt Nam như ANZ đã làm năm 2017.

Protect Users’ Work

July 21, 2014July 21, 2014 ~ binhtruong ~ 1 Comment

Nhắc lại khái niệm usability căn bản: Đừng cản trở người dùng

(Hình 1: Ảnh chụp màn hình Foody app yêu cầu người dùng nâng cấp phiên bản mới)

Dạo này viết lách về Foody hơi nhiều, nhưng có lẽ mobile app của Việt Nam ít người review quá, nên nhân dịp gặp một case study mới, mình lại “tám” một chút về nó.

Case study

Tình huống người sử dụng lần này khá đơn giản: Tôi và bạn gái hẹn nhau đi ăn tối, và quyết định khám phá 1 chi nhánh mới mở của M2C cafe. Trong đầu không nhớ rõ địa chỉ, vì thế nên nhớ tới Foody app nên lấy điện thoại ra để tìm địa điểm. Hai người chúng tôi dùng một chiếc iPhone 5 và một chiếc iPhone 4, cả hai đều cài ứng dụng Foody từ AppStore. Tuy nhiên, khi bạn tôi mở foody app thì nhận được thông báo “yêu cầu phải nâng cấp phiên bản mới nhất“, nếu không bấm vào CTA “Launch AppStore” thì chỉ có nước thoát khỏi ứng dụng mà thôi. Tôi cũng thử lại một lần nữa với Foody app trên điện thoại của mình và cũng nhận được kết quả tương tự. Câu hỏi đặt ra là:

Nhu cầu của chúng tôi (users) là sử dụng app để tìm địa chỉ quán. Chúng tôi không muốn cập nhật vào lúc này, làm sao để đạt được mục đích?
Khi bạn đang đứng ở.. ngoài đường, thì khả năng update ứng dựng từ AppStore với mạng 3G của Việt Nam là không khả thi và tốn rất nhiều thời gian, trong khi đó thì bạn đang đói. Thứ mà ứng dụng “yêu cầu” không match với cái người dùng cần. Mà nếu không update Foody app thì.. có ảnh hưởng gì tới hòa bình thế giới không?

Khái niệm usability căn bản

Tôi không biết bản Foody app v2.7 có gì nổi bật, ngay cả giờ đây sau khi đã cập nhật xong xuôi, thứ tôi cần vẫn chỉ là tìm địa điểm quán ăn / cafe một cách nhanh nhất, tiện nhất khi cần thiết (mà phần lớn tôi đoán rằng user behavior của người dùng sẽ diễn ra ở… ngoài đường). Tôi không thực hiện được điều tôi muốn, không thao tác được chức năng cơ bản nếu không update phiên bản mới, và điều này gọi là blocker bugs trong khái niệm phần mềm.

Prevents developers or testers from performing their jobs. Impacts the development process. – open SUSE – Bug definitions

Đối với interaction design thì điều này phạm phải 2 nguyên tắc cơ bản nhất đó là ngăn cản người dùng thao tác với sản phẩm / thiết bị / ứng dụng phần mềm và không cho phép người dùng ra quyết định đối với tương tác hệ thống. Nghe có vẻ to tát, nhưng thực chất từ chuyên môn gọi là Protect Users’ Work và Autonomy. Cụ thể hơn, 2 nguyên tắc này có thể được giải thích ngắn gọn như sau:

Autonomy: Qui tắc này cho phép người dùng đưa ra quyết định của riêng họ, kể cả với những người kém về mặt thẩm mỹ hoặc yếu trong khâu thao tác với sản phẩm ( Nguyên văn: Enable users to make their own decisions, even ones aesthetically poor or behaviorally less efficient).
Protect Users’ Work: Đây là qui tắc đầu tiên và căn bản của usability design. Ý nghĩa của nó là luôn luôn đảm bảo người sử dụng hoàn thành công việc của mình, đảm bảo công việc của họ được thực hiện thành công. Ngoài ra, nghĩa mở rộng của qui tắc này là đảm bảo người dùng không bị mất thông tin, dữ liệu trong trường hợp không thể tiếp tục thao tác với ứng dụng (vd: mất đường truyền internet, mất password…)

Cải tiến nho nhỏ?

Trường hợp của Foody app không phải là quá khó cải tiến, mà có lẽ ai trong chúng ta cũng biết, với 1 thay đổi nhỏ nhưng sẽ mang lại hiệu quả tích cực hơn với người dùng, ví dụ như: Bổ sung nút lựa chọn “Later” bên cạnh nút CTA “Launch AppStore” để người dùng có quyền lựa chọn cài đặt bản nâng cấp hay tiếp tục sử dụng phiên bản cũ.

Vấn đề ở đây không lớn, nhưng thuộc về khái niệm cơ bản mà có lẽ những người ở vị trí nhân viên phụ trách sản phẩm (Product manager / UX manager ) nên có một checklist để kiểm tra trước khi để sản phẩm go live.

Tham khảo:

10 Usability Heuristics for User Interface Design [URL]
First Principles of Interaction Design (Revised & Expanded) [URL] => Cái này rất rất chi là cơ bản 🙂

One eyeball, One thumb

September 19, 2013September 19, 2013 ~ binhtruong ~ Leave a comment

Một lưu ý khi thiết kế giao diện mobile app

(Ảnh 1: one eyeball, one thumb. Nguồn Internet)

Khái niệm “One eyeball, one thumb” là một phát biểu của Luke Wroblewski, người đứng trong hàng ngũ chuyên gia đầu ngành về UI, UX cho web và mobile application design. Phát biểu này rút ra từ các báo cáo (1) nghiên cứu hành vi sử dụng smart phone của người dùng. Các báo cáo này cho thấy, phần lớn thời gian người dùng sử dụng smart phone là ở nhà, và sử dụng song song với thời gian làm các công việc khác như xem TV, ăn cơm, ngồi cafe tán chuyện với người thân, đọc sách báo, hay là một tay bế em bé – 1 tay nghịch iPhone… Trong quá trình sử dụng đó, phần lớn người dùng chỉ sử dụng 1 tay để thao tác với chiếc điện thoại, và phần lớn là chỉ dùng ngón cái để tương tác với các thành phần giao diện (UI) của ứng dụng smart phone, rồi khi cần thì liếc mắt xem thông tin trên màn hình. Thử ngẫm lại xem bạn có hay làm vậy không? Nếu có, thì đó chính là “one eyeball, one thumb”.

Nếu như phần lớn người dùng chỉ sử dụng ngón tay cái (thumb) thì việc thiết kế giao diện cho ứng dụng smart phone phải tính tới khả năng tiện dụng, usability, và UX trong trường hợp này.

Khi người dùng chủ yếu tương tác với điện thoại smart phone bằng ngón tay cái, nghĩa là khả năng thao tác sẽ có giới hạn của nó. Trên giao diện ứng dụng iPhone, HTC sẽ có những vùng mà nếu như sử dụng 1 tay thì người dùng sẽ gặp khó khăn. Ở đây, người ta chia ra làm 03 vùng như sau:

REACH: Vùng giao diện người dùng phải vất vả nhất nếu muốn dùng ngón tay cái chạm tới.
OK: Vùng giao diện nằm trong khả năng “touch” của ngón tay cái.
EASY: Vùng giao diện thuận tiện nhất dành cho đối tượng “one eyeball, one thumb”

Như vậy, nếu nhìn vào 2 bức ảnh trong blog này (ảnh 1 và ảnh 2) thì dù điện thoại iPhone, hay HTC, Android… người dùng đều có vùng giới hạn khi sử dụng ngón cái để thao tác. Vậy xử lý việc này thế nào? Dễ hiểu là các navigation, hay chức năng quan trọng nên đặt trong vùng EASY, ngược lại, những thứ như cover photo, wallpaper hay thông tin ít thay đổi, có thể đặt trong vùng REACH, phần còn lại, những thông tin, listing item, feed nên đặt ở vùng OK.

(Ảnh 2: các vùng giới hạn của iPhone khi thao tác bằng ngón tay cái)

Việc đưa ra giao diện phù hợp với các vùng giới hạn (tôi tạm dịch từ “limitation area”) là điều cần thiết, và bởi vì những lúc sử dụng smart phone bằng cả 2 tay là ít hơn, hoặc nếu có thì giao diện có thế nào cũng dễ tương tác hơn. Có một số cải tiến trong các ứng dụng iPhone phổ biến mà ta có thể nhận thấy họ đã điều chỉnh để phù hợp với tình huống “rule of thumb” như là:

Tập trung các navigation menu tương tác ở phía dưới màn hình smart phone. Ví dụ facebook phiên bản mới, Path, foursquare…
Thiết kế các icon, button to hơn, chuẩn hơn để cho ngón tay cái có thể chạm vào tốt hơn. Điều này cũng có nghĩa là hạn chế sử dụng “text navigation” và áp dụng các icon, button có kích thước lớn hơn. Apple sử dụng kích thước 44 x 44 points, Windows phone đưa ra khoảng cách tiêu chuẩn của họ từ 7mm (min) cho tới 9mm (max), MIT thì cung cấp kích thước 10-14mm cho tablet và 8-10mm cho smart phone. (các kích thước này thường ngụ ý là chiều cao x chiều rộng, nếu button/menu không phải hình vuông thì đó là chiều cao).
Thay đổi khoảng các giữa các icon, button sao cho giảm thiểu được việc thao tác “nhầm” menu mà người dùng mong muốn. (định bấm vào nút này nhưng vô tình chạm phải nút kia). Khoảng cách đề xuất tương đối chuẩn hiện nay là 2mm.

(Ảnh 3: màn hình giao diện ứng dụng Path, Foursquare với menu tương tác nằm gọn trong vùng EASY)

Không chỉ ảnh hưởng tới navigation, mà “one thumb rule” còn khiến người thiết kế ứng dụng smart phone phải lưu ý tới việc tổ chức thông tin sao cho phù hợp, cũng như phải sắp đặt thứ tự ưu tiên của các chức năng được xem là “core feature” nhằm thu hút người dùng ở mức tối đa. (bởi họ chỉ “liếc” bằng “one eyeball” mà thôi).

Với việc áp dụng UX concept “one eyeball, one thumb” vào thiết kế, các ứng dụng mobile đã có nhiều thay đổi đáng kể và nếu để ý một chút thì foursquare và Path là 02 ứng dụng làm tốt nhất việc này. Bên cạnh đó, màn hình iPhone 4 (theo tôi là thiết kế tốt nhất của iPhone từ trước tới nay) với kích thước 3.5in (320 x 480) sẽ dễ dàng thao tác hơn so với iPhone 5 (kích thước 4.08in, 1,136 x 640) khi sử dụng một tay theo thói quen thường lệ.

Tham khảo:

(1) Báo cáo thống kê thời điểm sử dụng smart phone trong ngày của người dùng [URL].

(2) Rule of thumb, tạp chí Forbes.

(3) How do users really hold mobile devices, UXMatter.

Thiết kế sản phẩm bắt đầu từ mobile?

September 17, 2013September 20, 2013 ~ binhtruong ~ Leave a comment

Định hướng lấy mobile làm trọng tâm khi xây dựng sản phẩm

(Ảnh: mobile life, nguồn Internet)

Cách làm sản phẩm phần mềm truyền thống từ trước tới nay vẫn thường là bắt đầu với desktop, laptop… rồi sau đó mới tới mobile, tablet nếu “có nhu cầu” nở rộng thị phần hoặc khách hàng “yêu cầu”. Nhất là các dự án ở Việt Nam, cứ phải có 1 URD (1) hoặc SRS (2) với một bó tính năng hoành tráng. Thế giới giờ thay đổi rồi, làm sản phẩm thì không làm như vậy được nữa. Mọi thứ nên bắt đầu từ mobile.

Hiện trạng và động lực

Hiện nay, lượng người dùng sử dụng mobile truy cập các trang web, sử dụng mobile app để chia sẻ dữ liệu lên các trang mạng xã hội (Facebook, Twitter…) tăng vọt, các báo cáo thông kê (3) cho thấy xu hướng sử dụng điện thoại để online càng ngày càng phổ biến hơn dùng laptop, hoặc desktop. (Khổ lắm, biết rồi…nói mãi…)

Thời điểm năm 2006, điện thoại thông minh nhất thì cũng chỉ có máy ảnh 2mega pixel, tốc độ vào web chậm, mạng 3G tại Việt Nam vẫn còn chậm, và các điện thoại smart phone phổ biến vẫn là motorola, Black Berry với bàn phím vật lý không tiện dụng… (thực ra là tiện dụng với SMS chứ vào web thì không ổn lắm).

Ngày 29 tháng 6 năm 2007, chắc nhiều người vẫn còn nhớ, Steve Job cho ra mắt iPhone, với touch screen và bàn phím ảo, đó thực sự là bước ngoặt, với một thiết bị mới, tiện dụng hơn và UX hơn hẳn các điện thoại cùng thời bấy giờ.

Theo thời gian, 6-7 năm kể từ ngày ấy, giá thành của smart phone ngày càng rẻ đi cũng như giá viễn thông (3G, wifi) không tăng lên và có xu hướng ngày càng rẻ, thậm chí ở Việt Nam còn rẻ hơn nữa… bên cạnh đó thì tốc độ truy cập ngày một nhanh hơn, băng thông rộng hơn… Nói không ngoa thì Việt Nam là nước dùng free wifi, internet nhiều và sướng nhất Đông Nam Á tính đến bây giờ.

Theo báo cáo của Cisco, số lượng người dùng toàn cầu sở hữu smartphone khoảng 13% trên tổng số người sử dụng các thiết bị di động, tuy nhiên nhóm người dùng này tạo ra lượng trao đổi dữ liệu chiếm 78% trên tổng số lưu lượng thống kê được (handset traffic).

(Ảnh: mobile era, nguồn: Internet & Mobile Internet 2013 của KPCB)

Hiện trạng đã rõ rồi, động lực cũng có đủ rồi… vậy nên bắt đầu với native app (iPhone app, Android app) hay với mobile web?

Native mobile app và mobile web

Câu trả lời là… Nếu có thể, hãy làm cả 2 phiên bản. Native app thì rõ ràng là sẽ thao thác tốt hơn với các lợi thế của smartphone (SMS, Camera, định vị GPS, các chương trình chạy ngầm v.v…) và cũng có nghĩa là UX tốt hơn. Tuy nhiên thì nếu một website có phiên bản mobile thì sẽ tăng khả năng truy cập (từ smart phone) cho người dùng. Dễ hiểu thôi, không phải lúc nào cũng hùng hục cài iPhone app của một website “xa lạ” hoặc “mới quen” được, cứ chơi mobile web cho lành.

Bên cạnh đó, mobile web thì phù hợp cho chia sẻ content, xử lý điều hướng những URL tốt hơn và cross-platform vì không cần phải làm riêng cho mỗi 1 dòng điện thoại một phiên bản. Dễ dàng cập nhật hơn (từ máy chủ web) khi có phiên bản mới chứ không phải cập nhật từng phiên bản như native app, A/B testing cũng sẽ dễ thực hiện hơn.

Tóm lại, không nhất thiết phải cung cấp tất cả các phiên bản cùng lúc, những liên tục mở rộng và cung cấp nhiều cách thức tiếp cận cho người dùng, cũng là một cách mang lại cho họ (người dùng) nhiều trải nghiệm hơn.

Nhưng tại sao lại mobile first? và “UX” có vai trò gì ở đây?

Khi chọn thiết kế cho mobile trước tiên, cũng có nghĩa là nhóm phát triển phải thiết kế cho một màn hình nhỏ, nhiều hạn chế. Bạn phải chắc chắn rằng, những tính năng hiển thị trên màn hình mobile sẽ là những tính năng quan trọng nhất, cần thiết nhất. Và cần hiểu một thực tế là: không có chỗ cho tất cả các tính năng, bạn và nhóm của bạn phải lựa chọn, phải tìm hiểu cái người dùng quan tâm nhất để đưa vào key features.

You have to make sure that what stays on the screen is the most important set of features for your customers and your business – Luke W.

Khi nhóm phá triển của Flickr thiết kế phiên bản dành cho mobile, họ đã phải giảm bớt số lượng tính năng (functions/ features) từ hơn 60 chức năng xuống còn 6 tính năng cơ bản nhất, nhưng quan trọng nhất. Flickr có phiên bản web trước khi ra mắt phiên bản mobile, cũng bởi nguyên nhân lịch sử. Bạn có cơ hội hoàn toàn khác. Ngay hôm nay, khi lựa chọn thiết kế cho mobile trước, thì điều đó cũng có nghĩa là bạn phải lựa những gì đáng được ưu tiên nhất, để rồi sau đó, phiên bản web (ra đời sau) sẽ tránh được những dư thừa không cần thiết. Như vậy, bạn sẽ chắc chắn được một điều rằng: ta chỉ đưa cho người dùng những gì họ thực sự cần, và cơ hội hiểu người dùng cũng sẽ nhiều hơn, tốt hơn.

Cuối cùng, “Simply the best” và “less is more” chính là 2 slogan mà tôi muốn nhắc lại để kết thúc blog này. Mobile là hiện tại, và cũng sẽ là tương lai.

Ghi chú:

(1) URD viết tắt của User Requirement Definition, nghĩa là tài liệu mô tả yêu cầu của người dùng đối với một phần mềm (hoặc hệ thống phần mềm).

(2) SRS viết tắt của Software Requirement Specification, là tài liệu đặc tả phần mềm (mang tính kỹ thuật hơn là tính chức năng ở phía người dùng).

(3) Xem các báo cáo thông kê tại đây [Mobile Data Wave 13 june 2012], [The Mobile Internet Report 2009], và report mình thích nhất (tìm trên slideshare.com sẽ có rất nhiều) [Internet & Mobile Internet 2013 KPCB]

Mobile context

July 18, 2013 ~ binhtruong ~ 2 Comments

Hãy nghĩ về mobile context trước khi thiết kế phần mềm cho iPhone, Adroid…

(Ảnh: mobile context, nguồn: Internet)

Thiết kế phần mềm ứng dụng từ trước khi các thiết bị mobile ra đời, đa phần đều hướng người dùng ngồi trước màn hình máy tính và thao tác những chức năng nghiệp vụ. Với các thiết bị mobile ngày nay, ngoài việc gọi điện, gửi tin nhắn sms thì người dùng còn có thể sử dụng phần mềm trên thiết bị di động (điện thoại, tablet…) ở bất cứ nơi đâu. Có người thì sử dụng Facebook, Twitter khi đang ngồi trên xe khách, trên tàu hỏa. Người thì dùng điện thoại để check-in bằng foursquare tại nhà hàng, thậm chí có người check mail, lướt web ngay trong phòng họp. Tất cả những “hành vi” và “bối cảnh” sử dụng phần mềm trên điện thoại như vậy được gọi chung là mobile context.

Việc thiết kế các ứng dụng iPhone hay Android ngày nay cũng gắn liền với mobile context một cách chặt chẽ và kỹ lưỡng. Thông thường, khi lên ý tưởng thiết kế, những người designer chuyên nghiệp sẽ nghĩ về context. Khi thay đổi context, mọi thứ cũng thay đổi theo. Để dễ hình dung hơn ta có thể hình dung một phần mềm mô phỏng chơi piano thì sẽ ít khi được sử dụng ngoài trời cho dùng người dùng có gắn tai nghe. Tương tự như vậy, với 1 nhà hàng thì khi xem thông tin trên website, việc thiết kế thông tin có thể sẽ rất “rộng tay” với hình ảnh sản phẩm, món ăn, hình ảnh khách hàng, và các hiệu ứng media như flash, video.v.v… nhưng khi xem thông tin (website) hoặc cài đặt iPhone app của nhà hàng, các thông tin được ưu tiên hiển thị trên mobile sẽ phải là số điện thoại, địa chỉ, giờ đóng mở cửa..v.v.. Bởi 1 lẽ, khi bạn dùng điện thoại di động để tìm thông tin nhà hàng, nghĩa là bạn đang không ngồi trước máy tính, rất có thể đang đứng ngoài đường hay ở đâu đó, nơi mà kết nối 3G không cho phép hiển thị nhanh và nhiều thông tin dạng rich media.

Vậy phải làm gì khi nghĩ về mobile context? Thông thường có vài gợi ý dễ nhớ như sau:

Nếu bạn thiết kế ứng dụng cho chính nhu cầu của mình, bạn sẽ biết mình hay dùng mobile app này ở đâu, khi nào. Còn nếu không, hãy cố gắng tưởng tượng ra người dùng sẽ sử dụng như thế nào? Dùng ở đâu? tần suất sử dụng bao nhiêu lần 1 ngày? Ví dụ Foursquare thì thường được dùng khi tới 1 địa điểm nào đó, game app được dùng khi ngồi rảnh rỗi, giết thời gian.
Với mỗi đối tượng sử dụng (user type) sẽ có những cách tiếp cận khác nhau. Những ứng dụng liên quan tới đo lường, thời gian, thời tiết thì thường hiển thị thông tin to, rõ ràng, và phục vụ tối đa lượng người dùng. Nhưng với những ứng dụng nhiều chi tiết như Facebook thì độ tuổi của người dùng sẽ thu hẹp lại. Nếu để ý, 1 mobile app như Facebook có rất nhiều chi tiết trong thiết kế.
1 ứng dụng mobile app có thể sẽ có nhiều context khác nhau với cách thể hiện khác nhau. Ví dụ dễ hiểu nhất là cùng 1 ứng dụng nhưng khi sử dụng trên iPhone sẽ khác với khi dùng trên iPad bởi real estate (khoảng trống) trên màn hình của chúng khác nhau, các tính năng của thiết bị cũng khác.

Nếu chỉ nói chung chung, thì mobile context là một khái niệm khá trừu tượng. Chính vì vậy, tôi chọn một ví dụ rất nổi tiếng trong giới người dùng là dân chơi thể thao. Đó là 1 dự án có sự liên kết giữa Apple và Nike. Để hỗ trợ các vận động viên tham gia luyện tập, cũng như quảng bá loại giày chạy có gắn thiết bị cảm ứng, hãng sản xuất giày Nike đã kết hợp với Apple để xây dựng một ứng dụng có tên Nike+ Running. Ứng dụng này khi làm ra bao gồm 03 phần:

Hỗ trợ 02 loại thiết bị: iPod và iPhone.
Có một thiết bị cảm ứng gắn liền với giày hoặc có thể mang theo bên mình (gọi là nike+ sensor)
Với việc xác định mobile context là những người luyện tập thể thao, hoạt động ngoài trời và có nhu cầu theo dõi tốc độ chạy của mình cũng như quãng đường đã chạy được, người thiết kế ứng dụng đã tập trung vào một số điểm quan trọng như ánh sáng màn hình phù hợp với ánh nắng ngoài trời, thông tin hiển thị to, rõ ràng, kết hợp với bản đồ dạng geo map và cũng không quên áp dụng gamification trong việc đưa ra những thách thức chạy nhiều hơn, xa hơn với người chơi.

Như vậy, có thể thấy việc đánh giá kỹ lưỡng về mobile context sẽ định hình cho mobile app về vóc dáng, chức năng sau này một cách đầy đủ, đáp ứng đúng nhu cầu của người dùng. Ở góc nhìn toàn cảnh, mobile context thể thể được tổng kế trong 03 phạm vi chính như sau:

ACTIVITY: bao gồm các hoạt động mà qua đó người dùng có thể sẽ sử dụng ứng dụng trên điện thoại. Ví dụ như đi dạo, lái xe, ăn tối, đứng chờ xe buýt hoặc trong phòng chờ lên máy bay, v.v…
ENVIRONMENT: là môi trường xung quanh người dùng như âm thanh, ánh sáng, không gian (rộng/hẹp/dài…), nơi đông người, v.v..
CULTURE: hơi trừu tượng nhưng có thể hiểu là bao gồm tôn giáo, nền kinh tế, cơ cấu xã hội… ở một xã hội hiện đại thì thanh toán qua mobile sẽ dễ dàng được chấp nhận hơn, hoặc có những phần mềm iPhone viết ra chỉ để giúp những con chiên tụng kinh hàng ngày với những bản kinh thánh ghi âm sẵn.v.v…

Mobile context không quá phức tạp và rắc rối, nhưng trước khi nghĩ tới việc phần mềm iPhone bạn định làm sẽ có những tính năng gì, giao diện sẽ ra sao, màu sắc, bố cục menu, items thế nào… hãy nghĩ về nó trước, bởi đơn giản mobile context là địa điểm, là tần suất thời gian mà người dùng sẽ engage (gắn bó) với ứng dụng của bạn.