Abstraction Hub

IA, UX, UI, User Experiences, Usability, Web Design, Information Architect, HCI

Category: User Experience

UX Thailand Feb 2019

May mắn biết đến event này khi đang tham dự UXSEA ở Singapore hồi tháng 11 năm ngoái, và nhìn thoáng qua thấy ban tổ chức có liên hệ với IDF để hợp tác, thế là mình liên hệ và nhận được vé mời ;). Ban đầu, bản thân mình nghĩ rằng chắc sự kiện cũng chỉ như UX event ở Singapore, nhưng trên thực tế thì qui mô của UXThailand2019 lớn hơn nhiều.

Với hơn 700+ người tham dự và các diễn giả được mời từ Mỹ như Jared Spool, hay Melissa Perri (tác giả cuốn “Escape the build trap”), phối hợp với những người làm trong ngành và nhiều kinh nghiệm tại Thoughtworks, cũng như các công ty digital ở Thailand, UXThailand2019 đã thực sự gây ấn tượng.

Mở đầu chương trình

Thẻ đăng ký của mình

Sảnh hội nghị.

Từ khâu tổ chức rất chuyên nghiệp, bài bản và qui mô, cho tới những “phụ kiện”, quà tặng và bố trí không gian ăn uống, giao lưu dành cho người tham dự cho thấy ban tổ chức rất quan tâm đến “trải nghiệm” của khách đến event. Không gian của địa điểm hội thảo là một nhà hát hiện đại trên tầng thượng của Siam Square với các thiết bị âm thanh, ánh sáng, sân khấu không chê vào đâu được.

Gặp lại team UX Malaysia, Indonesia và cả Philippines.

Giới thiệu về VR/AR trong user reseach tại sân bay New Zealand

Khi buổi hội thảo bắt đầu, ngay từ chủ đề đầu tiên của Melissa Perri đã làm tôi và các đồng nghiệp ấn tượng. Escape the build trap là tên của cuốn sách mà chính Melissa Perri là tác giả. Chủ đề được xoay quanh việc tập trung vào tầm nhìn của sản phẩm, xây dựng sản phẩm phục vụ đúng nhu cầu của khách hàng (client expectation) và làm sao đảm bảo được rằng, sản phẩm làm ra sẽ giúp khách hàng chinh phục được người dùng, đạt được mục tiêu cần thiết của dự án. Để làm được điều này, nhóm làm sản phẩm cần “bớt” thần tượng hoá Agile / scrum một cách máy móc mà cần tập trung vào những valuable deliveries, nghĩa là các bản “build” thực sự tạo ra giá trị như tăng tỷ lệ CRO, giảm tỷ lệ rời bỏ sản phẩm (app abandonment), v.v… Đằng sau việc này là quá trình thay đổi tư duy làm sản phẩm, cả team cần phối hợp với khách hàng để tạo ra sản phẩm có giá trị thực với người dùng thay vì làm ra một sản phẩm “theo đúng yêu cầu” của chủ đầu tư. Tất nhiên bạn có thể phản biện rằng việc này khó, không chỉ khó ở Việt Nam mà khó đối với bất cứ team làm sản phẩm nào trên Thế Giới (vì 99% các chủ đầu tư thường rất “tự tin” vào nhận định của mình). Mặc dù vậy, cái cần nắm bắt ở đây là tư duy, tư duy đúng thì sản phẩm làm ra sẽ giải quyết đúng vấn đề của end-user, và nó sẽ mang đúng nghĩa “user-centered” design. Đối với cá nhân mình, đây là bài trình bày làm hài lỏng phần lớn mọi người trong khán phòng và nó là một trong 02 bài nói tốt nhất của hội thảo.

Melissa Perri trong bài trình bày của mình.

Product kata – Melissa Perri

Tiếp theo là một số chủ đề “buồn ngủ” khác mà mình không muốn đề cập tới. Một phần là nó hơi “xa vời” so với những gì đang diễn ra tại Đông Nam Á, một phần là người trình bày không “truyền năng lượng” được cho khán giá. Chính vì thế mà thời gian giữa ngày của buổi hội thảo mình không tập trung cho lắm 😛

Bài nói ấn tượng thứ 2 cũng là bài trình bày cuối cùng của hội thảo thuộc về Jared Spool. Ai ở trong ngành HCI và UI lâu rồi thì đều biết bác này với trang web http://www.uie.com và các khoá học liên quan. Đây cũng là tác giả viết về UI design từ những năm 80′, 90′ khi máy tính chỉ có giao diện command line hoặc cùng lắm là GUI (Windows).

