Abstraction Hub

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

Category: User Experience

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

Advertisements

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

UX is not always fun

Ai cũng nghĩ làm công việc liên quan đến UX là hay ho lắm, hàng ngày ngồi “chơi” với những công cụ đồ hoạ, những wireframe, những thứ như Sketch, Adobe XD, v.v…chỉ nghĩ tới thôi đã thấy cool rồi. Nhưng thực tế những công việc của UX designer có rất nhiều thứ khiến bạn mau nản lòng, hoặc cảm thấy nhàm chán nếu bạn không thực sự đam mê lĩnh vực này. Trong bài viết này, tôi sẽ chỉ ra những điểm để các bạn hình dung rõ hơn những việc phải làm hàng ngày của “dân UX”.

(Nguồn ảnh: UX planet)

Bắt đầu như thế nào?

Các dự án UX có 3 loại chính:

  1. Làm từ đầu, đừng nghĩ đây là hạnh phúc nhé bởi bạn sẽ phải thực hiện khối lượng công việc khá nhiều.
  2. Cải tiến một sản phẩm / dịch vụ nào đó => dự án kiểu này có sẵn dữ liệu đầu vào giúp bạn định hình phần nào nhưng đổi lại áp lực phải chứng mình giải pháp của bạn thông qua những thay đổi (về design) có hiệu quả.
  3. Tư vấn, thường là giai đoạn 1 dự án đã thiết kế gần xong, hoặc được thiết kế xong bởi team designer nội bộ của một công ty, bạn nhảy vào “góp ý”.

Với loại 1, bạn phải biết nhiều thứ hoặc phải phụ thuộc vào nhiều người tham gia, do đó, dự án chậm là đương nhiên. Bên cạnh đó, việc đi thuyết phục, trao đổi với những cá nhân trong dự án cũng khiến bạn mệt mỏi. Tổ chức càng lớn, communication & progress càng chậm (đơn giản là do họ có qui trình kiểm soát chặt, dẫn đến ai cũng sợ trách nhiệm, do đó ra quyết định chậm, thiếu chính kiến).

Với dự án loại 2, như đã nói ở trên, bạn phải đối mặt với áp lực về mặt hiệu quả của giải pháp đưa ra, nhiều khi giải pháp mới thông qua UX research, dẫn tới điều chỉnh UI “có” mang lại hiệu quả nhưng không đáp ứng kỳ vọng của chủ đầu tư, ví dụ CAC (Customer Acquisition Cost) bị đội lên, hoặc lượng giao dịch trong một payment app chỉ “tăng nhẹ” (do không phải đợt Tết chẳng hạn).

Dự án loại 3 bạn cảm thấy khá “an toàn”, nhưng bạn sẽ nói gì nếu UX không tốt? bạn sẽ huỵch toẹt nói với đội ngũ thiết kế đập đi làm lại? Bạn sẽ “phán” về chất lượng UX khi nó chưa có real testing và chưa có test data? Nói chung bạn nên nghĩ đến những điều này để hình dung về dự án UX trong tương lai.

(nguồn ảnh: uxpin)

Không có chỗ mà làm UX?

Cái này tôi đã nói khá nhiều trong các bài viết trước đây, nhưng trong phạm vi bài này tôi chỉ nhấn mạnh rằng ở Việt Nam, bạn sẽ được “dí” ngay vào bước làm prototype và bị cắt đi hầu như toàn bộ các công đoạn của UX. Tóm lại, bạn khó tìm ra chỗ nào trong qui trình các dự án ở Việt Nam để làm UX chi tiết. Vì sao? UX tốn thời gian, cần thời gian để thử nghiệm, cũng đồng nghĩa là tốn tiền, mà các sếp Việt Nam chỉ muốn nhìn thấy UI và không đủ kiên nhẫn chi tiền cho UX.

“UX team of one” không thực sự hiệu quả

