Wireframing: Quy trình thiết kế UX trong thực tế

idesign udc process

Chúng ta đều biết yếu tố cơ bản của thiết kế lấy trọng tâm là người dùng (user-centered design). Có quá nhiều nền tảng nghiên cứu, nhiều cách làm prototype khác nhau, cũng như nhiều quy trình kỹ thuật trong lĩnh vực này. Vậy câu hỏi đặt ra là: Trong thực tế, phương pháp nào hiệu quả nhất?

Bài viết bởi Marcin Treder.

-

Một quy trình thiết kế UX thực sự sẽ ra sao? Liệu chúng ta có đủ thời gian để làm tất cả các bước? Trong bài viết này, tôi sẽ chia sẻ một số cái nhìn sâu sắc về quy trình thiết kế UX thật sự, những quan điểm dựa trên kinh nghiệm và nghiên cứu của tôi.

User-Centered Design: Sự thật vs “Chém gió”

Cách đây vài năm, tôi gia nhập một trong những công ty thương mại điện tử lớn nhất tại Đông Âu. Khi tới văn phòng mới, tôi lập tức để ý một tấm poster về user-centered design (UCD) lớn trên tường. Tất cả quy trình thiết kế được mô tả chi tiết khiến ta không còn chút băn khoăn về việc phải tiếp cận từng bước thế nào. Tôi chăm chút nhìn tấm poster với niềm hy vọng lớn lao và hình dung sẽ thú vị thế nào nếu mình có thể làm theo những quy trình lý tưởng đó. Đoán xem điều gì xảy ra? Họ chẳng áp dụng bất cứ thứ gì trên poster cho quy trình thực sự của họ. Họ chẳng bao giờ làm nghiên cứu, cũng chẳng phân tích nghiêm túc về hành vi người dùng. Thậm chí họ còn không làm.. prototype! Cái poster “nghiêm túc” này hẳn sẽ rất hổ thẹn khi nó được treo ở vị trí quan trọng đến thế.

untitled 1

Sau đó ba năm, tôi đã làm việc chăm chỉ để đưa yếu tố “thiết kế trải nghiệm” làm trọng tâm của nhóm lập trình. Chúng tôi quên đi cái poster đó và lập nên một quy trình riêng, phù hợp với khả năng của công ty và cho phép chúng tôi liên tục tập trung vào hoạt động dịch vụ chính của mình. Tại sao không sử dụng cách tiếp cận lý thuyết kia? Đơn giản vì nó quá tốn thời gian, ảnh hưởng đến kinh tế - ngân sách có hạn của dự án.

Để tung ra một giao diện người dùng đúng hẹn, chúng tôi bị ép phải tinh gọn. Bằng cách sử dụng quy trình UCD truyền thống làm cảm hứng, tôi và mọi người trong đội đã tạo ra một quy trình vừa đơn giản mà phù hợp với công ty. Chúng tôi xác định vấn đề, mục tiêu dự án, thử nghiệm thông qua prototyping bằng giấy và wireframing, lập trình nó nhanh nhất có thể, và thường xuyên sử dụng phép thử kép (A/B) và Google Analytics event để theo dõi.

Thời điểm trước khi công bố dự án là lúc để đo đạc và đặt kế hoạch tối ưu, điều này cần tiến hành ngay. Thật không may, chỉ những dự án lớn mới có đủ chi phí cho việc kiểm thử chất lượng. Những dự án đó cũng có rất nhiều biểu đồ (site maps, flow charts, diagraming) - một số lượng lớn số liệu tham khảo đưa ra cách giải quyết những vấn đề phức tạp.

Nhưng trên tất cả, quy trình tinh gọn của team tuy đơn giản nhưng lại hiệu quả. Dĩ nhiên nhìn chung nó vẫn là quy trình UCD truyền thống, nhưng so sánh với cách tiếp cận thông thường và những poster UCD nổi tiếng thì nó chỉ thực hiện được khoảng 20% lời khuyên và các nghiên cứu (đoán rằng người dùng không hưởng lợi từ những quy trình gương mẫu trên poster). Những lợi ích người dùng có được là từ sự làm việc chăm chỉ của nhóm làm sản phẩm; vì vậy một quy trình đơn giản tốt hơn là một quy trình đấy tính lý thuyết.

