Thực ra thì event này diễn ra đã lâu rồi, từ cuối tháng 11 nhưng hôm nay mới có thời gian ngồi tổng hợp lại, để sang năm nếu có đi sẽ cân nhắc và tham dự những session mang lại nhiều giá trị thông tin hơn. OK, let’s start.

Biết đến UXSEA qua một đồng người ở Malaysia khi bạn ấy share lên LinkedIn. Vì tò mò, nên mình đăng ký bởi cũng không mấy khi ra nước ngoài dự event kiểu này. Khi vào trang web thì thấy toàn bộ vé đã…sold out 😮 thật khó tin, nhưng có lẽ UX đang là hot trend ở Singapore. Nước cờ cuối cùng là lấy tư cách IDF của mình email trực tiếp cho ban tổ chức và may mắn thay, các bạn ấy mở cho mình thêm 1 slot với giá vé không đổi 😀

Cách tổ chức

Giống như các event ở nước ngoài, UXSEA (Viết tắt của User Experience South East Asia summit) có 03 ngày sự kiện. Ngày đầu tiên là workshop (mình không tham dự), và 2 ngày còn lại là conference. Cách tổ chức của UXSEA cũng có một số điểm khá chuyên nghiệp và đáng lưu ý như sau:

• Check-in chuyên nghiệp, có quà tặng nho nhỏ và thiết kế tag đeo cổ khá đẹp
• Đồ ăn, đồ uống đầy đủ, phụ vụ gọn gàng, sạch sẽ.
• Các diễn giả nói ngắn gọn và không cho đặt câu hỏi tràn lan, các câu hỏi đều phải qua hệ thống đặt câu hỏi online và người dẫn chương trình sẽ lựa chọn sao cho phù hợp với chủ đề chính và khung thời gian cho phép.

Địa điểm của UXSEA event khá xa trung tâm, ở Mapple Tree city và nếu đi từ trung tâm thành phố, ngồi xe bus như mình sẽ mất khoảng 45 phút để đến nơi. Mặc dù vậy thì khu này là trung tâm của các cty công nghệ, accelerator, start-up..v.v.. và do UXSEA được Unilever tài trợ địa điểm nên làm được như vậy là khá tốt rồi. Vậy còn nội dung và diễn giả thì sao?

Nội dung, diễn giả

Nhìn chung, diễn giả đều là những người có kinh nghiệm, đang quản lý những đội nhóm làm UX ở các tổ chức lớn như Singtel, Visa, PropertyGuru, Bukalapak, GoJek, v.v.. và có nhiều năm hoạt động trong lĩnh vực product design, team management. Tuy nhiên, phần lớn những diễn giả này không đi ra từ môi trường start-up của chính họ mà làm cho các unicon start-up, hoặc các công ty, tập đoàn lớn. Nghĩa là những tổ chức có tiền và kinh phí để làm UX. Chính vì vậy, nếu bạn là start-up builder, bạn tham gia sự kiện như này thì cần có một đầu óc cởi mở, bởi những gì họ chia sẽ không nghĩa là nó sẽ đúng và có thể áp dụng trong trường hợp của bạn.

Nội dung thì sao?

Ở góc độ cá nhân, tôi đánh giá nội dung của UXSEA phù hợp với người mới bắt đầu tham gia vào UX hoặc có 1-2 năm kinh nghiệm. Các chủ đề được đem ra chia sẻ hầu như không có gì mới trong 2 năm trở lại đây, nhưng có thể là mới được trao đổi ở Singapore, cụ thể như sau:

• UX team management
• DesignOps (chia sẻ từ quyển sách cùng tên)
• Research culture
• Chatbot script
• Design ethic
• Design leadership
• v.v…

Nếu bạn đã hoạt động trong ngành digital design bao gồm UX, CX, behavioural marketing…thì những chủ đề này không mới với bạn, thậm chí bạn đọc và làm về nó hàng ngày. Trong giờ nghỉ ăn trưa, tôi có ngồi cùng với mấy bạn CEO của UX studio Malaysia thì chúng tôi đều thừa nhận rằng, nội dung của event cần chia sẻ kinh nghiệm trận mạc cũng như “practical case study” nhiều hơn. Các bạn ấy cũng nói rằng: đi event như thế này chủ yếu là dẫn nhân viên đi giao lưu học hỏi. Đây là một ý hay, khác hẳn với các công ty ở Việt Nam, toàn sếp đi giao lưu là chính :D.

Những điều thu lượm được

Kết thúc 02 ngày sự kiện UXSEA, điều tôi thu lượm được không nhiều nhưng cũng có một số điểm tích cực với cá nhân tôi và phần nào đó là sự hiện diện của IDF. Tôi xin thống kê một vài ý chính dưới đây:

• Accept the differents – đây là cái tôi thích nhất bởi nó là nền tảng của Empathy. Điều này được bạn design lead của bukalapak chia sẻ và nó rất thực tế. Chúng ta cần chấp nhận sự khác biệt, trong mỗi tổ chức, trong mỗi người để từ đó cải thiện khả năng thấu hiểu, và rồi tạo ra những sản phẩm, dịch vụ tốt hơn.
• IDF dần được giới thiệu với những người trong hội thảo. Bước đầu tôi đặt mối quan hệ với Kuldeep, người quản lý UXSEA và UXArmy. Chúng tôi nói về kế hoạch hợp tác lâu dài trong năm tới.
• Tôi hiểu hơn về tình hình UX tại Singapore và các nước lân cận như Malaysia, Philippines, Indonesia, phần nào định hình được làn sóng đang nổi dần lên về ngành này.
• DesignOps với large scale – cái này mới thấy ở Đông Nam Á, chủ yếu vẫn là team bukalapak (Start-up unicon về eCommerce của Indonesia) với team designer lên tới 100+ người.

Tất nhiên, nếu bạn mới bước chân vào làm UX, tôi vẫn khuyên bạn nên tự mình đi tham gia những sự kiện như thế này để có hình dung rõ hơn về ngành cũng như cách thức các công ty trong khu vực, những người chuyên nghiệp trong khu vực đang làm việc ra sao, vận hành đội nhóm như thế nào. Nếu có thể, bạn nên tham gia workshop để được thực hành về các khái niệm card sorting, brain storming, agile scoping, v.v..

Sau cùng, UXSEA là một sự kiện được tổ chức chuyên nghiệp, đông đảo người quan tâm và tham dự, dù chưa có nhiều tài trợ nhưng những người đứng ra tổ chức đã làm rất tốt, rất “có nghề” cũng như có nhiều kinh nghiệm dẫn dắt chương trình, chia sẻ kiến thức và kết nối cộng đồng.

Singapore, tháng 11/2018

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