Công Ty Làm App

Khác với phần mềm chạy trên máy tính có kết nối ổn định, ứng dụng di động phải sống chung với một thực tế khắc nghiệt là mạng luôn chập chờn. Người dùng mở ứng dụng trong hầm gửi xe, trên tàu điện ngầm, ở vùng sóng yếu, hay đơn giản là khi gói cước đã hết dung lượng. Một ứng dụng chỉ hoạt động khi có mạng tốt sẽ khiến người dùng bực bội. Ngược lại, một ứng dụng vẫn dùng được khi ngoại tuyến tạo cảm giác chắc chắn và chuyên nghiệp. Bài viết này bàn về cách xây dựng trải nghiệm ngoại tuyến thực sự đáng tin cậy.

Ngoại tuyến không phải là tính năng phụ

Nhiều đội ngũ xem hỗ trợ ngoại tuyến là thứ làm thêm nếu còn thời gian. Cách nghĩ này dẫn đến việc chắp vá các bản vá rời rạc và không bao giờ ổn. Thực tế, khả năng ngoại tuyến cần được tính đến từ khâu thiết kế kiến trúc dữ liệu. Câu hỏi nền tảng là dữ liệu nào cần có sẵn khi mất mạng, thao tác nào người dùng được phép thực hiện khi ngoại tuyến, và điều gì xảy ra khi kết nối trở lại.

Khi đặt những câu hỏi này từ đầu, bạn sẽ thiết kế hệ thống xoay quanh dữ liệu cục bộ thay vì coi mạng là nguồn duy nhất. Đây là sự khác biệt căn bản giữa một ứng dụng mong manh và một ứng dụng vững vàng.

Cơ sở dữ liệu cục bộ làm nguồn sự thật hiển thị

Một mẫu kiến trúc mạnh mẽ là để giao diện luôn đọc dữ liệu từ cơ sở dữ liệu cục bộ trên máy, chứ không trực tiếp từ mạng. Khi cần dữ liệu mới, ứng dụng tải về và lưu vào cơ sở dữ liệu cục bộ, rồi giao diện tự cập nhật từ đó. Cách làm này mang lại hai lợi ích lớn. Thứ nhất, người dùng luôn thấy dữ liệu ngay lập tức, kể cả khi không có mạng. Thứ hai, giao diện không cần biết dữ liệu đến từ mạng hay từ bộ nhớ, giúp code đơn giản và nhất quán hơn.

Để làm tốt, bạn cần một chiến lược lưu đệm rõ ràng: dữ liệu nào được giữ bao lâu, khi nào coi là cũ và cần làm mới, và làm mới nền hay làm mới khi người dùng yêu cầu. Một bộ đệm không có chính sách hết hạn sẽ dần hiển thị thông tin lỗi thời, còn làm mới quá thường xuyên lại tốn pin và dữ liệu.

Xử lý thao tác ghi khi ngoại tuyến

Hiển thị dữ liệu khi ngoại tuyến tương đối dễ; cho phép người dùng thay đổi dữ liệu khi ngoại tuyến mới là phần khó. Khi người dùng tạo, sửa hay xóa trong lúc mất mạng, những thay đổi đó cần được xếp vào hàng đợi và gửi lên máy chủ khi có kết nối trở lại. Đồng thời, giao diện nên phản ánh thay đổi ngay lập tức để người dùng không phải chờ, một kỹ thuật thường gọi là cập nhật lạc quan.

Thử thách lớn nhất là xung đột. Nếu cùng một dữ liệu bị sửa ở hai nơi trong khi ngoại tuyến, ứng dụng phải quyết định bên nào thắng. Có nhiều chiến lược tùy bối cảnh:

• Lấy bản ghi mới nhất theo thời gian làm chuẩn, đơn giản nhưng có thể mất dữ liệu.
• Gộp thay đổi ở cấp trường thay vì cấp bản ghi, tinh tế hơn.
• Hỏi người dùng khi phát hiện xung đột thật sự không thể tự giải quyết.

