Chủ đề 3.2 — Hệ thống thiết kế và tạo mẫu

Một hệ thống thiết kế biến các quyết định thiết kế tốt thành hạ tầng dùng chung, tái sử dụng được — để khả năng tiếp cận, an toàn lâm sàng và sự nhất quán được xây vào một lần rồi thừa hưởng ở mọi nơi, thay vì bị tranh cãi lại và làm hỏng lại trên từng màn hình.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Trong y tế và chăm sóc, giao diện thường là vài xentimét cuối cùng giữa một quyết định lâm sàng và một bệnh nhân. Một ô nhập thuốc gây nhầm lẫn, một bộ chọn ngày không thể tiếp cận, một nút có nghĩa là "hủy cuộc hẹn" ở dịch vụ này và "hủy và mất dữ liệu của bạn" ở dịch vụ khác — đây không phải vấn đề thẩm mỹ. Chúng là vấn đề an toàn bệnh nhân, vấn đề công bằng và vấn đề niềm tin. Khi mỗi nhóm tự thiết kế các thành phần của mình từ đầu, lỗi nhân lên và các bảo đảm an toàn trở nên không thể lập luận được trên một danh mục.

Một hệ thống thiết kế là cách bạn ngừng trả giá cho cùng những sai lầm lặp đi lặp lại. Khi một thành phần dễ tiếp cận, được kiểm thử tốt được xây một lần và tái sử dụng qua hàng chục dịch vụ, bạn sửa một lỗi khả năng tiếp cận hay một sự mơ hồ về an toàn ở một nơi và mọi dịch vụ thừa hưởng bản sửa. Phương án thay thế — giao diện người dùng đặt riêng ở mọi nơi — nghĩa là chất lượng không rõ, không đồng đều: một số dịch vụ đáp ứng Hướng dẫn Khả năng Tiếp cận Nội dung Web (WCAG) và một số lặng lẽ loại trừ chính những người phụ thuộc nhiều nhất vào các dịch vụ y tế công.

Sự nhất quán cũng là vấn đề về khả năng hiểu. Bệnh nhân và nhân viên di chuyển giữa các dịch vụ — một ứng dụng của Dịch vụ Y tế Quốc gia (NHS), một cổng ngoại trú của bệnh viện, một công cụ đặt lịch của phòng khám bác sĩ gia đình — và mỗi mô thức xa lạ đặt ra tải nhận thức. Trong một quần thể gồm những người đang ốm, lo lắng, lớn tuổi, bị loại trừ số, hay dùng công nghệ hỗ trợ, tải đó không được phân bố đều. Các mô thức dùng chung làm giảm nó cho mọi người. Chủ đề này nói về bộ máy — thành phần, mô thức, token, nguyên mẫu và vận hành thiết kế — làm cho thiết kế an toàn, dễ tiếp cận, nhất quán trở thành con đường ít kháng cự nhất thay vì một hành động anh hùng.

Các khái niệm cốt lõi#

Một hệ thống thiết kế là một nguồn sự thật duy nhất cho các thành phần, mô thức, kiểu dáng và hướng dẫn tái sử dụng được dùng để xây dựng một tập các dịch vụ số. Nó không chỉ là một hướng dẫn phong cách: nó ghép các thành phần được mã hóa, đang hoạt động với lý do thiết kế, ghi chú khả năng tiếp cận và hướng dẫn sử dụng cho bạn biết khi nào và cách nào dùng từng cái. Hai ví dụ công khai liên quan nhất là hệ thống thiết kế NHS (do NHS England duy trì, xây trên giao diện người dùng NHS.UK) và Hệ thống Thiết kế GOV.UK, do Dịch vụ Số của Chính phủ (GDS) duy trì. Cả hai đều mở, miễn phí và đã được thử lửa qua hàng triệu tương tác.

Một thư viện thành phần chứa các khối xây dựng rời rạc — nút, ô nhập biểu mẫu, đầu trang, tóm tắt lỗi — trong khi một thư viện mô thức chứa các giải pháp bậc cao cho các vấn đề lặp lại: cách hỏi ngày sinh, cách cấu trúc một trang câu hỏi, cách báo lỗi, cách hỏi người dùng số NHS của họ. Thành phần là từ vựng; mô thức là các câu. Cả hai dựa trên kỹ thuật phần mềm dựa trên thành phần, nơi các hệ thống được lắp ráp từ những bộ phận ghép lỏng, kiểm thử độc lập, tái sử dụng được.

