Đầu năm 2018 (khoảng tháng 01), trên các blog về design xuất hiện một loạt các bài viết nhắc tới khái niệm DesignOps (viết tắt của Design Operations). Với ý tưởng cần một người điều hành chung, đảm bảo sự phối hợp tốt giữa designer team, khách hàng, các team khác (IT, Marketing), v.v.. cũng như nhằm đảm bảo team design đi theo đúng hướng, đúng chuẩn của doanh nghiệp.. một vị trí operation ra đời, và nó được gọi là Design Ops. Vậy DesignOps là gì? tại sao lại cần có vị trí này? nó áp dụng khi nào? và yêu cầu cụ thể ra sao?… trong bài viết này, tôi sẽ mô tả sơ lược để bạn đọc có một hình dung tổng quan nhất và cũng thực tế nhất (theo kinh nghiệm của mình).

Designops là gì? 

Viết tắt của Design Operation, designops có thể hiểu nôm na là từ vay mượn của DevOps (trong IT) nhưng được áp dụng tương đối rộng hơn, phức hợp hơn (nghĩa là phối hợp cả theo chiều ngang và dọc với nhiều phòng ban, trong và ngoài cty hơn). Nếu cả công ty chỉ có bạn là designer (hoặc 1-2 người) thì bạn có lẽ chưa cần đến designops. Theo trải nghiệm của cá nhân tôi, designops là một người, thường là phụ trách mảng design của một agency lớn, (hoặc ít nhất là trợ lý của Chief Design), có trách nhiệm điều hành “toàn bộ hệ thống liên quan đến các công việc design” của cty nhằm đảm bảo mấy thứ sau đây:

• Sự đồng nhất trong công việc: Cái này vô cùng quan trọng. Sự đồng nhất ở đây có thể đơn giản như là công cụ sử dụng trong thiết kế (không thể có ông thì XD, ông thì Figma, ông thì Sketch..), cho tới qui trình thiết kế. Nên nhớ rằng, ngay cả trong UX design thì cũng có rất nhiều trường phái khác nhau 😉
• Sự tương thích và thích ứng trong các dự án: Nghe qua thì tương đối phức tạp nhưng nếu dùng từ tiếng Anh thì nó là integration & adaptive, nghĩa là bạn phải điều hành (operate) sao cho các sản phẩm của team design làm ra tương thích được với “khả năng, năng lực” của các bộ phận khác, ví dụ như IT. Sản phẩm mà team design làm ra phải “nói cùng một thứ ngôn ngữ” với các bộ phận khác trong công ty (kể cả ban GĐ) để họ có thể “hiểu” cái bạn đang muốn làm. Thứ “ngôn ngữ” này cũng cần “match” với kỳ vọng của khách hàng, đối tác. Nếu công ty nào có sẵn Agile process thì designops cần hiểu Agile và đảm bảo rằng sản phẩm đầu ra “khớp” với khách hàng (hay các stakeholders), qua đó giảm thiểu quá trình “anticulating design” (cái này bạn nên tự Google nhé).
• Tận dụng lợi thế của các mô hình là việc khác: Đây là điều quan trọng nhưng thường bị các agency phớt lờ. Nếu cứ cắm mặt làm theo mô hình agency truyền thống, hoặc studio, cộng với khả năng giao tiếp yếu kém vốn có của team design và team AM sẽ dẫn tới cả công ty chỉ cố gắng “design the thing right” thay vì “design the right thing“. Đặc biệt là khi thử nghiệm, thậm chí có 1 chút áp đặt thì tôi thấy designops thực sự “ốp” được mọi người giao tiếp với nhau hiệu quả hơn. “Bắt” họ (designer) đi theo Agile, Scrum, Lean và thậm chí là PACT (People – Activity – Context – Technology, một IxD framework) thì việc chấp nhận điều chỉnh và cho ra nhiều phiên bản tinh chỉnh của công việc thiết kế UX (hoặc UI) sẽ nhanh hơn. Nên lưu ý rằng, trước giờ, design rất “ít” các qui trình tối ưu (khác hẳn với IT hay Business admin vốn nhất nhiều mô hình) bởi mọi người quen nghĩ rằng: design là phải sáng tạo. (Bây giờ thì cần định hướng và quản lý tốt hơn, bởi design ra cho ai làm tiếp phần còn lại? có bán được không? có ra hiệu quả không?…)
• Đảm bảo và duy trì process chung: Hiểu một cách đơn giản, designops là người quản lý, điều hành chung design team của công ty và đảm bảo các bên “liên quan” hoạt động theo đúng qui trình đã đề ra. Qui trình này có thể “vay mượn” từ các mô hình nêu trên (Agile, Lean) và cũng được designops tối ưu theo thời gian sử dụng.
• Đảm bảo tính khả thi: Cái này nên hiểu nôm na là “cờ ngoài, bài trong”. Nghĩa là người bên ngoài nhìn vào bao giờ cũng “tỉnh táo” hơn. Thay vì để team design cắm đầu làm “brain-storming” thì designops là người tập trung vào design thinking (nghĩa là solution oriented), tập trung vào data-driven decision making (các bạn muốn design gì cũng được, nhưng phải chứng minh nó hợp lý). Bên cạnh đó, designops là người đảm bảo sản phẩm của team design làm ra thì ví dụ như bên front-end làm được, back-end tích hợp được, khách hàng có tiền để trả, và người dùng có thể sử dụng cũng như tái sử dụng trong khoảng kỳ vọng nhất định.

