Là một người đã làm việc trong lĩnh vực “trải nghiệm người dùng” trong nhiều thập kỷ, được đào tạo về nửa tá phương pháp phát triển và hoàn thành hơn 150 dự án nhanh, một điều mà tôi khá bối rối về những ngày này là thuật ngữ thác nước. Trong thời kỳ tiền nhanh nhẹn, tôi chưa bao giờ làm việc trong bất kỳ tổ chức nào tuyên bố họ đang thực hiện và phát triển mô hình thác nước. Nếu tôi nghe thấy những thuật ngữ như “ném nó lên tường”  thì lúc đó, họ đã bị chế giễu như bây giờ. Phát triển sản phẩm, ít nhất là đối với các sản phẩm mà bất kỳ ai cũng mong muốn thành công, luôn luôn lặp đi lặp lại, tăng dần và hợp tác.

KHÔNG CÓ THÁC NƯỚC

Các phương pháp phát triển phần mềm truyền thống không phải là từng bước hoặc im lặng.

Các phương pháp phát triển phần mềm truyền thống không phải là từng bước hoặc hệ thống silo hóa. Ngay cả trong quá trình phát triển tồi tệ nhất, mọi người cũng không bị khóa vào các phòng riêng biệt để làm việc của mình một cách cô lập, sau đó chuyển tài liệu hoàn chỉnh, không thay đổi thông qua một khe trên tường. Như Phillip G. Armor đã viết trong bài báo của mình về việc kinh doanh phần mềm: Ước tính không phải là điều xấu:

Mô hình thác nước chưa bao giờ thực sự là một cách làm việc. Nó không phải là một mô hình phát triển như một mô hình quản lý cho phép một cơ sở đơn giản hóa để theo dõi các dự án. Công việc hiếm khi được hoàn thành vào một ngày ngẫu hứng trong khi hầu hết các yêu cầu có thể được xác định trước các giai đoạn khác đã được xác định trong các giai đoạn sau đó và việc làm lại cần thiết xảy ra trong suốt vòng đời tất cả đều mâu thuẫn với các giả định mô hình ngây thơ.

Điều sau đây cũng là kinh nghiệm của tôi. Chỉ có các tập thể tồi mới  không thể hợp tác hoặc làm việc lặp đi lặp lại. Ngay cả khi một số người quản lý thông minh đã phản ứng thái quá và cố gắng hướng mọi người đi theo những lựa chọn tồi, các ngành khác nhau sẽ gặp gỡ bí mật và điều phối các hoạt động của họ. Tất cả mọi người đã hành động lặp đi lặp lại tất cả mọi lúc. Ví dụ, xoắn ốc chỉ là một phương pháp phát triển cũ hơn với mục đích cải thiện sản phẩm trong suốt vòng đời phát triển. Hình 1 minh họa cách phát triển xoắn ốc hoạt động.

Hình 1 Vòng đời phát triển xoắn ốc

VÒNG ĐỜI PHÁT TRIỂN XOẮN ỐC

Các quá trình phát triển khác có xu hướng tương tự. Ngay cả khi có các giai đoạn riêng biệt, mọi người, kể cả những người cuối cùng sẽ duy trì hệ thống, được mời hoặc thậm chí bắt buộc phải tham gia. Thêm vào đó, nhiều giai đoạn chồng chéo hoặc mọi người tiếp tục làm việc trong vai trò giám sát bởi vì gần như không thể đóng đinh một thiết kế trong sự cô lập.

Điều này dẫn chúng ta đến cách tích hợp “trải nghiệm người dùng” vào các quy trình này. Điều này khá dễ dàng và tự nhiên, tôi nghĩ vậy. Khi các nhà phát triển phần mềm hoặc kiến ​​trúc sư đề cập đến thiết kế, họ thường có ý là thiết kế phần mềm, thiết kế cơ sở dữ liệu hoặc các nỗ lực thiết kế kỹ thuật khác. Trong khi các đội thường đưa ra những nỗ lực ngắn như vậy ngày nay, họ rất quan trọng để xây dựng một sản phẩm đáng tin cậy làm bất cứ điều gì như những gì được mong đợi.

ĐỊNH LƯỢNG VỀ NHU CẦU NGƯỜI DÙNG

Thiết kế UX cũng là về hệ thống xây dựng. Chúng tôi chỉ bao gồm người dùng như một phần của hệ thống và thừa nhận rằng họ có các nhu cầu và ràng buộc có thể định lượng.

Sự nhầm lẫn về thuật ngữ này có thể là một vấn đề. Nếu chúng ta có ý nghĩa khác nhau theo thiết kế, làm thế nào chúng ta có thể làm việc cùng nhau? Chà, tôi không nghĩ rằng chúng tôi có những ẩn ý khác nhau. Thiết kế UX là về hệ thống xây dựng. Chúng tôi chỉ bao gồm những người dùng như là một phần của hệ thống và thừa nhận rằng họ có các nhu cầu và ràng buộc có thể có định lượng.

Điều này rất quan trọng để xác định phạm vi người dùng càng rộng càng tốt. Không chỉ tất cả các thể loại người dùng cuối sẽ sử dụng sản phẩm của bạn, mà cả người dùng nội bộ như quản trị viên, người tạo nội dung và những người chịu trách nhiệm bảo trì hệ thống nữa. Cho dù bạn chuyển hệ thống kế thừa sang các nền tảng mới hoặc tạo ra các công nghệ hoàn toàn mới từ đầu, ngoài công nghệ kỹ thuật số, vẫn có các quy trình và mục tiêu kinh doanh mà bạn cần phải giải quyết.