Design token là những quyết định dùng chung nhỏ nhất được thể hiện dưới dạng biến có tên — một màu, một đơn vị khoảng cách, một cỡ chữ, một đường viền trạng thái tiêu điểm. Vì token được tham chiếu bằng tên thay vì mã hóa cứng, một thay đổi với một token (ví dụ tăng kích thước vùng chạm tối thiểu hoặc độ tương phản) lan truyền nhất quán đến mọi thành phần dùng nó. Token là cơ chế giữ cho một hệ thống mạch lạc khi mở rộng, và làm cho có thể đặt chủ đề cho một hệ thống dùng chung để dùng tại địa phương mà không cần tách nhánh.

Một nguồn sự thật duy nhất là ý tưởng chi phối: mỗi quyết định thiết kế được làm chủ ở đúng một nơi, nên nó không thể trôi lệch khỏi đồng bộ giữa các dịch vụ. Khi thiết kế, mã và hướng dẫn cho một thành phần cùng nằm trong một thư viện có thẩm quyền, bạn loại bỏ cả lớp lỗi nơi hình ảnh và sản phẩm mâu thuẫn nhau.

Tạo mẫu phần mềm là thực hành xây các phiên bản cố ý chưa hoàn chỉnh của một dịch vụ để học điều gì đó trước khi bạn cam kết xây thứ thật. Nguyên mẫu trải từ độ trung thực thấp (phác thảo trên giấy, khung dây thang xám) đến độ trung thực cao (tương tác, thực tế, thường được xây bằng mã). Nguyên tắc GDS là tạo mẫu để học, không phải để giữ: nhiệm vụ của một nguyên mẫu là trả lời một câu hỏi thông qua kiểm thử khả năng sử dụng với người dùng thật, sau đó nó bị vứt bỏ — đây là tạo mẫu dùng-một-lần (hay "nhanh"), khác với một nguyên mẫu tiến hóa mà bạn định củng cố thành sản phẩm vận hành.

DesignOps (vận hành thiết kế) là ngành vận hành thiết kế ở quy mô lớn — con người, quy trình, quản trị, mô hình đóng góp và công cụ giữ cho một hệ thống thiết kế dùng chung khỏe mạnh, được tài trợ và đáng tin trên một tổ chức hay hệ thống chăm sóc tích hợp (ICS). Nó đối với thiết kế như kỹ thuật nền tảng đối với mã: hầu như vô hình khi hoạt động, rõ mồn một khi không. Tạo mẫu được thực hiện trong các công cụ thiết kế như Figma hoặc trực tiếp bằng mã sử dụng giao diện người dùng của một hệ thống thiết kế, dẫn chúng ta đến phát triển web phía giao diện — tầng HTML, CSS và JavaScript nơi tái sử dụng thực sự giảm trùng lặp, chi phí và rủi ro.

Chủ đề này cố ý không đề cập lại người dùng cần gì (xem Chủ đề 3.0 — Nghiên cứu người dùng và thiết kế dịch vụ) hay từ ngữ được viết ra sao (xem Chủ đề 3.1 — Thiết kế nội dung và hiểu biết về sức khỏe). Các ngành đó nuôi hệ thống thiết kế; chủ đề này nói về bộ máy tái sử dụng được mang kết luận của chúng một cách an toàn vào vận hành.

Thực hành tốt nhất#

1. Áp dụng trước khi xây. Bắt đầu từ hệ thống thiết kế NHS và Hệ thống Thiết kế GOV.UK thay vì tự phát minh. Chúng đã mã hóa nhiều năm kiểm thử khả năng tiếp cận, thiết kế nội dung và sử dụng thực tế qua các dịch vụ y tế và chính phủ. Phát minh lại một bộ chọn ngày hay tóm tắt lỗi không phải cách dùng tốt năng lực thiết kế và kỹ thuật khan hiếm, đắt đỏ, và một phiên bản tự chế gần như chắc chắn kém dễ tiếp cận hơn. Mở rộng và đặt chủ đề cho các hệ thống này theo nhu cầu địa phương; đừng tách nhánh chúng nếu không có lý do có chủ đích, được ghi chép.

2. Xây khả năng tiếp cận và an toàn lâm sàng vào các thành phần dùng chung, không phải từng màn hình riêng. Toàn bộ lập luận kinh tế và an toàn cho một hệ thống thiết kế là bạn sửa một thứ một lần và thừa hưởng nó ở mọi nơi. Một thành phần ngày sinh dễ tiếp cận, điều hướng được bằng bàn phím, được kiểm thử bằng trình đọc màn hình, được xây và đảm bảo một lần, bảo vệ mọi dịch vụ dùng nó. Đưa sự tuân thủ WCAG, xử lý lỗi hợp lý và các hành vi liên quan an toàn (xác nhận rõ ràng các hành động phá hủy, đơn vị không mơ hồ cho liều lượng và số đo) vào chính thành phần, để các nhóm không dễ làm sai (xem Chủ đề 1.9 — Hòa nhập số và khả năng tiếp cận, và Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro).