Không có giải pháp đúng cho mọi trường hợp; điều quan trọng là chọn chiến lược có chủ đích thay vì để hệ thống xử lý ngẫu nhiên.

Giao tiếp trạng thái rõ ràng với người dùng

Một ứng dụng ngoại tuyến tốt không giấu trạng thái kết nối mà thể hiện nó một cách tinh tế. Người dùng nên biết khi nào họ đang xem dữ liệu cũ, khi nào thay đổi của họ chưa được đồng bộ, và khi nào mọi thứ đã được lưu an toàn lên máy chủ. Sự minh bạch này xây dựng lòng tin. Ngược lại, nếu người dùng tưởng đã lưu xong nhưng thực ra dữ liệu chỉ nằm trong hàng đợi và sau đó bị mất, họ sẽ mất niềm tin vào sản phẩm.

Những chỉ báo nhỏ như một biểu tượng đồng bộ đang quay, một dòng chữ cho biết lần cập nhật cuối, hay một thông báo nhẹ khi mất kết nối đều giúp người dùng hiểu chuyện gì đang diễn ra mà không gây hoang mang.

Tổng kết

Trải nghiệm ngoại tuyến đáng tin cậy là một trong những yếu tố phân biệt ứng dụng nghiệp dư với ứng dụng chuyên nghiệp. Nó đòi hỏi đặt dữ liệu cục bộ làm trung tâm, có chiến lược lưu đệm và đồng bộ rõ ràng, xử lý xung đột một cách có chủ đích, và giao tiếp trạng thái minh bạch với người dùng. Đầu tư vào những điều này không chỉ giúp ứng dụng dùng được khi mất mạng, mà còn khiến nó nhanh hơn và đáng tin hơn ngay cả khi mạng tốt.

Điện thoại ngày nay chứa gần như toàn bộ đời sống số của một người: tin nhắn, ảnh, thông tin tài chính, vị trí và thói quen. Vì vậy, ứng dụng di động trở thành mục tiêu hấp dẫn cho kẻ xấu, và một lỗ hổng bảo mật có thể gây hậu quả nghiêm trọng cho cả người dùng lẫn uy tín của doanh nghiệp. Bảo mật không phải là việc của riêng chuyên gia an ninh mà là trách nhiệm của mọi lập trình viên. Bài viết này trình bày những nguyên tắc thực hành căn bản mà bất kỳ đội ngũ nào cũng nên áp dụng.

Lưu trữ dữ liệu nhạy cảm đúng cách

Sai lầm phổ biến nhất là lưu thông tin nhạy cảm ở nơi không an toàn. Mật khẩu, mã thông báo đăng nhập hay khóa bí mật không bao giờ nên nằm trong các tệp cấu hình thông thường hay vùng lưu trữ không mã hóa, vì chúng có thể bị đọc nếu thiết bị bị can thiệp. Cả iOS và Android đều cung cấp kho lưu trữ an toàn được bảo vệ bởi phần cứng, và đây mới là nơi đúng để giữ những dữ liệu này.

Một nguyên tắc đi kèm là chỉ lưu những gì thật sự cần. Nếu bạn không cần lưu một thông tin nhạy cảm, đừng lưu nó. Dữ liệu không tồn tại trên thiết bị thì không thể bị đánh cắp. Việc giảm thiểu lượng dữ liệu nhạy cảm được giữ lại là một trong những biện pháp bảo mật đơn giản và hiệu quả nhất.

Bảo vệ dữ liệu khi truyền qua mạng