Khi bạn nhìn vào “trải nghiệm người dùng” theo cách này, đột nhiên mọi người trong doanh nghiệp có thể thậm chí cả nhóm Kỹ sư, sẽ thấy rằng vai trò của bạn có ý nghĩa và có giá trị. Điều này đặc biệt đúng nếu bạn, với tư cách là nhà thiết kế UX, cũng dành thời gian để hiểu các ràng buộc kỹ thuật và xem xét các nhu cầu của khách hàng, cũng như nhu cầu của người dùng. Nếu bạn làm như vậy, công việc thiết kế của bạn sẽ tự nhiên đồng bộ với các thông số kỹ thuật. Do tính chất phân tích trong công việc của chúng tôi, các chuyên gia UX có thể sớm trở thành thành viên có giá trị nhất trong nhóm của họ. Và đây là thời điểm dễ dàng nhất để thực công việc của chúng tôi.

“TRẢI NGHIỆM NGƯỜI DÙNG” VÀ QUÁ TRÌNH PHÁT TRIỂN

Công việc của tôi là khám phá, tổng hợp và cân bằng tất cả các nhu cầu và hạn chế.

Sau đó, thách thức duy nhất là quá trình phát triển. Trong tuần vừa qua, tôi đã thấy các chuyên gia nhanh nhẹn đến, những người người mà hoàn toàn không hiểu được “trải nghiệm người dùng” để làm gì. Ngay cả sau khi tôi đã giải thích vai trò của “trải nghiệm người dùng” một vài lần, họ vẫn cho rằng chúng tôi đã thiết kế giao diện người dùng sau khi các câu chuyện được đặt ra. Họ thậm chí còn nghĩ rằng chúng ta chỉ nên dọn dẹp UI  sau khi vòng phát triển đầu tiên của một tính năng hoàn tất. Tệ hơn nữa, quan điểm của họ là, nếu chúng tôi khăng khăng thực hiện một số thiết kế tổng thể, toàn diện, chúng tôi sẽ phá vỡ quy trình của họ và do đó, phạm tội cuối cùng: không hợp tác.

Trong một cuộc trao đổi trên Twitter một thời gian trước, Brian Rieger đã trả lời tweet của tôi như sau:

Các cuộc thảo luận về “Tôi tìm ra thiết kế nhanh nhẹn” khiến tôi rất tò mò vì tôi không bao giờ biết rằng thiết kế (như tôi đã được dạy) có thể là bất cứ điều gì ngoài nhanh nhẹn.

Ngoài một vài người quản lý, huấn luyện viên quy trình và nhà phát triển được huấn luyện không tốt, hầu hết các nhóm dự án ít nhất sẽ cho bạn có thể đến trễ để giải thích vai trò của bạn như một chuyên gia UX và những gì bạn có thể làm để giúp dự án. Vì vậy, bạn có thể làm gì để vượt qua những thành kiến ​​như vậy?

Ngày nay, thường xuyên hơn thông thường, tôi có thể nói rằng tôi là một nhà thiết kế hệ sinh thái. Công việc của tôi là khám phá, tổng hợp và cân bằng tất cả các nhu cầu và hạn chế, như trong Bảng 1.

Và làm thế nào để chúng tôi làm điều đó? Nếu tôi phải khắc phục điều này bằng cách xác định một vài nguyên tắc chính, tôi sẽ nói:

Đầu tiên, đừng rút lui.

Tụ lại và hiểu.

Thiết kế hệ sinh thái đầu tiên.

Giữ, nhìn, chạm và kết nối.

Chú thích, mô tả và giải thích.

Đánh giá và xác nhận.

Trước khi tôi đi sâu vào từng vấn đề, tôi muốn nhấn mạnh rằng chúng thực sự không phải là các bước trong một quy trình. Thay vào đó, chúng là những hành động hoặc hành vi mà bạn sử dụng nhiều lần hoặc thậm chí liên tục trong suốt một dự án. Đây là những điều mà bạn làm lặp đi lặp lại. Ví dụ, bạn thực hiện việc đầu tiên trong số này bất cứ khi nào có thông tin mới phát sinh, không chỉ khi bạn lần đầu tiên tham gia một dự án mới.

ĐẦU TIÊN, KHÔNG RÚT LUI 

Khi tôi dành thời gian để lắng nghe và suy nghĩ, tôi luôn đưa ra các giải pháp tốt hơn, dễ dàng hơn và rẻ hơn để xây dựng và bảo trì.

Tôi đã hiểu những điều này về vai trò của “trải nghiệm người dùng” trong quá trình phát triển không phải thông qua nội tâm triết học, mà từ thất bại, thật chẳng hay ho gì . Theo lẽ tự nhiên, tôi là nhà thiết kế thiên tài, kiểu ra quyết định và nhận được kết quả khá tốt bằng cách dựa vào trực giác và kinh nghiệm, mặc dù tôi ghét một số hàm ý của thuật ngữ này. Tôi thực sự đã từng thường xuyên làm gián đoạn các giải thích của khách hàng về nhu cầu của họ và đưa ra các giải pháp khá tốt trên bảng trắng trong vài phút. Nhưng, hơn 10 năm trước, mọi ý tưởng xuất hiện trong đầu tôi  khi tôi là nhà thiết kế UX cho một bản làm lại hoàn chỉnh của trang web Sprint.