Đột nhiên, tôi chuyển thắc mắc tới những dự án khác khi áp dụng UCD. Đã có nhiều thảo luận về wireframe, nhưng điều gì thật sự phía sau chúng? Liệu có phải tôi là số ít người áp dụng phương pháp tinh gọn? Điều gì giúp chúng ta tạo nên những thiết kế thành công? Quy trình thực tế đằng sau những poster kia thực sự thế nào? Nó có phải là khuôn mẫu hiệu quả cho nhiều người thiết kế?

Lý do để tìm hiểu

Tôi quyết định tìm một số câu trả lời cho thắc mắc của mình về quy trình thiết kế. Tôi tự ép mình kiểm tra tính ứng dụng của quy trình thiết kế UCD trên cấp độ toàn cầu. Tôi sẽ chia sẻ thắc mắc của mình trong bài viết này.

Nếu bạn là người mới gia nhập thế giới UX design, đang học kinh nghiệm về cách làm việc của những người thiết kế khác thì bài viết này sẽ rất có ích.

Nếu bạn một người thiết kế chuyên nghiệp thì hãy xem bài viết như một tín hiệu tích cực để cân nhắc lại quy trình thiết kế của mình. Chúng ta đều quá bận rộn. Đây là lúc thở đều và xem xét điều gì là hiệu quả và không hiệu quả trong thiết kế sản phẩm - bên cạnh UCD.

Tôi có một Startup nho nhỏ, chúng tôi may mắn có được nhà đầu tư và quyết định đối mặt với thử thách: Tạo ra một công cụ thiết kế trải nghiệm - hỗ trợ khả năng làm việc nhóm - với quy trình thiết kế cụ thể.

Tôi thấy rằng team mình đang cố gắng đấu lại Godzilla (hay Twin Lannister nếu bạn thích Game of Thrones và phim của Nhật). Nếu nhóm UX của tôi không thể áp dụng cách tiếp cận UCD truyền thống, làm sao biết chắc những framework lý thuyết sẽ giúp chúng tôi thiết kế một công cụ phù hợp với tất cả lĩnh vực trong thế giới sản xuất thực tế? Liệu có một quy trình thiết kế mẫu nào thường được áp dụng trong các công ty? Tôi không có câu trả lời.

Chúng tôi thấy rằng cần tìm ra sự thật về quy trình đang được sử dụng. Nghiên cứunày sẽ vô cùng ý nghĩa với cộng đồng. Một công cụ tốt cho thiết kế quy trình tương đương với việc designer ít phải mất thời gian cho công cụ, nhiều thời gian hơn cho việc sáng tạo và tạo ra nhiều thiết kế tốt hơn cho tất cả chúng ta. Phần thưởng rõ ràng rất giá trị, chỉ cần: đi ra ngoài, bắt tay vào nghiên cứu, tìm và học hỏi về quy trình thiết kế thực tế (nếu nó tồn tại) và săn lùng đúng nghĩa những điểm tổn thương để giúp cho nhóm làm việc dễ dàng và thoải mái hơn. Chúng tôi đóng gói những công cụ và đi tới những điểm nóng để trò chuyện và thực hiện một số nghiên cứu tại San Francisco và Silicon Valley.

Hãy đọc tiếp nếu bạn muốn biết những gì tôi tìm hiểu được về quy trình thiết kế!

Quy trình phát triển khách hàng và hàng ngàn cuộc phỏng vấn cá nhân chi tiết

Cuộc sống của một startup hiện đại toàn là những việc về thiết kế Ux, thậm chí người sáng lập còn không nhận ra nó. Drake Marinet (Wall Street Journal, Stanford University) cho rằng hầu hết các lean startup (khởi nghiệp tinh gọn) là những ứng dụng đơn giản về các nguyên tắc thiết kế đối với môi trường kinh doanh. Tôi hoàn toàn đồng ý.

Khi bắt đầu một dự án, bạn thực sự cần nói chuyện với những người trong các nhóm mục tiêu. Nơi đây xảy ra những thứ mà chúng ta thường biết tới như IDIs (individual in-depth interviews - phỏng vấn kỹ từng cá nhân): thường thì trong các cuộc phỏng vấn cá nhân bạn sẽ cố gắng học nhiều nhất có thể về các vấn đề của người tham gia trong một lĩnh vực chuyên biệt trong đời sống của họ.