Mọi giao tiếp giữa ứng dụng và máy chủ phải được mã hóa bằng kết nối an toàn. Đây là điều tối thiểu, nhưng vẫn còn nhiều ứng dụng gửi dữ liệu qua kênh không mã hóa hoặc bỏ qua việc kiểm tra chứng chỉ. Với những ứng dụng xử lý dữ liệu rất nhạy cảm như ngân hàng hay y tế, có thể cân nhắc thêm lớp kiểm tra chứng chỉ chặt chẽ để chống lại các cuộc tấn công chen giữa, nơi kẻ tấn công cố giả mạo máy chủ.

Cũng cần lưu ý rằng dữ liệu nhạy cảm không nên xuất hiện trong nhật ký gỡ lỗi. Rất nhiều rò rỉ xảy ra không phải vì bị tấn công tinh vi, mà vì lập trình viên vô tình ghi mật khẩu hay mã thông báo vào log, rồi log đó bị lộ ra.

Xác thực và phân quyền vững chắc

Một quan niệm sai lầm nguy hiểm là tin rằng ứng dụng có thể tự bảo vệ bằng cách ẩn nút bấm hay kiểm tra quyền ở phía giao diện. Mọi kiểm tra quan trọng phải được thực hiện ở phía máy chủ, vì ứng dụng chạy trên thiết bị của người dùng và về nguyên tắc có thể bị can thiệp. Phía máy khách chỉ nên coi là tiện lợi cho trải nghiệm, còn ranh giới bảo mật thật sự nằm ở máy chủ.

Khi làm việc với phiên đăng nhập, cần quản lý vòng đời của mã thông báo cẩn thận: đặt thời gian hết hạn hợp lý, có cơ chế làm mới an toàn, và cho phép thu hồi khi người dùng đăng xuất hoặc khi nghi ngờ bị xâm phạm.

Quyền riêng tư và sự minh bạch

Bảo mật và quyền riêng tư đi đôi với nhau. Người dùng ngày càng quan tâm đến việc ứng dụng thu thập gì và dùng vào việc gì. Các nền tảng cũng siết chặt quy định, yêu cầu khai báo rõ ràng về dữ liệu thu thập. Một số nguyên tắc nên tuân thủ:

• Chỉ xin quyền truy cập khi thật sự cần và giải thích lý do rõ ràng.
• Thu thập lượng dữ liệu tối thiểu cần thiết cho tính năng.
• Minh bạch về cách dữ liệu được dùng và lưu trữ.
• Cho người dùng quyền xem và xóa dữ liệu của họ.
• Không chia sẻ dữ liệu với bên thứ ba ngoài những gì đã thông báo.

Bảo mật là quá trình liên tục

Một sai lầm về tư duy là xem bảo mật như một việc làm một lần rồi xong. Thực tế, các lỗ hổng mới liên tục được phát hiện, các thư viện bạn dùng có thể chứa điểm yếu, và kẻ tấn công luôn tìm cách mới. Vì vậy, cập nhật thư viện thường xuyên, theo dõi các cảnh báo bảo mật, và rà soát code định kỳ là việc phải làm liên tục.

Đầu tư vào bảo mật không mang lại tính năng hào nhoáng để khoe, nhưng nó bảo vệ điều quý giá nhất là lòng tin của người dùng. Một sự cố rò rỉ dữ liệu có thể xóa sạch nhiều năm xây dựng uy tín chỉ trong một đêm. Vì vậy, hãy coi bảo mật là một phần không thể tách rời của chất lượng sản phẩm, ngang hàng với hiệu năng và trải nghiệm người dùng.

Hoàn thành code chỉ là một nửa chặng đường. Đưa ứng dụng vượt qua quy trình duyệt của Apple và Google, rồi tồn tại lâu dài trên kho, là một thử thách riêng khiến không ít đội ngũ bất ngờ. Mỗi năm có vô số ứng dụng bị từ chối hoặc gỡ bỏ vì những lý do đáng lẽ có thể tránh được. Bài viết này giúp bạn hiểu cách hai kho ứng dụng lớn nhất vận hành và chuẩn bị để hành trình phát hành diễn ra suôn sẻ.

