5 trạng thái của UI và Quy trình làm việc mới của SpaceWalker

Space Walker

Làm thế nào để quá trình thiết kế một sản phẩm không xảy ra quá nhiều biến cố dẫn đến phải thay đổi thiết kế ban đầu và kéo theo những thiết kế khác? Làm thế nào để developers có thể làm việc ăn ý với UI/UX designers? Làm thế nào để việc thiết kế UI và UX đạt hiệu quả với thời gian ít nhất?

Đó là những câu hỏi mà một thời SpaceWalker đã phải trăn trở để tìm ra các câu trả lời tốt nhất. Cho đến một ngày…

5 trạng thái khi thiết kế UI

Đó là một ngày đẹp trời tháng 9, bọn mình được gửi cho một bài viết rất hay về UI và UX. Nó ngay lập tức trả lời cho những câu hỏi làm thay đổi quy trình làm việc của Squad.

Bài viết chia sẻ về 5 trạng thái khi thiết kế UI (5 states of UI stack):

  • Blank State (Trạng thái trống)
  • Loading State (Trạng thái chờ)
  • Partial State (Trạng thái lưng chừng)
  • Error State (Trạng thái báo lỗi)
  • Ideal State (Trạng thái lý tưởng)

UI Stack

Trước đây khi thiết kế, bọn mình chỉ tập trung vào Trạng thái lý tưởng mà bỏ sót những trạng thái khác, làm cho các bạn developers gặp khó khăn khi viết code cho ứng dụng.

Ví dụ điển hình là trong giai đoạn chạy nước rút của một dự án, developers khi phát hiện những trường hợp còn thiếu thì họ sẽ tự thiết kế giao diện mà không hỏi qua bên thiết kế (Đây là điều xảy ra khi bạn để các lập trình viên tạo giao diện người dùng). Việc đó dẫn đến:

  • Giao diện không đồng nhất với thiết kế trước đó.
  • Xung đột giữa developers và UI designers.
  • Cảm giác khó chịu của developers và UI designers khi phải làm sửa chữa thiếu sót của bên UX.
  • Phản ánh không tốt từ khách hàng.

Tất cả việc đấy ảnh hưởng đến tinh thần và hiệu quả làm việc của cả nhóm.

Áp dụng quy trình làm việc mới

Từ những kiến thức thu được từ bài viết, SpaceWalker đã tìm cách áp dụng chúng vào công việc thực tế. Bọn mình đã xây dựng nên một quy trình làm việc mới giúp tăng hiệu quả công việc, tiết kiệm thời gian cho mọi người và dẹp tan bầu không khí căng thẳng ở giai đoạn cuối của các dự án:

  1. Khi bắt đầu thiết kế user flow, PM và UX sẽ tổ chức những buổi thảo luận có sự tham gia của tất cả thành viên từ developers, UI designers cho đến QA. Việc này giúp ích rất nhiều trong việc tìm ra các giới hạn công nghệ, thời gian phát triển và các trường hợp phát sinh trong quá trình sử dụng sản phẩm.
  2. User flow sau khi hoàn thành sẽ được gửi cho khách hàng xác nhận. Nhằm đảm bảo khách hàng hiểu rõ user flow thì PM phải xác nhận từng trường hợp với họ. User flow sau khi được xác nhận sẽ tạo thuận lợi cho rất nhiều công đoạn khác: QA xây dựng test case dễ hơn, PM nắm vững sản phẩm nhiều hơn và xác định rõ timeline hiện tại đã ổn hay chưa để còn thay đổi cho phù hợp.
  3. Khi có bản user flow cuối cùng, UI và UX sẽ ngồi lại với nhau để quy định ra những màn hình chính, phụ và những màn hình có tương tác đặc biệt. Sau đó, wireframe của màn hình chính và phụ được thiết kế và gửi cho khách hàng xem xét. Nếu có thay đổi thì chỉ cần chỉnh sửa những wireframe của màn hình chính và tương tác đặc biệt thay vì tất cả wireframe như trước đây. Quy trình mới làm cho công đoạn này giảm xuống còn 2-3 ngày thay vì 1 tuần như lúc trước.
  4. Trong quá trình vẽ wireframe, bọn mình còn làm một spreadsheet để liệt kê những màn hình nào có trong ứng dụng và những phần tử xuất hiện trên màn hình đó (nút nhấn, ô nhập…). Các màn hình chính, phụ và tương tác đặc biệt sẽ được đánh dấu khác nhau. Cấu trúc của spreadsheet sau khi áp dụng 5 trạng thái khi thiết kế UI như sau:
    • Số thứ tự.
    • Hoàn thành: giúp PM kiểm tra tiến độ quá trình thiết kế.
    • Tên màn hình: đặt tên như file thiết kế, các màn hình chính sẽ được đánh dấu nổi bật hơn.
    • Nội dung: các phần tử có trong màn hình (nút gì, câu chữ gì…).
    • Trạng thái: Empty, Loading, Partial, Error, Ideal.
    • Ghi chú: Bổ sung những lưu ý.

Kết quả

Nhờ sự khuyến khích của các sếp và sự hợp tác nhiệt tình, vui vẻ của mọi người mà các dự án áp dụng quy trình làm việc này có kết quả rất khả quan:

  • Số lượng màn hình phải thiết kế tăng gấp 5 lần để đảm bảo đầy đủ tất cả trường hợp nhưng các màn hình phụ chủ yếu là sử dụng lại các phần tử trên màn hình chính.
  • Công việc thiết kế diễn ra trơn tru hơn do đã biết rõ nội dung từng màn hình khi thiết kế.
  • PM cập nhật tiến độ cho khách hàng cũng dễ dàng và thuận tiện hơn hẳn.
  • Developers chỉ cần tập trung làm theo thiết kế có sẵn, không phải tự thiết kế các trường hợp đặc biệt nữa.

Còn bạn, nhóm của bạn đang sử dụng quy trình nào trong quá trình phát triển sản phẩm?

SSS Full-stack Engineer

Love Silicon Straits and want to know more about our company culture, working environment or job vacancies?
Find out more at careers.siliconstraits.vn.

Silicon Straits
Be Challenged. Be Inspired. Be Different.