Xây dựng sản phẩm bằng kiến thức Design Thinking- Phần 1

Xây dựng một sản phẩm đòi hỏi kiến thức rộng về người dùng, công nghệ và vấn đề nằm giữa hai yếu tố ấy. Ngoài ra nó đi cùng những áp lực về phạm vi dự án, thời gian và những biến số trong quá trình phát triển khiến chúng ta bối rối. Tuy nhiên, để hoàn thành được công việc, chúng ta vẫn cần giữ sự tập trung để thúc đẩy và hoàn thành quy trình ấy.

Rút ra từ kinh nghiệm làm việc, chúng tôi thấy rằng việc xây dựng sản phẩm đòi hỏi một tư duy nhạy bén và một quy trình hiệu quả. Hiểu biết đóng vai trò quan trọng, bởi nó tác động tới cả tư duy lần quy trình của chúng ta.

Thành công của dự án phụ thuộc phần lớn ở hiểu biết của team về:

• Tư duy thiết kế sản phẩm (Design thinking)
• Vấn đề cốt lõi
• Phạm vi dự án
• Khám phá nhanh
• Thực hành double diamond
• Nghiên cứu UX
• Cộng tác thiết kế
• Giao tiếp trong nhóm

Tư duy thiết kế sản phẩm - Design Thinking

Gần đây chúng tôi đang thực hiện một dự án cho một nền tảng chiếu trực tiếp các cuộc thi thể thao. Trước tới giờ, chưa có một nền tảng tương tự nào như vậy, chúng tôi phải làm việc một cách thông minh và sử dụng quy trình thiết kế để chọn được những thông tin:

• Vấn đề phát sinh khi có nhiều đối tượng người dùng khác nhau
• Đưa sự kiện trực tiếp phát sóng trên nền tảng digital
• Những lựa chọn công nghệ hỗ trợ streaming
• Ứng dụng công nghệ vào ý tưởng thiết kế có thể có

Nó có nghĩa là chúng ta cần đưa tư duy thiết kế vào quá trình nghiên cứu và xây dựng ý tưởng. Cả team cần có chung một nền kiến thức về quy trình thiết kế sản phẩm phức tạp. Khi team hiểu được cách giải quyết vấn đề thực tế cho con người thực tế, mọi người cũng sẽ hiểu lý do cần có MVP và biết để đạt được mục tiêu cuối.

Đọc thêm: Tận Dụng Các Mô Hình Nhận Thức Vào Thiết Kế Sản Phẩm p2

Và hiểu biết về người dùng, biết cách tạo ra sản phẩm hữu ích cho họ chỉ có thể có được thông qua nghiên cứu. Nghiên cứu sẽ cho chúng ta nhìn thấy bức tranh lớn, xác định trọng tâm, cũng như hiểu người dùng rõ hơn.

Những nghiên cứu mà chúng ta thu được sẽ lấp đầy lỗ hổng kiến thức, từ đó cải thiện quá trình xây dựng sản phẩm.

Ví dụ như dự án stream thể thao mà chúng tôi đang thực hiện này, phần khó của nó là biết được cách để có được những hiểu biết ấy mà không vội vàng chọn một quyết định tệ hay tạo ra nhiều quyết định lựa thãi. Cả hai trường hợp này đều dễ xảy ra khi team thực thi không nhìn được bức tranh lớn.

Vấn đề cốt lõi

Vấn đề cốt lõi là những vấn đề lớn và phức tạp nhất. Ví dụ cho một vấn đề phức tạp đó là từ điển Wikipedia - vấn đề của nó rất khó, thậm chí không thể giải quyết vì những yêu cầu thay đổi lắt nhắt, mâu thuẫn và khó nhận ra.

Nếu nhận ra chúng sớm, chúng ta có thể chắc rằng chúng ta đang đầu tư vào một sản phẩm phù hợp với người dùng. Hội thảo là một cách hay để chúng ta tìm hiểu những vấn đề cốt lõi ấy, nơi chúng ta sẽ cùng các bên liên quan thảo luận về vấn đề của người dùng.

Để có thể cảm thấy tự tin về những hội thảo như thế, chúng ta nên xác định rõ thứ chúng ta cần biết để nhìn thấy được bức tranh lớn. Từ đó, những nghiên cứu thảo luận chúng ta sẽ tạo được hành trình người dùng và chân dung người dùng. Ngược lại, nếu chúng ta không hiểu sản phẩm mình làm cần giải quyết vấn đề gì, chắc chắn chúng ta sẽ rơi vào mê cung.

Hội thảo của chúng tôi sẽ bao gồm một Design Lead, một Product Designer, một Product Manager và một Tech Lead, cùng nhau làm việc với nhà đầu tư để hiểu vấn đề cốt lõi. Trong trường hợp của nền tảng stream thể thao, chúng tôi cần xây dựng những kiến thức về:

• Thể thao
• Cách truyền hình trực tiếp hoạt động
• Cách thực hiện việc quản lý, giám sát, đánh giá và cạnh tranh cùng một lúc
• Hệ thống hậu cần mạnh
• Công nghệ đáp ứng được hệ thống streaming

Khi chúng ta hiểu vấn đề, chúng ta cũng sẽ biết được phạm vi của vấn đề đó. Sau đó, chúng ta sử dụng chân dung người dùng, câu chuyện người dùng và hành trình người dùng để mô tả insight thu được cho đồng nghiệp. Cuối cùng, chúng ta sẽ có thể hình dung ra một MVP, cùng một trải nghiệm hoàn thiện với khách hàng.