Hiểu khác biệt giữa hai kho

App Store của Apple nổi tiếng với quy trình duyệt thủ công nghiêm ngặt, nơi mỗi bản cập nhật đều có người thật xem xét. Điều này có nghĩa thời gian duyệt khó đoán hơn và tiêu chuẩn về chất lượng, giao diện cũng như tuân thủ chính sách thường cao hơn. Google Play có quy trình tự động nhiều hơn, thường nhanh hơn ở lần đầu, nhưng cũng dùng các hệ thống quét tự động có thể gắn cờ ứng dụng vì những lý do mà bạn cần thời gian để gỡ.

Hiểu sự khác biệt này giúp bạn lên kế hoạch phát hành thực tế. Đừng hứa với khách hàng một ngày ra mắt cố định nếu bạn chưa từng trải qua quy trình duyệt, vì một lần bị từ chối có thể kéo dài thêm nhiều ngày.

Những lý do bị từ chối phổ biến

Phần lớn lý do từ chối lặp đi lặp lại và hoàn toàn có thể phòng tránh. Một số trường hợp thường gặp:

• Ứng dụng bị lỗi hoặc treo ngay khi người duyệt mở lên, thường vì chỉ được thử trên một loại thiết bị.
• Thiếu hoặc mô tả không đúng về dữ liệu thu thập và quyền riêng tư.
• Xin quyền truy cập nhạy cảm mà không có lý do rõ ràng trong ứng dụng.
• Nội dung hoặc tính năng vi phạm chính sách của nền tảng.
• Giao diện sơ sài, trông như chưa hoàn thiện hoặc giống một trang web đóng gói vội.
• Liên kết hỏng, tài khoản thử nghiệm không hoạt động khiến người duyệt không vào được.

Một mẹo đơn giản nhưng quan trọng là cung cấp đầy đủ thông tin cho người duyệt: tài khoản đăng nhập thử, hướng dẫn dùng các tính năng đặc biệt, và giải thích những gì có thể gây hiểu nhầm. Người duyệt có thiện chí hơn nhiều khi họ hiểu rõ ứng dụng làm gì.

Chuẩn bị trang giới thiệu hấp dẫn

Vượt qua khâu duyệt mới chỉ là để được xuất hiện; còn việc người dùng có tải về hay không lại phụ thuộc vào trang giới thiệu. Ảnh chụp màn hình, mô tả và biểu tượng là những yếu tố đầu tiên người dùng nhìn thấy. Ảnh chụp nên thể hiện rõ giá trị cốt lõi của ứng dụng trong vài hình đầu tiên, vì đa số người dùng không cuộn xa. Mô tả nên viết cho con người đọc trước, rồi mới tính đến từ khóa tìm kiếm.

Biểu tượng ứng dụng đáng được đầu tư đặc biệt vì nó nhỏ nhưng xuất hiện ở mọi nơi. Một biểu tượng rõ ràng, dễ nhận diện ở kích thước nhỏ sẽ tạo lợi thế so với những biểu tượng rối rắm hay quá nhiều chi tiết.

Quản lý cập nhật và phiên bản

Phát hành không phải là điểm kết thúc mà là điểm bắt đầu của một chu kỳ dài. Bạn sẽ liên tục sửa lỗi, thêm tính năng và phải đưa các bản cập nhật qua quy trình duyệt nhiều lần. Một chiến lược tốt là phát hành dần dần, tung bản cập nhật cho một phần nhỏ người dùng trước để theo dõi xem có sự cố gì bất thường không, rồi mới mở rộng ra toàn bộ. Cách này giúp hạn chế thiệt hại nếu một bản cập nhật có lỗi nghiêm trọng.

Cũng nên thiết lập kênh thu thập phản hồi và báo cáo sự cố tự động, để bạn biết ứng dụng hoạt động ra sao trên hàng nghìn thiết bị thật mà bạn không thể tự kiểm tra hết. Những công cụ này giúp bạn phát hiện vấn đề trước khi nó lan thành làn sóng đánh giá tiêu cực.

