Khóc như DesignOps

25/09/2025

Một ý tưởng – Một insight - Một trò chơi

Dear các bạn, lâu lâu ngoi lên tí cho đỡ chán. Sau 1 tháng wrap up cái project Healthcare mà mình cực kỳ tâm huyết, thú thật đã quên kha khá insight rồi. Trong lúc lật lại để note, tự dưng nghĩ ra:
“Ủa sao không đem mấy cái này ra chém gió cho vui, vừa nhớ lâu hơn, vừa khỏi phí của trời?”

👉 Và đó là lý do cái post này ra đời.

Mình sẽ host một buổi discussion (không phải sharing), số lượng

10/08/2025

Có 1 cái dự án mà...
- Multiple Language
- Multiple platform
- Multiple brand
- Custom by country
- Vừa rồi lại có khách hàng gặp lỗi, test hoài không ra, lại gặp HIPAA cản trở làm gì gặp mà hỏi được, dí PO mãi mới biết là client của client của client dùng máy Lenouvo cho nhân viên - vậy là có thêm quả multiple device tiếp, ai mà nghĩ được chạy web browser Mac không lỗi, Dell không lỗi, cơ mà Lenouvo lỗi, ủa alo???.
Tui vẫn còn nợ cái light/dark mode nữa, tui hết làm DesignOps rồi về làm công nhân thôi mà nó oằn còn hơn hồi làm DesignOps nữa 🥲🥲🥲.
Mong người anh đến sau chăm chút cho đứa con tinh thần của tui, dọn sẵn rồi lâu lâu vô nghía nó xí cũng được, đừng bỏ bê nó như trước, tội nó lắm 🥹🥹🥹

Send a message to learn more

22/08/2024

Một bài viết khá hay dành cho ai đang cảm thấy nhức nhức cái đầu khi dùng Design System mà hở tí là có người sửa này sửa kia loạn cả lên.
Bài viết chủ yếu nói chi tiết về quản lý version update và kiểm soát quyền edit DS bằng Branching, ai đã dùng Abstract cho DS trên Sketch trước đây hẳn sẽ quen với cái này.

Design systems evolve over time and so do the platforms they are built on. As maintainers, we need to make sure to keep them up to date…

18/03/2024

Share bài hay From ai đó trên FB. Không phải của mình :))))
---
Keep It Simple Stupid - quan trọng nhất là Keep It Simple, không phải Stupid 😌

Keep It Simple Stupid (KISS) là một nguyên tắc trong thiết kế nói chung, trong đó nhấn mạnh đến sự đơn giản và dễ dùng của sản phẩm. Với lĩnh vực phần mềm, sản phẩm của chúng ta sẽ là các app, các thư viện, framework, hoặc có thể sâu hơn là các class.
Một sản phẩm dễ sử dụng hoàn toàn khác với một sản phẩm đơn giản đến mức stupid, và cũng không có nghĩa là cắt bỏ đi tất cả mọi thứ hiện chưa sử dụng đến.

Việc áp dụng KISS một cách tiêu cực mà không quan tâm đến SOLID hay design pattern (như một số comment mình đọc được) là stupid, không phải KISS.

Tại sao phải sử dụng Factory trong khi ta hoàn toàn có thể sử dụng new? Tại sao phải tạo ra các interface trong khi cuối cùng ta vẫn phải có một "concrete object"? Việc tạo ra các thành phần mới như vậy chẳng phải làm cho vấn đề phức tạp hơn hay sao?

Vậy chúng ta thử đặt một câu hỏi khác nhé. Tại sao các bạn phải có phích và ổ cắm điện? Tại sao chúng lại phải theo các chuẩn? Chẳng phải bạn chỉ cần để sẵn đầu dây điện trần rồi dùng tay quấn lại là xong ☠️? Hoặc người ta có thể nối luôn cáp TV vào mạng lưới điện trong nhà? Đó là vì ổ cắm và phích cắm - vốn là những thành phần được thêm vào trong hệ thống điện, đã giúp chúng ta sử dụng một cách đơn giản hơn rất nhiều, giúp một đứa trẻ cũng có thể sử dụng thiết bị thay vì phải cần đến một thợ điện.

