5 điều tôi đã học được về Enterprise UX

Bài viết này được sử dụng cùng với phần đệm của bài hát: Man Sharp-Dressed Man 'của ZZ Top

Những thách thức lớn nhất mà một chuyên gia UX phải đối mặt trong một dự án lớn của công ty là gì?

Những cạm bẫy chính là gì? Đó là cách tiếp cận tốt nhất để thực hiện?

Bài viết này thảo luận về các dự án phần mềm cấp doanh nghiệp, thường được tìm thấy trong các công ty có một số bên liên quan đại diện cho các bộ phận khác nhau (ví dụ: tài chính, bán hàng, tiếp thị, v.v.).

Đây là loại phần mềm (thường là di sản), chịu một số lượng lớn các mô-đun và thành phần, cùng với nhiều thông tin phức tạp cao như người dùng có thể đối phó.

Quy mô công ty, cùng với mức độ lớn của thông tin cần xử lý, làm cho hiệu quả và hiệu quả của nhiệm vụ người dùng trở thành một phần quan trọng trong các mục tiêu khả năng sử dụng của hệ thống. Do đó, giảm thời gian thực hiện nhiệm vụ cho người dùng doanh nghiệp tiết kiệm hàng triệu mỗi năm cho các công ty lớn như vậy.

Tiếp theo, là một phác thảo về một số hiểu biết quan trọng mà chúng tôi đã phát hiện ra từ nghiên cứu và thu được từ kinh nghiệm cay đắng. Họ đã chứng minh sự sống còn trong nhiều tình huống, từ các nhiệm vụ hàng ngày, cho đến các quyết định thay đổi khóa học lớn.

# 1 - Phỏng vấn tất cả các bên liên quan

Đây là một nhiệm vụ để thực hiện vào ngày đầu tiên. Dành nhiều thời gian nhất có thể để lắng nghe mọi người tham gia dự án là vàng nguyên chất. Trong hầu hết các trường hợp, điều cực kỳ quan trọng là tách biệt những người ra quyết định khỏi cộng tác viên, khách hàng nội bộ và những người chỉ cần được giữ trong vòng lặp (chủ yếu vì lý do chính trị).

Điều khó khăn là xác định tất cả. Xin lưu ý rằng có một xu hướng trong các dự án lớn của công ty là có các bên liên quan mới xuất hiện ở giữa nước rút, vào thời điểm tồi tệ nhất có thể. Hãy nhớ rằng, luôn có một người ra quyết định không ngồi vào bàn khi bắt đầu một dự án.

Khi tất cả các bên liên quan chính đã được xác định, thật lý tưởng để phỏng vấn họ trong các phiên 1-1. Thu thập các quan điểm độc đáo của họ và hiểu quan điểm của họ, làm rõ sự mơ hồ và không nhất quán. Có được sự rõ ràng về các mục tiêu của dự án, từ sớm, sẽ giúp xây dựng một chiến lược UX tốt. Bước tiếp theo là mời tất cả các bên liên quan vào một hội thảo để làm cho chúng phù hợp (nhưng đây là một chủ đề cho một bài đăng khác).

# 2 - Kiểm tra và chia sẻ mọi thứ

Không đồng ý về hướng sản phẩm dự kiến ​​trong các dự án quy mô lớn. Mỗi bên liên quan có thể và sẽ bày tỏ ý kiến ​​của mình (thường là mạnh mẽ) khi dự án phát triển. Chống lại ý kiến ​​với ý kiến ​​là vô nghĩa.

Thay vì tranh cãi, tốt hơn hết là đưa mọi thứ vào thử nghiệm ngay từ đầu và thu thập dữ liệu trực tiếp từ người dùng.

Sau khi tiến hành nghiên cứu người dùng, sự minh bạch tiếp theo. Chia sẻ là quan tâm và vì vậy giữ cho tất cả mọi người trong nhóm tham gia. Các cuộc phỏng vấn và phiên âm của họ nên được chia sẻ ngay sau khi được xử lý. Không có lý do để giữ bí mật thông tin như vậy.

