Thiết kế lấy người dùng làm trung tâm (UCD) hoặc mô hình phát triển người sử dụng (UDD) là cơ cấu của các quy trình (không giới hạn trong các giao diện hoặc công nghệ), trong đó các mục đích sử dụng, đặc tính người dùng, môi trường, nhiệm vụ và quy trình công việc trong sản xuất, dịch vụ hoặc quá trình được bao quát chú trọng ở từng giai đoạn của quá trình thiết kế. Thiết kế lấy người dùng làm trung tâm có thể được mô tả như là một quá trình giải quyết vấn đề đa giai đoạn mà không chỉ đòi hỏi các nhà thiết kế phải phân tích và hình dung cách người dùng tiêu thụ sản phẩm mà còn để xác nhận độ chính xác của những giả định về hành vi của người dùng trong các thí nghiệm thực tế. Các thử nghiệm này được thực hiện cả khi có/ không có người dùng trong mỗi giai đoạn của quá trình, bắt đầu từ những yêu cầu, các mô hình tiền sản xuất và sản xuất,  hoàn thành một vòng tuần hoàn và đảm bảo rằng " Sự phát triển song hành với chiến lược lấy người dùng làm trung tâm". Việc thử nghiệm như vậy là cần thiết vì rất khó để các nhà thiết kế sản phẩm trực tiếp hiểu được những gì người dùng cảm nhận trong lần đầu tiên trải nghiệm thiết kế của họ và biểu đồ mô tả quá trình lĩnh hội của người dùng sẽ trông như thế nào.

Sự khác biệt chính trong các triết lý thiết kế những sản phẩm khác nhau là thiết kế lấy người dùng làm trung tâm cố gắng tối ưu hóa sản phẩm bằng cách cho người dùng muốn hoặc sử dụng sản phẩm thay vì buộc người dùng phải thay đổi hành vi để thích ứng với sản phẩm. Vì lẽ đó, người dùng đứng ở trung tâm của hai vòng tròn đồng tâm. Các vòng tròn bên trong bao gồm bối cảnh của sản phẩm, mục tiêu phát triển và môi trường hoạt động. Vòng ngoài bao gồm các chi tiết cụ thể hơn về chi tiết các nhiệm vụ, cách tổ chức

NHU CẦU VÀ CẢM XÚC

Thuật ngữ thiết kế lấy người dùng làm trung tâm được đặt ra tại phòng thí nghiệm của Donald A. Norman ở Đại học California, San Diego. Khái niệm này đã được phổ biến rộng rãi sau khi ông xuất bản cuốn sách "Thiết kế hệ thống lấy người dùng làm trung tâm: Các quan điểm mới về tương tác giữa con người và máy tính" vào năm 1986. Khái niệm này đã thu hút được nhiều sự chú ý xa gần và được chấp nhận trong cuốn sách "Thiết kế hàng ngày" của ông (ban đầu được gọi là "Tâm lý học thường nhật"). Trong cuốn sách, Don Norman mô tả tâm lý sau khi tiếp xúc với  những thiết kế 'tốt' và 'xấu' thông qua các ví dụ. Ông tôn vinh tầm quan trọng của thiết kế trong cuộc sống hàng ngày của chúng ta, và hậu quả của những thiết kế tồi. Cuốn sách cũng bao gồm những nguyên tắc để xây dựng sản phẩm thiết kế tốt. Các khuyến nghị của ông dựa trên nhu cầu của người sử dụng, bỏ qua những vấn đề mà ông cho là thứ (kém quan trọng hơn) như thẩm mỹ. Những khuyến nghị nổi bật bao gồm:

1. Đơn giản hóa cấu trúc của các công việc sao cho trực quan nhất, dễ làm nhất.
2. Làm cho mọi thứ thật rõ ràng, bao gồm mô hình khái niệm của hệ thống, hành động, kết quả của hành động và phản hồi.
3. Lập ra lộ trình đúng giữa kết quả mong muốn và các hành động phải làm.
4. Nắm bắt và khai thác những khó khăn của hệ thống