Nhóm hướng tới những người thiết kế trải nghiệm, vì vậy chúng tôi đặt cuộc hẹn với khoảng 50 người (gặp riêng và qua Skype). Mỗi người đều được hỏi một vấn đề giống nhau: Quy trình thực sự của thiết kế UX. Chúng tôi đề nghị các nhà thiết kế kể các câu chuyện trong quy trình thường nhật dựa trên các dự án của chính họ. Trong suốt các buổi phỏng vấn, chúng tôi hỏi rất nhiều câu hỏi chi tiết để học nhiều nhất có thể về quy trình. Chúng tôi ít khi hỏi về vấn đề của các quy trình thiết kế, cố gắng giúp họ tập trung vào câu chuyện và sau đó xác nhận lại đánh giá bằng việc đặt câu hỏi (ví dụ, “tôi hiểu rằng X là vấn đề trong dự án cụ thể này?”). Chúng tôi cố gắng nhất có thể để không đưa ra quan điểm của mình với họ. Để họ nói là điều quan trọng hơn cả.

Chúng tôi đã phỏng vấn những tên tuổi của làng UX như Mike Kuniavsky, Indi Young, Luke Wroblewski, Peter Merholz, Brandon Schauer, Jeffrey Kalmikoff, John Zeratsky và một số người trong lĩnh vực liên quan nhưng cũng rất giỏi về thiết kế UX. Một số họ là những Ux designer in-house (công ty làm sản phẩm), một số từ các công ty tư vấn và một số làm tự do. Đáng ngạc nhiên là những vấn đề xuất hiện khá giống nhau ở cả ba nhóm trên.

Đây là một kinh nghiệm rất đáng giá và tôi khuyên bạn cân nhắc tới những nghiên cứu trong mọi dự án. Nó sẽ cung cấp cho bạn vô vàn kiến thức sẵn có - một phương tiện để làm việc.

Quy trình xuất hiện từ các câu chuyện của người thiết kế

Đầu tiên, chúng tôi không thấy có gì nổi trội, và không thấy có gì khác biệt trong trạng thái tốt nhất. Hầu hết các quy trình đều khá giống quy trình UCD đơn giản nhưng đã được cắt gọt cho phù hợp với những người thiết kế. Linh hoạt là thứ giúp chúng ta vượt qua những thử thách trong các dự án. Quy trình từ đó sẽ được “uốn” theo dự án.

Cách tiếp cận với một trang web thương mại điện tử thì khác so với cách mà chúng ta thiết kế ứng dụng điện thoại trong lĩnh vực sức khoẻ (có thể đoán rằng do vấn đề bối cảnh), và khách hàng nhà nước thì khác so với các công ty tư nhân và những công ty khởi nghiệp. Ngoài những trường hợp ngoại lệ, hầu hết các quy trình đều giống nhau đáng ngạc nhiên.

1. Lựa thông tin về các vấn đề

Hầu hết những người thiết kế UX cần có tư duy phán đoán trong giai đoạn đầu của dự án. Chúng ta cần phát hiện nhiều nhất có thể về 3 chữ P (People - con người, Problem - Vấn đề, Project - dự án). Những hoạt động trong giai đoạn này tương phản với cách tiếp cận UCD thông thường, chúng khá đơn giản:

  • Họp với khách hàng (bất kể là người trong công ty hay khác công ty) và nhìn nhận những yêu cầu của sản phẩm (thông thường được viết trong trong những mẫu yêu cầu dự án);
  • Để ý và phân tích xu hướng (tất nhiên là những nhà thiết kế thích việc này).

Chúng ta hiếm khi quan sát quá trình phỏng vấn người dùng, nhưng viết những kịch bản người dùng chấp nhận được dựa trên tài liệu yêu cầu của sản phẩm. Câu chuyện của người dùng (User stories) đôi khi được dựa trên đặc điểm cá nhân (personas) thứ không được lưu trữ bằng dữ liệu. Các nghiên cứu thực tế và phân tích nhiêm vụ hầu như không được sử dụng bởi những người thiết kế mà chúng tôi hỏi.