Nghe qua thì thấy lằng nhằng phải không? Công nhận là hơi lằng nhằng 🙂

Vậy thì designops cần có những kỹ năng gì? 

Các kỹ năng designops cần có bên cạnh kỹ năng design sẵn có (không cần quá chuyên sâu, theo quan điểm của tôi)

• Business modeling & product management: Phải hiểu business model và qui trình làm sản phẩm thì mới design ra một thứ “có thể giúp các stakeholder” đặt được mục đích. Ví dụ như tăng doanh số, hoặc tiết kiệm chi phí, hoặc đạt mục tiêu của marketing campaign..vv…
• Front-end: Cái này không chắc là công ty nào cũng cần, nhưng với công ty mình là “bắt buộc”. Một người làm design phải hiểu khi áp dụng “vào thực tế” nó sẽ như thế nào? có khả thi không? nếu khả thi thì liệu performance có ổn không? v.v..
• Agile skill: Kỹ năng làm việc linh hoạt, làm việc nhóm, tạo sân chơi và luật chơi cho team design và cả những bên liên quan. Từ năm 2009 mình mới nghiêm túc áp dụng và học tử tế về Agile, và sau này chỉ cần áp dụng đúng vài kỹ năng là hiệu quả khác hẳn. Người làm designops cần hướng team design (hoặc nhiều team design) vận hành theo các best practice của Agile, ngay từ việc quản lý source files tập trung, qui trình commit files, v.v… là đã tiết kiệm nhiều chi phí re-work không đáng có.
•  Blind testing hay các kỹ năng test cơ bản để tìm ra vấn đề một cách khách quan.
• Communication: Cụ thể hơn là quản lý được luồng communication trong và ngoài team cũng như trong cty đối với khách hàng, đối tác. Người làm designops có kinh nghiệm thì sẽ biết cách quản lý và xây dựng feedback-loop model phù hợp với team của mình để sao cho công việc hiệu quả nhất (vừa né/ giảm thiểu sự bực dọc của designers, của khách hàng và vừa quản lý chặt chẽ các bước bàn giao, CR theo qui trình đã xây dựng).

Thế tóm lại, designer không có kỹ năng quản trị thì bổ thêm một ông designops đúng không? Về mặt quản lý thì đúng một nửa, bởi khi công ty có nhiều dự án, nhiều team design nhỏ làm việc (có thể 1 dự án có nhiều phần việc phải tách ra nhiều team design) thì bạn cần quản lý sao cho mọi việc được thực hiện chỉn chu, đồng nhất. Tuy nhiên, designops không thể là người “chỉ biết về agile hay quản trị” mà còn phải hiểu biết về design (ví dụ như UI/UX lead…) , hiểu biết về business, quan hệ khách hàng (AM, CX…).

Thế design system thì sao? Đương nhiên, design system vẫn dùng bình thường trên góc độ chuyên môn dành cho designer, và nó sẽ là một phần việc cho designops quản lý, cập nhật.

Ở công ty mình, hiện tại mình đảm nhận UX research & document, và vẫn phải làm CEO, tuy nhiên, có bạn founder làm công việc designops. Bạn này thành thạo frontend cũng như các hệ thống digital (web, mobile) và cũng thạo về UI design. Tuy nhiên bạn này luôn đứng ngoài và challenge team như sau:

• Rất hay nói “It doesn’t make any sense to me, please explain” (nghe ghét vãi 😀 nhưng sau này quen rồi thì thấy đúng là cần 1 ông như vậy).
• Câu thứ hay hay hỏi là “How will it work in the real life?, show me, show me…”. Tôi đã từng rất bực khi nghe mấy câu này, nhưng khi làm hệ thống end-to-end cho Johnnie Walker thì đúng là ngoài việc design experience landing page xong còn phải tính toán toàn bộ các khâu trải nghiệm khác cho tới khi người dùng cầm được chai rượu trên tay.

Cái tiện của designops là bạn có thể áp dụng ở mức tư duy (mindset) cho một nhóm nhỏ trước rồi lan rộng dần ra. Qui trình của nó không cần phải phổ biến cho toàn bộ team mà bắt đầu bằng những người leader. Cách áp dụng có thể dùng kỹ thuật của Agile adoption, từ từ rồi mọi chuyện sẽ ổn thôi.

Hanoi October 2018

Với đồ thực phẩm thì “date” là thứ bạn luôn cần quan tâm trước khi sử dụng, nhưng chẳng mấy khi thực sự dành thời gian kiểm tra nó. Again, user is lazy :D.

Cũng không biết vô tình hay cố ý (mà mình đoán 90% là vô tình) mà với hộp sữa này, thông tin ngày sản xuất và ngày hết hạn được in (đóng dấu) ngay vị trí mà người dùng sẽ cắm ống hút vào. Bằng cách này, có muốn lờ đi không đọc thì bạn vẫn phải đọc qua trước khi cắm ống hút. (Basic instint về visual communication).

Các hãng sữa nên áp dụng điều này.

Các hãng đồ uống đóng hộp nên áp dụng điều này.

Các hãng đồ hộp cũng nên áp dụng điều này.

Lần tới, nếu không có thông tin này “đập” vào mắt, mình sẽ lại bỏ qua.

Hanoi, 05/2018

(Ảnh minh hoạ UX design, nguồn NN/g)

Làm việc liên quan đến UX khó, hay “UX khó” là câu cửa miệng của rất nhiều người. Từ những người mới tinh trong ngành, mới va chạm với “UI” hoặc UX concepts cho tới những bạn chuyển từ BA, Graphic design sang UX đều thấy nó khó, và thường “phán” luôn rằng UX “rất khó”. Vậy thực hư ra sao? có thật sự đây là một ngành khó không và nó khó tới đâu để bạn theo đuổi? Qua bài viết này, tôi sẽ cố gắng giải thích phần nào để mọi người cùng hiểu rõ.

Tại sao mọi người thường thấy UX khó

Nói về cái “khó” ở một lĩnh vực thì thường do mấy nguyên nhân như sau (theo kinh nghiệm cá nhân mình quan sát mấy năm qua trong các group về UX):

• Vì tất cả mọi người xung quanh đều “bảo rằng” nó khó.
• Không có mentor (người hướng dẫn) trong lĩnh vực này ở Việt Nam (hoặc không có nhiều)
• Không được đào tạo bài bản về những lĩnh vực “liên quan” tới UX. Bạn cần hiểu rằng không có 1 trường lớp nào dạy “chuyên ngành UX”, bởi UX là một công việc và để làm công việc này bạn có thể xuất thân từ nhiều lĩnh vực liên quan.
• Thị trường Việt Nam vẫn đa phần là các công ty Outsourcing hoặc các Startup không có tiền làm UX. Các tổ chức lớn thì chưa quan tâm tới UX (hoặc thế hệ lãnh đạo chưa hiểu vụ này) do đó những người muốn làm việc liên quan tới UX (VD: như mình chẳng hạn) sẽ có rất ít cơ hội để cọ xát, mà như vậy thì có học mãi cũng không vỡ ra, không giỏi lên được.
• Hiểu sai từ đầu về UX, Usability, Utility, UI, v.v… Cái này khó trách bởi một phần là không có trường lớp / khoá học nào đào tạo cụ thể, tỉ mỉ những kiến thức này.
• Không hiểu biết về tiêu chuẩn ngành, vì ở Việt Nam không ai nói về cái đó cũng như không ai đặt ra cái đó trong các dự án liên quan.

Những điều này dẫn tới nhiều “ngộ nhận” và khiến cho các bạn “lầm tưởng” mình đang làm UX, rồi càng đi càng chệch hướng sang “UI” hoặc product managent. Đến những nhà tuyển dụng cũng gộp luôn cái “job title” là “UI/UX” để cho dễ tuyển dụng, kiểu như tôi cũng đang tuyển người làm UX về… để vẽ UI. Cứ thế mọi thứ càng khiến những người muốn làm UX cảm thấy khó khăn, mông lung.