3. Tạo mẫu để học, không phải để giữ. Xem nguyên mẫu là các thí nghiệm dùng-một-lần trả lời một câu hỏi cụ thể — "một bệnh nhân có hiểu biết sức khỏe thấp có thể hoàn thành chuyển tuyến này không?" — một cách rẻ và nhanh. Điều chỉnh độ trung thực theo câu hỏi: dùng phác thảo độ trung thực thấp để kiểm thử luồng và khả năng hiểu sớm, và nguyên mẫu mã hóa độ trung thực cao để kiểm thử tương tác thực tế, khả năng tiếp cận và các trường hợp biên về sau. Cưỡng lại sức kéo đưa thẳng một nguyên mẫu vào sản phẩm; mã nguyên mẫu tối ưu cho tốc độ học hiếm khi đủ an toàn, bảo mật hay dễ bảo trì cho một dịch vụ lâm sàng đang chạy.

4. Tạo mẫu trong giao diện người dùng thật khi tương tác và khả năng tiếp cận là câu hỏi. Các nguyên mẫu trong công cụ thiết kế (Figma và tương tự) rất tuyệt để khám phá bố cục, luồng và nội dung nhanh và cộng tác. Nhưng chúng không thể kiểm thử trung thực điều hướng bàn phím, hành vi trình đọc màn hình, quản lý tiêu điểm hay hiệu năng trên phần cứng cũ của hệ thống NHS. Khi đó là những rủi ro, hãy tạo mẫu bằng mã dùng giao diện người dùng của hệ thống thiết kế, để bạn đang kiểm thử thứ gần với điều người dùng thật sẽ trải nghiệm với công nghệ hỗ trợ thật (xem Chủ đề 3.7 — Kiểm thử và đảm bảo chất lượng).

5. Kiểm thử nguyên mẫu với người dùng thật trước khi xây. Một nguyên mẫu chưa bao giờ được đặt trước người dùng đại diện chỉ là một ý kiến đắt tiền. Kiểm thử với những người phản ánh quần thể thực của bạn — gồm người lớn tuổi, người khuyết tật, người ít tự tin về số, và nhân viên làm việc dưới áp lực thời gian. Ngay cả năm người tham gia cũng sẽ làm lộ phần lớn các vấn đề nghiêm trọng về khả năng sử dụng và hiểu, và tìm chúng trong một nguyên mẫu rẻ hơn hàng bậc độ lớn so với tìm trong vận hành.

6. Quản lý token như hợp đồng cho sự nhất quán. Diễn đạt màu, khoảng cách, kiểu chữ và trạng thái tương tác dưới dạng design token có tên, và đối xử với các thay đổi của chúng với sự nghiêm túc của một thay đổi phụ thuộc dùng chung. Token cho phép bạn thực thi độ tương phản tối thiểu, kích thước vùng chạm và khả năng nhìn thấy tiêu điểm trên toàn hệ thống, và cho một nhóm địa phương đặt lại chủ đề cho thương hiệu của mình mà không phá vỡ các bảo đảm khả năng tiếp cận bên dưới. Khi một chuẩn quốc gia thay đổi, bạn muốn đổi một token, không phải kiểm toán mười nghìn màn hình.

7. Vận hành một mô hình đóng góp, không phải một khu vườn có tường. Một hệ thống thiết kế chỉ nhận đầu vào từ một nhóm trung tâm sẽ luôn tụt lại sau nhu cầu dịch vụ thực và bị các nhóm triển khai oán giận. Công bố một đường rõ ràng để các nhóm đề xuất thành phần và mô thức mới, với tiêu chí cho điều gì được chấp nhận, ai rà soát, và cách khả năng tiếp cận và an toàn được đảm bảo trước khi bất cứ thứ gì được đưa lên thư viện dùng chung. Đây là công việc DesignOps cốt lõi: nó cân bằng căng thẳng giữa tính linh hoạt địa phương và sự nhất quán chung mà không để hệ thống mục nát hay phân mảnh.

8. Đánh phiên bản, ghi chép và truyền đạt thay đổi. Đối xử với hệ thống thiết kế như một sản phẩm có người dùng (các nhóm triển khai của bạn), lộ trình, ghi chú phát hành và một kênh hỗ trợ. Đánh phiên bản ngữ nghĩa, nhật ký thay đổi và thông báo ngừng sử dụng rõ ràng cho phép các nhóm áp dụng cải tiến một cách an toàn và theo lịch của riêng họ. Các thay đổi phá vỡ không được ghi chép phá hủy niềm tin khiến các nhóm chọn hệ thống dùng chung thay vì tự làm.

