Chương 1: Bắt đầu từ số không – Phần 1
1. Bắt đầu với 1 tính năng không phải là 1 bố cục
Khi bắt đầu thiết kế ứng dụng mới, bạn nghĩ nên tập trung vào phần nào đầu tiên? Nếu bạn bắt đầu bằng việc thiết kế thanh điều hướng ở đầu trang thì bạn đang mắc sai lầm. Đừng cố thiết kế toàn bộ ứng dụng ngay từ đầu. Thay vào đó, hãy bắt đầu bằng việc tập trung vào các tính năng quan trọng. Nếu bạn đang lo lắng về việc nên có thanh điều hướng trên cùng hay ở bên, có nên đặt các mục điều hướng ở bên trái hay bên phải, hãy giữ điều này sau. Điều quan trọng là tập trung vào những gì ứng dụng cần làm trước.
Nội dung trang có nên ở trong một container, hay nên là toàn bộ chiều rộng của trang? Logo nên đặt ở đâu?”
Vấn đề là, một ‘ứng dụng’ thực sự là một tập hợp các tính năng. Trước khi bạn thiết kế một vài tính năng, bạn thậm chí còn không có đủ thông tin để đưa ra quyết định về cách thanh điều hướng nên hoạt động. Đó là lý do tại sao nó làm bạn cảm thấy chán nản!
Thay vì bắt đầu với bố cục tổng thể, hãy bắt đầu với một tính năng cụ thể. Ví dụ, giả sử bạn đang xây dựng một dịch vụ đặt vé máy bay. Bạn có thể bắt đầu với một tính năng như ‘tìm kiếm chuyến bay’.
Giao diện của bạn sẽ cần:
- Một trường cho thành phố xuất phát
- Một trường cho thành phố đến
- Một trường cho ngày xuất phát
- Một trường cho ngày trở về
- Một nút để thực hiện tìm kiếm
Hãy bắt đầu với điều đó.
Ở mức độ đơn giản, đôi khi bạn không cần những tính năng phức tạp, và điều này đã thành công trong trường hợp của Google. Nghĩa là, việc giữ mọi thứ đơn giản có thể là chìa khóa cho thành công.
2. Chi tiết sẽ được xử lý sau
Khi mới bắt đầu thiết kế một tính năng mới, quan trọng là bạn không nên bị quá mắc kẹt trong những quyết định chi tiết như kiểu chữ, bóng đổ, biểu tượng, và những điều tương tự. Những thứ đó sẽ quan trọng ở giai đoạn sau, nhưng ở lúc này chúng không phải là ưu tiên. Nếu bạn gặp khó khăn khi phải bỏ qua những chi tiết nhỏ khi làm việc trong môi trường chính xác cao như trình duyệt hoặc công cụ thiết kế yêu thích của bạn, một chiêu trò mà Jason Fried của Basecamp thích sử dụng là thiết kế trên giấy với một cây bút Sharpie dày. Sự tập trung quá mức vào chi tiết nhỏ không thể xảy ra khi sử dụng Sharpie, vì vậy đó có thể là một cách tốt để nhanh chóng thử nghiệm nhiều ý tưởng bố cục khác nhau
Hãy giữ màu sắc lại
Ngay cả khi bạn muốn làm đẹp một ý tưởng với độ chi tiết cao hơn, hãy giữ lại sự cám dỗ và không nên sử dụng màu sắc ngay từ đầu. Bằng cách thiết kế chỉ trong gam màu xám, bạn sẽ phải tận dụng khoảng cách, sự tương phản và kích thước để thực hiện những phần công việc quan trọng nhất.
Quy trình này có thể khó khăn một chút, nhưng kết quả cuối cùng sẽ là một giao diện rõ ràng với sự phân cấp mạnh mẽ, và sau này dễ dàng thêm màu sắc.
Không nên đầu tư quá nhiều
Mục đích chính của việc thiết kế ở độ chính xác thấp là để có thể tiến triển nhanh chóng, giúp bạn bắt đầu xây dựng ứng dụng thực tế sớm nhất có thể. Những bản phác thảo và wireframes chỉ là những bước tạm thời — người dùng không thể tương tác với chúng. Hãy sử dụng chúng để khám phá ý tưởng và bỏ chúng lại khi bạn đã đưa ra quyết định.
3. Không nên thiết kế quá nhiều
Bạn không cần phải thiết kế từng tính năng một trong ứng dụng trước khi bắt đầu triển khai; thực tế, nếu không làm như vậy, sẽ tốt hơn
Việc xác định mọi tính năng trong một sản phẩm và các trường hợp đặc biệt trông như thế nào thật sự khó khăn, đặc biệt là khi đang ở mức trừu tượng. Màn hình này sẽ trông như thế nào nếu người dùng có 2000 liên lạc? Thông báo lỗi nên đặt ở đâu trong biểu mẫu này? Lịch này sẽ trông như thế nào nếu có hai sự kiện được lên lịch cùng một lúc?
Bạn sẽ tự làm khó mình nếu cố gắng tìm hiểu những điều này chỉ bằng cách sử dụng một công cụ thiết kế và trí tưởng tượng của bạn.
Thực hiện công việc theo chu kỳ
Thay vì dành nhiều thời gian thiết kế toàn bộ, hãy làm việc theo các chu kỳ ngắn. Bắt đầu bằng cách thiết kế một phiên bản đơn giản của tính năng tiếp theo mà bạn muốn xây dựng
Sau khi bạn hài lòng với thiết kế cơ bản, hãy đưa nó vào thực tế.
Có thể bạn sẽ gặp phải một số phức tạp không mong đợi trên đường đi, nhưng đó chính là mục đích — khi bạn đặt thiết kế vào ứng dụng thực tế và sử dụng nó, bạn sẽ có cơ hội dễ dàng hơn để phát hiện và sửa lỗi hơn là chỉ tưởng tượng mọi tình huống có thể xảy ra từ trước. Trải qua quá trình sử dụng thực tế giúp bạn hiểu rõ hơn về cách người dùng tương tác và phản ứng với giao diện của bạn. Bạn nên tiếp tục làm việc và điều chỉnh thiết kế hiện tại cho đến khi mọi vấn đề và khía cạnh cần cải thiện đều đã được giải quyết. Điều này đảm bảo rằng sản phẩm của bạn ngày càng hoàn thiện và đáp ứng tốt hơn với nhu cầu và mong muốn của người sử dụng. Sau đó quay lại chế độ thiết kế và bắt đầu làm việc trên tính năng tiếp theo
Không nên quá tải khi làm việc trong giai đoạn trừu tượng. Hãy bắt đầu xây dựng sản phẩm thực tế càng sớm càng tốt để giảm áp lực cho trí tưởng tượng của bạn. Việc này giúp bạn có cơ hội thực tế hóa ý tưởng và đối mặt trực tiếp với sản phẩm, từ đó dễ dàng đưa ra điều chỉnh và cải thiện mà không phải dựa hoàn toàn vào trí tưởng tượng
Trở thành một người bi quan
Tránh thêm vào thiết kế những yếu tố hoặc chức năng mà hệ thống hiện tại chưa thể hỗ trợ. Trong ví dụ, nếu bạn đang phát triển hệ thống bình luận, không nên bao gồm một tính năng đính kèm nếu bạn chưa sẵn sàng cung cấp tính năng đính kèm cho người dùng. Điều này giúp tránh tình trạng tạo kỳ vọng sai lệch hoặc gây hiểu lầm với người dùng về những gì họ có thể sử dụng được.
Khi bạn đã đầu tư nhiều công sức vào việc triển khai một tính năng nhất định, nhưng đột nhiên phát hiện ra rằng việc thêm chức năng hỗ trợ tệp đính kèm đòi hỏi nhiều công việc hơn so với dự tính ban đầu. Vì lý do thời gian và tài nguyên hiện tại không đủ để hoàn thành tính năng này ngay lập tức, nên bạn quyết định đặt toàn bộ hệ thống bình luận ở tình trạng chờ đợi. Điều này có nghĩa là tính năng nhận xét không thể triển khai cho đến khi bạn có thể dành thêm thời gian để giải quyết các công việc ưu tiên khác trước đó.
Vấn đề là, một hệ thống bình luận không hỗ trợ tệp đính kèm vẫn tốt hơn là không có hệ thống nhận xét nào cả. Tuy nhiên, vì bạn đã dự kiến từ ngày đầu tiên rằng tính năng này sẽ được bao gồm, nên hiện tại bạn không có khả năng triển khai bất kỳ phiên bản nào của hệ thống.
Khi bạn đang lên kế hoạch cho một tính năng mới, hãy dự đoán rằng quá trình xây dựng nó sẽ gặp khó khăn. Thiết kế phiên bản nhỏ nhất, nhưng vẫn có ích và có thể triển khai, giảm đáng kể nguy cơ và khả năng xảy ra các vấn đề phức tạp.
Nếu một phần của tính năng được coi là ” có để đẹp”, hãy lên kế hoạch thiết kế nó sau. Bắt đầu bằng việc xây dựng phiên bản đơn giản trước, điều này giúp bạn luôn có một nền tảng để dựa vào.