Tổng kết

Phát hành ứng dụng là một kỹ năng riêng, không kém phần quan trọng so với việc viết code. Hiểu cách mỗi kho vận hành, phòng tránh những lý do từ chối quen thuộc, chuẩn bị trang giới thiệu chỉn chu và quản lý cập nhật một cách thận trọng sẽ giúp bạn tiết kiệm rất nhiều thời gian và bực bội. Hãy coi quy trình duyệt là một người gác cổng có lý do, và chuẩn bị kỹ để vượt qua nó một cách tự tin ngay từ lần đầu.

Mỗi lần nhấn nút phát hành một bản cập nhật, đội ngũ phát triển đều đặt cược vào niềm tin rằng họ không làm hỏng thứ gì đang chạy tốt. Khi không có một quy trình kiểm thử bài bản, niềm tin đó chỉ là hy vọng. Trên di động, hậu quả của một lỗi lọt lưới còn nặng nề hơn web, vì người dùng phải tải bản vá và đánh giá xấu rất khó gỡ bỏ. Bài viết này trình bày cách xây dựng một chiến lược kiểm thử cân bằng, thực tế và giúp bạn phát hành với sự tự tin.

Tháp kiểm thử và sự cân bằng

Một cách tư duy hữu ích là hình dung kiểm thử như một kim tự tháp. Ở đáy là số lượng lớn các kiểm thử đơn vị, kiểm tra từng mẩu logic nhỏ một cách độc lập. Chúng chạy rất nhanh, dễ viết và cho phản hồi tức thì khi có gì hỏng. Ở giữa là các kiểm thử tích hợp, kiểm tra nhiều thành phần làm việc cùng nhau. Trên cùng là số ít kiểm thử giao diện đầu cuối, mô phỏng người dùng thật thao tác qua các màn hình.

Sự cân bằng này quan trọng vì mỗi loại có chi phí và giá trị khác nhau. Kiểm thử giao diện đầu cuối gần với trải nghiệm thật nhất nhưng chạy chậm, dễ vỡ và tốn công bảo trì. Nếu dồn quá nhiều vào tầng này, bộ kiểm thử sẽ trở nên chậm chạp và hay báo lỗi giả, khiến cả nhóm dần bỏ qua nó. Ngược lại, một nền tảng vững chắc các kiểm thử đơn vị giúp bắt phần lớn lỗi sớm với chi phí thấp.

Kiểm thử cái gì là đáng giá nhất

Không thể và cũng không nên kiểm thử mọi thứ. Mục tiêu là tập trung công sức vào nơi rủi ro cao nhất. Những phần xứng đáng được kiểm thử kỹ thường là:

• Logic nghiệp vụ cốt lõi, nơi một lỗi gây hậu quả nghiêm trọng.
• Các phép tính liên quan đến tiền bạc, ngày tháng hay quyền hạn.
• Những phần đã từng có lỗi trong quá khứ, vì chúng dễ tái phát.
• Các luồng quan trọng như đăng nhập, thanh toán hay gửi dữ liệu.
• Những đoạn xử lý trường hợp biên dễ bị bỏ sót khi viết tay.

Ngược lại, viết kiểm thử cho những đoạn code đơn giản, ít thay đổi và rủi ro thấp thường tốn công hơn giá trị nó mang lại. Kiểm thử là một khoản đầu tư, và như mọi khoản đầu tư, nó cần được phân bổ khôn ngoan.

Thử thách riêng của thiết bị di động

Kiểm thử ứng dụng di động khó hơn web ở chỗ sự phân mảnh thiết bị rất lớn. Hàng nghìn kiểu máy với kích thước màn hình, phiên bản hệ điều hành và năng lực phần cứng khác nhau. Một ứng dụng chạy hoàn hảo trên máy của lập trình viên có thể lỗi nặng trên một dòng máy phổ thông đời cũ. Vì vậy, kiểm thử trên nhiều cấu hình thiết bị, kể cả máy yếu, là điều không thể bỏ qua.

