Thỏa hiệp là một phần trong thiết kế. Hãy cùng iDesign và tác giả Brian McKenna tìm hiểu những bí quyết để giúp đôi bên, quan trọng nhất là người dùng hài lòng.

Thiết kế là một công việc vất vả. Chúng ta đặt nhiều tâm huyết để nghĩ ra concept. Chúng ta làm việc chăm chỉ đế xác định mục tiêu của người dùng và đặt chúng vào trong sản phẩm. Chúng ta làm ra những hình ảnh chuyển động để hướng dẫn và định hướng người dùng. Chúng ta chăm chút từng chi tiết để làm người dùng hài lòng, như đặt cả linh hồn và tính mạng của mình vào mỗi sản phẩm.

Và dù có tâm huyết đến đâu đi nữa, không phải mọi thứ chúng ta nghĩ ra đều có thể để vào thiết kế. Nghĩa là chúng ta phải biết cách từ bỏ.

Có nhiều nguyên nhân dẫn đến vấn đề này. Có thể là dữ liệu người dùng cần không có sẵn hoặc không dễ thu thập được. Chi phí thiết kế có thể quá đắt hoặc quá tốn kém, khiến mô hình MVP (tạm dịch: mô hình lập trình) mất đi nhiều yếu tố quan trọng. Dù sao đi nữa, ở một thời điểm nào đó, chúng ta sẽ được yêu cầu nhìn lại những gì đã thiết kế và phải thỏa hiệp với một phương án mới. Sau đây là một số kinh nghiệm quan trọng.

Cố gắng hết sức có thể

Khi bắt đầu thiết kế, mối bận tâm đầu tiên và trên hết chính là hỗ trợ người dùng cùng những mục tiêu của họ. Đây là vấn đề bạn cần cực kỳ lưu ý. Dù sẽ đến một giai đoạn bạn phải thỏa hiệp, bạn nên chú ý đến mối bận tâm này cho đến khi không thể được nữa. Có nhiều lý do giải thích cho vấn đề này.

Đầu tiên, mỗi thay đổi trong thiết kế có thể ảnh hưởng đến những yếu tố khác. Chúng ta là một hệ thống thiết kế tổng thể gồm những yếu tố có tương tác lẫn nhau. Thỏa hiệp ở giai đoạn đầu đem lại nhiều lợi ích. Bạn có thể đề cập đến những vấn đề, tránh những rủi ro xảy ra khi thay đổi về sau. Ngược lại, thay đổi càng sớm, tác động của bạn càng lớn.

Nếu bạn kéo còi quá sớm, bạn sẽ làm yếu đi nền tảng của toàn bộ hệ thống. Hãy nghĩ đến một hòn đá lăn xuống đồi. Hòn đá ở gần chân đồi sẽ lăn nhanh về đích. Hòn đá rơi từ đỉnh đồi có thể va chạm với nhiều hòn đá khác và gây ra sạt lở. Trong lúc làm việc, thỏa hiệp càng sớm, tức là vị trí bạn để đá lăn càng cao.

Điều thứ hai, bảo vệ tình trạng ‘lý tưởng’ của công việc thì dễ hơn bảo vệ ý tưởng hay vốn đã bị bác bỏ. Nhiều hệ thống có thể không được xây dựng chính xác như thiết kế, nhưng thiết kế lý tưởng vẫn đáng được bảo vệ. Khi những nhà thiết kế thỏa hiệp, quan trọng là đánh dấu lưu giữ tình trạng thiết kế mong muốn là gì, để những phiên bản sau này có một cột mốc để hướng tới.

Bảo vệ tình trạng ‘lý tưởng’ của công việc
thì dễ hơn bảo vệ ý tưởng hay mà đã bị bác bỏ

Điều này có thế đem lại tác động mạnh mẽ nếu bạn đã kiểm tra trải nghiệm của người dùng về tình trạng lý tưởng và đã xác nhận với họ. Như thế , nhóm của bạn có thể cố gắng làm đúng những gì bạn đã thiết kế, lấy được dữ liệu bạn cần, hoặc thực hiện những chuyển đổi cần thiết thậm chí ngay sau khi MVP đã ra mắt.

Cuối cùng, bạn sẽ không bao giờ biết những gì bạn có thể có được. Tôi đã trao đổi với nhiều nhà phát triển trong vài năm qua. Có nhiều lần tôi mong đợi sự thỏa hiệp chỉ đế ngạc nhiên khi biết những gì mình đòi hỏi là hoàn toàn có thể đạt được.

Trong một trường hợp, tôi nhìn dữ liệu có sẵn ở hệ thống hiện tại và không thấy điều mình tìm. Tôi cho rằng cần phải trò chuyện với những nhà phát triển để tìm hiểu ra nguyên nhân. Tôi khá ngạc nhiên khi câu trả lời là đúng như vậy, vì họ “luôn thu thập dữ liệu nhưng không đưa ra vì không nghĩ chúng sẽ cần thiết.”

Các nhà phát triển (developers) luôn thu thập dữ liệu
nhưng không đưa ra vì không nghĩ chúng sẽ cần thiết.

Công ty của bạn có thể thu thập dữ liệu của những sản phẩm khác có thể có ích cho sản phẩm của bạn. Phần lớn các công ty có những nhân viên hiểu biết tường tận mọi việc công ty làm, nhưng bạn sẽ không biết nếu không hỏi. Điều này dẫn tới điều thứ hai.

Hiểu rõ dữ liệu

Một trong những vấn đề thông thường nhất cần thỏa hiệp là cung cấp dữ liệu mà người dùng cần. Dù thông tin bây giờ có phần tràn lan, không phải lúc nào người dùng cũng có những dữ liệu họ cần, đặc biệt là với những tên miền phức tạp.