Những nghiên cứu kỹ lưỡng của Norman trong các cuốn sách trước đã được ông nhấn mạnh lại trong ấn phẩm "Thiết kế cảm xúc" của mình. Những cuốn sách khác cùng loại như "Những sản phẩm thiết kế lý thú" của Patrick W. Jordan, trong đó tác giả cho rằng các hình thức thú vị khác nhau nên được bao hàm trong cách tiếp cận lấy người sử dụng làm trung tâm bên cạnh những định nghĩa truyền thống về khả năng thực hiện

CÁC MÔ HÌNH VÀ CÁCH TIẾP CẬN

Ví dụ, quá trình thiết kế lấy người dùng làm trung tâm có thể giúp các nhà thiết kế phần mềm hoàn thành mục đích thiết kế sản phẩm cho người dùng. Yêu cầu của người dùng được xem xét đúng đắn ngay từ đầu và bao hàm trong toàn bộ vòng đời sản phẩm. Các yêu cầu này được lưu tâm và trau chuốt thông qua các phương pháp nghiên cứu, bao gồm:  nghiên cứu dân tộc học, điều tra theo ngữ cảnh, thử nghiệm mẫu, thử nghiệm khả năng sử dụng và các phương pháp khác. Các phương pháp khác cũng có thể được sử dụng bao gồm: phân loại thẻ, lập sơ đồ mối liên kết và tham gia các khóa thiết kế. Ngoài ra, yêu cầu của người sử dụng có thể được suy ra bằng cách phân tích cẩn thận các sản phẩm có thể sử dụng tương tự như sản phẩm đang được thiết kế.

• Thiết kế liên kết: thiết kế này đặt người thiết kế và người dùng ngang bằng nhau. Đây là thiết kế cổ điển Scadinavian của IT từ những năm 1970.
• Thiết kế tham gia PD, một thuật ngữ Bắc Mỹ cho một khái niệm tương tự, lấy cảm hứng từ Thiết kế hợp tác, tập trung vào sự tham gia của người sử dụng. Từ năm 1990 đã có Hội nghị thiết kế PD được tổ chức hai lần một năm.
• Thiết kế theo ngữ cảnh, "thiết kế lấy khách hàng làm trung tâm" trong bối cảnh thực tế, bao gồm một số ý tưởng từ thiết kế PD.

Dưới đây là những nguyên tắc cho thiết kế lấy người dùng làm trung tâm:

1. Thiết kế dựa trên sự hiểu biết rõ ràng về người dùng, nhiệm vụ và môi trường.
2. Người dùng tham gia vào quá trình thiết kế và phát triển.
3. Thiết kế được quản lý và trau chuốt bằng đánh giá của người dùng.
4. Quá trình này cần lặp đi lặp lại.
5. Thiết kế này nhấn mạnh toàn bộ trải nghiệm của người dùng.
6. Nhóm thiết kế cần có các kỹ năng đa ngành và nhìn xa trông rộng.

QUÁ TRÌNH THIẾT KẾ LẤY NGƯỜI DÙNG LÀM TRUNG TÂM

Mục tiêu của thiết kế lấy người dùng làm trung tâm là tạo ra các sản phẩm có khả năng sử dụng cao. Điều này bao gồm cách sử dụng, khả năng quản lý, sự hiệu quả của sản phẩm thuận tiện như thế nào và sản phẩm đáp ứng yêu cầu của người dùng tốt như thế nào,. Dưới đây là những giai đoạn chung của quá trình thiết kế lấy người dùng làm trung tâm:

1. Làm rõ bối cảnh sử dụng: Xác định ai là người dùng sản phẩm, tại sao họ sẽ sử dụng sản phẩm, yêu cầu của họ là gì và họ dùng sản phẩm đó trong môi trường nào.
2. Làm rõ yêu cầu: Khi bối cảnh đã được làm rõ, đây là thời điểm để xác định các yêu cầu chi tiết của sản phẩm. Đây là một quá trình quan trọng có thể tạo điều kiện thuận lợi cho các nhà thiết kế tạo ra storyboard và đặt ra các mục tiêu quan trọng để làm cho sản phẩm thành công.
3. Tạo ra các giải pháp thiết kế và phát triển: Dựa vào các mục tiêu và yêu cầu của sản phẩm, quá trình thiết kế và phát triển sản phẩm cần được lặp đi lặp lại
4. Đánh giá sản phẩm: Những nhà thiết kế sản phẩm thực hiện thí nghiệm khả năng sử dụng để có được phản hồi của người dùng. Đánh giá sản phẩm là một bước quan trọng trong việc phát triển sản phẩm bởi nó mang lại những phản hồi quan trọng về sản phẩm.