Phạm vi

Khi chúng ta thực thi sản phẩm, phạm vi của dự án có thể bị thay đổi. Điều này hoàn toàn bình thường, nhờ nó chúng ta cũng sẽ hiểu sản phẩm mà chúng ta xây dựng hơn. Tuy nhiên, chúng ta cần rõ ràng về sự thay đổi ấy với cả team, bao gồm cả lý do cho sự thay đổi ấy. Chúng ta không muốn họ nhận yêu cầu mà không hiểu vì sao có yêu cầu ấy, họ cần hiểu vấn đề để triển khai giải quyết nó một cách đúng đắn.

Trong dự án của chúng tôi, ban đầu chúng tôi xây dựng một MVP với khá nhiều tính năng. Tuy nhiên, khi nhận ra có những thứ không cần thiết, chúng tôi đã cắt bỏ một số tính năng. Quyết định được đưa ra khi chúng tôi đã hiểu hơn về vấn đề, vậy nên chúng tôi hoàn toàn chắc chắn về nó.

Biến số sẽ và nên xảy ra khi chúng ta làm việc và thường thì hiểu biết cùng MVP tốt hơn sẽ đến sau khi chúng ta có bản MVP đầu tiên.

Chúng ta bắt đầu với một số ý tưởng nhưng chúng ta cũng sẽ học thêm về người dùng khi chúng ta thực thi những ý tưởng ấy. Kết hợp cùng kinh doanh và công nghệ, chúng ta sẽ đưa ra những ý tưởng hấp dẫn hơn, thay đổi sự ưu tiên và tạo ra một MVP phù hợp hơn.

Đọc thêm: Đối mặt với Scope creep (vượt phạm vi dự án) P1

Nếu chúng ta là một team nhạy bén, chúng ta cũng sẽ cởi mở với kiến thức. Sự linh hoạt sẽ giúp chúng ta không bị chìm vào đống tài liệu, cũng như dễ thích ứng hơn với biến số. Nếu chúng ta giao tiếp hiệu quả, việc bổ sung tài liệu sẽ là việc khá tự nhiên. Tuy nhiên, team của chúng ta vẫn cần hiểu được lý do tại sao để học có thể hiểu đúng và kết nối nó với những thứ khác, đảm bảo dù thay đổi ấy xảy ra ở bất cứ giai đoạn nào của dự án, cả team vẫn gắn chặt với mục tiêu cuối cùng.

Khám phá nhanh

Để đảm bảo rằng chúng ta sẽ xây dựng một ý tưởng tốt, ý tưởng ấy phải được chọn lọc qua nhiều ý tưởng. Ý tưởng tốt được rút ra từ insight và nghiên cứu. Một lần nữa, chúng ta không thể tạo ra giải pháp khi chưa hiểu rõ vấn đề.

Khám phá nhanh (Discovery sprints) là cách tốt để thử nghiệm những ý tưởng, thu thập insight. Tuy nhiên, để có thể thực hiện nó, chúng ta cần thực hiện phác thảo sớm và nhanh chóng.

Dù chúng ta không có mọi thông tin chúng ta cần để bước vào thiết kế, những việc bản phác thảo sẽ giúp chúng ta biết chúng ta sẽ cần những thông tin nào. Phương pháp này rất hiệu quả với team chúng tôi. Chúng tôi mang những phác thảo này bàn luận với designer và chủ đầu tư, qua đó, những phác thảo và giả định ấy được phát triển và hoàn thiện hơn.

Đọc thêm: Creative Agency Model - Khám phá các mô hình Agency sáng tạo mới

Những phác thảo kích thích bộ não của chúng ta đặt ra câu hỏi từ sớm. Dù những bản phác đầu có thể không phù hợp với UX mà chúng ta muốn cũng sẽ không sao, mục đích của chúng là để thách thức bộ nào của chúng ta suy nghĩ kỹ về vấn đề.

Cụ thể, trong dự án chúng tôi đang làm, chúng tôi đã:

• Xác định những câu chuyện người dùng
• Lên kế hoạch cho chúng
• Tạo wireframe cho những vai trò xem khác nhau
• Tìm điểm chung trong các vai trò ấy
• Xâu chuỗi những câu chuyện thành những ý tưởng
• Ước tính những ý tưởng cần khám phá và điều phối thực hiện

Chúng tôi thực hiện tất cả những gạch đầu dòng ấy với tâm thế sẵn sàng ứng biến. Nó cho phép chúng tôi thấy được những tình huống khó khăn có thể xảy ra trong tương lai, cho chúng tôi luyện tập tác phong và tư duy trong việc hợp tác.

Học từ những dự án tương tự sẽ tăng thêm kiến thức cho chúng ta. Tuy nhiên, hãy cẩn thận, đừng vội vàng copy giải pháp của họ. Bởi bạn không biết nó thực sự hiệu quả tới đâu, và dù nó có đi nữa, bạn cũng không biết liệu nó có hiệu quả cho vấn đề của bạn. Hành động đúng đắn là tập trung vào việc tìm hiểu và tạo những hướng phát triển khác nhau, việc đòi hỏi một tư duy khách quan để đánh giá đúng những tiềm năng chúng ta có.

Việc học hỏi từ casestudy sẽ giúp bạn thu thập những chất liệu cần thiết cho việc xây dựng ý tưởng. Chúng sẽ tự động được thu nạp vào não bạn, nuôi dưỡng tư duy giúp cho ý tưởng kịp tới mỗi khi bạn cần.