ABCDigi|Customer personas
1. What are customer personas?
Chân dung khách hàng mục tiêu là một bản mô tả chi tiết về khách hàng hoàn hảo của doanh nghiệp.
- Khách hàng hoàn hảo: Là khách hàng khi ta đề cập sản phẩm của mình, chúng ta nói đến công năng của nó thì khách hàng sẽ mua ngay, khách hàng này có đầy đủ có yếu tố để mua hàng như nhu cầu, nổi đau, tiền bạc, thời gian. Chỉ cần thông tin phù hợp là họ sẽ mua ngay.
Đặc điểm của chân dung khách hàng tiềm năng là tính nửa hư cấu. Customer personas được vẽ lên dựa vào 2 yếu tố:
- Trực giác của chủ doanh nghiệp.
- Khảo sát thực tế, số liệu thực tế.
2. Why do you create customer personas?
Giúp hiểu sâu và rộng về các nhu cầu của khách hàng, từ đó đưa ra nội dung truyền thông thu hút họ nhất, đề xuất phương án thỏa mãn (Thiết kế sản phẩm, dich vụ) đúng vấn đề của họ.
- Tăng tỷ lệ chuyển đổi: Chuyển đổi dựa trên chi phí đầu tư, chi phí Marketing.
- Tăng mức độ hài lòng: Cung cấp đúng sản phẩm khách hàng quan tâm
- Tăng giá trị đơn hàng: Khách hàng mua nhiều hơn, sẵn sàng mua đơn hàng lớn hơn
- Tăng giá trị trọn đời khách hàng: Khách hàng quay lại sử dụng dịch vụ, giới thiệu sản phẩm:
Chủ doanh nghiệp giảm giá dịch vụ để thu hút khách hàng, họ lỗ nhưng vì sao họ làm. Bởi vì họ biết trung bình 1 khách hàng đến với họ xài bao nhiêu tiền cho tới khi khách hàng đó không dùng sản phẩm của họ nữa Hoặc khách hàng có thể giới thiệu bạn bè đến trải nghiệm dịch vụ. Giá trị của khách hàng không nằm ở những đơn hàng đầu tiên, cái quan trọng là làm sao họ quay lại với chúng ta để trải nghiệm dịch vụ nhiều lần, giới thiệu bạn bè.
Tư duy về thang sản phẩm: Chúng ta có nhiều sản phẩm, và sản phẩm đặc thù phải làm cho khách hàng sử dụng lại nhiều lần. Đối với khách hàng onboarding thì đầu tiên họ mua cái gì, Ví dụ như spa thì mới vô là lấy nhân mụn (dịch vụ đầu phểu) trước khi sử dụng các dịch vụ khác. Bệnh viên Vinmec chạy rất mạnh chiến dịch sinh con tại Vinmec, tạo niềm tin cho khách hàng để sử dụng các dịch vụ cho mẹ và bé, dịch vụ cho cha, cho người cao tuổi.
3. Type of Customer Personas
3.1. Chân dung khách hàng mục tiêu
Một mô tả khách hàng hoàn hảo (có giải thícg mục 1)
3.2. Chân dung đối lập khách hàng mục tiêu
Không bao h mua hàng mặc dù đã giảm giá, năn nỉ
Ví dụ: Chúng ta không thể nào bán thức ăn nhanh cho tệp khách hàng eat clean, tệp khách hàng ăn kiêng. Không bán thịt được cho khách hàng ăn chay trường
=> Không bỏ chi phí truyền thông cho tệp khách hàng này.
4. How many customer personas should a business have?
Một doanh nghiệp có nhiều chân dung. Tuy nhiên phải chọn 1-3 persona để tập trung chăm sóc vì nguồn lực hạn chế. Hãy chọn ra tệp chân dung rõ ràng, tiềm năng nhất để chăm sóc tệp khách hàng đó tận tình.
5. 4 steps to create customer personas
5.1. Xem lại dữ liệu lịch sử
5.2. Áp dụng mô hình câu hỏi 5W - 2H Câu hỏi sheet 1
5.3. Trực quan hóa chân dung khách hàng: Vẽ chân dung khách hàng Câu hỏi sheet 2
5.4. Thử nghiệm các chân dung đã vẽ:
+ Đối với công ty đã có dữ liệu: Vẽ lại chân dung khách hàng để tạo chiến lược mới, họ xem đối tượng khách hàng nào mang lại nhiều doanh số, lợi nhuận,..
+ Đối với công ty chưa có dữ liệu lịch sử: Khảo sát khách hàng, phỏng vấn các tệp khách hàng mình cần
Youtube|Thực hành kiểm thử phần mềm]Test API sử dụng
Củng cố kiến thức:
- Front-end: Giao diện người dùng
Hiển thị chữ, bố cục, font chữ, size chữ nội dung
-Back-end: Xây dựng logic xử lý, database
Mô tả lưu trữ dữ liệu ra sao? đưa dữ liệu lên web như thế nào?
Fetch: Lấy nội dung từ back end chuyển sang cho font end để hiển thị lên web
API: Application programming interface - cổng giao tiếp giữa các phần mềm
BE: xây dựng ứng dụng -> cho các phần mềm khác giao tiếp được với dữ liệu của mình -> BE tạo ra các API (URL) -> cung cấp cho mình 1 công giao tiếp để từ phương thức giao tiếp -> trả về dữ liệu -> hiển thị lên ứng dụng.
API:
+ Post = Create
+ Get = Read
+ Put = update
+ Delete = Delete
Tạo môi trường giả lập + tạo API + Test API CRUD + tạo biến: xem video cô Trang
https://www.youtube.com/watch?v=FgH3Q4gV3V8&ab_channel=PhuongTrang
Cách viết test case + các thuật ngữ tets : sninpets : học sau
Circle Academy|Module 5| Analyse and model Requirements
* Model:
Biểu diễn trực quan của thông tin có thể sắp xếp và truyền đạt hiệu quả nhiều thông tin trong một cách ngắn gọn
* Mục đích của model là:
✓ Hiểu bối cảnh và mục tiêu kinh doanh
✓ Xác định các lỗ hổng và sự khác biệt trong các yêu cầu
✓ Xác định các yêu cầu bổ sung
✓ Loại bỏ thông tin không cần thiết
1. Process Model:
Thể hiện được tính logic, tính năng bên tỏng phần mềm mình đang chạy như thế nào?
1.1. Hiểu được process hiện tại:
1.2. Hiểu được process tương lai:
Dựa vào prototype để vẽ future process: https://www.figma.com/file/pckyFrkyaEGAera8DOPdZm/Kim-Hi%E1%BB%81n?type=design&node-id=0-1&t=klbXUbTsR0U8S73n-0
Phân tích và mô hình hóa phạm vi dự án:
✓ Các mô hình phạm vi được sử dụng để hiểu phạm vi của dự án nhằm ước tính, lập ngân sách và lập kế hoạch high level
✓ Chủ yếu tập trung vào việc tạo và hiểu các yêu cầu high level
- Context Diagrams
- Feature List / Feature / Use Case List
- User Stories
2.1. Context diagram
Sử dụng Biểu đồ ngữ cảnh để hiển thị ranh giới/phạm vi tích hợp high level
✓ Chi tiết về tích hợp (API hoặc Batch Process) và các trường dữ liệu có thể được phân tích trong Mô hình giao diện (Tích hợp hệ thống)
✓ Tích hợp có thể 1 chiều hoặc 2 chiều
2.2. Feature/ Use case list
✓ Feature / Use Case List được sử dụng để xác định high level scope của hệ thống nhằm mục đích xác định phạm vi dự án, ước tính và lập ngân sách khi bắt đầu dự án.
✓ Business Analyst nên cung cấp danh sách các tính năng hoặc trường hợp sử dụng để PM ước tính thời gian và chi phí thực hiện.
2.3. User stories
Trong các Dự án Agile Scrum, user stories sẽ được sử dụng để viết các yêu cầu, do đó, một danh sách user stories để xác định phạm vi của dự án.
3. Rule Model
Focused on ensuring business policies are adhered to by defining and limiting acceptable actions
✓ Rules may be internal, contractual, regulatory, legal, etc
✓ Business rules catalogs
✓ Decision trees or decision tables
3.1. Business Rule
✓ Không chỉ định cách thức thực hiện công việc
✓ Mô tả những việc không nên làm
✓ Viết các quy tắc rõ ràng
3.2. Decision Trees & Tables:
Decision models cho thấy dữ liệu và kiến thức được kết hợp như thế nào để đưa ra một quyết định cụ thể
✓ A single decision table or decision tree để chỉ ra cách một tập hợp các quy tắc kinh doanh hoạt động trên một tập hợp các thành phần dữ liệu kết hợp để tạo ra một quyết định
✓ Có thể giúp xác định các yêu cầu liên quan đến quy tắc hoặc các yêu cầu chỉ áp dụng cho các kết quả cụ thể.
- Decision trees
- Decision tables
Ex:
Case study 1:
Decision trees:
Decision tables:
4. Data model
4.1. Database & SQL
4.1.1. Data model type:
Data Modelling là quá trình phân tích các yêu cầu của dữ liệu và xác điinh các đối tượng sẽ được sử dụng trong cơ sở dữ liệu.
4.1.2. Conceptual
Conceptual Data Model được tạo ra bởi BA để giải thích:
- Dữ liệu kinh doanh nào sẽ được thu thập
- Mối quan hệ giữa các đối tượng kinh doanh
- Giúp nhsom kỹ thuật hiểu các yêu cầu dữ liệu một cách có cấu trúc
4.1.3. Logical Data Model
Logical Data Model ( còn được biết nnhuwEntity Relationship Diagram - ERD)
ERD được cung cấp bởi nhóm kỹ thuật:
- Business Data (from requirements) + Technical Data (from Design)
- 1 đối tượng có thể được chia ra thành nhiều đối tượng và ngược lại
4.1.4. Physical Data Model:
Sau khi Logical data model được hoàn thiện, nhóm kĩ thuật sẽ thực hiện physical data model bằng:
- Mô tả internal schema của cơ sở dữ liệu
- Tên bảng, tên cột, các khóa và mối liên hệ
- Phụ thuộc vào giải pháp cơ sở dữ liệu bao gồm: Physical location, cluster, security, constraints, peformance ....
4.1.5. Entities
Entity/Object (thực thể) là thứ mà chúng ta muốn lưu trữ dữ liệu để biến thành một bảng trong cơ sở dữ liệu.
Entity/Object bắt buộc là một doanh từ ví dụ: school, student, department, customer, order...
4.1.6. Relationships:
Relationship là cách để 2 bảng liên kết với nhau
- Primary Key: Trường hoặc cột trong bảng chứa giá trị duy nhất cho hàng. Xác định duy nhất từng bộ(hàng) trong bảng, không chấp nhận giá trị null, có duy nhất một primary key trong bảng
- Foreign Key: Trường trong bảng có liên quan đến khóa chính trong bảng khác
- Unique Key: Dùng để xác định duy nhất một hàng, nhưng không phải là khóa, không chấp nhận giá trị null và mỗi table có thể có nhiều unique key.
Có 4 loại mối quan hệ :
+ One to one
+ Self - Relationship (xem lại)
4.1.7. Attributes:
Thuộc tính:
- Những gì đang được lưu trữ cho mỗi thực thể hoặc bảng
- Còn được gọi là column hoặc Field như là first_name, last_name, date_of_birth, email, phone_number.
- Attribute type: xem lại
4.1.8. Normalization
Chuẩn hóa là quá trình tổ chức dữ liêu trong cơ sở dữ liệu bằng cách thiết lập mối quan hệ giữa các bảng để tránh dư thừa và duy trì tính toàn vẹn của dữ liệu
Không chuẩn hóa dữ liệu là merge dữ liệu thành một bảng và phải chấp nhận rủi ro vi phạm quy tắc chuẩn hóa để truy xuất dữ liệu nhanh hơn và hiệu suất tốt hơn
4.1.9. Lookup table & Audit Trail
- Look up:
Còn được gọi là Reference Table để chứa dữ liệu tham chiếu
Đây là một bảng độc lâp và chia sẻ trên tất cat các hệ thống cần dữ liệu này như: Country, city, district, occuaption,...
- Audit:
Audit là để lưu giữ lịch sử thay đổi thành hồ sơ
✓ Thử nghiệm kiểm toán giúp trả lời ai đã tạo hồ sơ vào thời điểm nào
✓ Thử nghiệm kiểm toán giúp trả lời ai đã thay đổi cái gì khi nào
✓ Lĩnh vực kiểm toán:
- Được tạo vào (Ngày giờ)
- Được tạo bởi (Hệ thống hoặc Người)
- Cập nhật vào (Ngày giờ)
- Cập nhật bởi (Hệ thống hoặc Người)
4.2. Data model
4.3. Data dictionaries
Business Analyst có thể sử dụng Data dictionaries để chỉ định các yêu cầu về dữ liệu từ stakeholders và truyền đạt nhu cầu dữ liệu cũng như phạm vi yêu cầu
✓ Nếu có một hệ thống kế thừa, ERD sẽ là điểm khởi đầu để điền data dictionaries
✓ Nếu không có hệ thống kế thừa, stakeholders có thể gửi cho bạn một số dữ liệu mẫu từ
Bảng tính Excel chứa các trường dữ liệu
Template: https://studybawithryan.atlassian.net/wiki/spaces/BR1/pages/306348397/Kim+Hien+-+Data+Dictionary
4.4. Data flow diagram (ít dùng nên k cần care) vì busniess process phần này tốt rồi.
✓ Sơ đồ luồng dữ liệu (DFD) cho biết dữ liệu đến từ đâu, hoạt động nào xử lý dữ liệu và liệu kết quả đầu ra có được lưu trữ hoặc sử dụng bởi hoạt động khác hoặc thực thể bên ngoài hay không
✓ Minh họa sự di chuyển và chuyển đổi dữ liệu giữa các thực thể, quy trình và kho lưu trữ dữ liệu. Dữ liệu được xác định trong kho lưu trữ dữ liệu có thể được mô tả trong Từ điển dữ liệu.
4.5. State Diagram
Mô tả và phân tích các trạng thái khác nhau có thể có của một thực thể.
✓ Bất cứ khi nào có yêu cầu liên quan đến trạng thái của một đối tượng, nên sử dụng sơ đồ trạng thái hoặc bảng trạng thái để giải thích các chuyển đổi và trạng thái.
✓ State Diagrams
✓ State Tables
Case 1:
Case 2: 
Circle Academy|Module 3| UI/UX figma for Business Analyst
1. From idea to prototype
- Step 1: wife frame: Vẽ khung xương, trằn đen có thể vẽ ra giấy, vẽ ý tưởng của mình lên. Thể hiện tính năng và chức năng của dữ liệu. Mục đích: Show bố cục tổng thể, chức năng, tính năng, data, đạt được sự đồng thuận.
- Step 2: Mockup: Chi tiết và có màu sắc. Mục đích: Visualize design, chi tiết hơn wife frame
- Step 3: Prototype: Nối flow lại, bản chạy thử có thể tương tác được. Mục đích: Usability Testing: đưa cho người thứ ba không biết gì về ý tưởng, đưa goal cho họ biết app này dùng để làm gì để sau khi họ sử dụng prototype, họ cảm thấy thể nào.
2. Comman user interface elements
2.1. Lable:
Label được sử dụng để hiển thị tên của 1 field. Labe ở dạng tĩnh và cố định.
2.2. Textbox:
Field để cho khách hàng nhập text vào, single line of text
2.3. Dropdown:
Nơi để khách hàng chọn cùng 1 lúc chỉ 1 item. nên chú thích ‘Select one’ để giúp khách hàng hiểu action họ cần thực hiện.
2.4. Search box:
Searchbox hoạt động tương tự như Dropdown nhưng cung cấp danh sách dài hơn nhiều với khả năng tìm kiếm. Danh sách thả xuống sẽ có một danh sách được xác định trước (ví dụ như thành phố, nghề nghiệp ,,,)
2.5. Check box:
Nơi để khách hàng chọn một hoặc nhiều item cùng một lúc.
2.6: Radio/switch/toggle:
Các nút radio được sử dụng để cho phép người dùng chọn một mục tại một thời điểm.
✓ Nút chuyển đổi cho phép người dùng thay đổi cài đặt giữa hai trạng thái.
2.7: Text area:
Field để cho khách hàng nhập text vào, multiple line of text
2.8: Date picker:
Công cụ chọn ngày cho phép người dùng chọn ngày và/hoặc thời gian. Bằng cách sử dụng bộ chọn, thông tin được định dạng và nhập vào hệ thống một cách nhất quán.
2.9. Button:
Một nút biểu thị một hành động khi chạm.
2.10: Search field:
Hộp tìm kiếm cho phép người dùng nhập từ khóa hoặc cụm từ (truy vấn) và gửi nó để tìm kiếm chỉ mục với mục đích nhận lại kết quả phù hợp nhất. Các trường tìm kiếm thông thường là các hộp văn bản một dòng và thường đi kèm với một nút tìm kiếm.
2.11. Breadcrumb:
Breadcrumbs cho phép người dùng xác định vị trí hiện tại của họ trong hệ thống bằng cách cung cấp đường dẫn các trang tiếp theo có thể nhấp để điều hướng.
2.12. Pagination (Phân trang):
Phân trang phân chia nội dung giữa các trang và cho phép người dùng bỏ qua giữa các trang hoặc xem theo thứ tự nội dung.
3. Mobile & Responsive design:
3.1. Responsive design (Thiết kế đáp ứng):
Công ty có một trang web, nhưng trang web responds, zoom out, zoom in khác nhau tùy thuộc vào kích thước màn hình của thiết bị đang hiển thị. Co dãn theo thiết bị, tùy giao diện và tiến độ phân giải. Khi vẽ thì nên vẽ trên độ phân giải 320px.
3.2. Hybrid mobile app (App dạng Hybrid):
Trang web được "Wrapp" lại bằng một ứng dụng. Vỏ ở ngoài là ứng dụng nhưng thực chất trong ruột là web. Hybrid chạy nhanh hơn các website nhưng không nhanh bằng native app. Không sử dụng được khi không có wifi (ví dụ như gg map sử dụng được khi k có wifi)
3.3. Native mobile app (Native App theo IOS, Android)
Một ứng dụng gốc được thiết kế đặc biệt để chạy trên một nền tảng điện thoại di động nhất định. (ios, anroid)
Vẽ figma cho app mới dựa trên current process and idea:
