Đầ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