2. Khâu sẵn sàng thiết kế

Đây rõ ràng là một phần lý tưởng của quy trình. Nó hoàn toàn được thực hiện bằng những công cụ tương tự (như trong UCD mẫu). Tôi chưa thấy bất kỳ người thiết kế đơn lẻ nào lại không sử dụng những phác hoạ nhanh hoặc những mẫu prototype trên giấy ở giai đoạn này.

Những nhà thiết kế cố gắng làm việc trên vật liệu ở bước đầu tiên trong quy trình và tìm kiếm những thứ giá trị trong thiết kế. Ở bước này không chỉ là làm theo tài liệu và còn là bước khám phá và sáng tạo. Hầu hết đều sử dụng Adaptive Path’s multipage templates (xem clip) để nhanh chóng tạo ra những phác thảo liên quan.

 

Không may, việc kiểm thử ở giai đoạn này không phổ biến. Chúng ta thích lựa lấy phần mạo hiểm khi chọn phương án cùng những nhà đầu tư và bắt đầu tới quy trình xác định.

3. Thiết kế

Tương phản với cách tiếp cận agile phi tài liệu, hầu hết nhà thiết kế được hỏi đều tạo ra những wireframe và prototype rồi viết về cách trải nghiệm sau đó đưa tận tay những người lập trình.

Các phác thảo từ những giai đoạn trước đó vẫn là những bản phác sơ và không được kiểm thử. Thiết kế chi tiết được giao cho những người thiết kế giao diện. Tóm lại, chúng ta tạo ra các mẫu, trong khi các nhà lập trình và thiết kế giao diện phải vật lộn để giải quyết vấn đề.

4. Phê duyệt

Đây là một bước rất đặc biệt trong quy trình thiết kế. Nghiên cứu tài liệu và khả năng chuyển giao được coi là yếu tố thuyết phục trong quy trình duyệt thiết kế. Điều này không khác nhau giữa các nhóm thiết kế, tự do, in-house, hay công ty tư vấn. Được duyệt là một “đỉnh cao” trong quá trình của chúng ta. Không ai trong số chúng ta muốn thiết kế của mình đi thẳng tới thùng rác, và tôi cũng thấy rất nhiều dự án tuyệt vời bị từ chối chỉ vì câu chuyện đằng sau quá trình thiết kế đơn giản là không thuyết phục. Và đoán xem điều gì xảy ra? Rất nhiều người thiết kế được phỏng vấn thực sự tạo ra một tài liệu trình bày đặc biệt để kể một câu chuyện với người đầu tư. Tài liệu trình chiếu chỉ ra các giai đoạn tiến hành, chuyển giao, tương tác và họ nhắm tới việc cung cấp cho những nhà đầu tư mọi thông tin có thể.

Bốn điểm được nhắc tới ở trên - thông qua những người được phỏng vấn - tạo nên một mẫu quy trình thực tế trong quá trình thiết kế mà chúng ta thường làm. Bạn có thể để ý rằng không nhiều nghiên cứu tương tác được thực hiện. Thật đáng buồn là các nghiên cứu khả dụng cổ điển lại không xuất hiện trong quy trình. Tại sao? Câu trả lời đơn giản: Chi phí rất hạn chế. Vấn đề xuất hiện phổ biến trong những công ty mà tôi cùng làm việc. Chi phí hạn chế khiến người thiết kế UX phải xoay sở với quy trình và không thực hiện việc nghiên cứu.

Tôi tin rằng câu trả lời tốt nhất cho vấn đề này là những cách nghiên cứu nhỏ lẻ. Các công ty khởi nghiệp cần áp dụng những phương pháp nghiên cứu nhỏ phù hợp với từng giai đoạn của quá trình phát triển, hợp với tình hình của công ty. Một trong những thách thức của cộng đồng UX trong những năm tới là nền tảng của việc nghiên cứu nhỏ, linh hoạt và giới thiệu nó trong quá trình thiết kế thực tế.

Houston, chúng ta có rất nhiều vấn đề hay xảy ra.

