Bài này tổng hợp lại các cách mà mình nhận ra thường hay tiếp cận các bài toán design.
Gần đây mình có reflect lại vài tình huống:
Có vài project trong lúc mình propose design, thì tiếp nhận được những feedback khiến mình chợt phát giác “tại sao mình chưa nghĩ đến vấn đề này nhỉ? nó thậm chí là một ý rất quan trọng tác động đến toàn bộ định hướng design này”.
Có bạn đồng nghiệp đôi khi ngó sang bảng Figjam của mình & hỏi “đang làm gì đó”, rồi mình giải thích bla bla,… và bạn thấy mình tiếp cận mỗi project vs mỗi cách làm figjam khác nhau.
Start w Design tactics 🕳️
Thói quen này là thường xuyên nhất, ta bắt đầu giải quyết problem ngay từ những kĩ thuật của design như: chọn màu nào, layout nào, pattern nào,… từ đó explore được nhiều option, rồi đánh giá các option >> ra quyết định.
Try mixmatching design toolbox (pattern, flow, IA, psychology …) >> Explore option >> Analyze option >> Pick
Cách này tương tự như tactic của brainstorm, giúp mình explore nhiều hướng mà bản thân có thể không ngờ đến,… tuy nhiên nếu không chú ý ở khâu đánh giá option, ta dễ quên mất bài toán problem cần giải là gì.
Start w Outcome 🌟
Cách này bắt đầu tự việc define rõ outcome (JTBD), sau đó define được các tiêu chí cần đạt, rồi từ đó explore các design option để đạt tiêu chí đã đề ra, hướng này ngược với cách ở trên.
Define clear expected outcome >> Define success criteria >> Explore option >> Pick
Cách này thì gần vs mindset của design thinking hơn, vì làm mọi thứ đều có chủ đích rõ ràng, tuy nhiên sẽ khó khi brief không rõ ràng từ đầu >> khiến design bị stuck, đòi hỏi phía design phải có khả năng làm việc với stakeholder để làm rõ (và tất nhiên, việc này cũng phụ thuộc vào khả năng làm rõ vấn đề / mong muốn của bản thân họ).
Nhưng bù lại nếu define được rất kĩ ngay cả khi chưa design gì cả, thì hướng này giúp chúng ta tiết kiệm được thời gian vì đã narrow down dc hướng.
Start w Research
Bắt đầu dự án bằng việc research rất kĩ problem hiện tại (có evidence rõ ràng qua phân tích data / user research), và research đối thủ (phân tích context của họ & cách họ giải quyết)… Sau khi tìm ra điểm đau (Pain points), mình mới bắt đầu design để giải quyết đúng các điểm đau đó.
Suspicious problem >> Assumption >> Investigate >> Hypothesis >> Design explore
Cách này đầu đó như cách ở trên nhưng apply khi thấy vấn đề còn mơ hồ hoặc mang tính thử nghiệm (cải thiện flow/ uplift metrics nào đó). Việc research có thể gây tốn thời gian nhưng bù lại sẽ có bằng chứng khách quan để củng cố cho các quyết định design.
Start w System & Constraint-First
Cách này thường dùng khi cần design mang tính hệ thống to / sơ khai, ta cần define rất rõ có bao nhiêu rất, chúng nên được sắp xếp ra sao, cần quy chuẩn chúng như thế nào để consistent, scale được, đủ flexible để adapt cho nhiều design case,…
Design case >> Design element >> Design system