Tôi đã tạo một sơ đồ trang web rất cao cấp trước khi thuật ngữ kiến ​​trúc thông tin (IA) thực sự xuất hiện trong não của tôi và một bộ các mẫu trang tuân thủ tốt cả thương hiệu và thực tiễn tốt nhất. Sau đó, một người quản lý dự án rất giỏi đã sắp xếp cho chúng tôi ở trong một căn phòng với từng chủ sở hữu sản phẩm. Trong sáu tháng, đôi khi 16 giờ một ngày, tôi đã làm việc với họ, vẽ mỗi trang web hàng trăm trang trên bản in mẫu -Phần làm việc theo từng phần và vẽ bằng bút chì, như trong Hình 2.

Sau đó, tôi dịch những bản vẽ này sang mockup Photoshop. Phần này của quá trình tốn đến một vài tuần, rõ ràng là cách tiếp cận này là điên rồ, và ngay sau khi tôi kết thúc, tôi bắt đầu phát triển một quy trình tốt hơn. Tất cả điều này xảy ra trước khi biểu đồ máng và thang UCD tồn tại, vì vậy tôi không thể làm gì được. Hình 2 cho thấy cách tiếp cận cũ của tôi, thiết kế các phần riêng lẻ, từng trang một.

Gần đây, một kinh nghiệm dự án tái khẳng rằng thiết kế theo từng trang và từng tính năng một là phương pháp thật tệ. Tôi đã tiếp quản một dự án từ người khác, không có thời gian để bắt đầu lại. Cơ quan trước đây là một loại tổ chức chỉ tập trung vào Photoshop. Khách hàng chắc chắn rằng tôi có thể làm một công việc tuyệt vời bằng cách chọn chỗ làm cũ của họ, vì vậy nên họ cũng nhấn mạnh rằng chúng tôi chỉ tiếp tục tiến bước. Vì vậy, tôi đã làm như họ yêu cầu, mặc dù tôi đã thực hiện một số nỗ lực nửa vời để lập sơ đồ quy trình và thực thi tính nhất quán. Và thiết kế kết quả khá đẹp, đủ thú vị để sử dụng và được khen ngợi vừa phải lúc đầu. Sau đó, mọi người bắt đầu chú ý đến vấn đề, ví dụ có thể kể đến thiết kế có đầy đủ mười lăm kiểu phương thức, quảng cáo xen kẽ và cửa số mở lên, cả mớ vấn đề tồn tại không vì lý do nào khác ngoài việc chúng tôi đã thiết kế mọi thứ một cách nhanh chóng, để đáp ứng nhu cầu cụ thể phát sinh vào lúc này.

Khi tôi dành thời gian để lắng nghe và suy nghĩ, tôi luôn đưa ra các giải pháp tốt hơn, dễ dàng hơn và rẻ hơn để xây dựng và bảo trì. Luôn luôn làm điều này và nhấn mạnh rằng khách hàng của bạn cho phép bạn làm điều này. Nó sẽ làm cho khách hàng cảm nhận bạn và nhóm UX của bạn thân thiện hơn và bạn sẽ nhận được nhiều công việc hơn khi những người khác đến với bạn để cải thiện sản phẩm của họ.

Tập hợp và hiểu

Có rất nhiều quy trình xấu để thu thập thông tin. Ví dụ, trò chơi trí tuệ truyền thống là một cách khủng khiếp để tìm hiểu thông tin.

Vì vậy, bạn nên lắng nghe như thế nào? Theo bài bản thôi. Có rất nhiều quy trình xấu để thu thập thông tin. Ví dụ, trò động não truyền thống mà chúng ta được dạy trong trường lớp là một cách tồi tệ  để tìm hiểu thông tin. Trong việc động não, chúng ta luôn được bảo rằng không có ý tưởng tồi, nhưng điều đó không đúng. Bên cạnh đó là rất nhiều ý tưởng tồi, những gì thực sự tốt là những hạn chế. Dù sao, chúng tôi hiếm khi được yêu cầu đưa ra giải pháp cho một vấn đề thô. Thông thường, chúng tôi đã có một chút hướng đi theo.

Ngay trước khi “trải nghiệm người dùng” thường tham gia với các dự án, thường là ai đó đã có một ý tưởng trong kinh nghiệm của tôi ít nhất. Thông thường, đó là một sự thay đổi, xoắn, hoặc cải tiến về cái gì đó là được khoảng năm hoặc thậm chí nhiều thập kỷ. Vì vậy, điều đầu tiên chúng tôi làm là có được toàn đội với nhau. Họ có rất nhiều kiến ​​thức rất phù hợp.

Điều khó chịu là, nó có sẵn bên trong đầu họ. Hãy nhận biết mọi người rất tệ trong việc phân tích và chia sẻ những gì họ biết. Bạn không thể mang họ vào phòng hoặc ngồi ăn trưa với nhau và lấy thông tin từ họ. Tuy nhiên, có một số kỹ thuật hoạt động tốt trong việc trích xuất loại thông tin đó, cho phép bạn tìm thấy câu trả lời thực sự thú vị. Có một cách là đến tiếp cận những người này trong vùng thoải mái của họ. Dân tộc học thực sự là khoa học của nghiên cứu quan sát, nhưng chỉ cần đưa nhóm của bạn đến một môi trường thực sự như nhà, cửa hàng sửa chữa, công viên hoặc cửa hàng có thể khuyến khích cuộc trò chuyện và hồi ức. Hình 3 cho thấy một nhóm ghé thăm một cửa hàng Hallmark để khám phá với khách hàng của họ tại sao các sản phẩm kế thừa được sắp xếp và dán nhãn theo những cách cụ thể.