Mỗi lần lặp nghiên cứu người dùng cung cấp một nhóm kiến ​​thức mới về người dùng và miền (ví dụ: đối thủ cạnh tranh). Các buổi chia sẻ kiến ​​thức thường xuyên hoạt động tốt để giữ cho mọi người đồng bộ. Miễn là mọi người được thông báo chính xác, họ cảm thấy tất cả tham gia nhiều hơn vào quá trình UX. Bất kỳ mức độ sâu thông tin sẽ làm và sẽ được đánh giá cao. Đó là cách để các bên liên quan mua nhanh hơn ngay tại đó!

Nhưng một số bí mật thì quá ngon để không chia sẻ.
- Suzanne Collins, Mockingjay

# 3 - Giữ một phút họp Nhật ký

Ghi nhớ tất cả các bên liên quan từ điểm số 1 ở trên? Trong một tổ chức lớn, rất khó để mọi người đồng ý với nhau. Thậm chí rất khó để giữ chúng trên cùng một trang liên quan đến quy trình hiện tại. Thật không may, trong hầu hết các trường hợp, gần như không thể giữ tất cả mọi người trong một cuộc họp không đồng bộ với các bước và mục tiêu tiếp theo.

Giữ một tài liệu được chia sẻ với các ghi chú bằng văn bản trong các cuộc họp làm giảm sự mơ hồ giữa các thành viên trong nhóm và các bên liên quan. Nhật ký biên bản cuộc họp thường bao gồm một chương trình nghị sự cho cuộc họp, danh sách các điểm chính được thảo luận và các bước tiếp theo để theo dõi sau cuộc họp. Nó là một trong những công cụ truyền thông tốt nhất trong các dự án doanh nghiệp, đặc biệt là nếu các yêu cầu có xu hướng thay đổi (và cuối cùng chúng sẽ thay đổi).

Có một chương trình nghị sự trước mỗi cuộc họp và tránh các cuộc họp mà không có ai, tiết kiệm thời gian cho mọi người. Điểm thảo luận giúp hiểu kết quả của cuộc trò chuyện khi được xem xét lại. Cuối cùng, các bước tiếp theo giữ cho mọi người không đồng bộ với chiến lược đã thống nhất, ngay cả những người không tham dự cuộc họp.

# 4 - Chú ý đến IA

Hệ thống doanh nghiệp lớn xử lý một lượng lớn thông tin. Dữ liệu đa dạng được kết nối hoặc kết hợp theo nhiều cách và thường có thể được truy cập bởi nhiều tài khoản.

Thông thường, thông tin vướng víu này xuất hiện dưới dạng bảng phức tạp, danh sách mục lớn, biểu mẫu không đáy với trường nhập vô hạn và nút hành động (ví dụ: gửi, xóa) mà không có bất kỳ loại đối thoại ngăn ngừa lỗi nào.

Trong những trường hợp này, làm việc cùng với các BA là khéo léo. Ban đầu, phải mất một thời gian để nhận ra tầm quan trọng của việc tập trung vào phân loại trước khi bố trí hoặc điều hướng của UI. Tạo bảng tính với các thùng thông tin từ nền tảng, bao gồm các biến và tham số của chúng, giúp tiết kiệm rất nhiều thời gian trong việc thiết kế các biến thể giao diện sau này.

Một loạt các phiên phân loại thẻ phải được tiến hành sau đó, để xác thực hoặc vô hiệu hóa kiến ​​trúc thông tin với người dùng thực tế và do đó giúp tránh suy đoán. Việc giải quyết sự phức tạp thông tin rộng lớn này không chỉ đơn giản hóa các sơ đồ điều hướng sau này, mà thường làm cho quy tắc 80/20 của công việc thiết kế UX trong các dự án như vậy.

Một kẻ ngốc thông minh có thể làm cho mọi thứ lớn hơn, phức tạp hơn và bạo lực hơn. Nó cần một chút thiên tài - và rất nhiều can đảm để đi theo hướng ngược lại.
- Ernst F. Schumacher

