Tôi đã thiết kế và phục tùng những người khác thiết kế nhiều hệ thống trong quá khứ và tôi đã thấy quá trình này diễn ra theo nhiều cách khác nhau, nhưng điều tôi thấy phổ biến là kiến trúc ban đầu ít nhất phải lên kế hoạch cho sự tồn tại của hầu hết các tính năng chính.
Ví dụ, tôi đã thấy một hệ thống điều khiển HVAC không có khái niệm về các tòa nhà, tầng, phòng, v.v. được trang bị thêm với những thứ đó và kết quả là xấu xí như chúng đến. Hoặc một thiết bị âm nhạc di động được xây dựng từ các thành phần phù hợp hơn với đồng hồ bỏ túi (không thông minh) của bạn. Không cần phải nói các sản phẩm cuối cùng trong cả hai trường hợp không được khách hàng yêu thích.
Khi bạn nói "quan niệm" đó chỉ là một bước tiến lên từ "ý tưởng" và một khái niệm có thể rất mờ nhạt. Kinh doanh thường quan tâm đến các khái niệm. Khách hàng thường quan tâm đến UX - một khái niệm được đưa vào thực tế theo cách dễ sử dụng và dễ chịu và mang lại một số giá trị thông qua việc sử dụng nó.
Bạn phải thực hiện "khái niệm" trước khi lập trình, tôi không thể hình dung mình sẽ mở studio hình ảnh (hoặc IDE bạn chọn) và viết mã ngẫu nhiên, để xem nó đi đâu.
Bạn có thể không thực hiện một thiết kế hoàn chỉnh (và bạn không nên) trước khi mã hóa nhưng bạn nên có một bản phác thảo sơ bộ về quy trình làm việc của người dùng.
Thiết kế và mã hóa UX khá thường xuyên ăn nhập lẫn nhau, bạn có thể sẽ bị buộc sử dụng một số cách tiếp cận Agile cho bất kỳ thứ gì ngoại trừ các dự án nhỏ nhất như một cách để kết hợp thực tế này vào cách bạn tiếp cận công việc. Vì vậy, đừng nghĩ bạn là lập trình viên tồi tệ nhất nếu bạn không thể nhìn thấy tất cả cùng một lúc - không ai có thể và những người nghĩ rằng họ có thể là những người bỏ qua đủ vấn đề để họ có thể tuyên bố rằng họ đã hoàn thành hình ảnh.
Một ví dụ để đặt một kích thước cho một cái gì đó lớn. Khái niệm: "Tạo một công cụ dựa trên đám mây trực quan cho phép doanh nghiệp tích hợp nền tảng phần mềm của họ". Điều này nghe có vẻ tuyệt vời và người ta có thể bắt đầu viết lên tài liệu tiếp thị và bán nó trước cả khi nó ở đó. Bạn phải có điều này trước khi mã hóa.
Thiết kế trước: "Có hình dạng và mũi tên như trong Visio để mô tả logic; có khả năng bổ trợ để cho phép kết nối với các nền tảng khác nhau (SAP, SF, cơ sở dữ liệu ...); có bảng điều khiển giám sát nơi người ta có thể tìm kiếm dữ liệu đi qua hệ thống, có cách mô tả dữ liệu một cách trực quan và chuyển đổi định dạng này sang định dạng khác ". Một blob tiếp thị tuyệt vời. Nó cũng cung cấp cho bạn một số ý tưởng về những gì quan trọng, nên có một bản phác thảo thô như vậy trước khi viết mã.
Thiết kế / Mã: "Có trình duyệt lưu trữ trình thiết kế HTML với các tính năng tương tự và như vậy; mã hóa phần phụ trợ trong Java để nó có thể chạy trên bất kỳ máy chủ hiện có nào; xác định cấu trúc dữ liệu và UX để truy vấn hoặc sửa đổi chúng khi cần thiết; báo cáo, ghi nhật ký kiểm toán, kiểm soát phiên bản kế hoạch, kiểm soát truy cập kế hoạch; .... "- danh sách càng chính xác thì càng không thực tế để thấy trước tất cả.
... tuy nhiên, ít nhất mọi người nên nhận thức được mọi thứ có thể trông như thế nào hoặc sản phẩm cuối cùng của bạn có thể kết thúc bằng một số triển khai thực sự vô dụng, cuối cùng giết chết khái niệm nghe có vẻ tuyệt vời - nói rằng nhà thiết kế hình ảnh của bạn cần 40 " màn hình để hiển thị bất kỳ quy trình làm việc trong thế giới thực nào hoặc không có cách nào để tìm kiếm nhật ký ngoài một chuỗi khớp chính xác giới hạn ở một trong 20 trường trong nhật ký, v.v. Không có cách nào tốt để ngăn chặn điều này xảy ra ngoài việc thực hiện triển khai của bạn - một số sẽ thành công, một số khác sẽ thất bại.