Hầu hết việc thu thập thông tin của tôi thậm chí còn trực tiếp hơn thế này nhiều.Trong những năm qua, tôi đã học được cách hỏi bốn câu hỏi cốt lõi này về bất kỳ sản phẩm nào:

Sản phẩm là gì?

Mục đích chính của nó là gì?

Nó giải quyết vấn đề gì?

Ai sẽ sử dụng sản phẩm?

Bạn có thể thu thập thông tin này theo nhiều cách. Tôi đã nhận được câu trả lời thành công bằng cách chỉ cần đặt câu hỏi rất cẩn thận trong các cuộc gọi điện thoại hoặc trong email hoặc khảo sát trực tuyến. Cho đến nay, phương pháp yêu thích của tôi để làm điều này là những gì, trong nhiều năm, tôi chỉ đơn giản gọi là phương pháp “Post-it”. Nhiều người gọi đây là biểu đồ mối quan hệ. Gần đây, tôi phát hiện ra rằng phương pháp này đã có một tên chính thức, phương pháp KJ và được đặt theo tên của người sáng tạo Nhật Bản, Kawakita Jiro.

Theo phương pháp này, bạn sẽ tập hợp nhóm dự án, và những người khác có kiến ​​thức rằng bạn cần có trong phòng và yêu cầu họ viết thông tin lên thẻ hoặc Post-it, sau đó tổ chức chúng thành một nhóm. Chỉ cần nói với mọi người để làm việc cùng nhau và cho họ lời khuyên về sự hợp tác chỉ đi xa đến vậy. Đây là một trong những phương pháp phức tạp mà về cơ bản khiến mọi người làm việc cùng nhau để đi đến sự hiểu biết chung về một vấn đề và đồng ý về câu trả lời.

Đừng chỉ đơn thuần kiểm tra Bước này Phát triển thiết kế của bạn

Đây là về sự hiểu biết của khách hàng và các mục tiêu kinh doanh.

Điều quan trọng là bạn tiến hành các bài tập như thế này khác với cách bạn tập thể dục theo nhóm. Bạn không chỉ cần gặp nhau, chạy qua các bước của bài tập, sau đó tất cả ăn mừng và tiếp tục. Trong quá trình thiết kế, hãy áp dụng dữ liệu mà bạn có được từ các bài tập này. Thiết kế của bạn sẽ phát triển liền mạch từ bước này sang bước tiếp theo.

Loại bài tập này dẫn đến một số lượng nhỏ các tính năng được mô tả khá tốt. Đối với các đội nhanh nhẹn, sử thi và có lẽ câu chuyện người dùng có thể xuất hiện từ bài tập này. Bạn nên thực hiện bài tập này sớm nhất có thể trước khi bắt tay vào bất kỳ quá trình phát triển nào. Đây là về sự hiểu biết của khách hàng và các mục tiêu kinh doanh.

Một kết quả quan trọng khác phải là một bộ mục tiêu và kết quả chính. Điều này cho phép bạn chính thức định lượng thành công để bạn có thể nhận ra nó sau này, cũng như xác định rõ ràng các mục tiêu thực tế của doanh nghiệp.

Biết đối tượng của bạn

Các quy trình UCD cổ điển rất tốn thời gian đến nỗi tôi biết vài nhà thiết kế than phiền về việc tạo ra các diện chính thức.

Tạo personas là một cách tuyệt vời để hiểu cách mọi người sẽ thực sự sử dụng sản phẩm của bạn. Sau này, Personas có thể không thể thiếu, khi bạn đang cố gắng hiểu lý do tại sao người dùng thực sự gặp nhiều vấn đề.

Một trong những khách hàng của Diane Jacobsen đã từng trả lời rằng cô bày tỏ sự cần thiết phải có được loại dữ liệu này như sau: đừng làm điều đó sớm như những thằng ngu mà hãy bắt đầu từ giai đoạn ba!

Nhưng tôi đã giành được sự đổ lỗi chỉ dành cho khách hàng. Các quy trình UCD cổ điển rất tốn thời gian đến nỗi tôi biết vài nhà thiết kế bận tâm tạo ra các diện chính thức. Đây không chỉ là vấn đề về nhận thức; Tôi đã làm việc với các đội đã dành hơn 6 tháng để tạo ra personas. Sự cần thiết phải làm ngắn quá trình này là nhiều hơn đáp ứng nhu cầu cho tốc độ cao hơn; thế giới có thể thay đổi theo thời gian nhóm của bạn hoàn thành những điều đó.

Bạn có thể làm tắt quy trình này bằng cách hoàn thành các cuộc phỏng vấn người dùng và personas chỉ sau vài tuần. Thậm chí nếu tốt hơn, bạn có thể có được một xử lý khá tốt đối với khán giả của bạn trong vài ngày. Personas giả định đã tồn tại trong tâm trí của bạn và nhóm của bạn. Bạn có thể sử dụng các bài tập thu thập thông tin tương tự mà tôi đã mô tả trước đó để trích xuất thông tin về personas từ nhóm.