Khi bắt đầu thảo luận về những gì có thể được xây dựng, quan trọng là bạn cần biết về dữ liệu. Điều tra kho dữ liệu ở bất cứ đâu để biết dữ liệu nào có trong đó. Nếu bạn không có quyền truy cập kho dữ liệu, hãy hỏi xem mẫu dữ liệu chuẩn được tạo ra cho hệ thống. Tìm hiểu về dữ liệu mà hệ thống đang sử dụng và các hệ thống khác đang dùng. Bạn không bao giờ biết dữ liệu bạn đang tìm trốn ở đâu. Nếu bạn chủ động tìm hiểu, bạn sẽ ở hiểu rõ tình hình tường tận hơn.

Điều này cũng giúp bạn hiểu những gì có thể hiệu quả nếu điều bạn muốn lại không khả thi. Thỏa hiệp không chỉ là bỏ đi những gì bất khả. Đôi khi còn là điều chỉnh điều bạn muốn cho người dùng thấy để được ủy nhiệm kỹ hơn. Có thể đó không phải chính xác là những gì họ cần, mà là gần như vậy, vì thật khó khi bạn không biết phương án nào là khả thi để thực hiện.

Điều này cũng cho thấy tầm quan trọng khi làm việc ăn ý với các thành viên còn lại trong nhóm. Nếu bạn liên tục liên lạc/làm việc với người quản lý sản phẩm và nhà phát triển, bạn có thể yêu cầu sớm dữ liệu mới trong quá trình làm việc. Điều này mang lại cho nhóm nhiều thời gian hơn để phát triển sản phẩm hoàn thiện. Nếu bạn chỉ chăm chăm vào mẫu thiết kế, đến cuối cùng sẽ rất khó để thỏa hiệp. Bạn làm cho nhóm có ít thời gian để thực hiện các thay đổi cần thiết. Trao đổi sớm và liên tục sẽ giúp bạn dễ dàng có được những gì mình cần.

Bản thiết kế “hoàn chỉnh” bao giờ cũng tốt hơn

Mục tiêu của bạn là hỗ trợ nhu cầu của người dùng, và các thiết kế của bạn cũng vậy. Nhưng bạn không thể giúp người dùng của mình chỉ với một mẫu mock-up (tạm dịch: mô hình thu nhỏ được thiết kế sẵn) hoàn hảo. Người dùng của bạn không thể làm tất cả mọi thứ với JIRA (công cụ quản lý dự án, kiểm soát và theo dõi các vấn đề xảy ra trong dự án, quản lý các phản hồi từ phía người sử dụng). Để giúp người dùng của bạn, cần phải có một thứ đã được làm ra. Đây là lý do tại sao sự thỏa hiệp rất quan trọng. Như một quy luật chung, có lẽ tốt nhất là nên sai lầm khi mua một thứ gì đó được xây dựng để đặt nó vào tay người dùng.

Tuy nhiên, ở một số thời điểm, thỏa hiệp thực sự có thể đi quá xa. Nếu những gì nhóm có thể/sẵn sàng xây dựng là không đủ cho người dùng, sản phẩm có thể gây ra nhiều thiệt hại. Những gì bạn xây dựng có thể làm người dùng của bạn thất vọng. Nó có thể khiến người dùng mất niềm tin vào sản phẩm. Bạn có thể làm tổn thương thương hiệu của mình. Một số sản phẩm giúp gầy dựng lại những điều này, nhưng không phải công ty nào cũng thành công.

Là một desginer, bạn cần phải lên tiếng nếu bạn nghĩ rằng những gì đang được xây dựng bắt đầu mất chất lượng. Thỏa hiệp có thể trở thành một con dốc trơn trượt, và có những dấu hiệu hiếm khi rõ ràng rằng thỏa hiệp cuối cùng này tạo ra sự khác biệt giữa hữu ích và không. Hãy luôn nghĩ đến người dùng và đảm bảo rằng họ sẽ nhận được những sản phẩm có giá trị. Thử lại với phiên bản đã qua thỏa hiệp nếu bạn có thể. Cho phép người dùng góp ý theo bất kì cách nào để đảm bảo nhu cầu của họ được xem xét. Cố gắng thu thập càng nhiều thông tin càng tốt để đưa ra được quyết định tốt nhất có thể.

Ai cũng là người chiến thắng

Mục tiêu của sự thỏa hiệp không phải là ‘ thắng’. Mục tiêu của sự thỏa hiệp là làm những gì tốt nhất cho tất cả các bên – người dùng và doanh nghiệp cụ thể. Sản phẩm cần phải được thiết kế để có giá trị. Nhưng thiết kế đó không đem lại giá trị cho sản phẩm. Nếu người dùng muốn có những giá trị lớn lao hơn, hãy giúp họ. Nhưng đồng thời hãy hiểu vì sao những người còn lại trong nhóm lại muốn thay đổi. Bạn đang làm việc như một nhóm, vì thế hãy cùng cả nhóm tiến lên theo cách tốt nhất.

Không ai muốn thỏa hiệp, nhưng đó là một phần quan trọng trong quá trình làm việc. Đó cũng là một kỹ năng cần thời gian để phát triển. Nếu bạn ngần ngại, thiết kế tuyệt vời của bạn có thể không bao giờ được nhìn thấy ánh sáng. Nếu bạn nhường nhịn, người dùng có thể không được hỗ trợ đầy đủ. Tìm ra phương hướng đi đúng đắn luôn cần sự ứng xử tài tình, niềm tin và thời gian.

Người dịch: Long Hwarang

Nguồn: UXPlanet.org