Làm dự án cá nhân nhỏ để có thứ thật sự đem ra giới thiệu

Dự án cá nhân bắt đầu bằng một trang đăng ký. Vài hôm sau, bạn muốn thêm tài khoản, chat, thông báo và bảng thống kê. Ý tưởng ngày càng nhiều, nhưng chưa có bản nào đưa cho người khác thử. Nếu mục đích là thể hiện kỹ năng, hãy chọn một việc nhỏ rồi làm đủ từ đầu tới cuối.

Người xem portfolio cần hiểu bạn giải quyết vấn đề gì, tự làm phần nào và vì sao chọn cách đó. Một dự án nhỏ có bản thử, có lần sửa và giải thích rõ giới hạn sẽ cho họ thông tin cụ thể hơn danh sách tính năng còn nằm trong kế hoạch.

Chọn người dùng và việc họ cần làm

Lấy ví dụ giả định về Trúc, người muốn làm trang quản lý đăng ký cho một câu lạc bộ. Trúc bắt đầu từ người phụ trách sự kiện. Người này cần biết ai còn tham gia để chuẩn bị chỗ ngồi, nhất là sau những lần có bạn báo hủy.

Việc chính của bản thử là tìm một người và xem trạng thái đăng ký. Trúc viết câu này lên đầu ghi chú dự án. Nó giúp quyết định thông tin nào cần xuất hiện rõ, thay vì chọn chức năng theo những gì vừa thấy trong một sản phẩm khác.

Nếu có người dùng phù hợp để hỏi, bắt đầu từ cách họ đang làm. Họ gom tin nhắn, dùng form hay ghi vào bảng? Lần gần nhất bị sót thông tin xảy ra thế nào? Hỏi về việc đã gặp sẽ cụ thể hơn giới thiệu ngay ý tưởng rồi hỏi “bạn thấy hay không?”.

Có thể điều họ cần là phân biệt người đã hủy, còn bạn lại đang chăm chút ảnh đại diện. Thông tin đó giúp đổi ưu tiên. Một dự án nhỏ vẫn có ích khi tập trung vào chỗ gây nhầm, không nhất thiết phải có giao diện nhiều màn hình.

Nếu chưa hỏi người dùng thật, nói rõ đang làm trên giả định. Trúc có thể dùng tên và thông tin mẫu để luyện thiết kế luồng. Không nên kể rằng câu lạc bộ đã sử dụng hoặc công việc đã nhanh hơn nếu điều đó chưa diễn ra.

Viết một nhiệm vụ cho người thử: tìm bạn Minh và cho biết bạn ấy còn tham gia không. Nhiệm vụ này nối trực tiếp với vấn đề ban đầu. Bạn sẽ quan sát được người thử làm gì thay vì chỉ nhận một nhận xét chung về độ đẹp.

Trước khi thêm thông tin, hỏi nó giúp người dùng trả lời câu nào. Người phụ trách cần tra nhanh, nên trạng thái có thể quan trọng hơn một đoạn giới thiệu dài. Thứ bạn mất công làm chưa chắc là thứ người dùng cần thấy trước.

Giới hạn phạm vi của bản đầu

Trúc chọn bản đầu có danh sách, cách xem chi tiết và trạng thái đăng ký. Chat và thông báo tự động được để sau. Các ý tưởng vẫn được lưu, nhưng chưa nhận thêm vào công việc đang làm.

Phạm vi cần phù hợp với kỹ năng muốn thể hiện. Nếu luyện thiết kế, bản mô phỏng có thể tập trung vào luồng thao tác. Nếu luyện lập trình, chọn một luồng chạy được để người thử kiểm. Nói rõ loại bản đang làm để người xem hiểu đúng mức hoàn thiện.

Đừng đặt lịch theo một tuần trống tưởng tượng. Nếu chỉ có vài buổi tối, tính cả thời gian thử và sửa. Bạn có thể dùng cách chia việc thành kết quả nhỏ để biết mỗi buổi cần tạo ra thứ gì.

Trúc ghi điều kiện hoàn thành: mở được danh sách mẫu, tìm được một người và đọc được trạng thái. Với bản mô phỏng, bước nào không lưu dữ liệu thật phải được ghi rõ. Người thử không nên phải tự đoán nút nào chỉ để minh họa.

