Cách xây dựng cổng thông tin dịch vụ công

Xác định mục tiêu, đối tượng và chỉ số thành công

Một cổng dịch vụ công không thể là “mọi thứ cho mọi người” ngay từ ngày đầu. Bắt đầu bằng cách viết một tuyên bố mục đích rõ ràng vừa đủ trên một trang, có thể đọc được bởi bộ phận đấu thầu, ban lãnh đạo và nhân viên tuyến đầu.

Làm rõ cổng được tạo ra để làm gì

Quyết định xem cổng chủ yếu là:

• Thông tin (chính sách, điều kiện, giờ làm việc, yêu cầu)
• Giao dịch (đơn đăng ký, thanh toán, đặt lịch, kiểm tra trạng thái)
• Cả hai, với một tập dịch vụ ưu tiên rõ ràng cho lần ra mắt

Quyết định này ảnh hưởng đến mọi thứ tiếp theo — từ cấu trúc nội dung đến xác thực danh tính và hỗ trợ.

Đặt tên cho các đối tượng chính (và nhu cầu của họ)

Liệt kê các nhóm chính và những nhiệm vụ hàng đầu họ phải hoàn thành:

• Cư dân: tìm trợ cấp, gia hạn giấy tờ, báo cáo sự cố
• Khách: giấy phép, thông tin giao thông, an toàn
• Doanh nghiệp: cấp phép, hướng dẫn thuế, bước tuân thủ
• Nhân viên nội bộ: cập nhật nội dung, phân loại yêu cầu, quản lý thay đổi dịch vụ

Giữ thực tế: đối tượng được định nghĩa bởi những gì họ cố gắng làm, không phải bởi nhân khẩu học.

Chọn chỉ số thành công bạn thực sự có thể theo dõi

Đồng ý một tập nhỏ kết quả có thể đo lường, chẳng hạn:

• Tỷ lệ hoàn thành nhiệm vụ cho các hành trình hàng đầu (ví dụ: “nộp đơn xin giấy phép đỗ xe”)
• Giảm cuộc gọi và đến trực tiếp cho các câu hỏi cổng nên trả lời
• Thời gian để xuất bản cập nhật (ví dụ: thông báo khẩn, thay đổi chính sách)
• Thành công tìm kiếm (người dùng tìm được trang đúng mà không cần tìm lại nhiều lần)

Lên kế hoạch cách bạn sẽ đo lường chúng (phân tích, lời nhắc phản hồi ngắn, gắn thẻ tổng đài).

Ghi nhận các ràng buộc sớm

Ghi lại những thực tế ảnh hưởng phạm vi:

• Ngân sách và tiến độ (bao gồm phê duyệt)
• Quy định đấu thầu và yêu cầu nhà cung cấp
• Nhu cầu pháp lý/tuân thủ và các bước rà soát nội bộ

Một bản tóm tắt mục tiêu và chỉ số đơn giản sẽ là điểm tham chiếu khi các ưu tiên cạnh tranh sau này — và giữ dự án tập trung vào giá trị công cộng.

Nghiên cứu những gì người dân cần làm trên site

Cổng dịch vụ công tốt bắt đầu bằng sự rõ ràng: người dùng đến để thực hiện điều gì? Nếu bạn thiết kế theo phòng ban nội bộ, bạn sẽ buộc cư dân phải dịch thuật quan liêu thành ý định đơn giản. Nghiên cứu giúp bạn lật ngược điều đó.

Bắt đầu với các tín hiệu cầu hỏi thực tế

Bắt đầu bằng cách thu thập “nhiệm vụ hàng đầu” từ các nguồn bạn đã có:

• Nhật ký trung tâm cuộc gọi và quầy tiếp tân (lý do liên hệ, câu hỏi lặp lại)
• Các truy vấn tìm kiếm trên site và tìm kiếm không kết quả
• Khảo sát ngắn sau tương tác dịch vụ (trực tuyến và trực tiếp)