Trong phần mềm cũng vậy, các interface được tạo ra nhằm mục đích đơn giản hóa việc sử dụng, các Factory giúp bạn tạo ra các object dễ dàng hơn. Chúng được tạo ra để giúp sản phẩm của bạn đơn giản và dễ dùng hơn, không phải ngược lại. Chúng có thể làm code của bạn to ra một chút, nhưng sẽ "flexible" hơn nhiều, và sẽ giúp bạn ẩn đi những gì phức tạp đằng sau, đó chính là Keep It Simple Stupid.

Hay nói cách khác, hãy "làm sản phẩm đơn giản đến mức thằng ngu cũng dùng được", chứ không phải "làm sản phẩm đơn giản như những thằng ngu"
---

Dạo này mình đang học lại các Design Pattern cơ bản từ NN Group, các bài viết gốc đều được viết từ 10 - 25 năm về trước nhưng vẫn có giá trị đến bây giờ. Nếu bạn cũng hứng thú thì có thể học tại đây và lâu lâu ib để bốc phét + học chung với mình -

Unsure how to design and implement user-interface patterns? Use this collection of links to our content about specific patterns.

17/01/2024

Hên quá kiếm được bài đăng cho kênh khỏi mốc meo rồi 💃🕺
Cách tổ chức khá hay cơ mà ở VN thì vẫn recommend là team có ông làm chuyên môn, có ông làm communicate cho mấy ông kia đỡ bị phân tâm, team nhỏ thì có lead dẫn dắt là được, team khó kiểm soát mới cần manager.

Scaling a design team in a high-growth company

05/11/2023

Đợt này có bạn hỏi “Ủa group tạch rồi à a?"
À thì… cũng chưa tạch nhưng mà hết chuyện để nói á, tại cái role DesignOps này ở c.ty startup thì lúc loạn lạc thì người ta réo mình ầm ầm chứ êm êm tí rồi thì mình vẫn phải back lại làm công nhân chạy task sấp mặt như mọi người thôi 🥹🥹🥹

Ở chỗ hiện tại thì mình mấy cái liên quan đến trao đổi chiêu thức giữa Design và các team là chính, chứ chưa có đi sâu vào optimize sản phẩm gì đâu. Bạn nào muốn biết thêm về chuyên môn liên quan đến team thì recommend là đọc các bài gần đây của team One Mounth trong 2 tháng gần đây nha, toàn bài xịn đi chuyên sâu rất bài bản, toàn liên quan đến Ops cả đấy, vận dụng được 1 cái thôi là bay cả năm như chơi.

P/s: Nói chớ làm cái role này nhọc cái đầu nhưng mà được cái có drama hít bể phổi luôn, chắc cũng là một điểm cộng của môn này 😆😆😆

12/09/2023

Tối nay ngồi nói chuyện DesignOps với chị An cái chợt nhớ ra là có cái template mình làm để present trong buổi PO vs DES tháng trước khá dễ sài mà dễ áp dụng cho nhiều mô hình và chủ đề, tính share mấy lần mà quên hoài (thực ra thì chủ yếu là do lười viết cái CAP này là chính 🙈 🙈 🙈)

Note nhỏ: cái template này mục tiêu chính là để mọi người ngồi lại và nói chuyện để hiểu nhau và hiểu tình trạng hiện tại là chính hen, mình chạy cái này thôi đã gần 2 tiếng rồi nên không có bàn về solution, cái đó section khác có dịp mình ới tiếp sau nha.

Nội dung template có 3 phần chính:

1. Ice breaking mượn một câu chuyện để dẫn mọi người đi đến vấn đề (mình chọn Mario vì nó có thể replace cho hầu hết mọi vấn đề được).

2. Confirm thực trạng: đặt câu hỏi gợi mở và cố gắng để mọi người tự nói thực trạng (host dẫn dắt)

3. Nhận thức được scope của nhau để nhờ đúng người và tìm đúng việc, có một cái không gian để mọi người tự do tương tác

Đẹp nhất là sau bước 3 thì sẽ có solution và action luôn, tuy nhiên mình đặt mục tiêu là mọi người hiểu nhau là chính nên solution mình làm và tracking trong buổi khác, có dịp sẽ sharing tiếp sau

Mình nghĩ nó khá đơn giản và gọn nên bạn nào ưng thì xem chơi, thấy tiện thì sài còn sida quá thì skip giúp nha.

Link template đây, làm sao để cả team cùng ngồi lại với nhau và làm được cái mục số 3 một cách tự nguyện như hình bên dưới là coi như win 80%
https://www.figma.com/file/BhpKdiUQUerTzzX9MvRjXf/PO%2FBA-vs-DES?type=whiteboard&node-id=26-4447&t=GCfu4s2rg7AujrDr-11