Chọn một mốc đưa bản đầu cho người khác xem. Tới mốc đó, ưu tiên làm phần đã có dùng được thay vì tiếp tục mở rộng. Một deadline riêng có ích khi nó giúp bạn dừng thêm tính năng để kiểm kết quả.

Nếu dùng dữ liệu mẫu hoặc một phần có sẵn, giải thích đúng cách dùng. Điều đó không làm dự án mất giá trị. Nó giúp người xem phân biệt kỹ năng bạn đang thể hiện với phần chưa được xây trong lần này.

Trong lúc làm, ý mới có thể rất hấp dẫn. Ghi nó vào danh sách sau rồi hỏi: thiếu phần này, người thử có hoàn thành nhiệm vụ chính không? Nếu vẫn làm được, bạn có lý do giữ bản đầu gọn lại.

Ghi lại quyết định và lần sửa

Trúc giữ ảnh bản đầu trước khi nhận góp ý. Không cần ghi mọi lần đổi khoảng cách, nhưng nên giữ những thay đổi ảnh hưởng cách dùng. Sau này, ảnh thành phẩm riêng lẻ sẽ khó kể được bạn đã nhận ra vấn đề và sửa thế nào.

Khi nhờ thử, đưa nhiệm vụ rồi để người kia tự làm. Đừng chỉ sẵn vị trí mọi nút ngay từ đầu. Nếu phải hướng dẫn liên tục, bạn sẽ khó biết giao diện đã đủ rõ cho người mới hay chưa.

Giả sử người thử tìm thấy Minh nhưng không hiểu chấm vàng bên cạnh tên. Trúc hỏi họ đang nghĩ dấu đó nghĩa là gì, rồi thử thêm nhãn chữ “chờ xác nhận”. Đây là một thay đổi có lý do từ cách người khác đọc thông tin.

Sau khi sửa, thử lại nhiệm vụ. Ghi đúng điều quan sát được trong lượt thử ấy, không suy rộng thành kết quả cho mọi người dùng. Nếu chưa thử lại, nói đó là cách sửa dự kiến, chưa phải bằng chứng vấn đề đã được giải quyết.

Feedback nhiều thì chọn phần cản trở việc chính trước. Form không gửi được hoặc trạng thái gây hiểu nhầm cần được xử lý trước góp ý về màu sắc. Không phải đề nghị nào xuất hiện cũng phải biến thành một tính năng mới.

Bạn có thể lưu ảnh trước và sau cùng vài dòng giải thích. Cách phân biệt các phiên bản giúp tránh gửi nhầm bản cũ. Chọn những bản thể hiện quyết định đáng chú ý, không cần đưa mọi ảnh thử vào portfolio.

Ghi cả phần chưa xử lý. Nếu mới thử với danh sách ngắn, chưa biết giao diện có thuận tiện khi dữ liệu nhiều thì nói đúng giới hạn ấy. Một câu hỏi chưa giải quyết có thể là bước tiếp theo hợp lý của dự án.

Trình bày cả giới hạn của dự án

Phần giới thiệu nên bắt đầu bằng người dùng và việc cần làm, rồi tới phần bạn đã thực hiện. Sau đó chọn một quyết định để giải thích bằng ảnh hoặc ví dụ. Người xem có bối cảnh trước khi đánh giá thành phẩm.

Nếu làm cùng người khác, nêu rõ đóng góp của mình. Nếu dùng template, ảnh hoặc icon từ nguồn ngoài, giữ thông tin nguồn và tuân theo điều kiện sử dụng. Chỉnh một mẫu có sẵn vẫn là công việc, nhưng cần nói đúng phần đã chỉnh.

Trước khi gửi, mở link như người xem lần đầu. Có vào được không, cần tài khoản không, bắt đầu ở đâu? Kiểm quyền truy cập và thêm hướng dẫn ngắn cho bản thử. Một link không mở được sẽ khiến người nhận chưa xem được phần bạn đã làm.

Cuối phần giới thiệu, chọn một hướng làm tiếp và nói lý do. Với Trúc, đó có thể là thử danh sách dài hơn để xem cần cách tìm kiếm nào. Dự án nhỏ không cần giả vờ hoàn chỉnh mọi mặt. Nó cần cho thấy bạn hiểu vấn đề, làm được một phần rõ ràng và biết kiểm lại cách mình giải quyết.