Trong các bước tiếp theo, quá trình trên được lặp lại để tiếp tục hoàn thành sản phẩm. Đó là những cách tiếp cận chung và các yếu tố như mục tiêu thiết kế, đội ngũ, timeline và môi trường phát triển sản phẩm, xác định các giai đoạn thích hợp cho một dự án và thứ tự của chúng. Bạn có thể làm theo một mô hình thác nước, mô hình Agile hoặc bất kỳ phần mềm kỹ thuật thông thường nào khác.

MỤC ĐÍCH

UCD trả lời các câu hỏi của người dùng về nhiệm vụ và mục đích của mình, sau đó sử dụng các kết quả để đưa ra quyết định về mẫu thiết kế và sự phát triển. Ví dụ khi thiết kế UCD của một trang web thì bạn hãy tìm cách trả lời những câu hỏi sau:

• Ai là người sử dụng tài liệu?
• Nhiệm vụ và mục tiêu của người dùng là gì?
• Mức độ trải nghiệm của người dùng với tài liệu này và các tài liệu khác như thế nào?
• Những chức năng nào người sử dụng cần từ các bộ tài liệu?
• Những thông tin nào người sử dụng cần, và loại thông tin đó là gì?
• Người sử dụng nghĩ tài liệu nên hoạt động như thế nào?
• Môi trường khắc nghiệt là gì?
• Họ có phải là người dùng đa nhiệm hay không?
• Giao diện có sử dụng các chế độ nhập thông tin khác nhau thông qua chạm, nói, cử chỉ hay định hướng không?

CÁC YẾU TỐ

Ví dụ về các quan điểm UCD, các yếu tố thiết yếu của UCD là một trang web có khả năng hiển thị, khả năng tiếp cận, tính rõ ràng và ngôn ngữ.

Tầm nhìn

Tầm nhìn giúp người dùng xây dựng một mô hình trí tuệ của tài liệu. Các mô hình giúp người dùng dự đoán hành động của họ trong quá trình sử dụng tài liệu. Các yếu tố quan trọng (như hỗ trợ điều hướng) cần được nhấn mạnh. Người dùng nên trao đổi thẳng thắng cái họ có thể và không thể làm được với tài liệu.

Khả năng truy cập

Người dùng có thể tìm thông tin nhanh chóng và dễ dàng trong tài liệu, bất kể tài liệu đó dài thế nào. Người dùng nên được cung cấp nhiều cách khác nhau để tìm kiếm thông tin (như các yếu tố điều hướng, chức năng tìm kiếm, bảng mục lục, các phần được đánh dấu rõ ràng, số trang, mã màu,...). Các yếu tố điều hướng phải phù hợp với loại tài liệu nhất định. 'Chunking' là một chiến lược hữu ích liên quan đến việc chia nhỏ thông tin thành các phần nhỏ hơn mà được tổ chức theo trật tự kiểu dáng hoặc thứ bậc nhất định. Khả năng đọc lướt tài liệu cho phép người dùng tìm thấy thông tin của họ bằng cách quét toàn bộ thay vì đọc từng câu. Các từ đậm và nghiêng thường được sử dụng.

Tính rõ ràng

Văn bản cần phải dễ đọc: Thông qua việc phân tích tình huống, nhà thiết kế nên có thể xác định một kiểu chữ hữu ích. Các phông chữ trang trí và tất cả các chữ in hoa rất khó đọc, nhưng chữ in đậm và in nghiêng thì lại khác, nếu được sử dụng đúng cách. Cỡ chữ lớn quá hoặc nhỏ quá cũng khó để đọc. (Kích cỡ màn hình nên là 10-12 pixel với font không chân và 12-16 pixel với font có chân.) Độ tương phản cao giữa chữ và nền làm tăng tính rõ ràng. Văn bản tối trên nền sáng là rõ ràng nhất.

Ngôn ngữ