31/08/2023

Một nghề cho chín còn hơn chín nghề 💃🕺

Đầu tuần, mình được sếp team Tech tâm tình nhẹ, câu chuyện là mình Ops thì ok rồi, nhưng mà xét về kỹ năng Design thì mọi người rất khó nhận xét mình như thế nào vì mình làm ít quá…Bể đầu thiệt, hồi đầu mình làm Design thì expect mình Ops giờ mình Ops đang vô khuôn khổ lại muốn mình show skill Design.

Thế rồi câu chuyện ra sao, tỉ lệ Ops giảm xuống 20% và tăng Design lên 80% để có thời gian mà show kỹ năng chứ sao :))) À thì cũng hông vui vẻ mấy, mới làm 2 tháng mà switch xoành xoạch, thôi thì vì nghèo nên đành chấp nhận với tỉ lệ trên nhưng mình yêu cầu gỡ title DesignOps xuống và sẽ trở thành người support team chứ không chịu trách nhiệm cho các vai trò của Ops trước đây vì 20% không đủ để làm cái gì ra hồn cả.

Sau một hồi kiên quyết từ chối title thì scope của mình đã được down xuống nhỏ hơn để vừa khít với 20%, và mình chỉ chịu trách nhiệm với cái nhánh mình đang Ops thay vì cover toàn bộ như trước kia.

Tính ra là nếu DN thấy tình hình ổn ổn thì vai trò này có thể bị thay thế bất cứ lúc nào nên là làm role gì thì làm, miễn có chữ Design ở trước thì phải giỏi Design nghen mấy bồ, hông là ra đê hồi nào hông hay á 👻👻👻

27/08/2023

Thân gởi bạn nào tính chơi bộ môn này một cái report để biết tình hình của role này ở nước ngoài như nào -https://designops.report/wp-content/uploads/2022/10/State-of-DesignOps-2022.pdf

Với mình, công việc của một Ops sẽ rất nhiều và liên đới rất nhiều team, bạn sẽ làm mọi thứ để support team bao gồm: training, setup không gian làm việc, máy móc, tuyển dụng, request benefit, DS, collaboration... cái gì cũng được miễn là có lợi cho thành viên của team và tăng giá trị của team design với công ty hiện tại

Vậy nên để dấn thân vào bộ môn "tốn nhiều nước bọt" hơn là click chuột này thì mình nghĩ là các bạn cần phải rạch ròi vị trí của mình với người giao nó cho mình, vì rằng việc nhiều lắm, ít thì họ không tạo ra role này rồi.

Vậy nên sẽ rất khó để bạn vừa Ops vừa Lead team product vì sẽ bị bias giữa việc thành công của sản phẩm hay thành công của team design.
Tương tự với Ops và Manager thì sẽ bị xung đột vai trò tiếp - ông manager mà lại chiều lòng nhân viên thì toi rồi.

Mỗi role một nhiệm vụ rạch ròi sẽ tốt hơn, hông rạch ròi được thì hãy thẳng thừng từ chối cho lẹ. Tại team mình hiện tại, khi làm project thì một bạn A sẽ lead mình và bạn khác, bạn A sẽ chịu trách nhiệm chất lượng design đầu cuối. Còn nếu không làm project thì mình sẽ lead bạn A đó, mình sẽ chịu trách nhiệm để các bạn có thể làm việc tốt và grow được một cách thuận lợi

24/08/2023

Tổng kết nhanh hành trình 30 ngày mình đã làm được gì với vai trò DesignOps

DESIGN TEAM
- Làm rõ tình hình của team, vấn đề các bạn đang gặp phải, expectation của mọi người là gì.
- Define được scope of work của nhau để không bị chồng chéo công việc và support nhau tốt hơn.
- Down bớt scope design, mọi người dễ thở hơn và chạy task thoải mái hơn

PRODUCT TEAM
- Lấy lại được vai trò chủ động trong việc present ideas design của mình với stakeholders.
- Chạy thành công buổi internal discuss để xác định lại format requirements và xa hơn là scope công việc cũng như cách PO và DES support lẫn nhau trong tương lai.
- 2 team đã discuss với nhau nhiều hơn, team làm việc mượt hơn