9. Đo mức độ chấp nhận và chất lượng, không chỉ sự tồn tại. Một hệ thống thiết kế chỉ mang lại giá trị khi nó được sử dụng. Theo dõi dịch vụ nào dùng các thành phần dùng chung, nơi các nhóm phải xây các phương án đặt riêng (và vì sao), và liệu mức tuân thủ khả năng tiếp cận có cải thiện khi mức chấp nhận tăng không. Tỷ lệ cao các cách xoay xở địa phương là tín hiệu rằng hệ thống thiếu một thứ thực — hãy xem chúng là tồn đọng, không phải bất tuân.

Câu hỏi để thảo luận với nhóm của bạn#

1. Ranh giới giữa sự nhất quán chung và tính linh hoạt địa phương nên nằm ở đâu, và ai được quyết định? Đây là căng thẳng quản trị trung tâm của mọi hệ thống thiết kế. Quá cứng nhắc, các nhóm triển khai cảm thấy bị chặn, xây các thành phần bóng, và đi vòng hệ thống — phân mảnh chính sự nhất quán bạn muốn bảo vệ. Quá lỏng lẻo, "hệ thống" trở thành một đống rời rạc những thứ một lần không có bảo đảm an toàn hay khả năng tiếp cận chung. Trong bối cảnh y tế và chăm sóc rủi ro rất cụ thể: một số biến thể là chính đáng (một dịch vụ khủng hoảng sức khỏe tâm thần có nhu cầu thực sự khác với một công cụ đặt lịch thường quy), trong khi một số biến thể là nguy hiểm (các cách xác nhận không nhất quán cho một hành động lâm sàng phá hủy). Một câu trả lời tốt gọi tên những quyết định nào là không thể thương lượng (khả năng tiếp cận, các mô thức then chốt về an toàn, các hành vi tương tác cốt lõi) và những quyết định nào mở cho chủ đề hóa địa phương, và xác định một quy trình rõ ràng, nhân văn để một nhóm yêu cầu ngoại lệ hoặc đóng góp một mô thức mới thay vì chỉ cấm sự khác biệt.

2. Khả năng tiếp cận và an toàn lâm sàng sẽ thực sự được đảm bảo bên trong các thành phần của chúng ta như thế nào — và ai phê duyệt? Rất dễ tuyên bố khả năng tiếp cận và an toàn "được xây vào"; rất khó bảo đảm điều đó. Câu hỏi này buộc bạn cụ thể về đường ống đảm bảo: ai kiểm thử từng thành phần theo WCAG, với những công nghệ hỗ trợ nào, và với những người dùng khuyết tật nào; các hành vi liên quan an toàn được rà soát thế nào theo quy trình an toàn lâm sàng của bạn (DCB0129/DCB0160); và bằng chứng gì được đính kèm một thành phần trước khi nó được công bố là "an toàn để tái sử dụng". Cuộc tranh luận nên làm lộ ra những khoảng trống trung thực — có lẽ bạn có kiểm tra độ tương phản tự động nhưng chưa bao giờ kiểm thử với một người dùng trình đọc màn hình thật, hoặc Cán bộ An toàn Lâm sàng của bạn chưa bao giờ rà soát thư viện thành phần dùng chung. Một câu trả lời mạnh tạo ra một người sở hữu có tên, một chế độ kiểm thử xác định, và một quy tắc rằng không thành phần nào vào thư viện dùng chung nếu thiếu bằng chứng khả năng tiếp cận và an toàn được ghi chép, vì một lỗi được năm mươi dịch vụ thừa hưởng là gấp năm mươi lần tác hại.

3. Ai tài trợ, bố trí nhân sự và bảo trì hệ thống thiết kế khi sự hào hứng ban đầu phai nhạt? Các hệ thống thiết kế thường được tạo ra trong một cơn bùng nổ năng lượng rồi lặng lẽ bị bỏ rơi khi nhóm sáng lập chuyển đi, để lại một thư viện cũ kỹ mà các nhóm không còn tin. Về cơ bản đây là câu hỏi về DesignOps và kinh phí, không phải câu hỏi thiết kế. Hãy tranh luận một cách trung thực liệu bạn có một nhóm thường trực, được tài trợ chịu trách nhiệm về hệ thống như một sản phẩm liên tục — có năng lực cho hỗ trợ, rà soát đóng góp, đánh phiên bản và theo kịp các hệ thống NHS và GOV.UK thượng nguồn — hay bạn đang dựa vào thiện chí sẽ bốc hơi. Trong một ICS điều này còn sắc hơn: hệ thống do một tổ chức chi phối sở hữu, được quản trị chung, hay bị bỏ rơi giữa họ? Một câu trả lời tốt xem hệ thống thiết kế là hạ tầng tồn tại lâu với một người sở hữu có tên, một ngân sách đang chạy và mối quan hệ rõ ràng với các hệ thống quốc gia mà nó xây trên đó, thay vì một dự án "kết thúc".

