kỹ năng bị coi thường nhất của designer: xóa

Chiều nay đầu tóc bù xù quá nên mình chạy ra tiệm hớt tóc nhỏ ở đầu hẻm. Tiệm chỉ có đúng một cái ghế, một tấm gương lớn với một ông chú làm nghề chắc cũng hơn hai chục năm. Chú choàng tấm vải lên người mình rồi hỏi gọn lỏn: "Hớt sao con?" - "Dạ chú tỉa gọn lại giùm con là được."

Xong mình ngồi im nhìn vô gương. Tiếng kéo kêu lách cách đều đều, tóc vụn rơi lả tả xuống tấm vải choàng. Suốt ba mươi phút, chú chẳng nói thêm câu nào, chỉ thỉnh thoảng nghiêng đầu mình qua một bên, nheo mắt ngắm nghía rồi lại bấm kéo cắt thêm một nhát.

Ngồi nhìn trong gương tự nhiên mình nhận ra một chuyện khá thú vị: nguyên cả buổi chiều, chú chẳng gắn thêm vô đầu mình bất kỳ sợi tóc nào cả, chỉ toàn cắt bớt đi. Vậy mà lúc đứng dậy phủi tóc, nhìn mặt mũi sáng sủa hẳn ra, móc ví trả tiền mà lòng vui phơi phới.

Nghĩ lại chuyện làm nghề của tụi mình thấy hơi ngược đời. Dân làm sản phẩm tụi mình hễ đụng chuyện là lại nghĩ tới chuyện cộng thêm: khách không hiểu thì chèn thêm câu giải thích, khách không thấy thì đẻ thêm cái nút, luồng khó dùng thì nhét thêm màn hình onboarding hướng dẫn. Hiếm khi nào tụi mình chịu cầm kéo lên tỉa bớt.

Thợ cắt tóc nào cũng rành một kỹ năng mà dân làm sản phẩm tụi mình suốt ngày quên mất: gọt bớt những thứ dư thừa.

Sao gặp chuyện gì mình cũng nghĩ tới thêm trước?

Giáo sư kỹ thuật Leidy Klotz ở Đại học Virginia từng kể một câu chuyện rất đời thường. Một buổi chiều nọ, ông ngồi dưới sàn nhà lắp cây cầu Lego với cậu con trai mới ba tuổi tên là Ezra.¹

Hai cái trụ cầu lúc đó bị lệch nhau, một bên cao một bên thấp nên mặt cầu bị nghiêng. Theo đúng phản xạ của người lớn, ông bố kỹ sư lập tức xoay người ra sau thò tay vào thùng đồ chơi, định kiếm thêm một cục gạch Lego nữa chèn vào bên trụ thấp cho bằng nhau.

Nhưng lúc ông quay lại thì thằng nhóc ba tuổi đã giải quyết xong xuôi rồi: cu cậu chỉ việc rút bớt một khối Lego ở bên trụ cao ra là mặt cầu phẳng lì ngay lập tức.

Bị con trai ba tuổi "out trình" bằng một pha xử lý quá gọn, ông bố kỹ sư đâm ra tò mò thật sự. Mấy năm sau, ông rủ thêm ba đồng nghiệp làm nguyên một chuỗi thí nghiệm tâm lý học bài bản và đăng kết quả lên tạp chí khoa học Nature.²

Trong chuỗi đó, mình ấn tượng nhất là bài toán mái che Lego. Nhóm nghiên cứu đưa cho người tham gia một tấm mái phẳng đặt chênh vênh trên đúng một cục trụ duy nhất nằm ở góc, bên dưới là một khối nền đặc. Nhiệm vụ là phải gia cố sao cho khi đặt một viên gạch thật lên trên thì tấm mái không bị sập. Ai làm được sẽ nhận 1 đô tiền thưởng, nhưng cứ gắn thêm một mảnh Lego mới vào thì bị trừ 10 xu.

Cách giải thông minh và tiết kiệm nhất thật ra siêu đơn giản: chỉ cần nhấc bỏ đúng cái cục trụ lẻ loi ở góc đó ra, rồi đặt tấm mái nằm áp sát xuống khối nền đặc bên dưới là bao vững, chẳng tốn một xu nào.

Ấy vậy mà chỉ có 41% số người tham gia nghĩ ra nước đi này. Hơn một nửa còn lại cứ cặm cụi lấy thêm gạch chèn vào ba góc kia cho đủ bốn cái chân, vừa cực công vừa tự tay trừ sạch tiền thưởng của chính mình.

Mà thói quen đó không chỉ xảy ra khi chơi xếp hình đâu. Nhóm nghiên cứu còn thử nhờ người ta biên tập lại một đoạn văn, sắp xếp lại lịch trình du lịch bị quá tải, hay chỉnh một họa tiết trên lưới cho đối xứng. Dù đề bài cho phép thêm hoặc bớt tùy ý, đa số vẫn lao vào thêm: riêng bài sửa lịch trình đi chơi, chỉ có khoảng 28% số người chịu gạch bớt điểm đến cho đỡ mệt.

Thậm chí khi ông hiệu trưởng mới của trường đại học gửi thư xin ý kiến đóng góp để cải thiện nhà trường, trong tổng số 651 đề xuất gửi về thì chỉ vỏn vẹn 11% khuyên trường nên dẹp bớt những quy định hay chương trình rườm rà.

Không phải vì con người ta ghét sự gọn gàng đâu, mà đơn giản là não bộ không tự nảy số ra phương án trừ đi ngay từ đầu. Những ý tưởng kiểu "thêm cái này, đắp cái kia" lúc nào cũng xuất hiện trước tiên trong đầu, nên tụi mình cứ thế chụp lấy mà làm luôn cho lẹ.

(1) Khi gặp vấn đề, não bộ mặc định đi tìm thứ để đắp thêm vào, còn phương án gọt bớt thì bị bỏ quên.

Vậy nhắc một câu thì có khác không?

Tin vui là có, thậm chí thay đổi rất rõ rệt luôn.

Cũng trong thí nghiệm mái che Lego hồi nãy, khi nhóm nghiên cứu thử dặn trước một nửa số người chơi thêm đúng một câu: "Mỗi mảnh gắn thêm tốn 10 xu, nhưng tháo bớt mảnh cũ ra thì hoàn toàn miễn phí nha", tỷ lệ người chọn cách tháo cục trụ lập tức vọt từ 41% lên 61%.

Câu nhắc nhở đó thật ra chẳng hề gợi ý đáp án hay thay đổi luật chơi gì cả, nó chỉ làm đúng một việc là lôi phương án "bớt đi" ra đặt lên bàn để não bộ kịp nhìn thấy.

Nhóm tác giả còn phát hiện thêm một chi tiết rất đáng suy ngẫm: khi cho người tham gia thong thả làm nháp vài câu đố trước thì tỷ lệ chọn cách lược bỏ tăng từ 49% lên 63%; nhưng nếu bắt họ vừa giải đố vừa phải căng não làm thêm một tác vụ phụ cùng lúc, họ sẽ càng bám chặt lấy phản xạ thêm thắt hơn nữa.

Đọc tới đoạn này mình tự thấy nhột ngang. Tại dân Product Designer tụi mình hầu như ngày nào cũng làm việc trong trạng thái quá tải y hệt vậy: mở chục cái tab Figma, tin nhắn công việc nhảy liên tục, deadline thì dí sát nút. Những lúc đầu óc quay cuồng như thế, phản xạ tự nhiên nhất là cứ vẽ thêm một cái nút hay đắp thêm một cái popup cho xong chuyện.

Nhân tiện, bạn thử giải luôn bài toán lưới ô vuông trích từ chính nghiên cứu trên xem sao nhé. Hãy biến hình dưới đây thành đối xứng cả hai chiều ngang dọc với ít lượt bấm chuột nhất có thể (chỉ cần bấm vào ô để bật hoặc tắt màu):

Nếu phản xạ đầu tiên của bạn là bấm tô thêm màu vào ba góc trống kia cho giống với góc trên bên trái thì cũng cứ yên tâm, bạn có rất nhiềuuuuu đồng đội. Trong thí nghiệm gốc, cũng chỉ có khoảng một nửa số người nhận ra là chỉ cần bấm xóa mấy ô thừa ở góc trái đi là xong.

(2) Muốn nhớ tới chuyện lược bỏ, tụi mình phải tự nhắc thành lời, nhất là những lúc đầu óc đang bị cuốn theo deadline.

Thêm một tính năng thì có mất gì đâu?

Tóc trên đầu tụi mình cứ âm thầm dài ra mỗi ngày mà chẳng cần ai nối thêm sợi nào, nhưng chỉ cần lười đi tỉa vài tháng thôi là biết mặt nhau ngay: vừa bù xù che khuất tầm mắt, vừa hầm bí khó chịu.

Feature trong một cái app cũng sinh sôi theo đúng kiểu đó. Cứ mỗi đợt làm việc qua đi lại mọc thêm một cái nút nhỏ ở góc này, một bộ lọc ở góc kia. Chẳng có đội ngũ nào cố tình thiết kế ra một cái app rối rắm ngay từ ngày đầu cả, mà nó cứ phình to và rối dần lên sau từng đợt update.

Pendo - một nền tảng chuyên đo lường hành vi sản phẩm - từng tổng hợp dữ liệu từ 615 phần mềm và đưa ra một con số khá giật mình: có tới khoảng 80% tính năng trên sản phẩm hiếm khi hoặc chẳng bao giờ được đụng tới, trong khi chỉ khoảng 12% tính năng cốt lõi lại gánh tới 80% lưu lượng thao tác hằng ngày.³

Tất nhiên tụi mình cũng nên đọc số liệu này với một chút tỉnh táo, vì bản thân Pendo bán công cụ phân tích tính năng nên họ có lý do để nhấn mạnh sự lãng phí đó, và mẫu khảo sát cũng chỉ gói gọn trong tệp khách hàng của họ. Nhưng dù coi đây là một góc nhìn tham khảo hơn là quy luật tuyệt đối, con số ấy vẫn rất đáng để suy nghĩ.

Kể cả khi tỷ lệ tính năng thừa ngoài thực tế chỉ bằng một nửa con số của Pendo thôi, cái giá phải trả vẫn quá đắt. Một tính năng chẳng mấy ai xài vẫn cứ nằm chình ình trên giao diện, vẫn chiếm diện tích màn hình, vẫn làm người dùng mới bị ngợp khi lướt mắt qua, và đội kỹ thuật vẫn phải còng lưng bảo trì, sửa lỗi cho nó ở mọi bản cập nhật về sau. Vẽ thêm thì chỉ mất vài ngày, nhưng nuôi nó thì tốn chi phí cả đời sản phẩm.

Pha "cầm kéo tỉa tóc" kinh điển nhất trong lịch sử công nghệ chắc phải kể đến Apple năm 1997. Lúc Steve Jobs vừa quay lại tiếp quản, Apple đang bày bán hàng chục dòng máy Macintosh với đủ loại mã hiệu rối như canh hẹ. Trong cuộc họp, ông chỉ hỏi đội ngũ quản lý một câu rất đời thường: "Giờ bạn bè hỏi tôi nên mua mẫu máy Apple nào thì tôi biết khuyên họ mua cái gì đây?" - và cả phòng họp cứng họng.⁴

Thế là ông bước lên bảng vẽ đúng một ma trận bốn ô vuông: một chiều là máy bàn và laptop, chiều kia là người dùng phổ thông và dân chuyên nghiệp. Mỗi ô chỉ giữ lại duy nhất một sản phẩm, còn khoảng 70% dự án râu ria khác bị khai tử ngay lập tức. Quyết định lúc đó nghe cực kỳ phũ, nhưng chính nhờ nhát kéo ấy mà khách hàng mới hết bị loạn và Apple mới tập trung nguồn lực để lội ngược dòng.

(3) Tính năng trong sản phẩm cũng mọc dài như tóc, nếu không ai chịu khó cầm kéo tỉa bớt thì sớm muộn cũng rối mù.

Mà xóa giỏi thì ai khen?

Nghĩ kỹ thì đây chính là lý do lớn nhất khiến kỹ năng lược bỏ bị xem nhẹ trong môi trường làm sản phẩm.

Lúc bước ra khỏi tiệm tóc với cái đầu gọn gàng, bạn bè gặp mình chỉ khen "nay nhìn sáng sủa bảnh bao thế", chứ chẳng ai chỉ xuống đống tóc vụn dưới sàn rồi tấm tắc khen ông thợ cắt khéo. Những thứ được gọt bỏ đi, một khi đã rơi xuống đất rồi thì chẳng còn ai nhìn thấy để mà ghi nhận nữa.

Trong công việc hằng ngày của tụi mình cũng y hệt vậy. Mở portfolio của anh em designer ra xem, hầu như ai cũng khoe mình vừa thiết kế mới bao nhiêu màn hình, dựng thêm bao nhiêu tính năng hoành tráng. Cuối quý viết báo cáo kết quả công việc, ghi câu "ra mắt thành công 5 tính năng mới" lúc nào nghe cũng kêu hơn hẳn câu "đã dẹp bỏ 3 tính năng thừa giúp giao diện thoáng hơn". Thứ đã bị xóa đi rồi thì làm gì còn UI đẹp đẽ để chụp màn hình đem đi flex.

Bởi vậy, nếu muốn thuyết phục cả team đồng ý cắt bỏ một thứ gì đó, người làm thiết kế buộc phải kể được câu chuyện đằng sau sự biến mất ấy bằng con số và trải nghiệm thực tế: trước kia bước thừa đó làm bao nhiêu phần trăm user bỏ cuộc giữa chừng, và sau khi dẹp nó đi thì luồng thao tác mượt hơn ra sao. Nếu không chứng minh được giá trị của khoảng trống mình tạo ra, người ngoài nhìn vào sẽ chỉ tưởng là mình làm ít việc đi.

(4) Những thứ đã bị xóa đi sẽ không còn hiện diện trên màn hình, nên bạn phải học cách chứng minh giá trị của khoảng trống đó.

Vậy hớt sao cho khỏi lố?

Ai từng trải qua cảm giác ngồi ghế tiệm tóc mà bị thợ ủi lố tay một đường tông-đơ đều hiểu nỗi đau này: tóc đã rơi xuống đất rồi thì không có tổ hợp phím Ctrl+Z nào dán ngược lên đầu lại được, chỉ còn nước đội nón chờ vài tháng cho nó mọc lại.

Chuyện xóa tính năng trên sản phẩm thật cũng tiềm ẩn rủi ro y như thế. Có những nút bấm nhìn trên biểu đồ dữ liệu thấy lượt click lèo tèo vài phần trăm, nhưng lại là công cụ sống còn của một nhóm khách hàng đặc thù - giống như cái nút xuất file đối soát mà chị kế toán chỉ bấm đúng một lần vào chiều ngày cuối tháng. Xóa nhầm cái nút đó đi là hôm sau bộ phận hỗ trợ khách hàng nghe điện thoại mỏi tay ngay.

Ngay cả nhóm nghiên cứu của giáo sư Klotz cũng nhấn mạnh rằng không phải cứ gọt bớt lúc nào cũng tốt hơn thêm vào; các bài test trong phòng thí nghiệm của họ vốn được dựng sẵn để phương án trừ đi là tối ưu nhất, nhằm chứng minh việc con người hay bỏ quên lựa chọn này mà thôi. Còn ngoài đời thực, cắt hay giữ vẫn phải soi xét kỹ từng ngữ cảnh.

Nên để không bị "hớt lố tay" khi dọn dẹp giao diện, mình thường tự rèn cho bản thân ba thói quen nhỏ học từ mấy chú thợ cắt tóc lành nghề:

Thứ nhất là tự nhắc trước khi vẽ thêm. Mỗi lần chuẩn bị kéo một thành phần mới vào màn hình Figma để giải quyết yêu cầu, mình tập dừng lại vài giây và tự hỏi bản thân đúng câu nhắc trong thí nghiệm: khoan đã, ở màn hình này có thứ gì đang làm vướng chân người dùng mà mình dẹp bớt được không?

Thứ hai là soi thật kỹ trước khi xuống kéo. Trước khi đề xuất bỏ một tính năng nào đó, hãy kiểm tra dữ liệu xem có bao nhiêu người đang dùng nó, họ là nhóm user nào và thường bấm vào thời điểm nào. Nếu hỏi khắp cả team mà chẳng ai nhớ nổi nó sinh ra để giải quyết bài toán gì, lại thêm số liệu sử dụng gần như bằng không, thì cứ mạnh dạn đưa nó vào danh sách chờ thanh lý.

Và cuối cùng là tỉa từng chút một. Chú thợ tóc không bao giờ ủi một đường sát da đầu ngay từ nhát đầu tiên, mà luôn tỉa từng lớp mỏng rồi nghiêng đầu khách ngắm lại. Làm sản phẩm cũng vậy: trước khi xóa vĩnh viễn một tính năng, bạn có thể thử gom nó cất vào trong menu phụ, hoặc ẩn thử nghiệm trên một nhóm nhỏ người dùng trước để xem có ai đi tìm đòi lại hay không, rồi mới chính thức khai tử.

(5) Tự nhắc mình trước khi vẽ thêm, soi kỹ dữ liệu trước khi cắt, và luôn tỉa từng bước nhỏ để chừa đường lui.