# 5 - Cung cấp các thay đổi nhỏ

Người dùng của các hệ thống nói trên, phải vật lộn với phần mềm như vậy rất nhiều. Họ không có giải pháp thay thế hoặc thay thế (tất nhiên ngoài Excel), vì vậy họ phải đối phó với các lỗi thiết kế của phần mềm doanh nghiệp. Nhiều lần, họ thậm chí còn căng thẳng và coi mình là kẻ bất tài vì không thể hoàn thành thành công một số hoạt động.

Ngay cả những thay đổi nhỏ trong nền tảng cũng có thể cải thiện quy trình làm việc hàng ngày của người dùng bằng cách loại bỏ các điểm đau nghiêm trọng. Để đạt được điều này, tốt nhất là tránh phục vụ các phần mềm quy mô rộng hoàn toàn mới cho những người dùng này, đặc biệt là khi bắt đầu quá trình thiết kế lại. Hệ thống cũ có thể không sử dụng được nhiều như vậy, người dùng đã quen với nó vì họ đã làm việc với nó trong nhiều năm. Họ sẽ rất khó đối phó với một quy trình làm việc hoàn toàn thay đổi đột ngột.

Hãy nghĩ về nó theo cách này: Mỗi lần Facebook thay đổi bố cục, thậm chí nhẹ nhàng, người dùng sẽ đi chuối. That Facebook Facebook: hình ảnh tiệc tùng, bài viết khoe khoang và video mèo con! Hãy tưởng tượng có điều tương tự xảy ra trong phần mềm cốt lõi mà toàn bộ quy trình làm việc của bạn dựa trên. Mọi người sẽ nhảy ra khỏi cửa sổ!

Để giảm khả năng chống thay đổi, tốt nhất là cung cấp các thay đổi gia tăng nhỏ có tác động hạn chế nhưng tích cực đến quy trình làm việc của người dùng. Lưu ý khía cạnh của Giảm bớt về sức đề kháng của người dùng: gần như không thể tránh được hoàn toàn. Tuy nhiên, thời gian khó chịu có thể được giảm. Không cần phải nói rằng những cải tiến như vậy phải dựa trên bằng chứng và được thực hiện sau khi đánh giá hoặc thử nghiệm heuristic với người dùng để khám phá những điểm đau chính của họ.

Liếm vết thương

Điều cần thiết là lưu ý rằng trong các dự án này, không phải lúc nào cũng có thể làm theo tất cả các đề xuất được đề cập ở trên ngay từ đầu. Thiếu kiến ​​thức về miền, ngăn chặn những bất ngờ trong tương lai về bản chất chính trị hoặc quản lý. Vì vậy, coi bài viết này là một danh sách vết thương (exit-).

Mỗi trường hợp và dự án là khác nhau. Thử và sai sẽ chứng minh một cách tiếp cận lý tưởng ở đây, miễn là mỗi thử nghiệm được giữ trong các lần lặp nhỏ. Quan sát kết quả và lặp đi lặp lại, cuối cùng dẫn đến học tập và tối ưu hóa. Chính xác như cách tiếp cận Lean Startup cho thấy, nhưng ở cấp độ doanh nghiệp.

Một kinh nghiệm học tập là một trong những điều nói rằng, Bạn có biết điều bạn vừa làm không? Hãy làm điều đó.
- Douglas Adams, Cá hồi nghi ngờ

Tôi chắc chắn bạn sẽ phát hiện ra nhiều vấn đề quan trọng hơn trong dự án doanh nghiệp của bạn. Tôi rất muốn có thể so sánh các vết thương lòng, vì vậy hãy cho tôi biết trong phần bình luận bên dưới :)

Bạn có muốn biết thêm về việc triển khai UX trong các dự án doanh nghiệp không? Quan tâm đến UX và Scrum có lẽ? Sau đó, liên hệ với chúng tôi tại hi@zanshinlabs.io để giúp bạn với các nhu cầu sản phẩm doanh nghiệp cụ thể của bạn hoặc chỉ cần truy cập http://zanshinlabs.io/content.html.