Tôi muốn dành một chút thời gian để tìm kiếm trên Internet để tìm hiểu thêm về các diện mạo này. Đối với người dùng chuyên nghiệp, tôi tìm kiếm những thứ như sơ yếu lý lịch và thông báo việc làm. Nhưng điều này không phải là kết thúc quá trình của bạn. Đây có thể là công việc sơ bộ để chỉ đạo các cuộc phỏng vấn hoặc nghiên cứu dân tộc học của bạn, vì vậy bạn sẽ nhận được kết quả chính xác hơn nhiều, nhanh hơn khi bạn tiến hành dự án của mình.

THIẾT KẾ HỆ SINH THÁI ĐẦU TIÊN

Trở thành một chuyên gia UX luôn luôn là về thiết kế hệ sinh thái. Tất cả mọi thứ mà chúng tôi thiết kế là một hệ sinh thái.

Trở thành một chuyên gia UX luôn luôn là về thiết kế hệ sinh thái. Tất cả mọi thứ mà chúng tôi thiết kế là một hệ sinh thái. Các nhà thiết kế UX giỏi đã nghĩ theo cách này từ rất lâu trước kỷ nguyên kỹ thuật số. Ví dụ, các nhà xuất bản thiết kế báo và tạp chí không chỉ có thể đọc được mà còn hấp dẫn trên sạp báo, cho phép chỗ để gửi nhãn cho người đăng ký, và được in và đóng bìa, vì vậy mọi bản sao đều có vẻ tốt khi vào tay người đọc trong khi đáp ứng ngân sách

Hãy xem xét ba yếu tố sau:

Với các thiết bị mới được kết nối, hệ sinh thái đang trở nên phức tạp hơn. Nó không chỉ là sự lựa chọn giữa Web hoặc di động, mà cả hai cùng một lúc, cộng với Smart TV, bộ điều chỉnh nhiệt và xe hơi của bạn.

Các hệ thống phức tạp tùy ý, do đó, giả sử một quy trình tuyến tính đơn giản làm bạn thất bại. Bạn phải thiết kế cho các lỗi phức tạp và tiềm ẩn để đáp ứng tất cả các nhu cầu của người dùng và tiêu chuẩn kỹ thuật.

Có rất ít nhà phát triển hệ sinh thái thực sự toàn diện. Trong thực tế, tôi không thực sự biết bất kỳ ai như vậy cả. Bạn cần lập kế hoạch cho toàn bộ trải nghiệm trước khi tạo mẫu hoặc phát triển có thể xảy ra trên một hoặc nhiều nền tảng.

Thiết kế hệ sinh thái là thực sự thiết kế theo quan điểm của người dùng. Hãy suy nghĩ về người dùng, động lực và mục tiêu thực sự của họ và môi trường rộng lớn hơn mà họ sinh sống. Hãy suy nghĩ về những gì họ đã làm ngày hôm nay. Họ ở trong nhà hay bên ngoài? Ở bàn làm việc hay đi dạo bế em bé? Có phải trời đang mưa không? Họ đang lái xe à? Bạn có thể thấy việc kết hợp ít nhất một chút tính cách sẽ hữu ích như thế nào trong việc trả lời những câu hỏi này.

Có nhiều cách để vẽ một hệ sinh thái, nhưng hãy đảm bảo rằng bạn tập trung vào các hành vi thay vì giao diện người dùng hoặc tương tác. Tập trung vào các dịch vụ, dữ liệu, cảm biến, mạng và người dùng, không phải màn hình, trang và nút.

Sơ đồ này không phải là đẹp. Bạn có thể bắt đầu sơ đồ của mình bằng cách chỉ vẽ các hộp hoặc theo nghĩa đen bằng cách lấy Post-it từ các bài tập trước của bạn ra khỏi tường.

Bất kỳ sơ đồ đáp ứng nhu cầu của bạn có thể làm việc. Ví dụ, xây dựng cốt truyện là một cách tốt khác để mô hình hóa các hệ sinh thái. Cuối cùng, bạn sẽ cần một cái gì đó rõ ràng và không mơ hồ, vì vậy các nhóm thực hiện có thể đưa đầu của họ xung quanh nó đi vào thiết kế và ước tính hệ thống. Sơ đồ của bạn sẽ phát triển thành các hộp và mũi tên, bao gồm mọi nút của hệ thống mà người dùng tương tác và tất cả các tài nguyên mà hệ thống sẽ sử dụng, chẳng hạn như lưu trữ và vị trí. Sơ đồ hệ sinh thái trong Hình 4 cho thấy tất cả các điểm tiếp xúc của khách hàng và hệ thống và dòng chảy giữa chúng. Tôi đã tách riêng các bộ phận của hệ thống, các liên kết bên ngoài và các công cụ khác trên thiết bị cầm tay như điện thoại hoặc dịch vụ định vị trong một dải dọc phía dưới.

