Nợ thiết kế (Design Debt)

Kim Dinh Son
8 min readMar 16, 2021

--

Rõ ràng trong đời không có ai là muốn nợ nần (tiền bạc) cả. Dĩ nhiên đó là về mặt “lý thuyết”. Có 3 kiểu người mà tôi đã quan sát được trong thực tế:

  • Không thích nợ nần, và không nợ gì cả
  • Không thích nợ nần, nhưng vẫn nợ
  • (Nhận định của tôi) Thích nợ nần 🙃

Trong product design có thuật ngữ Design Debt ám chỉ việc thiết kế tập trung vào ngắn hạn mà gạt đi những ý tưởng tốt, có ích cho tương lai. Nói cách khác là những thiết kế không có tính bền vững và chỉ chăm chăm giải quyết vấn đề trước mắt.

Nếu để design debt xảy ra, chúng ta không thể khẳng định “lấy người dùng làm trọng tâm” để bảo vệ cho ý tưởng của mình, việc đó không giải quyết vấn đề chính nào và cũng không đủ thuyết phục khi nói chuyện với các stakeholder.

Đầu voi đuôi chuột

Chúng ta viện cớ những lý do khách quan như do vấn đề kĩ thuật hiện tại chưa đáp ứng, chiến lược kinh doanh chưa hoàn thiện, không có đủ budget, không có thời gian, … và chúng ta vẫn “cố đấm ăn xôi” để cho ra một bản thiết kế với “life time” ngắn. Tất nhiên, chẳng mấy ai lại tiếp tục “trả nợ” vì luôn luôn lại vướng bận vào những vụ nợ nần khác (qua sprint này tới sprint khác, release này tới release khác).

Lấy vài ví dụ đơn giản như sau:

  • Phần phỏng vấn và khảo sát để nghiên cứu khách hàng không được thực hiện vì chưa có budget
  • Một bản UI prototype không được đem đi Usability testing vì không tuyển được ứng viên
  • Một form thiết kế (quan trọng) không được chỉnh sửa nhất quán vì cả luồng sẽ được chỉnh sửa lại
  • Ý tưởng thiết kế chỉ tập trung cho những thứ mà team tech xác nhận làm được trong giai đoạn này, và gọi đó là một ý tưởng khả thi

Khi nhìn lại thành quả, tôi nghĩ đa số ai cũng trải qua những tình huống như bức tranh được mô tả dưới đây. Đừng lo, bạn hoàn toàn có thể kiểm soát được nếu thực sự chúng ta ý thức được vấn đề cần phải quản lý Design Debt cũng như Technical Debt.

Image Credit: Product Management Memes FB Page

Những tác nhân chính có thể dẫn đến Design Debt

Các yếu tố khách quan

  • Các manager (thượng tầng) tập trung xây dựng roadmap với đầy đủ các features “hay ho” có value với khách hàng, thị trường và đặc biệt là về mặt business, không thể giám sát những thay đổi nhỏ “bên dưới”.
  • Các leader (trung tầng) dẫn dắt để cân bằng thời gian thực thi, chi phí, sự cam kết, v.v dẫn đến việc trade-off các hạng mục.

Các yếu tố chủ quan

  • Designer luôn design với tầm nhìn ngắn hạn,
  • Chủ yếu focus vào “WHAT” thiếu sự tự vấn bản thân để trả lời “WHY” “HOW”
  • Không hiểu rõ context design và design goal (xem thêm bài viết của tôi về ultimate goal)

Đặc biệt, đối với in-house design team chúng ta luôn tỏ ra hào hứng với những tính năng mới, nói về những gì chúng ta sẽ đạt được “WOW” mà ít khi nghĩ tới chúng ta sẽ phải đối mặt những gì. Hay “quên” trả lời câu hỏi “WHY”. Nên nhớ rằng, một khi đã bước vào vòng xoáy nợ nần, mọi thứ lâu dần sẽ thành thói quen.

Trong bài viết này liệt kê một số ví dụ điển hình những lý do dẫn đến Design Debt.

https://uxdesign.cc/what-is-design-debt-and-why-you-should-treat-it-seriously-4366d33d3c89

Tầm quan trọng của việc lập kế hoạch và quản lý nợ thiết kế

Tôi chia làm 3 cấp độ trong việc tiến hành thiết kế.

  • Cấp độ 1: thiết kế theo “đề bài” cho trước, hoàn thành trước deadline (yêu cầu bởi bussiness team, leader). Sửa thiết kế cho đến khi được chấp thuận. Tập trung vào trả lời câu hỏi “WHAT”.
  • Cấp độ 2: có sự “phản chiếu" khi tiếp nhận yêu cầu, tính toán ước lượng thời gian và khối lượng các công việc sẽ hoàn thành, commit lại timeline và yêu cầu nguồn lực hỗ trợ. Tập trung vào trả lời câu hỏi “WHY”.
  • Cấp độ 3: tạo định hướng chiến lược thiết kế dựa trên tầm nhìn chung của sản phẩm, đánh giá sự ưu tiên các hạng mục, tạo ra sự kết nối trung tâm giữa mọi bên (bussiness, marketing, tech, design, risk, operation, v.v). Tập trung vào trả lời câu hỏi “HOW”.

Hai yếu tố chính tác động đến khả năng deliver: nguồn lực, khối lượng yêu cầu. Mấu chốt của việc lập kế hoạch là điều phối và phân bổ 2 yêú tố trên. Ba phương pháp luận được áp dụng rộng rãi nhất hiện nay là Design thinking, Lean và Agile, tốt nhất là kết hợp được cả ba:

Một quy trình phát triển sản phẩm được xây dựng dựa trên 3 phương pháp luận phổ biến hiện nay: Design thinking, Lean và Agile. Trả lời 3 câu hỏi WHY — WHAT — HOW? Tham khảo: https://www.oreilly.com/library/view/understanding-design-thinking/9781491998410/ch01.html

Hãy xem các minh hoạ thời gian bỏ ra để deliver trong 1 interation dưới đây.

Cấp độ 1: Nợ thiết kế sẽ bắt đầu ngay khi bắt đầu deliver dến developer, trải qua quá trình lên kế hoạch, team phát triển thống nhất làm cái gì trước, cái gì sau, do đó ở cuối interation có thể sẽ bắt đầu tồn đọng nợ thiết kế (chẳng hạn nguồn lực team không đủ để thực hiện và fix bug). Ở cấp độ này, hầu như không có sự xuất hiện của việc quản lý nợ thiết kế.

Qua từng interation (1–2 tháng), số lượng nợ thiết kế có thể được cộng dồn, vì khi số lượng requirement được tăng thêm đồng nghĩa số lượng nợ thiết kế được phát sinh. Lưu ý rằng, những thứ được coi là nợ thiết kế trong tầm nhìn ngắn hạn (1 vài interation hoặc những MVP đầu tiên) thường được ưu tiên thấp. Designer muốn tinh chỉnh nhỏ như đổi vị trí nút, màu sắc một dòng text hoặc sửa copy nhưng nguồn lực dev không cho phép maintain những thay đổi nhỏ đó. Rất khó để Product Owner ra quyết định cải thiện những thay đổi “lắt nhắt” ấy hay là ưu tiên những tính năng chính, xử lý những core component trước — những thứ đã được commit sẽ release sắp tới.

Cấp độ 2:

Áp dụng Design thinking, bằng cách liên tục trả lời các câu hỏi “What's possible?” và “How do we deliver?” ta luôn có trong tay một danh sách các vấn đề chắc chắn giải quyết và chưa được giải quyết. Nợ thiết kế sẽ được quản lý ngay từ đầu và được chuyển thành những requirement, chúng sẽ được đưa vào trong lần planning ở interation tiếp theo.

https://www.departmentofproduct.com/blog/managing-ux-debt/

https://www.nngroup.com/articles/ux-debt/

Cấp độ 3:

Ở cấp độ này, sẽ tập trung nói đến design strategy, trong đó sẽ có những tính toán khi nào sẽ xử lý nợ thiết kế và xử lý nó ở bước nào, làm sao để xử lý chúng (conduct user research, align with business strategy, …).

Ngăn ngừa nợ thiết kế

Những thứ hiện hữu thì dễ nhận diện hơn là những thứ nằm ở tương lai. Giống như chúng ta thường nghĩ đến chữa bệnh thay vì ngừa và phòng tránh bệnh tật. Nợ thiết kế xảy ra hầu hết là do những thiếu sót trong mọi quá trình phát triển sản phẩm. Việc nghiên cứu và quan sát người dùng chưa đầy đủ, lên ý tưởng vội vàng hoặc bị chệch trọng tâm, khi review chỉ tập trung vào những vấn đề chính mà bỏ qua nhiều tiểu tiết. Cách phòng ngừa hữu hiệu nhất là liên tục nhận phản hồi từ nhiều phía, càng đa dạng càng tốt.

“There’s no shame in a project having design debt.”

“Tackling design debt? Fix the most visible elements first.”

“The best defense against design debt is a constant stream of feedback, both internal and external.”

Nguồn: Invsion, Insign Design

“Lắng nghe” chính là chìa khoá. Tuy nhiên bạn cũng cần phân biệt việc lắng nghe với sự cầu thị 100% so với việc đơn giản là cho xong việc (đằng nào cũng vẫn nợ tiếp). Cách áp dụng tư duy phản biện tốt (Crititcal thinking) khi đánh giá và nhận định vấn đề chính là lắng nghe và thực sự bình tĩnh trước mọi thông tin, bạn cần sự cởi mở, sẵn sàng đón nhận mọi ý kiến trái chiều. Nên nhớ là, quyết định cuối cùng vẫn là ở bạn nên việc bảo vệ tức thời quan điểm của bạn chỉ nói lên rằng bạn ra quyết định quá nhanh chóng vội vàng, chưa có sự chắc chắn.

Tổng kết

Nợ thiết kế là một phần của phát triển sản phẩm, vì vậy cần quản lý nó. Tuỳ theo cấp độ quản lý, nợ thiết kế sẽ được giải quyết theo thời gian nhưng điều đó diễn ra sớm hay muộn là phụ thuộc việc điều phối và phân bổ nguồn lực cũng như yêu cầu của team. Trong đó, áp dụng bô 3 phương pháp luận Design Thinking, Lean và Agile là một cách quản lý nợ thiết kế tối ưu và hiệu quả. Cuối cùng, người dùng cuối cùng đã và đang sử dụng những thứ mà bạn “tạo ra”, đừng biến nó trở nên “kém hoàn thiện" vì một vài lỗi “ngớ ngẩn" do không xử lý được nợ thiết kế (giống như mặc chiếc áo bị rách vậy 😂).

Originally published at https://son-oh-yeah.github.io on March 16, 2021.

--

--