(Nguồn ảnh: Cultivate)

Thế UX có khó thật không?

Câu trả lời là có, nhưng không phải là không làm được nếu bạn được định hướng bài bản. Và những vấn đề “khó” của UX nằm ở nhiều khâu trong qui trình thiết kế và nhiều cấp độ khác nhau bao gồm cả yếu tố tác động bên ngoài. Quan trọng hơn cả, cái khó của UX khi vào dự án là bạn phải chứng minh tính hiệu quả của nó. Ví dụ

• Các dự án UX được áp dụng ko chỉ với web hoặc mobile app, mà nó có phạm vi rộng ở touch screen, màn hình xe hơi, màn hình máy ATM v.v… Mỗi mảng nó có concepts, constraints riêng, cộng với dữ liệu phân tích audiences/ users, cộng với các design patterns.. từ đó outlight ra các concept & solution.
• Xuyên suốt chiều dài của một dự án UX, facing & facilitate là kỹ năng bạn sử dụng nhiều nhất bởi mục đích cuối cùng của dự án là sản phẩm “đầu ra” của bạn được thông qua, đáp ứng “tất cả” các bên liên quan. Không qua được khâu này, bạn fail 😦

Cụ thể hơn được không?

Tất nhiên là được, các dự án UX trong thực tế thường có dạng như sau:

• Bạn và team của bạn chạy 1 dự án UX, sau 2 tháng, facility meeting với chủ đầu tư mà bạn ko thuyết phục được các stakeholders bằng các option/solution bạn đưa ra -> bạn failed.
• Bạn làm dự án UX, chạy 3 tháng, implement sản phẩm, chạy A/B testing các kiểu nhưng traffic ko tăng, conversion rate giảm, bạn không lý giải được các nguyên nhân chủ quan, khách quan -> bạn failed. Tất nhiên ai cũng hiểu vụ trafic và conversion còn phụ thuộc vào thời điểm trong năm (vd với website mua sắm), tính hiệu quả của marketing campaign, đội ngũ chăm sóc khách hàng, CX process v.v… nhưng dù nhiều hay ít, là người làm UX bạn vẫn có liên quan trong đó. Nên nhớ, tất cả (UX, CX, Communication, Marketing..) đều là 1 team trước mặt khách hàng mà thôi.

Khó thế thì làm thế nào?

Câu trả lời rất rộng nhưng cũng có thể gói gọn trong mấy khái niệm dưới đây:

• Empathy – bạn phải hiểu người khác ở một mức độ nhất định (toàn bộ stakeholders) và những công cụ như personas, need finding… chính là phục vụ việc này.
• Communications – vô cùng quan trọng, nó là một kênh / một kỹ năng để truyền tải trong dự án UX (và các dự án trong lĩnh vực khác cũng vậy)
• Expectation management – kỹ năng này đòi hỏi bạn phải có kinh nghiệm từng trải trong sale, project management, account management mới có thể làm được. Chính vì thế làm dự án UX bạn không thể làm 1 mình (trừ phi dự án nhỏ, thật nhỏ).
• Solution – giải pháp cho sản phẩm, dịch vụ và nó phải phù hợp với các yếu tố Time – Budget – Business Context (gọi là other tactics)

Đến đây chắc bạn cũng phần nào hình dung được tại sao làm UX nó liên quan tới BA, marketing, digital solution, thậm chí là hardware/devices, hay những kiến thức về project management, process (Lean, Agile, Sprint…)..v.v.. tất cả cũng chỉ hướng đến một mục tiêu nhằm đạt được hiệu quả cao trong các mục tiêu nói trên. Có điều kiện tôi sẽ nói kỹ hơn về các kỹ thuật liên quan của từng khái niệm trên.

Sau cùng, UX luôn đi cùng với strategy, và nó là high-level plan to achieve one or more business goals under conditions. Có nghĩa là thông qua việc xây dựng đội ngũ làm UX, một doanh nghiệp, hoặc một team làm sản phẩm sẽ sử dụng nó (UX) như một phần của chiến lược nhằm mang lại kết quả tốt hơn ở “nhiều khâu” khác nhau trong quá trình vận hành sản phẩm hoặc business của doanh nghiệp đó. Đừng chỉ nhìn ở góc độ UI của website hoặc UI của mobile app. UX rộng hơn thế.

Hà Nội, tháng 12/2017

Bình Trương.