Hãy nhớ việc chuyển đổi suôn sẻ từ phương pháp biểu đồ này sang phương pháp khác là được xây dựng dựa trên nền tảng các giai đoạn trước. Bạn có thể cần phải tạo giao diện người dùng trước khi bạn thích, vì vậy quản lý cấp cao hiểu rằng bạn đang đạt được tiến bộ. Trong trường hợp này, tôi muốn mở rộng trên sơ đồ lấy người dùng làm trung tâm. Mọi người sẽ là một phần của hệ sinh thái của bạn. Khi phát triển từ sơ đồ đến giao diện người dùng và tương tác, hãy cố gắng giữ mọi người trong sơ đồ của bạn. Ví dụ, có các màn hình trong Hình 5, nhưng họ đã căn cứ vào một người dùng đang đi bộ trên đường phố ở Nairobi. Các màn hình đều có trên điện thoại di động của anh ấy, nhưng trải rộng trên các nền tảng, chuyển từ SMS sang Web sang một ứng dụng.

GIỮ, NHÌN, CHẠM VÀ KẾT NỐI

Hãy chắc chắn có nguyên mẫu trong phòng bất cứ khi nào bạn đang thảo luận về một dịch vụ.

Nhiều người trong chúng ta biết về câu chuyện của Jeff Hawkins ngay cả khi bạn biết tên anh ấy. Anh ấy là người sáng lập ra Palm, vì vậy đã mang đến cho chúng tôi chiếc máy hiện đại và sau đó là điện thoại thông minh. Trong thời kì đầu sự phát triển của Palm, anh ta mang theo một khối gỗ, bọc băng keo và in giấy. Để thử khái niệm này, trong bối cảnh, anh ta giả vờ ghi chú về nó trong suốt cả ngày, giống như cách mà một người dùng thực sự sẽ làm. Anh ta tập trung đặc biệt vào yếu tố hình thức bởi vì anh ta tin tưởng chính xác, vì hóa ra, các dự án tương tự trước đây đã thất bại phần lớn vì các thiết bị quá lớn để bỏ vào túi.

Tôi đã tạo và thấy các nguyên mẫu tương tự. Cho dù bạn đang chế tạo các nguyên mẫu bằng gỗ của các thiết bị chưa tồn tại hoặc chỉ đi qua các bản thiết kế giao diện người dùng trên thiết bị cầm tay, hãy chắc chắn có nguyên mẫu trong phòng mỗi khi bạn thảo luận về dịch vụ. Tránh dựa dẫm vào máy tính, bảng trắng và thuyết trình PowerPoint.

Một cách đơn giản để làm cho thiết kế của bạn chính xác hơn và quy trình của bạn hiệu quả hơn là làm việc theo quy mô. Vẽ trên bản in của các thiết bị ở kích thước thực của chúng, như trong Hình 6. Phác thảo theo tỷ lệ là một cách dễ dàng và rẻ tiền để đảm bảo rằng các thiết kế của bạn có ý nghĩa trong ngữ cảnh.

Một khi bạn đã chuyển sang tạo ra các thiết kế kỹ thuật số, hãy thường xuyên xuất các thiết kế giao diện người dùng của bạn, để bạn có thể thấy chúng trên điện thoại, máy tính bảng hoặc bất kỳ thiết bị nào mà giao diện người dùng sẽ xuất hiện. Có rất nhiều sản phẩm giúp bạn thực hiện điều này, nhưng nó không khó để tạo ra hình ảnh có tỷ lệ khung hình phù hợp, sau đó gửi email cho thiết bị di động và cuộn qua trình chiếu. Tôi thậm chí đã thực hiện thử nghiệm nguyên mẫu giấy với các mockup như vậy, và nó hoạt động tốt đáng ngạc nhiên.

HIỂU BIẾT CÔNG NGHỆ

Hiểu về công nghệ, và có thể tự kiểm tra nó.

Đằng sau tất cả mọi thứ, có dây, ăng-ten radio, pin, cảm biến, mạch tích hợp, điện trở, phim, chất kết dính, và nhiều hơn nữa. Nếu bạn nghĩ rằng bạn đang xây dựng cho thế giới thực, nhưng không có kế hoạch cho khi khi mà thế giới không ủng hộ, bạn sẽ thất bại.

Hiểu công nghệ, và tự kiểm tra nó. Có nhiều công nghệ mà bạn phải sử dụng để thực sự hiểu chúng; và tất cả chúng thường bị hiểu lầm. Bạn có thể sẽ không bao giờ sử dụng GPS cho ứng dụng di động của bạn, nhưng bạn có thể sử dụng vị trí, mà xuất phát từ nhiều nguồn khác nhau, trong đó có tới ba mạng vệ tinh khác nhau.

Xem xét những mục được hiển thị. Chúng tôi muốn giả vờ rằng chúng được tạo từ các pixel giống như những gì bạn nhìn thấy khi bạn phóng to hình ảnh Photoshop, mỗi hình vuông có một màu khác nhau nhưng điều đó không đúng. Có một số loại màn hình khác nhau, và loại màn hình nào bạn đang sử dụng có thể quan trọng và không chỉ để làm cho mọi thứ đẹp hơn mà còn quản lý năng lượng để thời lượng pin kéo dài cả ngày, thay vì chỉ một hoặc hai giờ.