Đây là khái niệm được nhắc tới 3-4 năm về trước, từ một cuốn sách cùng tên với nội dung hướng dẫn làm UX kể cả khi bạn chỉ có một mình. Nghe có vẻ ổn, nhưng đây là điều dành cho người có khả năng tiếng Anh + tự học + giao tiếp + kết nối tốt. Nó cũng phù hợp cho dự án nhỏ, còn vào dự án thực tế và với khả năng của người Việt, nó chưa hiệu quả ngay được. Ngoài ra, tính chất khó khăn nhất là việc làm một mình rất dễ khiến cho bạn bị “ego”, nghĩa là đưa cái tôi, đưa quan điểm cá nhân vào giải pháp thiết kế và trở nên phòng vệ trước những phản hồi của khách hàng.

(UX nhiều việc phải làm, cho nên chơi 1 mình mệt lắm. Nguồn ảnh: UX planet)

Agency luôn ép về tiến độ

Với kinh nghiệm làm digital agency 12 năm của mình thì chưa có bao giờ bạn có đủ thời gian rộng rãi, dễ thở khi làm với agency. Đối với các bộ phận marketing của khách hàng cũng vậy, thời gian phê duyệt kinh phí thì rất lâu, nhưng một khi duyệt rồi thì lại muốn có ngay sản phẩm để xem và nếu ai đã từng làm agency thì sẽ hiểu rằng, bạn sẽ bị “giục”, bị “ép” hàng ngày, hàng ngày, và hàng ngày… Cho dù là nửa đêm, cuối tuần hay ngày lễ, bạn luôn phải chuẩn bị tinh thần nghe điện thoại từ đối tác.

Build more, fail more

Đừng nghĩ làm một lần là “ăn ngay”, cũng đừng nghĩ gửi 1-2 options cho khách hàng là đủ. Mọi thứ sẽ thay đổi liên tục, và dự án càng để lâu càng nhiều phát sinh. Kể cả trường hợp dự án của bạn go-live ngon lành, khi có dữ liệu test và user’s analytics data thì bạn phải quay lại điều chỉnh. Người ta nói “làm UX là vừa làm vừa đo, cho nên đừng đánh giá một bản thiết kế mà hãy test nó”.

Do NOT evaluate design, test it. – NN/g

Adoption: có ai quan tâm đến việc bạn làm?

Câu trả lời là chẳng ai cả, hoặc số ít người trong công ty để ý tới, rất ít. Họ cũng không đánh giá cao công việc này của bạn, trừ những người đã từng phải “trả giá” khi thiết kế sản phẩm ẩu và mất nhiều tiền vì nó.

(ảnh remote testing với đủ thứ để làm – Nguồn ảnh: usabila)

Có nhiều việc chẳng vui vẻ gì

Ngoài việc ngồi vẽ UI, làm wireframe mà đa phần mọi người nghĩ về nó khi nghĩ tới UX (bởi nó khá thú vị) thì còn rất rất nhiều việc khác nữa bạn phải làm trong một dự án UX. Tôi có thể kể ra 20-50 công việc khác nhau mà bạn phải làm (nhiều khi chán ngấy) dù muốn dù không, tất nhiên tuỳ thuộc vào độ lớn của dự án và tuỳ thuộc vào qui trình của công ty bạn đang làm, qui trình của đối tác. Sau đây là một số ví dụ:

  • User research: cực kỳ lắm các thể loại kỹ thuật liên quan và càng làm càng thấy mông lung. Nhất là dự án có tính global như hệ thống website Kempinski.com mà tôi làm 3 năm qua. 80 website chạy trên 1 nền tảng, 7 ngôn ngữ cho site corporate, 19 ngôn ngữ cho các site khách sạn thành viên và lượng người dùng trải rộng khắp thế giới.  Chỉ một báo cáo về eyes-tracking thôi mà cãi nhau cả buổi.
  • Experience mapping: nếu bạn chưa làm bao giờ thì thử Google xem nó là cái gì và ngồi làm nó “tốn máu” như thế nào. Với website là một bản, với mobile là một bản, thậm chí nếu làm kỹ thì bạn có thể làm cho từng khâu như check-out, onboarding, cart-abandonment.. càng làm kỹ càng mất thời gian, thử đi thử lại, cứ có data rồi thì lại update.
  • Documentation: UX rất nặng về làm tài liệu và nó có đủ thể loại tài liệu trên đời. Từ personas, đến use case, cho tới wireframe, IA, search model, v.v.. và cái nào bạn cũng phải cho vào tài liệu chuẩn để gửi cho khách hàng. Có tài liệu là kích thước A4, có cái mô tả POC (proof of concept) thì tôi hay dùng A3 để lúc in màu ra cho đẹp + dễ nhìn. Nếu bạn không làm thì ai làm? cùng lắm bạn có thêm 1-2 BA tham gia giúp bạn, nhưng họ không thể mô tả cái ý tưởng của bạn cũng như những kết quả của bạn làm ra. User journey vẽ thì hay, nhưng mà ngồi mô tả main flow, exceptional flow, alternative flow cũng hết hơi.  
  • Presentation & meeting: Dự án càng lớn thì càng phải họp nhiều, trình bày + giải thích nhiều, thậm chí bạn cứ phải đi qua đi lại hoặc sang bên khách hàng ngồi on-site. Nhưng khách hàng họ còn lo làm việc của họ, đâu có làm với bạn hàng ngày, đôi khi tôi trình bày tại cuộc họp nhưng đối tác không nhớ 2 tuần trước chúng tôi đã làm những gì, đã xử lý tới đâu, tại sao hôm nay lại đưa ra giải pháp này?
  • v.v.. không muốn kể nhiều nữa vì…nói ra thì nhiều lắm 😀