Tùy thuộc vào tình huống tu từ, mà những loại ngôn ngữ nhất định là cần thiết. Các câu ngắn đều có ích, cũng như các văn bản được viết tốt thường sử dụng trong việc giải thích và xử lý tình huống tương tự. Trừ những trường hợp thật cần thiết, không nên sử dụng thuật ngữ hay từ chuyên ngành. Nhiều tác giả sẽ chọn sử dụng giọng nói tích cực, những động từ (thay vì chuỗi danh từ hoặc danh từ riêng), và cấu trúc câu đơn giản.

TÌNH TRẠNG ẨN

Thiết kế lấy người dùng làm trung tâm được tập trung xung quanh những tình trạng ẩn. Những tình trạng ẩn định dạng thiết kế của môi trường thông tin. Có ba yếu tố cần được xem xét trong tình trạng ẩn: Độc giả, Mục đích và Bối cảnh.

Đối tượng

Độc giả là những người sẽ sử dụng tài liệu. Người thiết kế cần phải xem xét độ tuổi, vị trí địa lý, dân tộc, giới tính, giáo dục,..của độc giả.

Mục đích

Mục đích là Mục tiêu mà tài liệu đặt ra hay vấn đề mà bài viết đang cố chỉ ra.

Bối cảnh

Bối cảnh là hoàn cảnh xung quanh tình huống đó. Bối cảnh thường trả lời câu hỏi: Tình huống nào khiến tài liệu này trở nên cần thiết? Bối cảnh xung quanh tình huống bao gồm bất kỳ vấn đề xã hội hoặc văn hoá nào.

CÔNG CỤ PHÂN TÍCH

Có một số công cụ được sử dụng trong phân tích thiết kế lấy người dùng làm trung tâm, chủ yếu là: diện mạo, kịch bản, và các trường hợp sử dụng thiết yếu.

Personas (Diện mạo)

Trong quá trình UCD, một Persona đại diện cho người dùng có thể được tạo ra. Persona là nguyên mẫu người dùng được dùng trong quá trình ra các quyết định về các tính năng của sản phẩm, điều hướng, tương tác và thậm chí thiết kế trực quan. Trong hầu hết các trường hợp, personas được tổng hợp từ một loạt các cuộc phỏng vấn với người dân, sau đó tóm gọn trong các mô tả trong 1-2 trang bao gồm các mẫu hành vi, mục đích, kỹ năng, thái độ và môi trường, với một vài chi tiết cá nhân hư cấu để persona trở nên gần với thực tế hơn.

Đối với mỗi sản phẩm, hoặc đôi khi với mỗi bộ công cụ trong một sản phẩm, sẽ có một tập hợp nhỏ các persona, một trong số đó được coi là trung tâm của thiết kế. Cũng có những cái gọi là persona thứ hai, tuy họ không phải là mục tiêu chính của thiết kế, nhưng nhu cầu của họ nên được đáp ứng và các vấn đề của họ nên được giải quyết nếu có thể. Họ tồn tại để giải quyết các vấn đề và khó khăn có thể xảy ra ngay cả khi persona chính hài lòng với giải pháp của họ. Ngoài ra còn có persona phản diện, đó là nhân vật mà thiết kế không phù hợp với họ.

Personas rất hữu ích khi tạo ra sự hiểu biết chung chung về nhóm người dùng cho quy trình thiết kế được tạo ra cho họ. Hơn nữa, họ cũng giúp ưu tiên hóa các tiêu chuẩn thiết kế bằng việc cung cấp bối cảnh về những gì người dùng cần và những chức năng nào cần thiết. Họ cũng có thể cung cấp khuôn mặt nhận diện và sự tồn tại cho nhóm những người dùng đa dạng và rải rác, và cũng có thể tạo ra sự đồng cảm và tăng thêm cảm xúc khi đề cập đến người dùng.

Tuy nhiên, vì personas là nhận thức chung về  các nhóm được khảo sát để thu thập dữ liệu, các đặc điểm có thể quá rộng và điển hình, hoặc quá nhiều "Joe đại trà". Đôi khi, personas có những đặc tính khuôn mẫu, mà có thể ảnh hưởng đến toàn bộ quá trình thiết kế. Tóm lại, personas có thể là một công cụ hữu ích giúp các nhà thiết kế tạo lập các ý tưởng, thay vì phải truy cập bộ dữ liệu hoặc điều tra một loạt các đối tượng.

