Topic highlights
- Nam Bui's presentation on product design:
- Introduction to the Sparkle icon and its use in AI applications.
- Sharing insights on onboarding new users for AI applications.
- Phat's share on Go weekly commentary:
- Introduction to "Prep", a tool for compile-time evaluation in Go.
- Overview of "War Zero", a database-compatible web assembly runtime.
- Discussion on the advantages and limitations of these tools.
- Hoang's presentation on chatbot evaluation:
- Introduction to a method for evaluating chatbots using simulated users and evaluators.
- Description of the setup and implementation of the evaluation process.
- Anh's case study on a stock trading application:
- Introduction to the research and redesign project for the Kafi stock trading app.
- Sharing the process of user research, problem analysis, and proposed solutions.
- Discussion on applying AI in the user research process.
- Important announcements from management:
- Request for everyone to write 2 essays and 1 practical assignment on AI:
- Essay 1: About company culture
- Essay 2: About AI applications in each person's field of work
- Assignment 3: Practical task (topic yet to be determined)
- These are conditions for the year-end trip and performance review.
- Submission deadline is before the 4th week of November.
- Emphasis on controlled use of AI in work processes.
- Request for everyone to write 2 essays and 1 practical assignment on AI:
- Updates on ongoing projects and research topics in the team:
- Discussion on topics such as multi-agent systems, knowledge routing, semantic projection, etc.
- Emphasis on the importance of understanding and applying new architectures in software development.
- Highlighting the importance of applying AI in work and the need for proactive learning to keep up with trends.
- Discussion about changes in the job market, especially for junior and mid-level positions.
Vietnamese Transcript
00:00 Hôm nay có một vài topic về Go commentary, ngoài ra thì sẽ có bài của Nam về phần product design commentary. Sau đấy thì sẽ có một vài phần liên quan đến evaluate chatbot và kỹ thuật để làm chatbot của Hoàng và Tom. Chắc là sẽ share anh em một tí về cái kiến trúc microservices, nếu còn thời gian thì có một bài case study về một cái project crypto finance của Anna.
08:47 Nam Bùi lên được, em chưa thấy Nam Bùi xong bài… Xong rồi thì em share màn hình nhé.
10:31 Rồi mọi người thấy màn hình chưa? Ok, chắc mọi người thấy rồi. Tiếp nối bài product design của tuần trước, tuần này em sẽ nói về hai bài, đầu tiên sẽ là về icon Sparkle. Đầu tiên thì icon Sparkle này thì chắc là cũng phổ biến, không biết mọi người có thấy icon này bao giờ chưa? Nếu có thì mọi người bấm phím 1 cho em với. Thì icon này nó sẽ thuộc dạng là… Ừ thì icon này thì hiện tại nó đang sử dụng cho tất cả các app, và hiện tại em sẽ muốn giới thiệu một vài cái app.
11:30 Đầu tiên là cái app Plane Finder này thì nó sẽ dùng icon này để hiện thị cho các bài viết mới của Plane Finder. Cái app thứ hai là app e-commerce chuyên bán quần áo mỹ phẩm Ulta, thì nó sẽ có một cái tính năng là discover, sử dụng icon Sparkle để show tính năng này. Tiếp theo thì chắc mọi người cũng quen thuộc hơn, đó là Google Meet, nó có tính năng remove background và thêm background khác vào, thì nó cũng sử dụng icon Sparkle này.
12:14 Như vậy là mình có ba cái app đã sử dụng icon Sparkle, ngoài ra thì còn nhiều app khác nữa cũng đang sử dụng icon này. Sp icon này không chỉ sử dụng cho một tính năng nhất định mà nó rất phổ biến. Đến khi AI bắt đầu xuất hiện thì AI hiện tại cũng đang dùng icon này rất nhiều, ví dụ như Figma dùng cho icon generator. Ngoài Figma thì còn có Miro, một app để vẽ diagram hay wireframe.
12:59 Một cái app nữa đó là Dovetail app, nó sử dụng icon này để generate lại các buổi họp. Hầu hết các app AI hiện tại đều đang sử dụng icon này. Và cuối cùng là ứng dụng Nylas, hiện tại Nylas sử dụng icon này làm giao diện chính của họ. Việc này làm cho người dùng khi thấy icon Sparkle sẽ liên tưởng đến các tính năng liên quan đến AI, vì icon Sparkle này đang trở thành biểu tượng của AI.
13:45 Trước khi em show các giao diện về AI, em có show một số ví dụ về việc sử dụng icon này cho những tính năng khác của các app khác, để chứng minh rằng icon Sparkle này không bị giới hạn chỉ cho một tính năng duy nhất mà nó có thể dùng cho nhiều tính năng khác nhau. Để sử dụng icon này hiệu quả, em nghĩ khi mình hover lên icon thì sẽ có tooltip để hiển thị tính năng cụ thể là gì, hoặc là show ra tên tính năng ở dưới icon luôn. Nhìn chung thì việc sử dụng icon Sparkle hay các icon dạng generic khác sẽ cần tooltip hoặc tên tính năng để user tránh bị nhầm lẫn.
14:31 Bây giờ em sẽ chuyển sang bài thứ hai, bài này sẽ nói về việc onboarding người dùng mới cho AI. Em sẽ tập trung so sánh các app với nhau để đưa ra những best practices cho việc onboarding người mới sử dụng AI hay vừa đăng nhập vào và khám phá một tool AI mới.
15:26 Ở đây thì có một app khá nổi tiếng ở Trung Quốc tên là SparekDesk. Khi người dùng vừa vào app, họ sẽ có một danh sách các câu hỏi và hướng dẫn để tìm hiểu về app này. Ngược lại thì ChatGPT không cần phải có danh sách câu hỏi này, mà người dùng có thể bắt đầu ngay bằng cách gõ câu hỏi của mình vào để kiểm tra khả năng của nó.
16:10 Thay vì cung cấp list câu hỏi hướng dẫn, người dùng thường bắt đầu với ChatGPT bằng cách hỏi ngay một câu như ‘Can you…’ để kiểm tra khả năng của AI này có thể làm được hay không. Cách này giúp việc onboarding với ChatGPT hiệu quả hơn so với các tài liệu hướng dẫn dài dòng.
17:09 Ví dụ tiếp theo là khi người dùng lên App Store, họ có thể thấy các danh mục như Productivity để hiển thị tính năng của app. Ví dụ ở bên trái là Productivity, bên phải là kết quả tìm kiếm và các tính năng của app. Điều này giúp người dùng dễ hiểu hơn về app trước khi họ tải về.
18:02 Nên là em nghĩ rằng với từng character thì nó sẽ tạo ra một câu hỏi khác nhau cho từng character, nên là người dùng sẽ bị khó hiểu và phải cân nhắc việc nên chọn cái nào. Còn phần mềm này thì nó chỉ có những hướng dẫn tool-tip ngắn gọn cho user, và không có những bước onboarding rườm rà như vậy. Thì cái ý ở đây là mình nên loại bỏ những cái step không cần thiết cho user, thay vì đưa quá nhiều bước hoặc quá nhiều thứ làm người dùng bị confused. Đây là ý cuối cùng.
18:58 Ví dụ như cái app bên trái đưa ra những câu hỏi chi tiết cụ thể cho người dùng, còn app bên phải thì lại đưa ra các câu hỏi chung chung, không liên quan đến một tình huống cụ thể nào. Theo em thì việc đưa ra câu hỏi chung chung sẽ hiệu quả hơn, vì những câu hỏi chi tiết quá sẽ không hữu ích cho người dùng, và thường thì những câu hỏi chi tiết quá sẽ không match với những gì người dùng mong muốn. Vì vậy em nghĩ là nó sẽ dư thừa trong quá trình onboarding user. Ngược lại, ChatGPT thì đưa ra những câu hỏi chung chung, và điều này sẽ có phần trăm cao hơn là nó phù hợp với mong muốn của người dùng.
19:44 Từ bốn cái ví dụ so sánh này, em rút ra: Thứ nhất, mình nên hạn chế đưa ra quá nhiều câu hỏi chi tiết cho user, thay vào đó, để họ tự do hỏi trực tiếp cái gì họ muốn. Thứ hai, mình nên đưa ra phạm vi tính năng rõ ràng ngay từ đầu, như dạng để set expectation cho user, thay vì để họ vào rồi không dùng được thì họ sẽ xóa ứng dụng. Thứ ba, mình cần bỏ đi những bước onboarding rườm rà không cần thiết và tối ưu hoá thời gian cho user. Cuối cùng, mình nên đưa ra những câu hỏi chung chung, thay vì những câu hỏi quá chi tiết.
20:33 Dạ rồi, em xong. Anh em có câu hỏi gì không thì comment lại phía dưới nhé. Nhưng mà anh thấy ở đây, thực ra việc so sánh như vậy thì anh có cảm giác những cái app này nó có target đến cùng một tác vụ không em? Tại vì thực ra kiểu cái case này, những câu hỏi mang tính specific có thể vẫn useful trong một số hoàn cảnh khác nhau. Chứ không phải lúc nào câu hỏi random cũng hợp lý, vì như kiểu ChatGPT là một tool chat general có thể làm nhiều thứ. Còn một số giao diện chat khác thì nó lại specific cho một tác vụ cụ thể thôi.
21:26 Nhưng cái mà em nói thì nó cũng thuộc dạng generic tool chat như ChatGPT, chứ không phải cho một tác vụ cụ thể. Đúng rồi, nên là em so sánh hai cái dạng generic tool chat với nhau thôi.
22:09 Dạ, thì đúng như anh nói, ví dụ như là một cái app cụ thể thì nó cần có những câu hỏi cụ thể hơn. Nhưng mà ở đây em chỉ so sánh hai cái dạng tool chat chung chung thôi.
23:07 Dạ. Đúng rồi, thắc mắc thêm không? Có gì hỏi tiếp nhé. Bây giờ thì chuyển qua topic tiếp theo. Topic lần này là hai bài viết về AI: một cái là sự hiểu lầm về Sparkle icon, và một cái là các best practice để onboarding user mới dùng AI. Anh em có câu hỏi gì về Sparkle icon không?
23:58 Thực ra thì bây giờ đa phần những cái app có AI thì đều có những kiểu như mic icon, các thứ tương tự. Nhìn vào là biết ngay là có AI chứ không nhầm lẫn được. Đồng ý. Còn phần onboarding thì anh thấy hơi cấn. Mục đích của việc onboarding là để giúp user bắt đầu với app và có điểm tựa để họ khám phá thêm, chứ không phải cho long-term user dùng. Onboarding này sẽ chỉ dùng cho user mới bắt đầu thôi.
25:10 Em có gửi một cái link để mọi người có thể đọc thêm sau. Bài đó em tóm tắt dựa trên các giao diện mới đang support AI hiện tại. Tháng này có nhiều app chat ra mắt với những feature và UI khá ngầu. Sáng nay, em thấy ChatGPT có thêm tính năng Canvas, mở ra pop-up để scroll artifact bên phía CR. Nếu mọi người hứng thú thì có thể tham khảo thêm. Ok, cảm ơn em. Được rồi, phát biểu tiếp nhé. Ok rồi anh, bye mọi người.
26:42 Dạ, thì tuần này em có được hai bài, thấy cũng ok, không có gì phức tạp lắm. Chủ yếu là những cái tool mới thôi. Bài đầu tiên đó là về thằng Prep. Thì Prep này nó là một cái tool để giúp compile-time evaluation. Nó là một cái tool để enable compile-time evaluation, giúp cho quá trình này xảy ra ngay tại compile-time thay vì tại runtime.
29:11 Thì mọi người hiểu compile-time evaluation là gì không nhỉ? Kiểu như bình thường khi mình viết code, những giá trị mà mình gán cho biến hoặc hàm thì nó sẽ được tính toán tại runtime, nhưng với thằng tool này, nó sẽ giúp chuyển những đoạn tính toán ở runtime thành compile-time. Việc này sẽ giúp boost performance lên một chút, đặc biệt trong các trường hợp cần tính toán nặng. Ví dụ, với những bài toán phức tạp như tính Fibonacci số lớn, nếu làm tại compile-time thì sẽ nhanh hơn nhiều so với tính tại runtime.
29:42 Cách dùng cũng đơn giản thôi. Prep này, mình chỉ cần nhét những đoạn code cần evaluate tại compile-time vào trong hàm prep là được. Như mọi người thấy ở đây, ví dụ như tính toán Fibonacci. Đối với những con số nhỏ thì đơn giản, nhưng khi con số lớn lên thì tính toán sẽ lâu hơn. Nhưng khi dùng prep, những con số lớn sẽ được tính toán nhanh hơn nhiều. Ngoài ra, khi build, mình sẽ cần dùng một cái lệnh như thế này (chỉ vào màn hình), lệnh này là để run cái tool prep luôn tại compile-time.
30:25 Tuy nhiên, có một số giới hạn của thằng tool này. Thứ nhất, nó chỉ hỗ trợ các giá trị mà mình có thể xác định được tại compile-time, và những giá trị đó phải nằm trong cùng scope với hàm prep. Ngoài ra, không thể sử dụng tool này cho các thao tác IO vì nó là compile-time, không hợp lý để xử lý IO operations trong compile-time.
31:15 Zero này nó là một cái runtime library. Nó claim là nó database compatible, xài nó cũng đơn giản thôi. Mọi người cứ import vào rồi xài thôi. Ví dụ như đây là một cái ví dụ mà nó compatible với thằng database relational cơ bản, thì nó claim là nó sẽ free cho. Ok, mọi người cũng ngại import những cái thằng mà xài kiểu SD. Dạ chắc vậy. Mọi người có câu hỏi gì không? Ok, không có thì tiếp tục nhé.
32:18 Dạ đúng rồi, bài này em check là nó nằm khoảng 4 ngày trước đúng không ta? Anh thấy cái Go với lại kia khoảng 4 ngày trước. Dạ đúng rồi, trong tuần đó anh. Dạ, có thêm cái này hôm bữa nữa. Cái bài về lm power Go này mình chưa có điểm qua phải không? Phép có rồi mà anh, nhưng không nhớ rõ nó nằm ở kỳ mấy nữa. Để em search lại cái. Rồi trên đây nó có một số bài mà chắc team mình sẽ quan tâm, không biết nó như thế nào. Cái bài là bài này nè, trong nguyên cái dàn list á, có một cái list được thả up rất là nhiều. Khứa này nó dùng Go mà nó dev web, thì nó ra được khoảng đâu 22 cái note của nó về việc dùng Go để code web.
33:07 Thì bài này không biết em check chưa, nhưng cộng đồng nó up vote cái này rất là nhiều. Dạ chắc là anh. Nó kiểu như là mấy cái nốt mà thông qua mấy cái release version, nó thấy cái nào technote hữu ích thì nó up lên. Em nghĩ nhiều người sẽ nhìn thấy và quan tâm. Ok, giống như là anh thấy mấy cái bạn điểm qua version rất là cũ của Google luôn.
33:49 Dạ, đúng rồi. Sau đó nó check out mấy cái win, mấy cái gì đó hay ho của những cái version đó của Go. Ok, bài tổng hợp này là mới đúng không ta? Dạ đúng rồi, bài tổng hợp này mới. Ông này tự tổng hợp lại theo cái list của ổng thay vì lên awesome Go, ổng tự làm list. Xong rồi bên dưới thì bán khoá học. Ok, chắc là bài này cũng uy tín. Chắc lấy bài này track lại, hôm qua mới lấy cái bài cũ đăng lên lại. Anh thấy cộng đồng đang pick up dần, nếu khéo chắc sẽ track thêm.
34:32 Dạ, đúng rồi. Với lại anh Hiếu có xem cái bài này, vô tình em cũng đọc được. Ảnh bảo là bên Go có một cái repo để mọi người tham khảo, kiểu microservice cũng ok lắm, tên gì đó luôn. Để em search lại cái link rồi gửi cho mọi người nhé.
36:32 Hôm nay em sẽ giới thiệu về một cái dự án em làm cách đây gần hai tháng. Đó là một bài liên kết với system AI. Khi mà cái task nó quá lớn, quá nhiều subtask, mọi người phải chia ra thành từng module riêng lẻ, thì sẽ có một con router ở giữa. Nó sẽ nhận request từ user, rồi phân chia tới từng module con. Bài này sẽ giới thiệu cách mà em evaluate cái system này.
37:10 Có một phương pháp mà team em đang làm là sẽ dùng một simulation con, gọi là simulated user, để tương tác với các module. Sau đó, sẽ có một con evaluator đánh giá thông qua cuộc hội thoại này dựa trên các tiêu chí mà mình tự định nghĩa. Ví dụ như em test thử một simulation cho một công ty hàng không, khách hàng muốn refund lại vé, thì mình tạo simulation cho khách hàng đó. Cuộc hội thoại hoàn toàn giữa các con AI với nhau, có thể thấy là mới vào sẽ có các lời chào hỏi, giới thiệu, request từ khách hàng, và AI sẽ gọi qua các module worker, làm việc với các module khác nhau. Sau đó, nó sẽ trả về kết quả cuối cùng và con evaluator sẽ đánh giá xem cuộc hội thoại này có đạt yêu cầu hay không.
37:56 Ví dụ như em dùng một metric là binary thôi, 0 hoặc 1. 0 là user không được refund, 1 là user được refund. Sau đó, evaluator sẽ đánh giá dựa trên các tiêu chí mà mình đã đặt ra. Em có test thử một bộ sinh thái của Langchain để chạy thử, dùng OpenAI để chạy qua. Khi kết thúc, kết quả sẽ được đưa ra, và mình sẽ đánh giá xem các bước có đúng với mục tiêu hay không.
38:41 Đây là một ví dụ thành công. Simulation chạy qua, module ticket office xử lý và trả kết quả về cho user. Từ đó, mình có thể xem và đánh giá các bước trong quá trình này. Nếu cần, mình có thể optimize lại luồng hoặc workflow. Đây là một phương pháp để mọi người evaluate một chatbot hoặc một agent.
39:33 Mọi người có câu hỏi gì không? Đại loại là mình sẽ dùng một con agent hoặc multi-agent để simulate conversation với một con chatbot. Sau đó, evaluator sẽ đánh giá kết quả của toàn bộ cuộc hội thoại. Ví dụ như trong một test case, mọi người sẽ có những input mong muốn. Simulation user sẽ đưa những input đó vào cuộc hội thoại với chatbot, và khi hoàn tất, evaluator sẽ đánh giá xem kết quả có đạt yêu cầu không.
40:35 Ví dụ là mình dùng ba con agent tổng cộng. Một con simulation user, một con chatbot, và một con evaluator để đánh giá. Langchain hỗ trợ luôn cả việc xây dựng một graph để tổ chức các cuộc hội thoại. Ví dụ user tương tác với chatbot, và khi kết thúc, evaluator sẽ kiểm tra lại toàn bộ quá trình hội thoại. Mọi thứ đều có thể define trong evaluator, ví dụ như check số lượng tool đã sử dụng, hoặc xem có công cụ nào bị gọi hai lần hay không.
42:07 Giống như automation test case đúng không? Đúng rồi, mình define những test case, rồi assign các tag cho từng con agent. Ví dụ test này để pass, test kia để fail, có những tag khác nhau tuỳ vào từng tình huống. Đạt có nói về việc define expected output cuối cùng, và quá trình thì tự generate. Khi chạy qua các tool, nó sẽ kiểm tra xem tool có sử dụng đúng cách hay không, có chạy đúng số lượng tool đã định trước không.
43:25 Mọi thứ đều có thể define trong evaluator ở cuối cùng để kiểm tra. Giả sử mình muốn hard-code một bộ test case thì cũng được. Ý là mình define conversation để book một cái ticket chẳng hạn, rồi kiểm tra xem có đủ step để đến thành công không, có step nào dẫn đến fail không. Tất cả đều có thể định nghĩa sẵn.
44:05 Khi mình hard-code nguyên một luồng như vậy, mình có thể theo dõi từng bước. Nhưng với approach này, mọi thứ đều có thể tự chạy và kiểm tra theo quá trình. Mọi người có thể define những metric để đánh giá conversation, như correctness hay accuracy, để biết agent có hoạt động đúng không. Đây là một cách để chạy test toàn diện cho agent.
45:31 Còn một bài nữa mà em kết hợp chung với bài này. Mọi người thấy con agent sẽ xử lý như thế này, qua nhiều bước khác nhau trong quá trình hội thoại. Cái này lấy từ hai ví dụ collaboration trước, nhưng nó specific cho case của tụi mình. Cả quá trình sẽ được đánh giá qua ba architecture nhỏ kết hợp lại, với một con router đứng giữa. Router sẽ route request tới những con nhỏ hơn dựa vào yêu cầu của user, rồi sẽ trả về kết quả.
46:40 Đó là một cách để xử lý, mọi người có thể nhìn vào đây để thấy cách nó vận hành. Cả quá trình đều có thể được đánh giá qua từng bước. Nếu cần build một bộ test trong app thực tế, thì approach này vẫn có thể áp dụng.
47:50 Ok, tiếp theo Hoàng trả lại diễn đàn cho Tom. Hình như mấy cái bài của Tom đều đã đại khái xong hết rồi, đúng không Tom? Mới form một chút thôi, nhưng tôi phải chạy script để update lại mấy cái link ảnh ấy. Nó có vẻ hơi nhiều ảnh nhỉ. Ok, share tiếp về case study nhé.
49:39 Mọi người vào link Figma này để nhìn cho rõ nhé, xem màn hình thì nó bị bể. Được rồi, trước khi share, mình có cần phải sensor cái gì không ta? Có dính NDA gì không? Hay là bài này bình thường thôi? Không dính vấn đề gì cả, đây là một case study về dự án đầu tiên mà team designer bắt đầu áp dụng AI, chủ yếu hỗ trợ trong quá trình nghiên cứu UX.
50:36 Kafi thì Kafi là công ty hồi xưa. Trước đây nó có một tên khác, nhưng mà trước đây thì nó mờ nhạt trên thị trường. Sau cái năm 2022 thì nó có một cái chuyển đổi về nhân sự nên là nó đổi tên thành Kafi. Từ đó, bắt đầu tái cơ cấu, và sau năm 2024 thì Kafi ghi nhận được một số lợi nhuận cao, kinh doanh vô cùng ấn tượng. Họ đã sử dụng nguồn lợi nhuận này để bắt đầu phát triển và nâng cấp hai ứng dụng là Kafi Trade và Kafi Wealth, với mục tiêu phát triển và mở rộng chiến lược kinh doanh và thị trường. Họ đã tìm đến bên Dwarves Foundation để đầu tư vào việc nghiên cứu người dùng và các công nghệ.
51:30 Về thách thức chính của ứng dụng Kafi hiện tại, đó là trải nghiệm người dùng chưa đáp ứng được nhu cầu của một nhóm người dùng đa dạng. Tưởng tượng như một ứng dụng đầu tư, nhưng khi người dùng tiếp cận thì lại không đáp ứng đúng nhu cầu của họ. Điều này đặt ra một thách thức, từ đó Kafi bắt đầu nghiên cứu về trải nghiệm người dùng để đáp ứng nhiều nhu cầu khác nhau của khách hàng. Vì vậy, nhóm đã đặt ra câu hỏi là: "Chúng ta phải làm gì tiếp theo?" Mục tiêu chính là tạo ra một ứng dụng đáp ứng kỳ vọng và mang lại giá trị thực sự cho các nhà đầu tư.
52:19 Quá trình này không hề dễ dàng bởi vì nhóm không chỉ cải thiện một ứng dụng mà còn mang đến một triết lý, đó là xây dựng một công cụ có thể thay đổi cách mọi người tiếp cận với việc đầu tư. Ở đây, em chia quá trình nghiên cứu để hiểu người dùng thành ba giai đoạn: empathize (đồng cảm và hiểu nhu cầu người dùng), lập kế hoạch và thiết kế. Đầu tiên là empathize, trong giai đoạn này nhóm bắt đầu thực sự hiểu được những gì mà khách hàng mong muốn và kỳ vọng.
53:07 Ba câu hỏi chính mà nhóm muốn trả lời trong giai đoạn đầu của dự án là: Những khó khăn và pain point hiện tại của người dùng là gì? Họ thực sự muốn gì? Và họ cần gì? Sau đó nhóm tiến hành nghiên cứu chuyên sâu để bóc tách những vấn đề này. Trong đó có phương pháp kiểm tra khả năng sử dụng (usability testing). Ở đây, nhóm trực tiếp sử dụng ứng dụng để hiểu sâu và nắm bắt các chi tiết mà phương pháp khác khó phát hiện được, ví dụ như cảm xúc và suy nghĩ của người dùng khi tương tác với ứng dụng.
53:54 Ngoài ra, nhóm cũng điều tra các diễn đàn và cộng đồng như Reddit hoặc Facebook để nắm bắt hành vi và những yếu tố tiềm ẩn trong thị trường chứng khoán mà Kafi chưa kịp nắm bắt. Trong quá trình nghiên cứu, nhóm cũng sử dụng AI để nghiên cứu thị trường và phân tích đối thủ, sử dụng SWOT để hiểu rõ về sản phẩm hiện có trên thị trường, ví dụ như nghiên cứu điểm mạnh và điểm yếu của các sản phẩm đó.
55:29 Sau khi hoàn thành tất cả các nghiên cứu sơ cấp và thu thập dữ liệu, nhóm chuyển sang giai đoạn khái niệm hóa dự án. Giai đoạn này bao gồm việc phân tích thông tin đã thu thập và thực sự hiểu sâu về nó. Tiếp theo là giai đoạn lập kế hoạch dự án. Sau khi thu thập tất cả các dữ liệu sơ cấp từ đối thủ cạnh tranh, AI, và khảo sát, nhóm ưu tiên hình thành các chiến lược cho trải nghiệm người dùng thực tế.
56:18 Nhóm bắt đầu hiểu rõ về mong muốn và nhu cầu của khách hàng. Sau đó, nhóm phân loại thông tin thu thập được và sắp xếp chúng theo thứ tự ưu tiên. Nhóm trình bày các phát hiện này cho team Kafi để cùng hình thành các chiến lược dựa trên dữ liệu thực tế và đồng ý với các vấn đề đã được phát hiện. Tiếp theo là giai đoạn nghiên cứu thứ cấp, một giai đoạn nghiên cứu sâu hơn về chiến lược sản phẩm.
57:08 Có ba giai đoạn chính: xây dựng personas, mapping ưu tiên và pain point. Từ đó, nhóm sẽ hiểu rõ hơn về lộ trình sản phẩm và xác định các tính năng cần có trong phiên bản thứ hai. Sau đó, nhóm sẽ trình bày các insight này cho khách hàng. Bước đầu tiên là xây dựng personas, tức là tạo ra đại diện cho phân khúc khách hàng dựa trên các yếu tố như độ tuổi, kinh nghiệm đầu tư, mục tiêu tài chính và mức độ chấp nhận rủi ro của họ.
57:57 Sau khi xác định được personas, nhóm sẽ tiến hành phân tích sâu hơn về hành vi bằng cách xây dựng một journey map để hiểu rõ hành vi của người dùng. Điều này bao gồm các điểm chính như nghiên cứu cách họ tương tác với các tính năng, tần suất sử dụng, và các yếu tố ảnh hưởng đến quyết định đầu tư của họ. Tiếp theo, nhóm tập trung vào việc xác định nhu cầu ưu tiên của từng đối tượng khách hàng.
58:49 Ví dụ, nhà đầu tư mới cần nhiều hướng dẫn và công cụ học tập hơn, trong khi các nhà giao dịch chuyên nghiệp có thể ưu tiên các công cụ phân tích để nâng cao khả năng thực hiện giao dịch thành công. Cuối cùng, dựa trên kết quả phân tích dữ liệu và triết lý của Kafi – xây dựng ước mơ tài chính – nhóm quyết định tập trung vào hai đối tượng chính: new trader và professional trader (hay còn gọi là newbie trader và day trader).
59:31 Từ đó, nhóm rút ra kết luận quan trọng là cần định hình lại cách tiếp cận giao dịch chứng khoán. Các kết luận bao gồm việc giúp nhà đầu tư mới vượt qua các rào cản kiến thức, đáp ứng nhu cầu về tốc độ và chính xác cho các nhà giao dịch chuyên nghiệp, và giải quyết các vấn đề liên quan đến bảo mật và quản lý rủi ro. Cuộc nghiên cứu này cũng chỉ ra rằng các nhà giao dịch có xu hướng sử dụng ứng dụng di động như một công cụ hỗ trợ, để theo dõi biến động thị trường, cập nhật tin tức nhanh chóng, và kiểm tra số dư tài sản.
01:00:15 Sau khi hoàn thành quá trình nghiên cứu, nhóm và Kafi đã thống nhất được một số giải pháp chính. Ba vấn đề chính mà nhóm xác định được là sự phức tạp đối với nhà đầu tư mới, quy trình onboarding khó khăn, và nhu cầu đa dạng của các nhóm đối tượng khác nhau.
01:01:10 Để giải quyết từng vấn đề này, nhóm phát triển ba giải pháp chính. Các giải pháp này được thiết kế dựa trên những hiểu biết sâu sắc từ nghiên cứu người dùng và phân tích thị trường. Giải pháp đầu tiên là giúp đỡ các nhà đầu tư mới, vì đầu tư là một lĩnh vực phức tạp, đặc biệt là đối với người mới bắt đầu. Cafi được thiết kế trở thành một người hướng dẫn đáng tin cậy, sử dụng công cụ hỗ trợ Contextual Help (trợ giúp ngữ cảnh).
01:01:49 Ví dụ, trong một biểu đồ giá phức tạp, sẽ có một biểu tượng nhỏ xuất hiện ở góc màn hình. Khi người dùng chạm vào biểu tượng này, một trợ giúp tương tác sẽ xuất hiện, giải thích các khái niệm như khối lượng giao dịch là gì, giá đóng cửa là gì. Nó cũng cung cấp các mẹo để đọc biểu đồ, chẳng hạn như biểu đồ nến.
01:02:36 Phép tìm hiểu sâu về các kỹ thuật và các chỉ số kỹ thuật. Tất cả đều sẽ hiển thị trong một màn hình. Cuối cùng là việc cải thiện giao diện người dùng bằng cách áp dụng nguyên tắc "Less is More" bằng cách tạo ra một giao diện tối giản, hiện đại và khoa học. Mỗi yếu tố trên màn hình đều có một mục đích cụ thể để giúp người dùng thực hiện giao dịch nhanh chóng và hiệu quả, làm cho các nhà giao dịch mới không cảm thấy choáng ngợp trước khối lượng thông tin lớn.
01:03:21 Với giải pháp thứ hai, nhóm tập trung vào việc cải thiện từng bước trong quy trình onboarding, giúp người dùng dễ dàng hơn. Trước đây, nhóm nhận thấy ứng dụng Cafi gặp khó khăn với tỷ lệ người dùng bỏ cuộc trong quá trình đăng ký. Nguyên nhân chính là do quy trình đăng ký và xác minh danh tính điện tử (eKYC) phức tạp, khiến người dùng nản lòng vì phải cung cấp quá nhiều thông tin. Để khắc phục vấn đề này, nhóm đã tối ưu hóa quy trình onboarding bằng cách chia nhỏ quá trình đăng ký thành các bước ngắn gọn, chỉ yêu cầu đủ thông tin ở mỗi bước.
01:04:06 Ngoài ra, nhóm còn cho phép người dùng khám phá ứng dụng trước khi hoàn tất đăng ký để tạo cảm giác thoải mái, không bị áp lực phải cung cấp quá nhiều thông tin ngay lập tức. Khi người dùng đã tạo tài khoản xong, nhóm cũng hướng dẫn từng bước về xác minh, theo dõi danh mục và đặt lệnh một cách trực quan, tích hợp thanh tiến độ để giúp người dùng dễ dàng theo dõi quá trình. Cách tiếp cận này không chỉ đơn giản hóa quy trình mà còn tạo ra trải nghiệm phù hợp với nhu cầu cá nhân của từng đối tượng khách hàng.
01:04:48 Giải pháp thứ ba là thiết kế công cụ tùy theo từng đối tượng người dùng. Các nhà đầu tư có nhu cầu sử dụng công cụ hỗ trợ khác nhau tùy theo mức độ kinh nghiệm. Khi nền tảng web có thể linh hoạt trong việc bố trí các tính năng, thì thiết kế giao diện trên điện thoại lại bị hạn chế hơn. Vấn đề đặt ra là làm sao để cung cấp đủ công cụ cho các nhà đầu tư chuyên nghiệp mà không làm khó khăn cho người dùng mới. Giải pháp của nhóm là áp dụng hệ thống phân loại người dùng. Sau khi hoàn tất đăng ký, người dùng sẽ được chia thành các nhóm như mới bắt đầu, trung cấp và chuyên nghiệp. Mỗi nhóm sẽ nhận được trải nghiệm phù hợp với mức độ hiểu biết và mục tiêu đầu tư của họ.
01:05:24 Ví dụ, người mới có thể tiếp cận các bài học cơ bản, trong khi nhà đầu tư chuyên nghiệp sẽ được cung cấp các công cụ phân tích chuyên sâu. Cách tiếp cận này không chỉ cải thiện trải nghiệm người dùng mà còn thúc đẩy sự phát triển của nền tảng Kafi bằng cách cung cấp nội dung và công cụ phù hợp với từng giai đoạn phát triển của người dùng. Kafi sẽ trở thành một môi trường học tập và đầu tư năng động, phục vụ cho cả người mới và những nhà đầu tư dày dặn kinh nghiệm.
01:06:00 Kết quả sau case study của Kafi cho thấy rằng, có rất nhiều cách để giải quyết những vấn đề mà các ứng dụng chứng khoán đang đối mặt. Tuy nhiên, quan trọng nhất vẫn là hiểu rõ nhu cầu của khách hàng. Nếu một công ty đang phục vụ nhiều nhóm đối tượng người dùng khác nhau, thì việc thu thập và phân tích nhu cầu đa dạng của họ là rất quan trọng. Sau đó, cần sắp xếp thứ tự ưu tiên để đáp ứng nhu cầu phù hợp với từng đối tượng.
01:06:43 Ở đây có một số phương pháp hiệu quả để khám phá và hiểu nhu cầu khách hàng, bao gồm khảo sát bằng câu hỏi đóng mở để thu thập thông tin, xây dựng personas để tạo các đại diện người dùng, xác định mục tiêu, hành vi và khó khăn của họ. Phân tích đối thủ cạnh tranh cũng là một phương pháp, sử dụng các công cụ phân tích để đánh giá sản phẩm của đối thủ, từ đó nhìn ra điểm mạnh và yếu của họ.
01:07:26 Ngoài ra, AI có thể được kết hợp vào quá trình nghiên cứu người dùng, giúp xử lý một khối lượng thông tin lớn từ các đối thủ cạnh tranh hoặc từ dữ liệu thu thập được trong quá trình khảo sát và phỏng vấn người dùng. AI có thể phân tích tất cả các dữ liệu đó và tạo ra những personas cho từng nhóm người dùng. Từ đó, chúng ta có thể tìm ra các giải pháp phù hợp với nhu cầu của từng tập khách hàng.
01:08:08 Em xin hết. Mọi người có câu hỏi gì không? Thật ra mấy cái này cũng không rút gọn được vì áp dụng hết luôn. Không có rút gọn được. Đúng rồi, cực lắm. Ai không có giọng rung rung sợ sợ vậy đâu. Personal của em là gì, của một designer là gì?
01:09:52 Personal hả? Thì đó, giống như em nói, từ khi có AI thì việc nghiên cứu user trở nên nhẹ nhàng hơn. Không còn phải đi khảo sát, đi hỏi, đi phỏng vấn quá nhiều user. Có nhiều người bên ngoài mỗi ngày phải gọi điện phỏng vấn mười mấy người. Chị có xài cafe để làm research không? Em có xài cafe để làm research là sao? Mình phải bớt lại chị, phỏng vấn personas của bên mình, thì em chat với cả ChatGPT.
01:11:08 Ừ, personas thật ra khi hỏi AI về personas nó sẽ cho anh một nùi luôn. Rất nhiều thứ. Vấn đề chính là AI không giúp lên kế hoạch ưu tiên các vấn đề, mà chỉ giúp mình tìm ra những personas ban đầu thôi. Từ đó mình phải dựa vào kinh nghiệm và những cuộc phỏng vấn người dùng thực tế, rồi mới phân tích và nhóm lại các personas cho đúng. Nếu không thì AI sẽ đưa ra quá nhiều personas.
01:11:56 Kafi chỉ là tham khảo mấy cái của đối thủ cạnh tranh thôi. Ok, anh không có câu hỏi gì nữa. Không biết có thu được giọng anh chưa. Nếu có phần nào thiếu thì gửi slide để xem sau.
01:13:25 Theo kịch bản là Tom sẽ có một cái bài cho anh em tên là mixture of agents, tức là cụm mấy cái agents nó ngồi lại với nhau xong rồi nó chạy multi-agent để ra kết quả, mà tạm thời bài đó có vẻ dễ, mọi người sẽ chưa đến lúc để nghe bài đó đâu. Anh đang nghĩ vậy nên skip bài đó nhé. Giờ có một thông báo quan trọng hơn về chuyện đi chơi và bài test.
01:14:09 Bài test sẽ có nội dung như sau: mấy anh em xem chuẩn bị trước là vừa. Thứ nhất là anh em sẽ viết hai bài luận. Tự viết, nào viết dở là sẽ bị chém ha. Hai bài luận, một bài luận đầu tiên là về văn hóa. Anh sẽ pick ra một trong bốn cụm văn hóa mà team mình đang theo đuổi, chắc xoay quanh hybrid working xong rồi các kiểu thôi nha. Mấy anh em sẽ viết một bài về cái đó. Câu hỏi thì anh sẽ đưa sau, nhưng giờ phổ biến trước, chắc cuối tuần sẽ release một cái về văn hóa, để mọi người đặt tay vào làm.
01:14:52 Lý do để làm bài này là vì giai đoạn hiện tại, anh nghĩ mọi người cần cố gắng, phải tự set motivation cho mình để thích nghi với giai đoạn mới. Giai đoạn mới là giai đoạn của thị trường. Giai đoạn của công ty mình thì bình thường, không có gì hết, nhưng thị trường nó thay đổi, nên để phù hợp thì mọi người cần có lý do để refresh lại động lực của mình trong ngành này. Được ha. Sẽ có một bài luận cho mấy anh em về văn hóa.
01:15:36 Bài thứ hai, câu hỏi sẽ xoay quanh chuyện này. Anh chưa chốt câu hỏi chính xác là gì, nhưng nó sẽ nằm trong chuyện mà ứng dụng của lĩnh vực mà mấy anh em đang làm, nó đang được ứng dụng tới đâu rồi. Có thể gom lại thành một bài giống như state of the app của lĩnh vực mấy anh em đang làm, ở bên ngoài người ta đang triển khai như thế nào, thì đó là bài thứ hai.
01:16:18 Sample cho bài đó có thể nhìn như sau: không biết đây có không, nhưng sample thôi. Bên dev thì chắc dễ, nhưng bên kiểu làm sale, làm design, làm tester, làm PM, tất cả các roles liên quan. Mà Tom đang tính là nó sẽ cut hết mấy cái đó thành agents hết. Thật ra là mình sẽ biết nó sẽ cover được đâu đó 70-80% công việc, nhưng vẫn cần người đứng đằng sau để lái agents đó, thành ra là cũng sẽ tùy ý.
01:17:04 Ví dụ như bài này phải không? Để coi lại nha. Đúng rồi, thử coi, phải không? Có một số bài anh đang coi cách sử dụng AI như thế này. Có một số bài như vậy. Bên vật dev nó cũng cover một số, cũng không có nhiều lắm, nhưng đại ý là vậy nhé. Bài số hai sẽ là với mỗi role của mấy anh em trong công ty, mấy anh em đang cầm một cái role nhất định, thì cái role của mình, hiện tại là làm sao, chuyện sử dụng AI người ta đang xài như thế nào, đó là bài số hai nhé. Được ha.
01:17:42 Bài số ba sẽ liên quan tới chuyện thực hành. Đề thì chưa biết, tại vì nếu đưa chủ đề linh tinh quá thì mấy anh em lên ngồi chat với GPT nó cũng không có tác dụng gì lắm. Nên sẽ liên quan đến chuyện chạy thực tế, làm nghề, build software thôi, nên chuyện thực tế áp dụng cho mình sao để hiệu quả thì chắc anh sẽ nghĩ ra một cái đề. Có thể là một đề để submit, rồi mọi người dùng AI để assessment. Anh không có cổ súy hoàn toàn cho chuyện AI cover mọi thứ nhá. Tại vì thấy cách mọi người sử dụng rồi. Ví dụ như anh dùng mấy cái tool kia để ra cái script, thì nó cũng rất chung chung, không có thực tiễn và không có bài học rút ra.
01:18:16Comment nhanh vậy thôi để mọi người thấy rằng chuyện sử dụng máy móc, làm rập khuôn thì nó rất là gà. Gà, mà biết dùng chữ gì cho đúng nữa? Nhưng nhìn nó chán, chán đời lắm. Rồi ha, bài số ba là ứng dụng nhé. Là chuyện của mình sau khi tìm hiểu rồi, thì bài thứ ba sẽ là ứng dụng.
01:18:58 Tiếp, hiện tại mọi người sẽ có lịch đi chơi, nếu mà đúng thì khoảng đầu tháng 12 mình sẽ có khoảng hai tháng để chuẩn bị. Mình sẽ cần chốt trước đó một tháng là ít nhất, nên mọi người có một tháng để làm thôi. Được ha. Nên những thứ mọi người cần submit là đây. Đây là gần như điều kiện cần cho chuyện mấy bạn đi chơi, và nó cũng là điều kiện đủ cho performance review cuối năm vào tháng 12 và tháng 1.
01:19:39 Hiện tại, anh đang expect những hoạt động của team mình sẽ được assess với AI ở mức độ mà mình kiểm soát được, đảm bảo cái đầu ra vẫn là cái mà mình mong muốn như trước giờ, chứ không phải là "tại vì em dùng cái này, nên giờ kết quả nó ra như vậy, là tại anh bảo em dùng". Được ha? Như đương dao tự đâm chân mình rồi đổ lỗi cho người khác, thì không được. Ok, đó là điều kiện cần để đi chơi, và điều kiện đủ để làm bài review.
01:20:14 Điều này quan trọng, vì lần này, bài review vào tháng 12, nếu bạn nào đi một vòng mà không làm được, thì khả năng cao là junior với fresher sẽ bay màu hết. Hôm qua có xem một cái bài rất buồn cười. Nó không được tuyển vào đâu hết, nên nó làm một cái game multiplayer, firm crash, sử dụng Go và TP. Nó đăng lên và sử dụng toán để làm animation. Comment rất là vui.
01:21:04 Review đợt tháng 12 sẽ là cái đó nhé. Đó là thông báo cuối cùng để anh em nắm. Message sẽ được release vào cuối tuần để mọi người chuẩn bị deadline để nộp, và chấm điểm cho Huy vào trước tuần thứ tư của tháng 11. Chắc tuần thứ tư của tháng 10 là mấy bạn còn ba tuần đó, đúng không? Đúng rồi, ha. Đây là thông báo. Mấy anh em không tham gia con thì cũng không quan trọng lắm.
01:21:55 Tiếp nữa, đó là cái list mà Tom đang làm một số phần ở đây. Anh chưa check hết, nhưng anh bắt đầu check từ từ xem là assess những gì. List pilot sao chậm quá nè. List khác, list khác, khác list bữa trước nói. Review nhanh qua cho mấy anh em thấy một chút. List này ha, Tôm đang làm. Anh thấy có một số bạn tham gia nè. Đây là tín hiệu rất tốt, cho thấy mọi người đã bắt đầu aware được sự thay đổi concept trong chuyện làm software.
01:22:42 Giờ nó xuất hiện thêm server, rồi cách làm data manipulation khác nhau, data collection khác nhau. Mọi thứ đều khác hết, nên là sẽ khác. Những phần reward đã gửi rồi xong. Còn phần Tom đang làm, để review. Đợi anh review, anh review của mấy bạn. Rồi Tom sẽ review tiếp những phần khác. Một số cái như Hiếu Vũ nữa. Hiếu Vũ có đây không? Nhưng mà chưa thấy update gì hết. Bắt đầu xin việc kiểu này là toang rồi.
01:23:15 Các bạn ơi, phải chủ động đi tìm đề tài để làm rồi ha. Đây là một cái list. Còn cái list khác đợi Tom finish, thì mình sẽ đi qua một cái list khác. Cái chủ đề multi-agent, khi nào mấy chủ đề kia thông qua hết? Knowledge sharing, grouping, specific projection.
01:24:07 Mấy cái MapReduce, team đang làm nè, collect data, build gom data lại rồi chạy cho nó. Thành đang làm con này nè, bữa trước đang kiến trúc, đang hơi quay. Tiếp theo là những chủ đề khác liên quan đến hệ thống cũ. Trước chỉ có server thôi, mà giờ có thêm agent, nên phải đưa dữ liệu qua cho tụi nó. Cấu trúc kiến trúc sẽ khác đi một tí. Khi nhận một cái đề bài, cấu trúc agent ra sao vẫn là chủ đề chưa bao giờ thảo luận kỹ với nhau.
01:25:12 Một số bạn đang setup dify, thấy có liên quan, nhưng mà nhiều câu hỏi về kiến trúc, về cấu trúc một hệ thống không chỉ có server mà có nhiều agent đứng dọc trong đó. Giống như bài Hoàng làm hồi nãy. Đó là một sample dễ, nhưng bài toán cụ thể thì cấu trúc server sẽ như thế nào? Đó là chủ đề thực tế thôi, phải làm. Nhắc lại vậy thôi, hiện tại nếu không quan tâm thì phần Tom đang viết chẳng có ý nghĩa gì lắm. Chúng ta đang bị tụt lại rất xa trong kiến thức này.
01:25:39 Anh nghĩ cụm kiến thức này sẽ thành foundation cho software engineer. Không phải là kiến thức blockchain, không cần ai cũng phải biết. Nhưng phần này phải biết. Quan trọng là phải biết cách chia bài toán ra sao, để có logic chart trong đầu. Nếu không chia được thì đang gà. Nhẹ nhàng vậy ha.
01:26:17 Đó là toàn bộ message. Muốn tranh thủ cho anh em biết định hướng và expectation đang di chuyển theo hướng đó nha. Cuối tuần này sẽ có đề bài để viết hai bài luận, một bài report và một bài case study nhé. Nếu không còn gì thêm thì chắc là gg.
01:26:53 Tạm biệt anh em, hẹn gặp lại. Hy vọng hôm nay mấy chủ đề recap lại vẫn có giá trị. Sau khi có kiến thức đầy đủ hơn thì sẽ tiếp tục chủ đề hệ thống mới. Còn hiện tại, tất cả hệ thống mọi người đang build vẫn còn trong cái group cũ. Nghĩa là cũ với bên ngoài, chưa đến đó. Nhưng đi trước biết trước thì tốt hơn ha. Rồi ok, vậy ha. Mọi người xem thử còn câu hỏi gì không?
01:27:44 Chắc không có gì thêm, kết thúc nhé. Đúng rồi, cái này phải chat với team mình. Hôm qua thằng Đạt nó một cái clip lên này. Mình cảm thấy mình đi sau xã hội rất nhiều luôn. Đạt đâu nhỉ? Nó là clip của mấy anh Việt Nam ngồi automate với cái gì đó. Tiêu rồi. Biết kênh nào không?
01:28:42 Rồi, chắc vậy. Kênh đó random nhỉ? Hiện tại mọi người còn upset về việc học sâu như cũ. Học kiến trúc này kiến trúc nọ. Nhưng automate ở mức độ này thì phải ứng dụng nhiều hơn. Tất cả các app doanh nghiệp hay app bình thường sẽ nằm trong scope như vậy. Nếu build up dễ thì nó cover hết các trường hợp và làm rất nhanh. Nếu build up khó thì mấy anh em còn chưa biết mấy cái dễ nữa thì khó.
01:29:22 Hy vọng mỗi buổi thứ sáu mình học thêm được một cái gì mới. Hẹn gặp mọi người ở OGIF tuần sau.
English Transcript
00:00 Today we have a few topics on Go commentary, and there will be a product design commentary from Nam. After that, there will be some sections related to evaluating chatbots and technical details on how to build a chatbot by Hoang and Tom. They will probably share a bit about microservices architecture. If we have time, there will be a case study on a crypto finance project by Anna.
08:47 Nam Bui is up, but I haven’t seen his work completed yet... Okay, share your screen when you're ready.
10:31 Can everyone see the screen? Great, let's continue from last week's product design presentation. This week, I will discuss two topics, starting with the Sparkle icon. The Sparkle icon is probably quite familiar to everyone. If you’ve seen this icon before, press 1 for me. This icon is used across multiple apps, and today I’ll introduce a few of those apps.
11:30 First is the Plane Finder app, which uses this icon to show new blog posts. The second app is Ulta, an e-commerce app specializing in clothing and cosmetics. It uses the Sparkle icon for the Discover feature. You’re probably more familiar with the third app, Google Meet, which uses this icon for removing the background and adding a new one.
12:14 So we have three apps using the Sparkle icon, and there are more apps utilizing it. The Sparkle icon isn’t just for one specific feature; it’s becoming quite common. As AI technology emerged, it started incorporating this icon heavily. For example, Figma uses the icon for the AI generator. Other apps, like Miro (for drawing diagrams or wireframes), also use it.
12:59 Another example is Dovetail, which uses the icon to generate meeting summaries. Most AI apps are now adopting this icon. Finally, the Nylas app has integrated the Sparkle icon as its primary interface symbol. This has made users associate the Sparkle icon with AI features, making it a symbol for AI.
13:45 Before showing AI interfaces, I shared some examples of how this icon is used in other apps for various features, demonstrating that the Sparkle icon isn’t limited to just one function but can support multiple ones. To use the icon effectively, I think we should display a tooltip when hovering over it to explain the feature, or show the feature name underneath the icon. Generally, using the Sparkle icon or other generic icons requires tooltips or feature names to avoid user confusion.
14:31 Now, I’ll move on to the second topic, which discusses onboarding new users for AI. I’ll compare different apps and share best practices for onboarding new users who are just logging in or exploring a new AI tool.
15:26 Here we have a famous app from China called SparekDesk. When users first enter the app, they are presented with a list of questions and tutorials to help them explore the app. On the other hand, ChatGPT doesn’t need such a list, as users can immediately start by typing a question to test its capabilities.
16:10 Instead of providing a list of guiding questions, users often begin with ChatGPT by asking something like “Can you...?” to test what it can do. This makes onboarding with ChatGPT more effective than going through lengthy documentation.
17:09 Another example is the App Store, where users can see categories like Productivity to display app features. On the left side, it shows Productivity, while on the right side, it displays search results and the app’s key features. This makes it easier for users to understand the app before downloading it.
18:02 I think each character creates a different set of questions, which can confuse users as they have to decide which one to choose. Meanwhile, this software offers concise tooltips for users without lengthy onboarding steps. The key takeaway here is that we should eliminate unnecessary steps for users instead of overwhelming them with too many.
18:58 For example, the app on the left gives users very specific, detailed questions, while the one on the right offers general questions without relating to any specific situation. In my opinion, general questions are more effective because overly specific questions often don’t match users’ actual needs. Thus, I think detailed questions are redundant in the onboarding process. In contrast, ChatGPT’s general questions have a higher chance of aligning with users’ expectations.
19:44 From these four examples, I conclude: First, we should limit giving users too many detailed questions and instead let them ask directly what they want. Second, we should clearly define the scope of features right from the start, to set user expectations. Otherwise, they might get frustrated and delete the app if it doesn’t meet their needs. Third, we need to remove unnecessary onboarding steps to optimize user time. Lastly, we should present general questions rather than overly specific ones.
20:33 That’s it for me. If you have any questions, feel free to leave comments. But I think the comparison here raises a point: Do these apps target the same task? Because in some cases, specific questions might still be useful depending on the situation. It’s not always ideal to present random questions, as ChatGPT is more of a general-purpose chat tool, whereas other chat interfaces are more specific to certain tasks.
21:26 But what I was talking about here is also a generic chat tool like ChatGPT, not for any specific task. Yes, that’s why I compared two generic chat tools side by side.
22:09 Yes, exactly as you said. A specific app might need more specific questions, but in this case, I’m only comparing two general-purpose chat tools.
23:07 Got it. Any more questions? Feel free to ask. Now let's move to the next topic. This time we have two articles about AI: one about the misunderstanding of the Sparkle icon and the other about best practices for onboarding new AI users. Does anyone have questions about the Sparkle icon?
23:58 Actually, now most AI apps have mic-like icons and other symbols that make it easy to recognize AI features. Agreed. As for onboarding, I feel like it’s a bit tricky. The goal of onboarding is to give users a starting point to explore the app, not something for long-term use. This type of onboarding is specifically for new users only.
25:10 I’ve sent a link for further reading. This article summarizes new AI-supported interfaces. Recently, there have been many cool new chat apps with great features and UI. This morning, I noticed ChatGPT added a Canvas feature, with a pop-up to scroll through artifacts from CR. If you’re interested, feel free to check it out. Okay, thanks. Alright, let’s continue. Ok, I’m done. Bye, everyone.
26:42 This week, I’ve got two articles to share, nothing too complicated. The first one is about Prep, which is a tool for compile-time evaluation. It enables compile-time evaluation, allowing the process to happen during compile-time instead of runtime.
29:11 So, does everyone know what compile-time evaluation is? Normally, the values we assign to variables or functions are evaluated at runtime, but this tool helps convert those calculations to compile-time. This boosts performance, especially for computationally heavy tasks. For example, calculating large Fibonacci numbers at compile-time is much faster than doing it at runtime.
29:42 It’s simple to use. You just place the code that needs compile-time evaluation inside the prep function. As you can see here (pointing to the screen), Fibonacci calculations for small numbers are straightforward, but as the numbers grow, it gets slower. By using prep, larger numbers are calculated much faster. When building the code, you need to use a command like this to execute the prep tool during compile-time.
30:25 However, there are some limitations. First, it only supports values that can be determined at compile-time, and those values must be in the same scope as the prep function. Additionally, you cannot use it for IO operations because they don’t make sense at compile-time.
31:15 Zero is a runtime library. It claims to be database compatible. It’s also simple to use. You just import it and start using it, like in this example here, which shows compatibility with a basic relational database. It claims to be free. Ok, any questions? If not, let’s move on.
32:18 Right, this article I checked was posted about four days ago, correct? I saw that Go thing was also from about four days ago. Yes, that’s right, during that week. And I also have something else from the other day. The article on lm power Go, did we go over that yet? I’m not sure, but I think we did. Let me search for it. Anyway, there are some articles here that I think the team will be interested in. This one here, for example, got a lot of upvotes. The guy used Go to develop a web app, and it produced around 22 notes on how to use Go for web development.
33:07 I’m not sure if you’ve checked it, but the community has upvoted this a lot. Yes, I think I did. It’s like these notes came from various release versions. It highlights useful technical notes, which is why it’s getting attention. Ok, it’s like they pointed out old versions from Google, right?
33:49 Yes, exactly. Then they check out the wins and cool features of those older Go versions. Ok, is this summary new? Yes, it’s a new one. Instead of relying on Awesome Go, this guy made his own list. Underneath, there’s a link to his paid course. Ok, seems legit. We’ll track this article again. I picked up an older article yesterday, reposted it, and saw the community is slowly picking up on it. If we’re smart about it, we’ll track more.
34:32 Yes, and I read the article Hiếu pointed out too. He mentioned a Go repo where people can find microservice examples, and it looks pretty good. I’ll search for the link and send it to everyone.
36:32 Today I’ll introduce a project I worked on about two months ago. It’s a system AI project. When the task becomes too large with too many subtasks, you need to break it into individual modules with a router in the middle. This router receives user requests and forwards them to the relevant submodules. Today’s article will explain how I evaluated this system.
37:10 One method we used was a simulated user to interact with the modules. Then, an evaluator would assess the conversation based on criteria we defined. For example, I simulated a scenario with an airline customer wanting a refund for their ticket. The entire conversation happens between AI agents, and you can see from the chat that it starts with greetings and introductions, followed by the refund request. The AI then calls different modules to handle each part of the process. After the final response, the evaluator checks whether the process met the refund criteria.
37:56 In this case, I used a binary metric, 0 for no refund, 1 for successful refund. Then, the evaluator reasons through the conversation and provides the result. I used Langchain’s ecosystem to test this. Everything worked smoothly with OpenAI. The evaluator looks at whether the necessary steps were taken to meet the goal.
38:41 Here’s an example of a successful simulation. The ticket office module processed the request and returned the result to the user. This way, we can assess and optimize the workflow if needed. It’s a method for evaluating chatbot agents.
39:33 Any questions? Basically, you simulate a user-agent conversation, and the evaluator assesses the final result. For instance, in a test case, you input what you want the simulated user to say. Then, it interacts with the chatbot, and the evaluator reviews the result to see if it meets the expected outcome.
40:35 For example, we’re using three agents here: one simulated user, one chatbot, and one evaluator. Langchain supports building a graph to organize the conversations. For instance, the user interacts with the chatbot, and at the end, the evaluator checks the conversation. The evaluator can define things like checking the number of tools used, ensuring no tool was called twice, etc.
42:07 It’s like an automation test case, right? Exactly. You define the test cases and assign tags to each agent. Some tests are set to pass, others to fail, depending on the situation. Last time Đạt talked about defining the expected output, but the workflow is generated automatically. This way, when a tool is used, it checks whether the tool is used correctly and how many times the tool was called.
43:25 Everything can be defined in the final evaluator to check. Suppose we want to hard-code a test case, we can do that. Meaning we can define a conversation, like booking a ticket, and check if all the steps for success are there or if any steps lead to failure. Everything can be predefined.
44:05 When we hard-code a full flow like that, we can track each step. But with this approach, everything can run automatically and check as part of the process. You can define metrics to evaluate the conversation, such as correctness or accuracy, to determine if the agent is functioning properly. This is a way to comprehensively test the agent.
45:31 There’s another part I combined with this one. You can see how the agent handles everything, going through different stages of the conversation. This example was taken from two previous collaboration samples, but it's specific to our case. The whole process is evaluated through three small architectures combined, with a router in the middle. The router routes requests to smaller modules based on the user’s request and returns results.
46:40 That’s one way to handle it, and you can see how it operates. The entire process can be evaluated step by step. If you need to build a test in a real app, this approach can still be applied.
47:50 Okay, next, Hoang is handing it back to Tom. Looks like Tom’s topics are almost done, right Tom? I just need to run a script to update some image links. There seem to be a lot of images. Okay, continue sharing about the case study.
49:39 Please check the Figma link to get a clearer view because the screen sometimes gets distorted. Before sharing, do we need to sensor anything? Is there any NDA involved? Or is this just a normal case study? There’s no issue here; this is the first project where the design team applied AI, mainly to support UX research.
50:36 Kafi is a company from before, which used to have a different name. It was obscure in the market for a while, but after 2022, there was a personnel restructuring, so they renamed it Kafi. They began re-structuring, and after 2024, Kafi reported impressive profits. They used these profits to start developing and upgrading two applications: Kafi Trade and Kafi Wealth, with the goal of expanding their business strategy and market. They came to Dwarves Foundation to invest in user research and technology.
51:30 The main challenge for Kafi’s current app is that the user experience doesn’t meet the needs of a diverse group of users. Imagine an investment app that doesn’t align with user needs when they first approach it. This challenge led Kafi to research user experience to meet the varying needs of their customers. So, the team posed the question, “What do we do next?” The main goal was to create an app that met expectations and provided real value to investors.
52:19 This process wasn’t easy because the team wasn’t just improving an app, they wanted to create a philosophy, building a tool that could change how people approach investing. I’ve broken down the user research process into three phases: empathize (understanding user needs), planning, and design. First is empathize. In this phase, the team began to really understand what customers wanted and expected.
53:07 The three main questions the team wanted to answer at the start of the project were: What are the current pain points and difficulties? What do users really want? And what do they need? The team then conducted in-depth research to dissect these issues. This included usability testing, where the team directly used the app to gain deep insights and capture details that other methods might miss, such as the emotions and thoughts of users when interacting with the app.
53:54 Additionally, the team investigated forums and communities like Reddit and Facebook to understand user behavior and hidden factors in the stock market that Kafi hadn’t yet grasped. During the research, the team also used AI to study the market and analyze competitors, using SWOT analysis to understand the current products on the market, including their strengths and weaknesses.
55:29 After completing all primary research and data collection, the team moved to the concept development phase, where they analyzed the collected information to gain deep insights. Next was the project planning phase. After gathering all primary data from competitors, AI, and surveys, the team prioritized forming strategies for the real user experience.
56:18 The team first needed to understand what users wanted and needed. Then they classified the collected information and sorted it by priority. The findings were presented to the Kafi team to help them form strategies based on real data and agree on the identified issues. The next phase was secondary research, a more in-depth study of product strategy.
57:08 There are three main phases: building personas, prioritizing user journeys, and addressing pain points. From this, the team better understood the product roadmap and identified features for the second version of the product. They then presented these insights to the client. The first step was building personas, representing customer segments based on factors such as age, investment experience, financial goals, and risk tolerance.
57:57 After identifying the personas, the team analyzed user behavior more deeply by mapping out a user journey to understand their actions. This included key points like how they interact with features, the frequency of use, and factors influencing their investment decisions. Next, the team focused on identifying the prioritized needs of each customer segment.
58:49 For example, new investors need more guidance and learning tools, while professional traders might prioritize analytical tools to enhance their trading success. Finally, based on data analysis and Kafi’s philosophy of building financial dreams, the team decided to focus on two main user groups: new traders and professional traders, also known as newbie traders and day traders.
59:31 The team drew an important conclusion: we need to reshape how users approach stock trading. These conclusions include helping new investors overcome knowledge barriers, addressing the need for speed and accuracy for professional traders, and solving security and risk management issues. The research also showed that traders tend to use mobile apps as a support tool to track market fluctuations, quickly update news, and check asset balances.
01:00:15 After completing the research process, the team and Kafi agreed on several key solutions. The three main issues identified were the complexity for new investors, the difficult onboarding process, and the diverse needs of different user groups.
01:01:10 To address these issues, the team developed three key solutions. These solutions were designed based on deep insights from user research and market analysis. The first solution was to help new investors, as investing is a complex field, especially for beginners. Kafi was designed to become a reliable guide, using a tool called Contextual Help.
01:01:49 For example, in a complex price chart, a small icon will appear in the corner of the screen. When the user taps on it, interactive help will pop up to explain concepts like what trading volume or closing price means. It also provides tips on reading charts, such as candlestick charts.
01:02:36 This allows users to dive deeper into techniques and technical indicators, all within a single screen. Finally, to improve the user interface, the team applied the principle of "Less is More" by creating a modern, minimalist, and functional interface. Every element on the screen has a specific purpose, helping users trade quickly and efficiently, ensuring new traders don’t feel overwhelmed by the large amount of information.
01:03:21 The second solution focused on simplifying the onboarding process, making it easier for users. Previously, the team found that Kafi’s app had a high dropout rate during registration, mainly because the electronic identity verification (eKYC) process was too complex, requiring users to provide too much information. To fix this, the team optimized the onboarding process by breaking it down into smaller steps, only requiring essential information at each step.
01:04:06 Additionally, users were allowed to explore the app before completing registration, helping them feel more comfortable without the pressure of providing too much information upfront. After users created an account, they were guided through steps like verification, tracking portfolios, and placing orders with an integrated progress bar to help them follow the process. This approach not only simplified the process but also created a personalized experience for each customer segment.
01:04:48 The third solution was designing tools tailored to each user group. Investors have different tool needs depending on their experience level. While the web platform allows flexible feature placement, the mobile interface is more limited. The challenge was providing enough tools for professional traders without making it difficult for new users. The team’s solution was to apply a user segmentation system. After completing registration, users were categorized into groups like beginners, intermediate, and professionals. Each group received an experience tailored to their level of knowledge and investment goals.
01:05:24 For example, beginners could access basic learning modules, while professional traders would be provided with in-depth analytical tools. This approach not only improved the user experience but also promoted the growth of the Kafi platform by providing relevant content and tools at different stages. Kafi could create a dynamic learning and investment environment, serving both newcomers and experienced investors.
01:06:00 The results after Kafi’s case study showed that there are many ways to address the issues that stock trading apps face. However, the most important thing is understanding the customers’ needs. If a company serves multiple user segments, it’s crucial to gather and analyze their diverse needs. After that, priorities need to be set to meet the needs of each group.
01:06:43 Some effective methods for discovering and understanding user needs include surveys with closed and open-ended questions to collect information, building personas to represent users, identifying their goals, behaviors, and pain points, and competitor analysis using tools to assess their products and identify strengths and weaknesses.
01:07:26 Additionally, AI can be integrated into the user research process, helping process large amounts of data from competitors or from survey and interview data. AI can analyze all that data and create personas for each user group. From there, we can find solutions that match the needs of each customer segment.
01:08:08 That’s all from me. Any questions? Honestly, these things can't really be shortened, as we applied everything. There’s no way to summarize it further. Exactly, it’s a lot. Nobody’s voice is shaking with nerves here.
01:09:52 What’s your personal take, as a designer, on AI? Well, as I said, since AI came along, user research has become lighter. No more need to go out and survey or interview too many users. Many people out there still have to call and interview a dozen users every day. Have you used ChatGPT for research? How do you use it for personas?
01:11:08 When I ask AI about personas, it gives me a lot of results. The main issue is that AI doesn’t help plan the prioritization of issues, it only helps find initial personas. From there, you have to rely on experience and real user interviews, then analyze and group personas correctly. If not, AI will give you too many personas.
01:11:56 Kafi mostly references competitor benchmarks anyway. Okay, I don’t have any more questions. Not sure if we recorded my voice. If there’s anything missing, just send the slides.
01:13:25 According to the agenda, Tom has a session called mixture of agents, where a group of agents work together, running a multi-agent system to get results. For now, though, that session might be too easy. I don’t think we’re ready for it, so we’ll skip it for now. There’s something more important to discuss about the trip and the test.
01:14:09 The test content will be as follows. You should start preparing now. First, you’ll write two essays. Write them yourself, if it’s bad, you’ll get criticized! The first essay will be about culture. I’ll pick one of the four core cultural pillars our team is following, likely centered around hybrid working, among other things. You’ll write an essay about that. I’ll share the question later, but I’m letting you know now. We’ll release it by the weekend for you to get started on it.
01:14:52 The reason for this is that, at this stage, I think everyone needs to set their own motivation to adapt to this new phase. The new phase is shaped by the market. The company phase is still normal, nothing special, but the market is changing. To align with that, everyone needs to refresh their motivation in this industry. That’s the first essay.
01:15:36 The second essay question will revolve around this: I haven’t decided on the exact wording yet, but it will be about the state of the app in your field. How is AI being applied in the field you work in? You’ll summarize this into an essay, kind of like a state-of-the-app report about how AI is being implemented in the industry outside. That’s the second essay.
01:16:18 Here’s a sample for that essay. I don’t know if I have it here, just a sample, though. For devs, it’s easier, but for those in sales, design, testing, or PM roles, it applies to all of you. Tom is thinking about cutting out those roles and replacing them with agents entirely. To be honest, we can expect AI to cover about 70–80% of the work, but we’ll still need people to drive those agents. So it’s a mixed approach.
01:17:04 For example, this article, is this the one? Let me check again. Right, take a look, does it look familiar? Some articles talk about how to use AI in a certain way. There are a few like this. The dev community covers some of this, but not a lot. Anyway, the second essay is about your role in the company. Given your role, how is AI being applied to your work today? That’s the second essay, okay?
01:17:42 The third one will be about practical application. I haven’t decided on the prompt yet because if I give you random topics, you’ll just sit and chat with GPT, and it won’t be very useful. So it’ll relate to hands-on tasks, building software and making sure AI is used effectively in your actual work. I’ll think of a submission prompt for that, maybe asking everyone to use AI for assessment. I’m not fully endorsing AI to cover everything because I’ve seen how everyone is using it. For instance, when I use certain tools to generate scripts, it’s very generic and lacks practical insights.
01:18:16 Just a quick comment on that: the way you’re using AI as a machine, in a formulaic way, shows inexperience. I’m not sure what word to use here, but it’s pretty dull. Very underwhelming. Okay, essay three will be on application, after you’ve researched and understood things, it’ll be about how you practically apply AI.
01:18:58 Moving on, if the trip goes as planned, we’ll likely go in early December. That gives us about two months to prepare, and we’ll need to finalize everything at least a month in advance. So you’ll have about a month to work on this. Alright? These submissions will be required. This is a necessary condition for the trip, and it’ll also be a condition for the performance review in December and January.
01:19:39 Currently, I’m expecting that our team’s activities will be assessed using AI to a level where we can control the outcomes and ensure they align with what we want, just like before. It shouldn’t be a case of, “because I used this tool, now the result is like this, because you told me to use it.” Got it? It’s like stabbing yourself with a knife and then blaming someone else, this won’t work. Okay, this is a necessary condition for the trip, and also the sufficient condition for the review.
01:20:14 This is important because this December’s review, if someone makes it all the way through and doesn’t perform well, then it’s highly likely that the juniors and freshers will be cut. Yesterday, I saw a really funny post. This guy didn’t get hired anywhere, so he made a multiplayer game called firm crash, using Go and TP. He posted it and used math to create animations. The comments were pretty amusing.
01:21:04 So, the December review will focus on that. That’s the final announcement to make sure everyone is aware. The message will be released by the weekend so that everyone can prepare for the deadline to submit, and Huy will grade it before the fourth week of November. Probably, by the fourth week of October, you’ll have about three weeks left, right? Exactly. This is the announcement. If some of you aren’t participating, it doesn’t really matter that much.
01:21:55 Next, there’s the list that Tom has been working on. I haven’t checked everything yet, but I’m starting to assess things one by one. Why is the pilot list so slow? This is a different list from the one I mentioned before. I’ll quickly go through it to show you all. This list here, Tom is working on it. I see some of you are participating, which is a good sign. It shows that people are starting to become aware of the change in the concept of how we develop software.
01:22:42 Now, we’ve got the addition of servers, new methods for data manipulation, and different approaches to data collection. Everything is changing, so things will be different. The rewards have already been sent out and are done. As for what Tom is working on, I’ll review it. I’ll review the work that others have done, and Tom will review some other parts. One of the examples is Hieu Vu. Hieu Vu, are you here? I haven’t seen any updates from you. If you’re starting to look for jobs like this, it’s not going to go well.
01:23:15 You guys need to be proactive in finding topics to work on. Here’s one of the lists. As for the other list, we’ll go through it once Tom finishes it. There’s the multi-agent topic, when the other topics are done. Knowledge sharing, grouping, specific projection.
01:24:07 The MapReduce topic, the team is working on it, collecting data, building it up, and running it. Thanh is working on this one. Last time we were working on the architecture; it’s still a bit rough. Next up are other topics related to the old system. Before, we only had servers, but now we have agents, so we need to send data to them. The architecture will change a bit. When given a problem, how we structure the agents is still a topic we haven’t fully discussed with each other.
01:25:12 Some of you are setting up Dify and can see it’s related, but there are many questions about architecture and how to structure a system with not just servers but multiple agents distributed throughout. It’s similar to the example Hoang gave earlier, that was just an easy sample. But when it comes to a real problem, how will the server architecture look? This is a real, practical topic that we need to handle. Just reminding you all again: if you’re not paying attention, what Tom is writing might not make much sense to you. We’re falling far behind in this area of knowledge.
01:25:39 I think this cluster of knowledge will become foundational for software engineers. It’s not blockchain knowledge, I’m not saying everyone needs to know that. But this part, you need to know. What’s important is knowing how to break down a problem and create a logical flowchart in your mind. If you can’t break it down, then you’re still inexperienced. Just a gentle reminder.
01:26:17 That’s the full message. I just wanted to make sure everyone knows where the direction and expectations are heading. This weekend, there will be an essay prompt: you’ll need to write two essays, one report, and one case study. If there’s nothing else, I think that’s it.
01:26:53 Goodbye everyone, see you later. Hopefully, today’s recapped topics are still valuable to you. Once you have more knowledge, we’ll move on to discussing the new system. For now, everything you’re building is still within the old framework, meaning it’s old compared to the outside world. But knowing ahead of time is always better. Okay then, let’s wrap up. Does anyone have any questions?
01:27:44 I guess not. Let’s finish here. Yes, I need to chat with our team. Yesterday, Dat posted a video. I feel like we’re lagging behind society so much. Where’s Dat? He posted a video of some Vietnamese guys automating something. This is crazy. Do you know which channel it’s from?
01:28:42 Alright, I think so. Is it a random channel? Right now, everyone is still upset about learning architecture the old way. They’re stuck on learning this architecture and that architecture. But at this level of automation, we need to apply it more. Every enterprise app or regular app will fall under this scope. If it’s easy to build up, then it’ll cover everything quickly. If it’s hard to build up, and you don’t even know how to handle the easy stuff yet, then it’s going to be even harder. See you all at OGIF next week.
01:29:22 I hope that every Friday we learn something new. See you all at OGIF next week.