4. Mối quan hệ của chúng ta với các hệ thống NHS và GOV.UK thượng nguồn là gì — và làm sao chúng ta theo kịp chúng khi chúng thay đổi? Áp dụng một hệ thống thiết kế quốc gia không phải một lần tải về; đó là một sự phụ thuộc liên tục vào hạ tầng bạn không kiểm soát. Câu hỏi này buộc bạn quyết định, một cách có chủ đích, bạn đứng ở đâu trên dải từ "đặt chủ đề nhẹ và bám sát thượng nguồn" đến "tách nhánh và phân kỳ". Mỗi lựa chọn có cái giá: ở gần nghĩa là hấp thụ các thay đổi thượng nguồn (một bản sửa khả năng tiếp cận mới, một mô thức được sửa đổi) theo lịch của người khác và đôi khi làm lại các tùy biến địa phương; tách nhánh nghĩa là bạn sở hữu mọi bản sửa khả năng tiếp cận và an toàn trong tương lai mà nhóm quốc gia lẽ ra cho bạn miễn phí. Trong y tế và chăm sóc sức kéo phân kỳ là có thật — quy trình lâm sàng và thương hiệu địa phương tạo áp lực thực sự — nhưng mỗi sự phân kỳ là một khoản nợ thường trực. Một câu trả lời tốt gọi tên ai theo dõi ghi chú phát hành thượng nguồn, các phần mở rộng địa phương được cấu trúc ra sao để sống sót qua một bản cập nhật thượng nguồn, và phép thử rõ ràng một sự phân kỳ đề xuất phải vượt qua trước khi được phép, để "chúng tôi cần nó trông khác" không bao giờ lặng lẽ trở thành "giờ chúng tôi bảo trì một nhánh cũ, kém dễ tiếp cận của bộ chọn ngày NHS".

5. Làm sao chúng ta thực sự giữ ranh giới giữa "tạo mẫu để học" và "xây để giữ"? Mọi người đều đồng ý về nguyên tắc rằng nguyên mẫu dùng-một-lần không nên trở thành dịch vụ vận hành; thất bại xảy ra dưới áp lực hạn chót, khi một nguyên mẫu độ trung thực cao thuyết phục nằm ngay đó và giao nó trông như một lối tắt. Câu hỏi này làm ranh giới trở nên cụ thể thay vì khát vọng. Hãy tranh luận điều gì thực tế ngăn mã nguyên mẫu — tối ưu cho tốc độ học, không phải bảo mật, khả năng phục hồi hay khả năng bảo trì — được đưa vào một dịch vụ lâm sàng đang chạy: đó là một sự tách biệt kỹ thuật (nguyên mẫu xây trong sandbox không thể chạm vào sản phẩm), một cổng quản trị (không phê duyệt an toàn lâm sàng, không vận hành), hay chỉ là một ý định tốt chung bốc hơi lần đầu tiên một ngày giao hàng bị trượt? Rủi ro y tế và chăm sóc rất cụ thể, vì mã chưa được đảm bảo trong một lộ trình lâm sàng là sự phơi bày an toàn bệnh nhân, không chỉ là nợ kỹ thuật. Một câu trả lời trung thực thừa nhận áp lực sẽ đến từ đâu, gọi tên ai được trao quyền nói không, và xác định "xây lại cho sản phẩm từ các thành phần đã được đảm bảo" thực sự đòi hỏi gì để ranh giới đứng vững khi bị thử thách.

6. Làm sao chúng ta biết hệ thống thiết kế có thực sự hiệu quả — và chúng ta sẽ làm gì khi các chỉ số gây khó chịu? Một hệ thống thiết kế có thể tồn tại, được ghi chép đẹp đẽ, mà vẫn mang lại ít giá trị nếu các nhóm lặng lẽ đi vòng nó. Câu hỏi này đẩy qua "chúng ta có một hệ thống thiết kế" để đến "nó có xứng đáng với chỗ của nó không". Quyết định bạn sẽ đo gì: mức chấp nhận trên các dịch vụ, tỷ lệ và lý do của các cách xoay xở đặt riêng, liệu mức tuân thủ khả năng tiếp cận có thực sự cải thiện khi mức chấp nhận tăng không, và các nhóm tiết kiệm được bao nhiêu thời gian khi tái sử dụng thay vì xây lại. Phần khó không phải thu thập số liệu mà là thống nhất trước cách đọc chúng — vì tỷ lệ cao các cách xoay xở địa phương là tín hiệu rằng hệ thống dùng chung thiếu một thứ thực, không phải bằng chứng các nhóm triển khai bất tuân. Một câu trả lời tốt cam kết xem dữ liệu chấp nhận gây khó chịu là đầu vào tồn đọng và lộ trình, xác định ai rà soát nó và bao lâu một lần, và cưỡng lại cám dỗ chỉ đo thứ đẹp mặt (sự tồn tại, số lượt tải) thay vì thứ quan trọng (các dịch vụ an toàn hơn, dễ tiếp cận hơn, nhất quán hơn thực sự được giao).