Radio là một công nghệ yêu thích của tôi. Tôi nghe nhiều người nói về việc mạng di động chậm như thế nào, nhưng điều đó không hoàn toàn đúng. Chúng có thể, nhưng tốt nhất thường nhanh như mạng gia đình thông thường của bạn. Tuy nhiên, chúng có độ trễ khủng khiếp, đó là tốc độ mà mỗi kết nối được tạo ra. Để tối ưu hóa cho các mạng di động, tổng kích thước trang không hoàn toàn quan trọng bằng việc giảm số lượng mục trên trang. Bạn có thể giải quyết vấn đề này bằng cách sử dụng JavaScript và CSS nội tuyến thay vì tham khảo các tệp bên ngoài và thậm chí sử dụng mã hóa Base64 để nhúng hình ảnh trực tiếp vào trang Web.

NÓ CÓ THỂ TỆ ĐẾN MỨC NÀO?

Công nghệ là một phần của trải nghiệm người dùng có với sản phẩm của bạn.

Tất nhiên, công nghệ là một phần của trải nghiệm người dùng có với sản phẩm của bạn. Trong trường hợp bạn có thể nghĩ rằng tất cả những điều này thuộc về phía triển khai, vì vậy bạn có thể lo lắng về điều đó sau đó, điều đó đã sai. Thiết kế phần mềm, thiết kế tương tác và thậm chí cả kiến ​​trúc thông tin và khái niệm dữ liệu có thể gây ra lỗi nếu bạn không cẩn thận.

Ngay bây giờ, tôi đang nghiên cứu sửa đổi một loại hệ thống Internet vạn vật (IoT) kết nối với thiết bị từ xa cho mục đích chẩn đoán. Chúng tôi xây dựng sản phẩm để đọc hệ thống từ xa trong thời gian thực. Nhiều, rất nhiều, rất lâu sau, chúng tôi phát hiện ra rằng nó thực sự không thể làm điều đó, nhưng thay vào đó phải có được ảnh chụp nhanh dữ liệu bất cứ khi nào người dùng vào trình xem hoặc nhấn nút refresh.

Chúng tôi đã thử nghiệm điều này với người dùng thật và thậm chí sau khi thực hiện một vài điều chỉnh để giải thích điều này, nó đã không hoạt động. Khái niệm thiết kế ứng dụng đã không có ý nghĩa theo những cách khá cơ bản. Chúng tôi đã phải quay trở lại và thiết kế lại khá nhiều kiến ​​trúc và các bộ phận của giao diện người dùng để phản ánh cách hệ thống thực sự hoạt động. Đây là những khác biệt không tầm thường khi nó bật ra. Bạn có thể chỉ cần thêm một nút bấm hoặc lớp phủ giải thích. Bạn phải xây dựng sự tương tác xung quanh cách hệ thống thực sự hoạt động trong môi trường thực tế của người dùng.

CHÚ THÍCH, MÔ TẢ VÀ GIẢI THÍCH

Các thông số kỹ thuật nên rõ ràng và có thể kiểm tra. Sau này, khi nó không được xây dựng đúng, bạn có thể nhắc nhở mọi người đây là một đặc điểm kỹ thuật và các lỗi mở chống lại nó.

Vì vậy, giữ tất cả những vấn đề đó trong tâm trí, tôi chuyển từ yêu cầu sang thực sự thiết kế các chi tiết. Đây là nơi tôi chuyển từ hệ sinh thái sang một nền tảng duy nhất bởi vì các nhóm, giai đoạn hoặc lặp lại riêng lẻ giải quyết một hoặc một vài nền tảng chứ không phải toàn bộ hệ sinh thái.

Tôi nhận công việc và làm cho nó một nền tảng cụ thể. Để đảm bảo rằng tôi luôn chú ý đến hệ thống rộng hơn, tôi chuyển đổi lại một lần nữa bằng cách sử dụng bản vẽ dòng tác vụ và sử dụng công cụ Pen hoặc InDesign, viết nguệch ngoạc lên các phần mà don don áp dụng. Tôi tiếp tục phân nhánh thiết kế, tạo ra một loạt các sơ đồ bao gồm từng nền tảng. Tất cả những thứ này là con của dòng nhiệm vụ hệ sinh thái, nhưng tôi mở rộng chúng riêng lẻ, khi cần.

Đây là nơi tôi có xu hướng muốn nói về việc không tạo mẫu, nhưng vẽ và mô tả. Khi bạn di chuyển đến số lượng thiết bị tùy ý hoặc thậm chí các thiết bị hoàn toàn mới, bạn có thể mã hóa thiết kế của mình. Các thiết bị này hoàn toàn không tồn tại cho đến khi nhóm của bạn tạo ra phần cứng mới. Bạn phải có khả năng vẽ và chỉ định những thứ như đèn, tốc độ nhấp nháy hoặc cách người dùng lắc hoặc sóng tại thiết bị.

Mô tả, danh sách và bảng phải đi kèm với bất kỳ bản vẽ nào để chỉ định giao diện người dùng giống như một đặc tả chức năng. Các thông số kỹ thuật nên rõ ràng và có thể kiểm tra. Sau này, khi nó không được xây dựng đúng, bạn có thể nhắc nhở mọi người đây là một đặc điểm kỹ thuật và các lỗi mở chống lại nó.

Khi chúng ta chuyển sang các loại thiết bị khác như thiết bị đeo và bộ điều nhiệt thông minh, đừng để bị lo lắng khi nghĩ rằng không cần có giao diện người dùng Mặc dù phong trào No-UI non trẻ là một cách thông minh để suy nghĩ về nhiều thứ, nhưng nó thực sự có nghĩa là một giao diện người dùng khác với màn hình mà bạn chạm hoặc bàn phím.