Đến với UXThailand2019 Jared Spool có bài phát biểu về chủ đề mơ hồ, và nhạy cảm, cũng rất khó đó là “future of UX design”. Nó khó bởi tương lai ai cũng “chém” qua qua được nhưng để định hình cho những người đi sau mình một cách nghiêm túc thì thực sự rất..rất khó. Nhưng Jared Spool đã làm rất tốt công việc của mình bằng lối kể chuyện nhẹ nhàng, dẫn dắt người nghe đi vào kịch bản của ông, để rồi mô hình hoá một loạt những ý tưởng mới. Một trong những ý tưởng quan trọng nhất đó là “broken comb” nhằm thể hiện ý tưởng phát triển kỹ năng của người làm trong ngày UX / digital design. Trước đây, khi đọc và học về Agile shortcuts hồi năm 2013, mình có biết đến T-shape model với cột dọc của chữ T là kiến thức nền tảng, và thanh ngang của chữ T là kiến thức mở rộng. (mọi người có thể google T-shape skill model để hiểu thêm nhé), nhưng với việc khuyến khích và đòi hỏi việc học liên tục của ngành, Jared Spool đã đưa ra đề xuất….học đều các kỹ năng, và theo thời gian, các kỹ năng này sẽ được tích luỹ, ghi nhớ rồi bổ trợ cho nhau (xem hình phía dưới).

Với những người mới vào ngành hoặc mới chuyển qua học về UX / product / UI design, các bạn có thể thấy hơi mông lung và mô hình này hơi quá sức. Nhưng thực tế là nếu đã làm digital product design một thời gian, kinh qua nhiều vị trí cũng như nhiều dự án thì các bạn sẽ thấy việc phải đọc và học thêm các kiến thức như business model, business operation, leadership, team building, psychology, marketing, customer serivce, business analysis, hay thậm chí IT (IA, mobile / web architect…) là điều không tránh khỏi (nếu không muốn nói là bắt buộc) để có thể hiểu sản phẩm, hiểu về hành vi tổ chức (tổ chức của mình và của khách hàng) để từ đó làm ra sản phẩm “thoả mãn yêu cầu”.

Jared Spool cũng có nói rằng: “ban đầu, bạn cứ bám sát kỹ năng nền tảng của mình, nhưng liên tục học hỏi và mở rộng kiến thức sang các mảng khác, lâu dần, kiến thức đó sẽ là của bạn”. Với cá nhân mình, mình thấy đúng.

Sân khấu, với logo của IDF ở dưới cùng, cạnh Axure 😀

Sự tiến hoá của ngành UX / UI design

Mô hình broken comb skill learning

Hội thảo kết thúc cũng là lúc để “team building” với các bạn trong khu vực và điều bất ngờ nhất là có nhiều bạn đến từ…Myanmar, một đất nước mà bản thân mình nghĩ vẫn chưa “năng động” bằng Việt Nam. Vậy mà, số người đến từ Việt Nam chỉ đếm được ít hơn số ngón tay trên một bàn tay 😦

Với nhiều người, tham gia hội thảo là sự kiện “tốn tiền” và thực sự không muốn “đầu tư” để..đi. Nhưng nếu không “chịu khó” đi và bước ra xem Thế Giới ngoài kia, người ta đang làm cái gì? Với tôi đây là điều quan trọng khi ở Việt Nam, phần lớn các bạn chỉ làm Web, mobile App và thậm chí các web và app các bạn làm cũng “bó hẹp” trong những mảng ít nghiệp vụ hoặc trong những ngành đã bão hoà như đặt xe, gọi đồ ăn, e-commerce.v.v..

Bản ghi chép của team UX Malaysia

Khép lại 2 ngày hội thảo và workshop, ban tổ chức UXThailand2019 thực sự đã làm rất tốt công việc của mình. Các diễn giả cũng như bài trình bày của họ chất lượng hơn rất nhiều những UX event khác trong khu vực. Hy vọng rằng, sang năm 2020, sẽ có nhiều bạn ở Việt Nam tham gia sự kiện này hơn, và xa hơn là UX Vietnam có thể có những event như thế này.

Bangkok, tháng 02/2019

Advertisements

UXSEA 2018

Singapore bay

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.

Conference room

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?

Rất đông người tham dự

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..

With IDF Malaysia

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

DesignOps – Tìm hiểu sơ lược

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

Wires-V4-1-1000x438

Ảnh mô tả DesignOps – nguồn Airbnb

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

TH Milk – Khi user lười đọc due date

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.

unnamed

TH True Milk không đường, NSX, HSD in ngay cạnh chỗ cắm ống hút.

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

CMS, một khía cạnh trải nghiệm bị bỏ quên

CMS đúng là một trải nghiệm mặc định bị bỏ quên bởi đội ngũ xây dựng web. Họ cho rằng cứ bàn giao cho người dùng hệ thống CMS sẵn có và người dùng phải chấp nhận điều đó. Trên thực tế, chúng ta có thể làm tốt hơn.

TDB*

Các dự án thiết kế website thường chỉ được chú trọng vào giao diện (UI) của trang web với những thứ như banner, bố cục, màu sắc, menu (navigation), v.v.. Và rồi sau khi mọi thứ được thống nhất giữa các bên thì trang web được ra mắt, công bố trên các phương tiện truyền thông. Sau đó thì sao? Toàn bộ hệ thống website, phần mềm quản trị nội dung (hay còn gọi là CMS, viết tắt của Content Management System) được bàn giao cho bộ phận vận hành, quản lý nội dung của khách hàng. Đội ngũ phát triển website thì tổ chức ăn mừng và không cần quan tâm tới dự án đó nữa.

3 tháng sau quay lại hỏi thăm khách hàng, đội ngũ làm web phát hiện ra giao diện của website xấu quắc, hình ảnh, nội dung của các bài viết bị xô lệch…

View original post 864 more words