Trong thực tế: một ví dụ về y tế và chăm sóc#

Một hệ thống chăm sóc tích hợp gồm ba bệnh viện cấp cứu, một bệnh viện sức khỏe tâm thần và một nhà cung cấp cộng đồng quyết định hợp nhất hệ thống số hướng tới bệnh nhân của mình. Hiện nay mỗi tổ chức chạy cổng ngoại trú của riêng mình; giữa họ có bốn bộ chọn ngày không tương thích, ba cách khác nhau để hỏi số NHS, và mức tuân thủ khả năng tiếp cận chênh lệch rất lớn. Một cuộc kiểm toán nội bộ phát hiện chỉ một trong bốn cổng vượt qua một bài kiểm thử trình đọc màn hình cơ bản về luồng đặt lịch — một sự phơi bày rõ ràng về công bằng và an toàn lâm sàng.

ICS lập một nhóm hệ thống thiết kế nhỏ, được tài trợ chung. Thay vì xây từ đầu, họ áp dụng hệ thống thiết kế NHS làm nền tảng và xác định một lớp địa phương mỏng gồm các design token cho thương hiệu riêng của ICS, cộng với một nhúm mô thức thực sự địa phương (ví dụ một mô thức dùng chung để đặt hỗ trợ phiên dịch, mà không hệ thống quốc gia nào bao phủ). Mỗi thành phần dùng chung mang bằng chứng WCAG được ghi chép và sự phê duyệt của Cán bộ An toàn Lâm sàng của ICS theo quy trình DCB0129 trước khi được công bố.

Trước khi xây lại luồng đặt lịch ngoại trú, nhóm tạo mẫu. Họ bắt đầu ở độ trung thực thấp, kiểm thử một phiên bản giấy-và-thang-xám của luồng mới với mười hai người tham gia được tuyển để phản ánh quần thể địa phương — gồm hai người dùng trình đọc màn hình, ba người trên 75 tuổi và một số người ít tự tin về số. Nguyên mẫu làm lộ một vấn đề nghiêm trọng về khả năng hiểu: bệnh nhân không phân biệt được hành động "đổi lịch" với hành động "hủy". Nhóm sửa mô thức, rồi xây một nguyên mẫu mã hóa độ trung thực cao dùng giao diện người dùng của hệ thống thiết kế và kiểm thử lại, lần này xác nhận hành vi bàn phím và trình đọc màn hình trên phần cứng thực được dùng trong các phòng khám ngoại trú của một bệnh viện đối tác.

Chỉ sau đó họ mới xây thật, lắp ráp dịch vụ vận hành chủ yếu từ các thành phần đã được đảm bảo, tái sử dụng được. Mười tám tháng sau, một bản cập nhật WCAG siết chặt yêu cầu về khả năng nhìn thấy tiêu điểm. Vì kiểu dáng tiêu điểm nằm trong một design token duy nhất, nhóm giao một thay đổi và mọi dịch vụ của ICS thừa hưởng nó trong bản phát hành tiếp theo — một bản sửa mà dưới hệ thống phân mảnh cũ sẽ có nghĩa là năm dự án khắc phục riêng và, thực tế, ít nhất một dịch vụ bị bỏ hỏng.

Góc nhìn theo khu vực#

Công ty khởi nghiệp#