Nháy mắt và ù là đầu ra. Hành động của người dùng có thể là đầu vào. Đấu nối bộ điều nhiệt của bạn hoặc cắm vào thiết bị đeo của bạn để sạc pin mỗi đêm hoàn toàn là một sự tương tác. Và đừng quên các quy trình nội bộ như tải nội dung mới hoặc hệ thống kỹ thuật tác động đến người dùng, chẳng hạn như truy xuất dữ liệu. Hãy nghĩ về tất cả những điều này, và thiết kế chúng là tốt.

Đánh giá và xác nhận

Hệ thống bao gồm con người, nhưng trong quá khứ, chúng tôi có xu hướng phân biệt giữa kiểm tra hệ thống và kiểm tra khả năng sử dụng.

Các nhà phát triển có thể quen thuộc với một số biến thể của thử nghiệm tích hợp hệ thống. Nó là một trong một vài cái tên để thử nghiệm kỹ thuật từ đầu đến cuối của toàn bộ hệ thống. Nhưng, những ngày này, tuyên bố thực hiện thử nghiệm từ đầu đến cuối đang ngày càng không đúng sự thật. Bạn đang thử nghiệm trên phần cứng thực tế, trên các mạng di động khác ngoài văn phòng công ty của bạn? Ở ngoài? Với tiếng ồn và ánh sáng chói và phiền nhiễu? Bởi vì tất cả những vấn đề này.

Hệ thống bao gồm con người, nhưng trong quá khứ, chúng tôi có xu hướng phân biệt giữa kiểm tra hệ thống và kiểm tra khả năng sử dụng. Như tôi đã đề cập trong ví dụ trước đây, điều này không phải lúc nào cũng hoạt động. Ứng dụng mà chúng tôi xây dựng và tất cả các API và máy chủ hoạt động về mặt kỹ thuật, nhưng không phải khi chúng tôi sử dụng trong môi trường của người dùng và môi trường của họ.

Tất nhiên, trước tiên bạn cần đảm bảo hệ thống cơ bản hoạt động. Kiểm tra phần cứng và đảm bảo các giả định cơ bản của bạn là chính xác trong bối cảnh, càng nhiều càng tốt. Kiểm tra băng ghế trong văn phòng của bạn chỉ có thể đi xa, vì vậy bạn cần đi bộ xung quanh và thử mọi thứ trong thế giới thực. Hãy nhớ làm thế nào tôi nói mạng di động là khác nhau? Đừng trở thành người chỉ kiểm tra ứng dụng di động của bạn trên kết nối WiFi.

Càng sớm càng tốt và thường xuyên trong suốt quá trình phát triển, hãy thử nghiệm với những người thực sự trong môi trường của chính họ. Thực hiện kiểm tra với người dùng thực và trong môi trường thực của họ quan trọng hơn kiểm tra một phần mềm thực sự. Lấy nguyên mẫu giấy hoặc trình chiếu các bản nháp cho người dùng của bạn ngay khi bạn có chúng, để họ có thể thử thiết kế của bạn.

Ảnh hiển thị trong Hình 8 mô tả một trang web làm việc điển hình của người dùng, một cửa hàng bảo trì. Tôi đã cho người dùng này đeo kính quay video, vì vậy tôi có thể xem lại công việc của anh ta sau này và có được quan điểm thực tế của anh ta trong suốt quá trình. Chúng tôi đã nắm bắt mọi thứ người dùng đã thấy và làm, không chỉ những gì anh ta đã làm với ứng dụng trên điện thoại.

Trong nhiều năm, phòng thí nghiệm khả năng là nghiên cứu cuối cùng của UX, nhưng càng ngày, tôi thấy rằng nghiên cứu thực địa tốt hơn và, theo nhiều cách, làm cho việc tiến hành nghiên cứu dễ dàng và rẻ hơn. Bạn phải biết cách kiểm tra, làm thế nào để không làm hỏng kết quả với ý kiến ​​của riêng bạn. Nhưng bạn đi đến với người dùng, vì vậy họ dễ dàng nắm bắt và hành động tự nhiên hơn.

“Trải nghiệm người dùng” là một phần của ngăn xếp

Toàn bộ stack ngày càng bao gồm giao diện người dùng, tiếp thị cho mọi bộ phận của hệ thống.

Các kỹ sư thường nghĩ về các yêu cầu dự án của họ và các quy trình của họ về mặt ngăn xếp. Họ chọn một hệ điều hành, trên đó họ đặt một máy chủ Web, sau đó là cơ sở dữ liệu, v.v. Gần đây, họ đã mở rộng ngăn xếp để bao gồm mọi thứ trong một dự án.

Toàn bộ stack ngày càng bao gồm giao diện người dùng, tiếp thị cho mọi bộ phận của hệ thống. Kinh doanh và phát triển là tất cả, nhưng đòi hỏi các sản phẩm được thiết kế tốt, có thể sử dụng làm cơ sở cho những gì họ cần để cạnh tranh trên thị trường.

Liên tục có nhiều cơ hội cho các chuyên gia và đội UX đóng góp cho các sản phẩm tuyệt vời, nhưng chúng ta cần phải thực sự chủ động, thậm chí có thể hung hăng trong việc xen vào quá trình, thể hiện giá trị của chúng tôi và truyền đạt các quy trình của chúng tôi theo cách mà các nhóm Kỹ thuật đã từng nói chuyện.