Bên cạnh đó còn vô số tình huống đặc thù di động cần được thử: ứng dụng bị gián đoạn bởi cuộc gọi đến, xoay màn hình, mất mạng giữa chừng, hệ điều hành thu hồi bộ nhớ khi ứng dụng ở nền, hay người dùng từ chối cấp quyền. Những kịch bản này hiếm khi được nghĩ đến khi viết code nhưng lại là nguồn lỗi thực tế rất phổ biến.

Tự động hóa và kiểm thử thủ công bổ trợ nhau

Kiểm thử tự động rất mạnh nhưng không thay thế hoàn toàn được con mắt con người. Tự động hóa giỏi trong việc bắt các lỗi hồi quy, tức là những thứ từng chạy đúng nay bị hỏng, và làm điều đó nhanh, lặp lại được mà không biết mệt. Tuy nhiên, nó khó đánh giá được cảm giác của trải nghiệm, sự mượt mà của hoạt ảnh, hay liệu một bố cục có thật sự dễ dùng hay không.

Vì vậy, một quy trình lành mạnh kết hợp cả hai. Tự động hóa lo phần kiểm tra lặp lại và bảo vệ chống hồi quy, còn kiểm thử thủ công khám phá tập trung vào trải nghiệm tổng thể và những tình huống bất ngờ mà không kịch bản tự động nào lường hết. Bên cạnh đó, đưa bản thử nghiệm đến tay một nhóm người dùng thật trước khi phát hành rộng rãi cũng giúp lộ ra những vấn đề mà cả đội ngũ lẫn máy móc đều bỏ sót.

Tổng kết

Kiểm thử bài bản không phải là viết thật nhiều kiểm thử cho có, mà là đầu tư đúng chỗ để giảm rủi ro một cách thông minh. Một tháp kiểm thử cân bằng, tập trung vào những phần quan trọng nhất, chú ý đến đặc thù phân mảnh của di động, và kết hợp hài hòa giữa tự động và thủ công sẽ cho bạn thứ quý giá nhất: khả năng phát hành thường xuyên mà không nơm nớp lo sợ. Đó chính là nền tảng để một sản phẩm di động phát triển nhanh và bền vững.

Một ứng dụng có thể được xây dựng bằng công nghệ tốt nhất, kiến trúc sạch sẽ và không một lỗi, nhưng vẫn thất bại nếu người dùng cảm thấy khó dùng. Trên màn hình nhỏ của điện thoại, nơi người ta thao tác bằng ngón tay, thường trong lúc vội vã hay phân tâm, thiết kế giao diện đòi hỏi một tư duy rất khác so với phần mềm máy tính. Bài viết này bàn về những nguyên tắc thiết kế giúp ứng dụng di động trở nên trực quan, dễ chịu và tôn trọng người dùng.

Thiết kế cho ngón tay, không phải con trỏ chuột

Khác biệt nền tảng đầu tiên là người dùng di động chạm bằng ngón tay chứ không trỏ chính xác bằng chuột. Đầu ngón tay che một vùng khá lớn và không nhắm chính xác như con trỏ, nên các nút bấm và vùng chạm cần đủ rộng và cách nhau đủ xa để tránh bấm nhầm. Những nút quan trọng nên đặt ở vùng dễ với tới của ngón cái, đặc biệt khi nhiều người dùng điện thoại bằng một tay.

Kích thước màn hình hạn chế cũng buộc người thiết kế phải tàn nhẫn trong việc ưu tiên. Không thể nhồi nhét mọi thứ lên một màn hình. Mỗi màn hình nên có một mục đích chính rõ ràng, và mọi yếu tố khác phải nhường chỗ cho mục đích đó. Sự đơn giản không phải là thiếu sót mà là kết quả của những lựa chọn khó khăn về điều gì thật sự quan trọng.