(Hình mô tả user research, bạn có muốn làm không? Nguồn ảnh: IDF)

Khách hàng, họ là 1 thế giới khác

Đối với khách hàng, họ không quan tâm qui trình của bạn, không quan tâm tới thương hiệu của bạn, phần lớn họ chỉ quan tâm tới 3 điều: chi phí, tiến độ, và sản phẩm làm ra “trông” như thế nào. Nói như vậy để bạn hình dung được một điều, chỉ có một số ít khách hàng cá nhân sẽ “ngưỡng mộ” cái bạn làm ra, phần lớn còn lại, họ quan tâm tới vấn đề họ phải lo nghĩ, vì vậy, hãy cố gắng hiểu họ thay vì chỉ lo chăm chút bản thiết kế của mình. Hãy lắng nghe cái họ cần thay vì nghĩ rằng “ông/bà thì biết cái đếch gì về thiết kế mà nói…”, đúng là họ không biết UX, UI thật, nhưng họ biết họ cần gì (đặc biệt là chủ doanh nghiệp) và vì thế họ mới thuê bạn làm.

(Nhìn vào checklist cũng phát nản :D, nguồn ảnh: github.io)

Lời kết

Nhiều bạn nghĩ rằng: tôi chẳng cần thiết làm những việc ông nói ở trên, theme tôi làm ra bán vẫn chạy ầm ầm. OK, đấy là công việc làm web themes của bạn và nó rất hạn chế trong việc áp dụng UX (bởi nó tốt sẵn rồi, và expectation đã định hình từ lâu).  Còn ra dự án lớn, đa quốc gia, đa chủng loại người dùng, hay như một công ty có nhiều văn phòng khắp nơi trên Thế Giới, bạn sẽ phải làm những thứ đó. Tại sao? Thứ nhất, họ yêu cầu bạn làm thì bạn phải làm, đó là qui trình chuẩn và họ trả tiền cho bạn làm như vậy. Thứ 2, những kỹ thuật, qui trình này nhằm đảm bảo yếu tố thành công của dự án ở mức % tối đa với những rủi ro đi kèm.

Làm UX có nhiều cái vui nhưng cũng như các ngành nghề khác nó cũng có nhiều cái mệt mỏi, không vui vẻ gì. Bạn phải học cách vượt qua nó, sống chung với nó cũng như xây dựng một đội ngũ hiểu nhau, làm việc ăn ý với nhau. UX rất rộng và có nhiều việc phải làm. Đừng chỉ nhìn ở góc độ mình làm theme WordPress, Magento hay làm app du lịch, đặt phòng khách sạn, đặt vé máy bay v.v.. Khi nhìn UX ở góc độ business, projects… bạn sẽ thấy nó rất hay và rất khác.

Bài này hơi dài, nhưng bao lâu nay không thấy ai viết về vấn đề này, nên mình lại viết 😀

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

Binh Truong