Trong quá trình tìm hiểu, chúng tôi có gắng hướng tới vấn đề thường xảy ra trong quá trình thiết kế với những người được hỏi - được gọi những mẫu vấn đề gặp phải. Ngạc nhiên là những vấn đề tương tự xảy ra giống nhau với những người được phóng vấn. Rõ ràng, rất nhiều trong số họ luôn có trong tay ba vấn đề khó giải quyết khiến công việc không được như ý:

1. Mở rộng và hiểu về quy trình thiết kế: Làm sao gắn kết cả nhóm với quy trình và chỉ ra rằng người thiết kế trải nghiệm không phải là những người yếu kém trong việc vẽ vời, thiếu tài năng trong mỹ học. Làm sao để giải thích với họ rằng thiết kế trải nghiệm là những người làm việc đằng sau wireframe?

2. Trao đổi trong nhóm: Làm sao để trao đổi với mọi người trong nhóm thông qua quy trình và thực sự thấy được những góc nhìn, quan điểm đa dạng để có thể có thiết kế tốt hơn?

3. Chứng tỏ quy trình để được duyệt: Làm sao để trình bày quy trình thực hiện tới những người quyết định dự án (khách hàng, người trả tiền, sếp…) và lập trình viên để thực sự có được sự toàn tâm toàn ý?

Một trong những người thiết kế trải nghiệm mà chúng tôi được hỏi nói như sau:

Bạn có biết rằng điều gì dễ gây tổn thương nhất trong công việc của tôi không? Sự quan liêu. Họp hành. Tôi thà thiết kế hơn là phải tranh luận về các chi tiết. Chúng ta nên thực hiện một phần nào đó online thay vì gặp mặt. Duyện online hơn là duyệt bằng họp hành.

Người khác thì nói:

Thật khó mà chỉ ra quy trình với khách hàng và để họ có sự thấu hiểu tầm quan trọng của thiết kế.

Chúng ta hẳn đã cố gắng giải quyết ba vấn đề trên không biết bao nhiêu lần, nhưng chúng ta vẫn còn thiếu tính hiệu quả trong phương pháp. Kết quả này lấy đi thời gian dành cho sáng tạo và nghiên cứu.

Phương pháp của tôi trong vấn đề này là: Chúng ta là những người thiết kế UX cần giải quyết ba vấn đề nhạy cảm trên để dành nhiều thời gian cho những việc khác. Chúng ta cần chứng tỏ công việc của mình bằng wireframes, lan truyền sự hiểu biết về thiết kế trải nghiệm và thể hiện bản thân tốt hơn trong công ty cũng như ngoài công ty. Điều này sẽ giúp tăng thêm tầm ảnh hưởng của mình.

Quy trình thiết kế UX thực tế cần những điều chỉnh, và khi chúng ta chia sẻ những mẫu quy trình làm việc và cả những vấn đề gây khó khăn, chúng ta có thể cùng giải quyết chúng. Đây là điều tích cực nhất trong nghiên cứu này.

Những thứ rút ra từ nghiên cứu

Nghiên cứu chỉ ra rằng những người thiết kế trải nghiệm thường thay đổi cách tiếp cận UCD cổ điển có phần phức tạp. Ít tập trung vào nghiên cứu khả dụng và tập trung vào các hoạt động của thiết kế (so với UCD cổ điển) là những thứ nổi bật trong quy trình thực sự.

Một quy trình được thay đổi phù hợp với mỗi công ty và khách hàng sao cho hiệu quả nhất, nhưng nó vẫn còn những vấn đề hay gặp phải cần phải giải quyết.

Cuối cùng cần nhắc tới là UCD truyền thống vẫn tạo cảm hứng cho công việc của chúng ta. Cái poster đó (đang treo tại công ty tôi) vẫn nhắc nhở tôi sự cần thiết của việc tuỳ chỉnh trong quá trình thiết kế. Sau khi truyện trò với rất nhiều đồng nghiệp, tôi cũng tự hỏi chúng ta có nên có một cái poster cập nhật quy trình này. Nó sẽ giúp rất nhiều người thiết kế UX bước những bước đầu tiên trong lĩnh vực này và có thể có hiệu quả giáo dục với cả người trong và ngoài công ty.

Người dịch: Batsana

Nguồn: ceros