Một công ty khởi nghiệp y tế số nhỏ gần như không bao giờ nên xây hệ thống thiết kế của riêng mình từ con số không — nó không thể chi trả chi phí kiểm thử khả năng tiếp cận, và các nhà đầu tư đang trả tiền cho thẩm định lâm sàng, không phải những chiếc nút đặt riêng. Hãy áp dụng giao diện người dùng của NHS hoặc GOV.UK khi bạn xây cho người dùng NHS, và xem tạo mẫu là lợi thế cạnh tranh cốt lõi của bạn: các nguyên mẫu rẻ, nhanh, dùng-một-lần được kiểm thử với bệnh nhân thật cho phép bạn học nhanh hơn các đối thủ đã có thế được tài trợ tốt hơn. Rủi ro ngược lại — đưa một nguyên mẫu độ trung thực cao bóng bẩy thẳng vào sản phẩm để kịp một buổi demo cho nhà đầu tư, mang mã không được đảm bảo, không an toàn vào một dịch vụ lâm sàng đang chạy. Hãy giữ một ranh giới cứng giữa "tạo mẫu để học" và "xây để giữ", ngay cả dưới áp lực kinh phí.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão, hoặc một phòng khám đơn lẻ đặt hàng một công cụ hướng tới bệnh nhân — có bệnh nhân thật nhưng không có năng lực thiết kế hay giao diện người dùng chuyên trách, và không thể hấp thụ chi phí của các thành phần đặt riêng. Nước đi mạnh nhất của nó là khăng khăng bất kỳ nhà cung cấp nào cũng phải xây trên giao diện người dùng của NHS hoặc GOV.UK, để các bảo đảm khả năng tiếp cận và an toàn được thừa hưởng thay vì chỉ được hứa, và biến điều đó thành điều kiện bằng văn bản của hợp đồng thay vì một hy vọng. Nó hiếm khi cần vận hành một hệ thống thiết kế của riêng mình; nó cần tiêu thụ một hệ thống cho tốt, và nhận ra rằng một bản demo bóng bẩy của nhà cung cấp không phải bằng chứng về một dịch vụ vận hành dễ tiếp cận, được đảm bảo. Nơi nó tạo mẫu — kiểm thử một luồng đặt lịch trực tuyến mới với chính các bệnh nhân thực của mình, thường lớn tuổi hơn hoặc ít tự tin về số hơn — vài buổi với người dùng thật sẽ bắt được nhiều hơn một bản mô phỏng bóng bẩy từng tiết lộ. Áp dụng cùng các nghĩa vụ luật định về khả năng tiếp cận và an toàn lâm sàng như một bệnh viện lớn, nên câu hỏi trung thực không phải có tuân thủ hay không mà là làm sao có được sự tuân thủ thừa hưởng một cách rẻ từ hạ tầng quốc gia dùng chung.

Doanh nghiệp lớn#

Một bệnh viện NHS lớn hoặc công ty công nghệ y tế lớn đã có nhiều nhóm xây các giao diện chồng chéo, nên vấn đề của nó là sự phân mảnh và chi phí trùng lặp. Lập luận giá trị là một nhóm hệ thống thiết kế thường trực, được tài trợ vận hành một mô hình đóng góp thực sự, với các chỉ số chấp nhận được báo cáo cho lãnh đạo và một tuyến quản trị rõ ràng đến đảm bảo an toàn lâm sàng và khả năng tiếp cận. Căng thẳng trung tâm mang tính chính trị: các nhóm triển khai quyền lực chống lại việc nhường kiểm soát, và một nhóm trung tâm độc đoán sinh ra các thành phần bóng. Các doanh nghiệp lớn thành công bằng cách làm cho hệ thống dùng chung thực sự là lựa chọn dễ hơn — được ghi chép tốt, được hỗ trợ tốt và chất lượng rõ ràng cao hơn — thay vì bắt buộc nó và hy vọng.

Chính phủ#

Một cơ quan quốc gia như NHS England hay GDS vận hành hệ thống thiết kế như hạ tầng công cộng được các tổ chức mà nó không kiểm soát sử dụng, nên sự cởi mở, ổn định và tương thích ngược cực kỳ quan trọng. Các nghĩa vụ của nó mạnh nhất: các quy định luật định về khả năng tiếp cận, nghĩa vụ bình đẳng, và thực tế rằng một lỗi trong một thành phần quốc gia dùng chung lan đến hàng triệu công dân. Công việc ít về phát minh và nhiều về quản lý — đánh phiên bản rõ ràng, chính sách ngừng sử dụng, bằng chứng khả năng tiếp cận đầy đủ và sự đáp ứng với hàng trăm nhóm ở hạ nguồn. Hệ thống thiết kế NHS và Hệ thống Thiết kế GOV.UK là các ví dụ tham chiếu chính xác vì chúng đối xử với hệ thống như một lợi ích công cộng tồn tại lâu, không phải một dự án.

Các kiểu thất bại thường gặp#