Kịch bản

Kịch bản được tạo ra trong quá trình UCD là một câu chuyện hư cấu về "cuộc sống hàng ngày" hoặc một dãy các sự kiện với các nhóm liên quan chính là nhân vật chính. Thông thường, một persona đã được tạo ra trước đó sẽ là nhân vật chính của câu chuyện này. Câu chuyện nên trình bày cụ thể về những sự kiện xảy ra liên quan đến các vấn đề của nhóm liên quan chính, và thông thường các nghiên cứu chính tập trung đặt câu hỏi về quá trình thiết kế được xây dựng như thế nào. Đây hóa ra có thể là một câu chuyện đơn giản về cuộc sống hàng ngày của một cá nhân, nhưng các chi tiết nhỏ từ các sự kiện này phải bao gồm nhiều chi tiết về người dùng và có thể bao gồm các đặc tính cảm xúc hay vật lý. "kịch bản tốt nhất" xảy ra khi mọi thứ hoạt động tốt nhất cho nhân vật chính, "trường hợp tồi tệ nhất", là khi mà mọi thứ đều diễn ra một cách tồi tệ với nhân vật chính, và “ trường hợp trung bình", là cuộc sống điển hình của cá nhân, nơi không có gì thực sự đặc biệt hoặc thực sự buồn bã xảy ra, ngày qua ngày cứ thế mà thôi.

Các kịch bản tạo ra một bối cảnh xã hội trong đó các personas tồn tại, và cũng tạo ra một thế giới thực, thay vì chỉ tưởng tượng về đặc điểm bên trong của nhân vật từ các dữ liệu thu thập được mà không có gì khác; có nhiều hành động liên quan đến sự tồn tại của persona. Kịch bản cũng sẽ dễ tiếp thu hơn khi nó ở dạng một câu chuyện và dễ theo dõi. Tuy nhiên, giống như các persona, những kịch bản này chỉ là giả định của nhà nghiên cứu và nhà thiết kế, và cũng được tạo ra từ một bộ dữ liệu được tổ chức từ trước. Một số kịch bản còn bị xem là không thực tế so với ngoài đời thật. Cũng rất khó để giải thích và thông báo những nhiệm vụ đơn giản xảy ra như quá trình tư duy của persona trước khi hành động.

Use Case (Đối tượng người dùng muốn nhận được từ hệ thống)

Tóm lại, use case sử dụng mô tả sự tương tác giữa một cá nhân và những cái còn lại. Mỗi use case mô tả một sự kiện có thể xảy ra trong một thời gian ngắn trong đời thực, nhưng cũng có thể bao gồm cả các chi tiết phức tạp và tương tác giữa người dùng bên ngoài và thế giới. Nó được thể hiện dưới dạng một loạt các bước đơn giản để nhân vật đạt được mục tiêu của mình, thể hiện qua sơ đồ nguyên nhân và kết quả. Use case thường được viết dưới dạng một biểu đồ với hai cột: cột đầu tiên ghi nhân vật, cột thứ hai ghi thế giới và các hành động được thực hiện bởi mỗi bên được viết theo thứ tự trong các cột tương ứng. Sau đây là ví dụ về use case trong trường hợp chơi guitar trước khán giả.

Use case thiết yếu là use case đặc biệt, còn được gọi là "use case trừu tượng". Use case thiết yếu mô tả và đề cập bản chất của vấn đề. Trong khi viết các use case, không có giả định nào về những chi tiết không liên quan nên được thực hiện. Thêm vào đó, các mục tiêu của chủ đề nên được tách ra khỏi quá trình và sự thực hiện để đạt được mục tiêu cụ thể đó. Dưới đây là một ví dụ về use case thiết yếu với mục tiêu giống như ví dụ đã được nói tới ở phần trên.Sự tương tác giữa nhân vật và thế giới là một hành động thường thấy trong cuộc sống hàng ngày và chúng tôi coi đó là điều đương nhiên và không nên nghĩ quá nhiều về những chi tiết nhỏ cần thực hiện giống như khi một nghệ sĩ biểu diễn nhạc cụ. Tương tự, thực tế là khi nói tiếng mẹ đẻ, chúng ta không nghĩ quá nhiều về ngữ pháp và cách diễn đạt; chúng ta cứ nói tự nhiên bởi ta nói mỗi ngày. Những hành động giữa một người và thế giới, đáng chú ý là các bên liên quan chính (người sử dụng) và thế giới trong trường hợp này, cần được suy nghĩ tới từng chi tiết, và do đó các use case được tạo ra để tìm hiểu xem những sự tương tác này xảy ra như thế nào.