DIGITAL PRODUCT TEAM
- Designer xuất hiện nhiều hơn, mọi người aware được nhiều hơn về vai trò của designer và những gì designer có thể thực hiện được.
- Thay đổi cách trình bày design để các team access dễ dàng hơn và tìm thấy thứ mình cần nhanh hơn
- Active hơn

CÔNG TY

- Một vài team bắt đầu xác định rõ hơn về vai trò và vị trí của design team.
- Design join nhiều hơn các hoạt động và được tiếp cập nhiều các thông tin liên quan đến công ty.
- Vạch ra được vài plan nhằm tác động đến các team khác với mục đích chính là để mọi người biết được rằng “khi làm cái này thì tôi sẽ liên hệ team UX/UI vì họ làm cái này tốt hơn”

——

Tracking - đang thực hiện
Plan cho thời gian tới - đang xem xét thử là nên improve cái cũ cho mượt trước hay làm tiếp cái mới!

——

Cảm ơn các bạn team Product nói chung, team Design nói riêng và văn hoá công ty đã support cho sự thành công trong thời gian ngắn này của mình rất nhiều. Mình tin rằng với 30 ngày ít hỏi của một nhân viên thử việc thì cho dù đặt ở bất kỳ công ty nào cũng sẽ là một thử thách lớn hơn rất nhiều, cám ơn mọi người rất nhiều!

24/08/2023

NGÀY 30 - CHALLENGE SUCCESSFUL

Điểm thú vị của ngày 30 là nó lại trúng luôn vào ngày mình review Probation.
Đối với mình thì vị trí Ops này là một vai trò có tác động rất nhiều tới các team khác và cả công ty chứ không hẳn chỉ chạy hành lang, chăm sóc tinh thần cho AE nội bộ. Nên mình cũng đặt ra khá nhiều nội dung để verify xem doanh nghiệp này phản ứng như thế nào đối với feedback của mình cho process, team, các sếp, công ty, phòng ban này nọ...
Đã có những căng thẳng xảy ra ngay trong buổi này, nhưng may mắn là đến cuối cùng thì mọi người lại rất hòa hợp, các bên liên quan cũng có những action nhanh chóng với nhau để clear các feedback của mình, theo mình đây là một điểm cộng rất lớn để verify xem mình có nên làm tiếp hay không, vì bạn biết đấy - Ops mà bị hạn chế thì chỉ có chết, chạy như culi thôi, thà làm chuyên môn còn hơn.

Yeah, một target nhỏ khác khá thú vị là mình sẽ có thể điều phối buổi này được trong 2 tiếng mà mọi người không mệt mỏi, nếu hông được thì là do mình chưa phù hợp - tốt nhất đừng làm. Hên là cái này cũng pass luôn :))))

Cảm thấy may mắn vì được trải nghiệm vị trí này, được thử thách, được đón nhận dù nó vẫn còn thiếu sót và quan trọng nhất là mọi người thẳng thắn feedback cho nhau - cái này hông có thì chịu thôi, mò kim đáy bể.

Cám ơn bạn đã đọc đến đây, nội dung thì chủ yếu là recap của mình trong quá trình làm thôi chứ chưa có gì đặc sắc, hy vọng có dịp nào đó mình sẽ chia sẽ cụ thể hơn sau hen. See ya!

23/08/2023

NGÀY 29 - CHUẨN BỊ LÊN THỚT

Ngày này cũng nhàn: làm slide - present, sửa slide - present, làm slide - present, làm tiếp sửa tiếp :))))

Lặp đi lặp lại liên tục để có thể nói hết ý trong khoảng thời gian 2 tiếng mà mọi người vẫn tỉnh táo, ít mệt mỏi. Cái này dẫn chuyện là một đằng á, mà mình thấy cần phải mix giữa thứ mình làm được với thứ mà người nghe quan tâm nữa thì các bạn mới tập trung được.

Tính ra cái slide này đập cũng mấy chục lần rồi, hóng ngày mai nó work ngon lành, hông thì rõ ràng là do mình dở chứ hông đổ ai được :)))

Một chút màu mè xôi chè được dùng: timeline để đảm bảo mọi người aware và present không bị ngắt quãng, MJM để vịn vào và nói rất nhiều thứ trên trời dưới đất là mọi người ít bị lạc lối, personal, metrix… này nọ các kiểu để show hàng cho các team khác biết là design team có thể làm gì - cơ mà không có team ngoài Tech nên thôi bỏ qua đi :))))