Tìm các mẫu như “gia hạn”, “nộp”, “thanh toán”, “báo cáo”, và “kiểm tra trạng thái”. Những động từ này sau đó sẽ định hình nhãn điều hướng, trang đích và luồng biểu mẫu.

Lập bản đồ hành trình cho các dịch vụ có tác động cao

Chọn một vài dịch vụ ưu tiên (ví dụ: giấy phép, trợ cấp, thanh toán) và lập bản đồ hành trình từ góc nhìn người dùng. Bao gồm:

• Điều gì kích hoạt nhu cầu (sự kiện cuộc đời, hạn chót, thông báo)
• Thông tin họ phải thu thập
• Nơi họ bị vướng (điều kiện đủ, tài liệu, kiểm tra danh tính)
• “Hoàn thành” nghĩa là gì (xác nhận, biên lai, thời gian xử lý, bước tiếp theo)

Điều này ngăn cổng chỉ giải thích chính sách mà không giúp người dân hoàn tất nhiệm vụ.

Tạo personas tập trung vào nhu cầu

Giữ personas đơn giản và thực tiễn: “Người lần đầu nộp đơn xin trợ giúp”, “Chủ doanh nghiệp nhỏ trả lệ phí”, “Cư dân hạn chế tiếng Anh”. Tập trung vào các ràng buộc (thời gian, căng thẳng, thiết bị, trình độ đọc, nhu cầu truy cập) hơn là nhân khẩu học.

Xác thực nhanh trước khi cam kết

Thực hiện phỏng vấn ngắn hoặc kiểm thử khả dụng nhẹ với prototype hoặc thậm chí bản phác thảo. Yêu cầu người tham gia hoàn thành các nhiệm vụ chính và tường thuật mong đợi của họ. Bạn sẽ phát hiện thuật ngữ gây nhầm lẫn, bước thiếu và vấn đề tin cậy sớm — trước khi nội dung và phần xây dựng cứng lại thành việc chỉnh sửa tốn kém.

Lên kế hoạch kiến trúc thông tin và điều hướng

Một cổng dịch vụ công thành công khi người dân tìm thấy điều họ cần nhanh — ngay cả khi họ không biết bộ phận nào chịu trách nhiệm. Kiến trúc thông tin (IA) là “bản đồ” của site: nội dung gì tồn tại, nhóm thế nào và người dùng di chuyển ra sao.

Bắt đầu với một kiểm kê nội dung trung thực

Trước khi vẽ menu, thu thập những gì bạn đã có:

• Trang web hiện có, microsite và trang chiến dịch
• PDF, biểu mẫu tải về và tài liệu quét
• Mô tả dịch vụ, luật điều kiện, phí và thời gian xử lý

Gắn thẻ từng mục bằng metadata cơ bản (chủ đề, đối tượng, loại dịch vụ, lần cập nhật, đội chịu trách nhiệm). Điều này ngăn việc xây lại những trang đã có — và làm nổi bật nơi nội dung cũ hoặc trùng lặp.

Tổ chức theo nhiệm vụ người dùng, không theo sơ đồ tổ chức

Hầu hết cư dân đến với một ý định: “gia hạn giấy phép”, “nộp đơn xin trợ cấp”, “báo cáo sự cố”. Cấu trúc các danh mục xung quanh những nhiệm vụ đó thay vì tên cơ quan. Bài kiểm tra đơn giản: nếu ai đó không thể đoán được mục menu đúng mà không biết cấu trúc chính quyền, thì nhóm cần điều chỉnh.

Khi nhiều cơ quan đóng góp cho cùng một hành trình, xử lý nó như một dịch vụ duy nhất với các bước rõ ràng. Liên kết tới các trang hỗ trợ (yêu cầu, tài liệu cần, liên hệ) từ một hub dịch vụ duy nhất.

Làm cho điều hướng ngắn và đáng dự đoán