Giải pháp đầu tiên ít rủi ro hơn bởi vì nếu có vấn đề gì xảy ra với mã lệnh, sẽ dễ dàng hơn trong việc tìm kiếm các vấn đề trong các bits nhỏ hơn, vì phân đoạn với vấn đề sẽ là một phần nhỏ trong quá trình, trong khi ở giải pháp thứ hai, lập trình viên có thể phải xem lại toàn bộ mã để tìm kiếm một lỗi đơn lẻ, mà khiến họ phải tốn nhiều thời gian. Lý do tương tự khi viết use case trong UCD. Cuối cùng, các case use chuyển tải những nhiệm vụ hữu ích và quan trọng mà người thiết kế có thể thấy được cái nào có tầm quan trọng cao hơn. Một số nhược điểm của việc viết các use case bao gồm thực tế mà mỗi hành động, được thực hiện bởi người dùng bên ngoài hoặc thế giới, bao gồm các chi tiết nhỏ và chỉ đơn giản là một hành động nhỏ. Điều này có thể dẫn đến sự hình dung xa hơn và sự diễn giải khác nhau giữa các nhà thiết kế khác nhau.Các use case rất hữu ích vì chúng giúp xác định mức độ hữu ích của công việc thiết kế. Chúng cho phép các nhà thiết kế nhìn thấy các quy trình thực tế ở mức thấp mà có liên quan đến một vấn đề nhất định, điều này làm cho vấn đề dễ xử lý hơn, vì một số bước nhỏ và chi tiết mà người dùng tạo ra đã bị lộ. Công việc của nhà thiết kế nên cân nhắc đến những vấn đề nhỏ này để đưa ra giải pháp hiệu quả cuối cùng. Nói cách khác, use case biến nhiệm vụ phức tạp thành các bits nhỏ hơn, trong đó các bits này đều là các đơn vị hữu ích. Mỗi bits hoàn thành một nhiệm vụ nhỏ, mà sau đó góp phần xây dựng cho nhiệm vụ lớn hơn. Giống như viết mã trên máy tính, dễ dàng hơn để viết các phần cơ bản nhỏ và làm cho chúng hoạt động trước tiên, và sau đó kết hợp chúng lại với nhau để hoàn thành mã lớn hơn, phức tạp hơn, thay vì giải quyết toàn bộ mã ngay từ đầu.

Trong quá trình này, cũng thật dễ dàng để đơn giản hóa một nhiệm vụ, vì một nhiệm vụ nhỏ từ một tác vụ lớn hơn có thể bao gồm các nhiệm vụ nhỏ hơn. Chọn một cây đàn guitar có thể liên quan đến việc chọn cây đàn guitar nào, sử dụng để làm cái gì và đặt cây guitar ở đâu đầu tiên. Những nhiệm vụ này sau đó có thể được chia thành các nhiệm vụ nhỏ hơn, chẳng hạn như suy nghĩ đầu tiên về màu sắc nào của cây đàn guitar phù hợp với địa điểm cũng như tác phẩm biểu diễn và các chi tiết liên quan khác. Các nhiệm vụ có thể được chia ra thành các nhiệm vụ nhỏ hơn nữa thậm chí còn đáng tin cậy hơn và nó phụ thuộc vào nhà thiết kế để xác định vị trí phù hợp để dừng việc phân chia nhỏ nhiệm vụ. Những nhiệm vụ không chỉ được đơn giản hóa, mà còn có thể được bỏ qua, do đó nhà thiết kế nên nhận thức rõ tất cả các chi tiết và các bước chính mà liên quan đến sự kiện hoặc hành động khi viết các use case.