• Hệ thống bị bỏ rơi. Một hệ thống thiết kế được xây trong ồn ào rồi bị bỏ không bảo trì khi nhóm sáng lập phân tán; các nhóm mất niềm tin và trôi về công việc đặt riêng. Tránh bằng cách tài trợ một nhóm sản phẩm thường trực, không phải một dự án một lần.
• Bức tranh nói dối. Tệp thiết kế và mã sản phẩm mâu thuẫn nhau vì không có nguồn sự thật duy nhất, nên "hệ thống thiết kế" mô tả một thứ mà sản phẩm không còn làm. Giữ các thành phần được mã hóa và tài liệu của chúng có thẩm quyền và được đánh phiên bản cùng nhau.
• Khả năng tiếp cận như điều nghĩ sau. Các thành phần được giao mà không có kiểm thử công nghệ hỗ trợ thực, nên một mô thức không thể tiếp cận được thừa hưởng ở khắp nơi — nhân lên, không giảm, tác hại. Yêu cầu bằng chứng WCAG và trình đọc màn hình được ghi chép trước khi bất kỳ thành phần nào được công bố.
• Nguyên mẫu-thành-sản-phẩm. Một nguyên mẫu độ trung thực cao được đưa thẳng vào một dịch vụ vận hành để tiết kiệm thời gian, mang mã không an toàn, không dễ bảo trì, không được đảm bảo vào môi trường lâm sàng. Thực thi ranh giới dùng-một-lần; xây lại cho sản phẩm từ các thành phần đã được đảm bảo.
• Khu vườn có tường. Một nhóm trung tâm từ chối mọi đóng góp, nên hệ thống không bao giờ đáp ứng nhu cầu dịch vụ thực và các nhóm triển khai đi vòng. Công bố một quy trình đóng góp và ngoại lệ và xem các cách xoay xở địa phương là tín hiệu tồn đọng.
• Sân khấu nhất quán. Sự đồng nhất cứng nhắc được thực thi ở nơi sự khác biệt địa phương thực sự chính đáng (dịch vụ khủng hoảng, nhi khoa), làm suy giảm an toàn và khả năng sử dụng nhân danh sự gọn gàng. Phân biệt các quyết định không thể thương lượng với những quyết định mang tính địa phương chính đáng.
• Kiểm thử sai độ trung thực. Các rủi ro tương tác và khả năng tiếp cận chỉ được "kiểm thử" trong một công cụ thiết kế tĩnh không thể thực hiện hành vi bàn phím hay trình đọc màn hình, mang lại sự tự tin giả. Tạo mẫu bằng mã khi tương tác là câu hỏi.

Mô hình trưởng thành#

Danh sách kiểm tra#

• Bạn đã áp dụng hệ thống thiết kế NHS và/hoặc Hệ thống Thiết kế GOV.UK làm nền tảng thay vì xây từ đầu.
• Các thành phần dùng chung mang bằng chứng tuân thủ WCAG được ghi chép, được kiểm thử với công nghệ hỗ trợ thật và người dùng khuyết tật.
• Các thành phần liên quan an toàn đã được rà soát theo quy trình an toàn lâm sàng của bạn trước khi được công bố để tái sử dụng.
• Design token chi phối màu, khoảng cách, kiểu chữ và trạng thái tương tác, cho phép thay đổi toàn hệ thống từ một nơi.
• Có một nguồn sự thật duy nhất nơi các thành phần được mã hóa và hướng dẫn của chúng cùng tồn tại và được đánh phiên bản cùng nhau.
• Nguyên mẫu có độ trung thực khớp với câu hỏi, được kiểm thử với một mẫu người dùng đại diện, và được xem là dùng-một-lần.
• Các luồng then chốt về tương tác và khả năng tiếp cận được tạo mẫu bằng mã, không chỉ trong công cụ thiết kế.
• Một nhóm có tên, được tài trợ sở hữu hệ thống thiết kế như một sản phẩm liên tục, với lộ trình và kênh hỗ trợ.
• Một quy trình đóng góp và ngoại lệ được công bố cho phép các nhóm triển khai đề xuất thành phần và mô thức mới.
• Mức chấp nhận và chất lượng được đo, và tỷ lệ cao các cách xoay xở địa phương được xem là tồn đọng, không phải bất tuân.

Nguồn chính#

• Hệ thống thiết kế NHS — NHS England: thành phần, mô thức, kiểu dáng và hướng dẫn khả năng tiếp cận cho các dịch vụ số của NHS.
• Hệ thống Thiết kế GOV.UK — Dịch vụ Số của Chính phủ: kiểu dáng, thành phần và mô thức cho các dịch vụ chính phủ Vương quốc Anh.
• Sổ tay Dịch vụ GOV.UK — tạo mẫu và "make a prototype" — Dịch vụ Số của Chính phủ: hướng dẫn về tạo mẫu để học và kiểm thử với người dùng.
• Tiêu chuẩn Dịch vụ Số của NHS — NHS England: tiêu chuẩn mà các dịch vụ dùng chung và nhất quán được đánh giá theo.
• Hướng dẫn Khả năng Tiếp cận Nội dung Web (WCAG) 2.2 — Sáng kiến Khả năng Tiếp cận Web của W3C: tiêu chuẩn tuân thủ khả năng tiếp cận.
• Quy định về Khả năng Tiếp cận của Các Cơ quan Khu vực Công (Trang web và Ứng dụng Di động) 2018 — chính phủ Vương quốc Anh: nghĩa vụ luật định về khả năng tiếp cận cho các dịch vụ khu vực công.
• Các tiêu chuẩn quản lý rủi ro lâm sàng DCB0129 / DCB0160 — NHS England: các tiêu chuẩn an toàn lâm sàng cho sản xuất và triển khai hệ thống CNTT y tế.
• Kim cương Kép của Design Council — Design Council: mô hình khám phá–xác định–phát triển–giao nền tảng cho khám phá và thiết kế.

Tài liệu tham khảo#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards