Khi tôi bắt tay vào xây dựng trang web đầu tiên của mình, sự phấn khích là có thật. Tôi đã cho rằng phần khó nhất sẽ là học lập trình—ghi nhớ các thẻ, hiểu các hàm, nắm vững cú pháp. Tôi đã lầm. Viết mã hóa ra lại là phần dễ dàng. Thử thách thực sự là biến những dòng mã đó thành thứ mà mọi người thực sự có thể sử dụng mà không thấy bối rối hay khó chịu. Dự án đầu tiên đó đã dạy tôi rằng phát triển phần mềm không phải là việc gõ phím trong sự cô lập, mà là giải quyết vấn đề cho con người—những người vốn chẳng quan tâm đến stack công nghệ của bạn. Tôi đã mắc những sai lầm khiến mình mất thời gian, mất ngủ và mất cả những người dùng đầu tiên. Có năm sai lầm nổi bật hơn cả.
Theo đuổi sự hoàn hảo trước khi ra mắt
Tôi đã rơi vào cái bẫy hoàn hảo ngay cả trước khi tôi có đủ tư cách để gọi bất cứ thứ gì là hoàn hảo. Tôi đã dành cả buổi chiều chỉ để thay đổi mã hex để khác đi một chút về sắc độ, điều chỉnh các giá trị border-radius từ tám pixel lên mười pixel rồi lại quay về như cũ, và viết lại nội dung tiêu đề năm lần trước khi có một khách truy cập duy nhất nhìn thấy trang web. Tôi tự nhủ rằng mình đang trau chuốt, nhưng thực chất tôi đang trì hoãn dưới danh nghĩa chất lượng. Kết quả là gì? Tôi ra mắt trễ ba tuần. Khi trang web cuối cùng cũng hoạt động, không một người dùng nào nhận xét về độ cong của nút bấm mà tôi đã trăn trở. Họ chỉ quan tâm đến việc liệu biểu mẫu có gửi đi thành công mà không bị lỗi hay không.
Bài học đó đã in sâu vào tâm trí: hãy ra mắt sản phẩm trước. Bạn không thể cải tiến dựa trên những phản hồi mà bạn chưa nhận được. Hãy xây dựng cấu trúc vững chắc, đảm bảo luồng chính hoạt động tốt, rồi đưa nó lên mạng. Sự tinh chỉnh thuộc về phiên bản hai, chứ không phải phiên bản không. Người dùng sẽ cho bạn biết cái gì thực sự bị lỗi, thay vì những gì bạn chỉ đơn thuần tưởng tượng là chưa hoàn hảo.
Xây dựng quá nhiều thứ quá sớm
Dự án của tôi bắt đầu như một công cụ đơn giản để chia sẻ các đề xuất sách. Đó là toàn bộ ý tưởng ban đầu. Đến tuần thứ hai, tôi đã phác thảo ra một hệ thống đăng nhập người dùng, một biểu đồ đánh giá động, một phần bình luận lồng nhau, một nút chuyển chế độ tối (dark-mode) và một bản tin tóm tắt qua email. Không có cái nào hoạt động tốt cả. Luồng đăng nhập bị lỗi một nửa số lần. Biểu đồ thì không có dữ liệu thực tế để hiển thị. Phần bình luận thì cho phép trùng lặp. Trong khi đó, tính năng liệt kê sách cơ bản—lý do chính mà trang web tồn tại—lại bị vùi lấp dưới một đống các tính năng phụ nửa vời, lỗi thời, gây bối rối cho bất kỳ ai truy cập vào trang chủ.
Một trang web đơn giản giải quyết gọn gàng một vấn đề sẽ luôn chiến thắng một trang web phức tạp làm mười việc một cách kém cỏi. Trước khi bạn viết thêm một dòng mã nào khác, hãy xác định một công việc duy nhất mà sản phẩm của bạn làm cho người dùng. Hãy xây dựng nó. Kiểm thử nó. Trau chuốt nó cho đến khi nó hoạt động đáng tin cậy. Nếu người dùng thực sự yêu cầu một bảng điều khiển (dashboard) hoặc một nguồn cấp dữ liệu mạng xã hội, lúc đó bạn có thể thêm vào. Cho đến lúc đó, hãy cưỡng lại ham muốn xây dựng một con dao đa năng Thụy Sĩ khi tất cả những gì mọi người cần chỉ là một con dao bếp sắc bén.
Bỏ qua trải nghiệm đằng sau vẻ bề ngoài
Tôi đã dành hàng giờ để chọn những phông chữ thanh lịch và một bảng màu phong cách. Tôi ám ảnh với dải màu gradient ở phần hero section. Sau đó, tôi lại phớt lờ cảm giác thực tế khi sử dụng trang web. Các trang tải chậm như rùa vì tôi sử dụng các tệp PNG độ phân giải đầy đủ mà không nén. Các nhãn điều hướng sử dụng cách dùng từ khéo léo trông thì đẹp nhưng lại khiến mọi người phải đoán xem liên kết sẽ dẫn họ đi đâu. Các nút bấm thì mỏng và phong cách nhưng lại quá nhỏ để chạm trên màn hình điện thoại.
Tôi đã học được một bài học đắt giá rằng thiết kế hình ảnh và trải nghiệm người dùng không phải là hai thứ có thể thay thế cho nhau. Một giao diện đẹp sẽ thất bại nếu khách truy cập phải chờ vài giây để xem một ảnh banner, hoặc nếu họ không thể tìm ra cách liên hệ với bạn trong vòng chưa đầy hai lần nhấp chuột. Hãy làm cho mọi tương tác trở nên đơn giản. Sử dụng ngôn ngữ bình dân cho các nhãn điều hướng. Nén các tài nguyên của bạn. Kiểm tra xem các mục tiêu chạm (tap targets) có đủ lớn hay không. Tốc độ và sự rõ ràng không phải là những thứ bổ sung vào lúc cuối; chúng là nền tảng để mọi thứ khác dựa vào.
Chỉ kiểm thử trên máy tính của chính mình
Tôi đã phát triển toàn bộ trang web trên một chiếc laptop duy nhất, trên một trình duyệt duy nhất, với một độ phân giải màn hình duy nhất. Trên máy của tôi, mọi thứ trông thật hoàn hảo. Thế rồi một người bạn mở nó trên iPhone của cô ấy. Các nút bấm bị đè lên nhau. Văn bản bị tràn khỏi khung chứa. Một người bạn khác sử dụng Safari trên Mac, và toàn bộ bố cục CSS grid bị sụp đổ thành một đống không thể đọc nổi. Tôi đã thầm mặc định rằng nếu nó hoạt động với tôi, nó sẽ hoạt động với tất cả mọi người. Giả định đó đã khiến tôi mất cả một cuối tuần để sửa lỗi khẩn cấp trong hoảng loạn và phải gửi những lời xin lỗi đầy ngượng ngùng.
Đừng lặp lại sai lầm của tôi. Trước khi xuất bản, hãy chạy thử trang web của bạn trên Chrome, Firefox, Safari và Edge. Sử dụng công cụ dành cho nhà phát triển (developer tools) của trình duyệt để mô phỏng điện thoại, máy tính bảng và laptop với các độ rộng khác nhau. Nhấp vào mọi liên kết. Gửi mọi biểu mẫu. Thay đổi kích thước cửa sổ một cách quyết liệt. Những lỗi bạn phát hiện được trong quá trình kiểm thử sẽ rẻ hơn nhiều so với những lỗi mà người dùng tìm thấy khi sản phẩm đã chạy thực tế.
Coi phản hồi như một sự tấn công cá nhân
Việc chia sẻ dự án khiến tôi thấy lo lắng. Lỡ như mọi người ghét nó thì sao? Khi một đồng nghiệp đề nghị loại bỏ một tính năng mà tôi đã dành