Hướng tới các dịch vụ chính trong 2–3 lần nhấp từ trang chủ. Dùng một tập nhỏ danh mục cấp cao, kèm các lối tắt nổi bật cho nhiệm vụ nhu cầu lớn. Tránh “mega menu” đầy thuật ngữ nội bộ; dùng nhãn rõ ràng mà người ta sẽ đọc to ra được.

Thiết kế tìm kiếm như một dịch vụ công, không chỉ một tính năng website

Tìm kiếm thường trở thành điều hướng chính. Lập kế hoạch cho nó một cách có chủ ý:

• Bộ lọc người dùng mong đợi (vị trí, loại dịch vụ, điều kiện, sự kiện cuộc đời)
• Đồng nghĩa và cách diễn đạt phổ biến (ví dụ: “thu gom rác” vs “thu gom chất thải”)\
• Hướng dẫn hữu ích khi “không có kết quả” (từ gợi ý, dịch vụ phổ biến)

Khi làm tốt, IA và điều hướng của bạn giảm cuộc gọi, khiếu nại và rớt trang — đồng thời làm cho cổng cảm thấy điềm tĩnh và đáng tin cậy.

Thiết kế cho khả năng truy cập và sử dụng bao trùm

Khả năng truy cập không phải là “thêm” cho website chính phủ — nó là một phần của việc cung cấp quyền truy cập công bằng vào dịch vụ. Hướng tới đáp ứng WCAG (thường là WCAG 2.2 AA) và coi khả năng truy cập như một yêu cầu thiết kế, không chỉ là kiểm tra cuối cùng.

Bắt đầu với cấu trúc mà con người (và công cụ) có thể hiểu

Dùng cấu trúc trang rõ ràng: một tiêu đề chính (H1), các tiêu đề phụ hợp lý (H2/H3), và văn bản liên kết mô tả (tránh “click here”). Điều hướng nhất quán và bố cục trang dự đoán giúp mọi người, bao gồm người dùng có khó khăn nhận thức và người dùng trình đọc màn hình.

Làm cho việc đọc dễ dàng: chọn màu tương phản cao, giữ độ dài dòng thoải mái và tránh chữ quá nhỏ. Phần tử tương tác nên có trạng thái focus nhất quán để người dùng bàn phím luôn biết họ đang ở đâu.

Kiểm tra với công nghệ hỗ trợ thực tế

Các kiểm tra tự động hữu ích nhưng không bắt được mọi thứ. Bao gồm kiểm thử thủ công như một phần của định nghĩa hoàn thành:

• Điều hướng các hành trình chính chỉ bằng bàn phím (không dùng chuột)
• Thử với trình đọc màn hình (ví dụ NVDA, JAWS, VoiceOver)
• Kiểm tra zoom ở 200% và reflow trên mobile

Viết bằng ngôn ngữ đơn giản

Thiết kế bao trùm cũng là về từ ngữ. Dùng ngôn ngữ đơn giản, giải thích các bước cần thiết, tránh biệt ngữ và từ viết tắt không giải thích. Nếu cần dùng thuật ngữ chuyên môn (ví dụ, một thuật ngữ pháp lý), giải nghĩa ngay tại chỗ.

Biểu mẫu phải truy cập được từ đầu đến cuối

Biểu mẫu thường là nơi người dùng bị vướng. Đảm bảo mỗi trường có nhãn hiển thị, văn bản trợ giúp rõ ràng nơi dễ gây nhầm lẫn và thông báo lỗi cụ thể được thông báo tới công nghệ hỗ trợ (ví dụ, “Nhập số BHXH” thay vì “Dữ liệu không hợp lệ”). Không chỉ dùng màu để chỉ lỗi.

Công bố tuyên bố khả năng truy cập và đường dẫn phản hồi

Thêm một tuyên bố khả năng truy cập giải thích trạng thái tuân thủ, các vấn đề đã biết và các tùy chọn liên hệ để báo cáo sự cố. Đặt nó ở footer dưới một liên kết nhất quán (ví dụ /accessibility) và đảm bảo kênh phản hồi được giám sát và trả lời.