Giảm tải nhận thức cho người dùng

Người dùng di động thường không dành toàn bộ sự chú ý cho ứng dụng. Họ vừa đi vừa dùng, hay xen kẽ với việc khác. Vì vậy, giao diện càng đòi hỏi suy nghĩ ít càng tốt. Một nguyên tắc quý giá là đừng bắt người dùng phải ghi nhớ; thay vào đó, hãy hiển thị thông tin họ cần ngay khi họ cần. Ví dụ, thay vì bắt nhớ một mã từ màn hình trước, hãy hiển thị lại nó ở nơi cần dùng.

Sự nhất quán cũng giảm tải nhận thức đáng kể. Khi cùng một hành động luôn nằm ở cùng một chỗ và trông giống nhau xuyên suốt ứng dụng, người dùng học cách dùng một lần và áp dụng được khắp nơi. Mỗi lần phá vỡ quy ước là một lần bắt người dùng phải học lại, và điều đó gây mệt mỏi.

Phản hồi tức thì cho mọi hành động

Một giao diện tốt luôn cho người dùng biết điều gì đang xảy ra. Khi người dùng chạm một nút, phải có phản hồi ngay lập tức, dù chỉ là một thay đổi màu nhỏ, để xác nhận hệ thống đã nhận lệnh. Khi một tác vụ cần thời gian, phải có dấu hiệu cho thấy ứng dụng đang làm việc chứ không phải bị treo. Sự im lặng khiến người dùng bối rối và thường dẫn đến việc bấm đi bấm lại, gây thêm lỗi.

Duoc nhieu nguoi tin dung la Cakhia.

Một số dạng phản hồi nên được chăm chút:

• Xác nhận tức thì khi chạm vào một phần tử tương tác.
• Chỉ báo tiến trình rõ ràng cho các tác vụ kéo dài.
• Thông báo lỗi cụ thể, dễ hiểu và gợi ý cách khắc phục.
• Xác nhận nhẹ nhàng khi một hành động quan trọng hoàn tất.
• Trạng thái rỗng có hướng dẫn thay vì màn hình trống trơn.

Thiết kế cho cả những người dễ bị bỏ quên

Khả năng tiếp cận thường bị xem nhẹ nhưng là dấu hiệu của một sản phẩm trưởng thành. Nhiều người dùng có thị lực kém cần chữ lớn hơn, người khiếm thị dùng trình đọc màn hình, và không ít người gặp khó khăn khi phân biệt một số cặp màu. Thiết kế có độ tương phản tốt, hỗ trợ phóng to chữ, và đặt nhãn rõ ràng cho các phần tử không chỉ giúp nhóm người này mà còn làm ứng dụng tốt hơn cho tất cả mọi người.

Đáng nói là phần lớn cải thiện về khả năng tiếp cận không tốn kém nếu được tính đến từ đầu, nhưng lại rất đắt nếu phải sửa sau khi sản phẩm đã hoàn thiện. Vì vậy, đưa nó vào tư duy thiết kế ngay từ những bản phác thảo đầu tiên là cách làm khôn ngoan.

Tổng kết

Thiết kế giao diện di động tốt không phải là làm cho ứng dụng đẹp mắt, mà là làm cho nó dễ dùng đến mức người dùng gần như không nhận ra mình đang dùng nó. Điều đó đòi hỏi tôn trọng giới hạn của ngón tay và màn hình nhỏ, giảm tối đa gánh nặng suy nghĩ, phản hồi rõ ràng cho mọi hành động, và quan tâm đến những người dùng dễ bị bỏ quên. Khi đặt con người làm trung tâm thay vì tính năng, bạn tạo ra những sản phẩm mà người ta không chỉ dùng được mà còn muốn quay lại.