Gamification at work

Gamification is the application of game design principles and mechanics to non-game environments

Cover of gamification at work
Cover of gamification at work

I have a chance to join the preview reading of this book when I received an inform last week from Interaction Design community.  Gamification is the buzzword these days over the internet, software application design, and even in user experience field study. Therefore, I was so impressed by the title of the book. It implies that not only the theory book but also the application of game design theory in daily life.

I spent nearly a week, most of my spare time after work or during the relax minutes in the office, night shift break-time to read and review the whole book. It’s because the preview reading need to be focused and quickly before it’s published to everybody. It’s not a long book, just 11 chapters, but almost concepts are demonstrated in the first 9 chapters, and it’s just 100 pages for preview version. (It might a little bit longer in publish version with printed format, I guess).

Like every other book, Gamificaiton at work has some advantages and disadvantages.

Janaki Kumar and Mario Herger bring a very clean and clear concept of Gamification through out this book, with the distinguish from Game design theory to the application of its concepts to business software. This book could be a good reference material for anyone who has first attempt to Gamification.

The book starts carefully with the concept of game in the daily life. Afterwards, it covers the new frame work which is called “player centered design”. It could be based on the “user centered design” concept, where the user is placed in the epicenter of the product as well as services. Around the player, there are several aspects which support to the design progress such as Mission, Motivation and one of the most important part of game theory, the Game mechanicsMission refers to the goal of gamification project activities, and what it need to achieve. Besides, the Motivation aspect is focus deeply on human behavior or social psychology. Motivation is also the core concept in every human interaction design activities. From usability engineering, to user experience, and web design, product design as well. It’s also applied in social media and marketing either. Human psychology is a big area, but the book authors try to collect some effective ideas which could help to gamification designer/ or software product design to apply in product/service design, and reach the final target that engage end users.

On the other hand, Game mechanics is the most important part of this book. Chapter 6 demonstrate 9 mechanics of game design theory. From the very basic concepts like points, badges, leaderboards to the advance items such as relationship, journey, emotion and challenge, constraints. Those things are not full game mechanics but it collected items which are believed by the authors in term of suitable for business software design. The book also opens reference to full covering of game mechanics to some outside resource like Tech Crunch network. Anyway, in my opinion, it should be placed a full game mechanics, at least more than 50 aspects in the separate appendix of this book. It will be a good reference for anyone who wants to take a look deeply.

The rest of the book focus on measuring, management and ethic considerations when a corporate execute the gamification project. For me, it’s not quite important in the area the book covers.

There are something good, and there are somethings need to be improved. The first half of this book is like a tasteful dish, but the second half make me feel confuse. It might be the first 6 chapters cover a lot of new things, bring the audience from the very basic concept to the detail deeper and deeper. But when I was enjoying the game theory and mechanics, I was expecting the book could show me how to applied in the real life, I mean the business software design, the rest chapters bring me away, to another fields like ethics, monitoring and leveling up reference resources.

With many new concepts, the book just raise a preliminary ideas and then show some example which are the screenshots of several online apps. It might make the readers a little bit skeptic of how it could be applied?  How gamification could be compare with traditional business software design? what are the key points and how are they can adapt together in the real life? Chapter 9 give us some example, or actually the screen shot of vampire app but it still not an concrete adoption with the title “Gamification at work“.

The readers may confuse with title “at work” because of many other related books like “coder at work”, “founder at work” and so forth. For me, I like this book, but I expect more than its current content. For example, I’m looking forward to apply gamification in business operation, software product design (ex: billing software, CRM, or something like that), and especially the retrospective we have to face when apply gamification concept in our project, with our team member and our customer.

This book is a good start for anyone who want to jump into gamification, read it, understand it before you wanna deep dive into this theory and techniques.

P.s: You can read the preview online version of this book here, or check it out in Amazon book store.

The Lucifer Effect

by Philip Zimbardo
Understanding How Good People Turn Evil

lucifer Có lẽ đối với nhiều người, đặc biệt là những bookaholic (mọt sách) hay những người làm/học ngành tâm lý học sẽ thấy quen thuộc với quyển sách này, cũng như quen thuộc với Philip Zimbardo. Quả thật, tôi rất lấy làm lạ bởi khi cố gắng tìm kiếm thông tin, review về cuốn sách này cũng như lý thuyết của Zimbardo trên các website tiếng Việt (tôi chỉ search qua Google, Bing) thì hầu như không có kết quả trả về. Có một số URL mang tính trích dẫn và giới thiệu sơ qua, nhưng không đầy đủ, chính vì vậy, tôi quyết định mình phải viết gì đó về cuốn sách này.

Từ từ đã, thế quyển sách này và lý thuyết trong đó thì liên quan quái gì đến design? Xin thưa là rất liên quan. Hihi… Sự liên quan của psychology ngày càng trở nên rõ rệt trong thiết kế sản phẩm cũng như trong usability design. Tại sao? bởi 1 lẽ, các ứng dụng ngày nay, từ web application cho tới mobile application đều hướng tới nghiên cứu, điều hướng hành vi người sử dụng (user behavior), thậm chí thay đổi thói quen của user (tôi sẽ nói về vấn đề này kỹ hơn trong 1 loạt bài blog khác).

Có rất nhiều điều tôi thích về cuốn sách này, cũng như lý thuyết của nó. Tuy nhiên, trước tiên chúng ta hãy nói về Zimbardo. Philip Zimbardo là cựu chủ tịch Hiệp hội tâm lý Mỹ (American Psychological Association) và là giáo sư danh dự tại đại học Stanford. Ông nghiên cứu về những hành động trái đạo đức và chủ nghĩa anh hùng, những biến đổi tâm lý mà nền tảng của sự biến đổi dựa vào 2 yếu tố chính: situations (tình huống, hoành cảnh) và system (hệ thống). “The Lucifer Effect” là kết quả của quá trình 30 năm nghiên cứu của Zimbardo mà qua đó, ông chỉ ra các yếu tố để biến một người bình thường/hoặc người tốt trở thành độc ác/quỉ dữ (Understanding How Good People Turn Evil). Nhưng trên tất cả, lý thuyết mà Zimbardo muốn nhấn mạnh là nhân tố làm biến đổi tâm lý, qua đó dẫn đến sự thay đổi trong hành vi của con người.

Câu truyện bắt đầu bằng cuộc thí nghiệm Nhà Tù Standford (Stanford Prison Experiment) năm 1971, lấy cảm hứng từ việc bạo hành tù nhân tại nhà tù Abu Ghraib. Việc thí nghiệm được tiến hành tại tầng hầm của Đại học Standford, trong đó 14 người tình nguyện đóng vai cai ngục, và 14 người còn lại đóng vai tù nhân (bị bắt giữ mà không báo trước – Sunday’s surprise arrests ), một cách ngẫu nhiên. Thí nghiệm dự định diễn ra trong 14 ngày, nhưng nó đã kết thúc sớm hơn dự định vào ngày thứ 6, vì những diễn biến rất khó kiểm soát (cả cai ngục và tù nhân giả định đều có dấu hiệu biến đổi tâm lý/hành vi rõ rệt). Những người tham gia dần bị biến chất mà quên đi mục đích ban đầu của thí nghiệm. Philip Zimbardo thậm chí đã thừa nhận rằng ông ngày càng lấn sâu vào vai trò “sĩ quan cai ngục” và hoàn toàn nhập vai thành một nhà quân sự độc tài. Trong quyển sách của mình, Zimbardo thậm chí còn miêu tả khá rõ quá trình biến đổi tâm lý khi 1 người khoác lên người bộ đồng phục của quản ngục.

Cuốn sách dày 540 trang, tuy nhiên phần nội dung chính khoảng 440-450 trang. Mặc dù vậy, theo quan điểm cá nhân tôi, chương hay nhất và quan trọng nhất là chương 10. Có thể bởi vì nó liên quan và lý giải nhiều nhất tới các yếu tố biến đổi hành vi con người, và liên quan nhiều tới product design, thứ mà tôi quan tâm. (Các chương còn lại thì chủ yếu nói về bắt bớ, thí nghiệm, nổi loạn, rồi các lý giải, điều tra về social dynamics, cũng như vấn đề đã xảy ra ở nhà tù Abu Ghraib).

Chương 10 có 2 luận điểm quan trọng, mà nói đúng ra là core của cuốn sách:

  • Why situation matter? Để cho dễ hiểu, thì đây là sức mạnh hoàn cảnh (nói như Malcolm Gladwell đã mượn kết quả thí nghiệm này trong cuốn The Tipping Point của ông). Nôm na là, hoàn cảnh của con người, hay bối cảnh, cũng quan trọng như tính cách của họ. Khi con người được đặt vào một hoàn cách khác, một tình huống khác (ví dụ như bị đi tù, bị bắt lột hết quần áo, chửi bới hàng ngày và dội nước lạnh) thì tâm lý và hành vi của người đó cũng biến đổi, thậm chí có xu hướng bùng phát nhanh hơn bình thường.
  • Why systems matter the most? Hệ thống là vô cùng quan trọng. Ở đây, chúng ta nên hiểu “hệ thống” là tất cả những thứ tạo ra hoàn cảnh/tình huống. Trong cuốn sách này, hệ thống bao gồm những thứ như việc bắt giữ, nhà tù, tra tấn, lăng mạ tù nhân, đồng phục cai ngục, luật lệ, không khí nhà tù, sự lạnh lẽo, bóng tối, v.v… Tất cả những thứ xung quanh tù nhân.

Suy rộng ra, có thể thấy điều này giống như 1 câu thành ngữ của người Việt: “ở bầu thì tròn, ở ống thì dài” hoặc là “đi với bụt mặc áo cà sa, đi với ma mang áo giấy” (mình chưa hiểu tại sao bụt có áo cà sa, chỉ có sư trụ trì mới có chứ nhỉ? hihi…). Có điều là các câu thành ngữ của Việt Nam thì không có chứng minh hay thí nghiệm khoa học nào cả.

lucifer-report
(Ảnh: báo cáo theo dõi biến đổi hành vi của cai ngục và tù nhân. Nguồn: sách The Lucifer Effect, chương 10, trang 202).

Như vậy, 2 yếu tố quan trọng là situations và system phần nào lý giải được việc biến đổi hành vi của con người. Điều này cũng làm sáng tỏ hơn các sự kiện trong xã hội. Ví dụ: tại sao 1 người có học vị cao (Thạc sỹ, Giáo sư, Tiến sỹ) hay có địa vị (như thày giáo) vẫn có những hành vi sai trái, thậm chí tồi tệ. Nguyên nhân có thể đến từ môi trường sống, bạn bè xung quanh (bọn nó chửi bậy thì mình cũng chửi bậy, tụi nó hút thuốc, mình cũng hút) hay có thể từ ý thức hệ hình thành trong quá trình trưởng thành. Gia đình cũng đóng 1 vai trò quan trọng trong việc tác động tới tâm lý trong suốt thời gian phát triển (tôi sẽ nói rõ hơn khi viết review về cuốn Developmental Psychology , Childhood and Adolescence) cũng như trong cuộc sống hàng ngày.

Việc 1 người có thiên hướng từ hiện hay bạo lực, có sở thích mua sắm hay ham chơi, có tâm lý tụ tập bầy đàn hay độc lập cũng có thể là kết quả của quá trình biến đổi tâm lý cũng như hành vi. Và ở đây, system có thể bao gồm lớp học (kiểu như học lớp chọn/với lớp mất dạy nhất trường thì ngoan/hư khác nhau), gia đình (bố, mẹ, anh chị em, ông bà…cà nhà cờ bạc thì con cháu cũng dễ cờ bạc theo, ví dụ thế, hihi..), đồng nghiệp,  câu lạc bộ, nhóm bạn trong xóm, và “hiện đại” hơn, nhóm hội trên Internet.

Một ví dụ dễ hình dung về situation đó là nhìn vào xã hội Việt Nam. Nếu bạn sống ở 1 môi trường cơ quan có thói quen nhận phong bì, hối lộ, vượt đèn đỏ (khi gặp đèn đỏ tại ngã tư đường phố, đêm tối, không có cảnh sát giao thông, những người đi cùng đường với bạn vượt đèn đỏ, bạn đang vội về nhà…cả xã hội có thói quen vượt đèn đỏ…và bạn cũng có xu hướng làm như vậy), nhổ bậy… những hành vi này xuất phát từ những con người “nhân tri sơ, tính bổn thiện” nhưng lại có đủ 1 hệ thống, 1 mớ tình huống khiến họ làm những điều “không hay ho gì”. (ko muốn nói là tệ hihi).

Sau cùng, nếu bạn đọc cuốn sách này, theo tôi (cách tôi đã đọc) thì chú trọng chương 1, 2, 10, 11 và 12.

Getting Real

Copyright by 37Signals
The smarter, faster, easier way to build a successful web application

getting-realTôi chọn quyển sách này là quyển đầu tiên để viết review bởi đối với tôi, nó quan trọng, nó (quyển sách) góp phần làm thay đổi tư duy, cách tiếp cận với việc viết phần mềm, và với sự nghiệp của tôi.

Getting Real là tên gọi của cuốn sách, với ý nghĩa đơn giản: hiện thực hóa sản phẩm phần mềm, ở đây là Web application. Riêng với tên gọi thôi đã thấy rằng những người viết ra quyển sách này rất hiểu tâm trạng của các lập trình viên, những người làm production.

Getting Real được viết bởi 37Signals. Đây là công ty đã “phát minh” ra Ruby on Rails từ ngôn ngữ lập trình Ruby đã có từ lâu, mở ra 1 mô hình phát triển sản phẩm mới, và từ 2006 đến nay rất “hot” ở Mỹ. Kèm theo đó là những cái niệm ORM (Object Relation Mapping) như Active Record. Đi kèm với 37Signals (viết liền nhé 😀 ) là các sản phẩm rất nổi tiếng và có hàng ngàn công ty trên thế giới sử dụng như BaseCamp (phần mềm quản lý dự án), HighRise (quản lý contact).v.v… Bên cạnh đó, 37Signals cũng là hình mẫu điển hình cho việc kinh doanh phần mềm theo mô hình SaaS (Software as a Service) và cloud computing ngày nay. Ngoài ra, Getting Real cũng là điển hình cho Agile development cũng như Lean UX, Lean start-up.

Nói về công ty và nhóm tác giả vậy đủ rồi, giờ thì quay lại với cuốn sách này. Cuốn sách chỉ khoảng 180 trang và được viết ngắn gọn, với lối kể chuyện mạch lạc, đi từ thiết kế sản phẩm, cho tới hỗ trợ, tương tác với người dùng giúp cho độc giả dễ dàng nắm bắt và hiểu thông tin mà sách truyền đạt. Sách có 16 chương nhưng lại chia nhỏ thành 171 topics (chủ đề), xuyên suốt đó là qui trình build sản phẩm (web app), test sản phẩm, support người dùng, promote sản phẩm, lập trình, thiết kế giao diện, qui trình làm việc, lựa chọn tính năng và điều chỉnh.

Có lẽ khi viết ra cuốn sách này, sau khi đã thành công với các sản phẩm SaaS (nêu trên), 37Signals muốn kể lại câu truyện thành công của họ, cách họ áp dụng Lean, Agile /Scrum như thế nào, làm việc nhóm ra sao để qua đó 1 công ty với số lượng nhân viên dưới 20 người (vào thời điểm ra mắt cuốn sách) đã mang lại doanh số ~400 triệu USD (nghĩa là kiếm hơn 1 triệu USD/ ngày). Và với mong muốn tạo ra sự thay đổi trong giới làm phần mềm web app, họ miễn phí quyển sách này. (bạn có thể download free tại đây).

Về quan điểm cá nhân, đối với nội dung cuốn sách, tôi thích và thực sự học được những thứ hay ho như sau:

  • Be willing to say no to your customers. Điều này có nghĩa là không đáp ứng ngay lập tức các yêu cầu sửa đổi đến từ người dùng / khách hàng. Tại sao? bởi những yêu cầu này không phải lúc nào cũng đúng. Ví dụ như người dùng yêu cầu Text Editor phải cho phép điều chỉnh format của font chữ, màu chữ… với mục đích gây chú ý. Nhưng giải pháp đôi khi rất đơn giản như VIẾT HOA TOÀN BỘ THẾ NÀY hoặc thêm các ký tự đặc biệt gây chú ý dưới dạng: @@@@@ Thế này có gây chú ý chưa ku? <==== ###
  • Done is done, và Build Less. Khái niệm này thuần túy của Lean, ai làm qua cũng hiểu rồi :). Phần mềm ban đầu cứ xây dựng những tính năng cơ bản, giải quyết v.đề lớn nhất cho người dùng, những thứ khác có thể bổ sung theo thời gian. Khi lượng người dùng yêu cầu 1 tính năng nhiều lần và nhiều người claim về nó, đó là lúc bạn cần bổ sung tính năng đó.
  • Alone Time, Meetings Are Toxic. Quan điểm này thực sự rất cần thiết cho các công ty phần mềm. Việc họp hành quá nhiều gây mất tập trung và thời gian (cũng là tiền) của các cấp nhân viên. Alone time ở đây theo 37Signals là 1 tuần dành ra 1 ngày (ví dụ như thứ 4 hàng tuần) cho phép mỗi nhân viên của họ được Alone, nghĩa là không bị làm phiền bởi bất cứ điều gì, họ tự làm cái họ cần. Điều này có lẽ nhiều người đã trải nghiệm, ví dụ như đi làm sáng thứ 7 hoặc Chủ nhật thường làm được nhiều việc nhất, có khi giải quyết công việc bằng khối lượng cả tuần.
  • Interface first, và Three State Solution. Luôn thiết kế giao diện xong xuôi, hiểu các flow tương tác giữa người dùng và ứng dụng (human interaction) rồi mới lập trình. Bên cạnh đó, một bản vẽ giao diện (UI) cần thể hiện được 03 giai đoạn: regular (lúc hiển thị dữ liệu bình thường), blank (lúc không có dữ liệu) và error (khi xảy ra lỗi). 37Signals đặc biệt chú trọng blank slate, bởi các nhân viên graphic design thường đưa ra bản vẽ có đầy đủ dữ liệu giả lập, nhưng với người dùng, khi vừa đăng ký 1 blog mới, 1 album ảnh mới… tất cả là empty vì chưa có dữ liệu. Bỏ qua giao diện blank slate là 1 lỗi lớn thường gặp, và rất dễ gây confuse với người dùng.
  • Open doors for Code. Phần này ngày nay được các công ty áp dụng triệt để. Nghĩa là 1 sản phẩm làm ra cần tương tác với các sản phẩm khác, cho phép các bên thứ ba (không phải người dùng) tham gia phát triển. 1 sản phẩm cần có API, Coding guidelines, RSS, XML data export, v.v…
  • Manage debt. Trong nhiều tài liệu phát triển phần mềm, người ta còn gọi đây là technical debt. Cái này bạn nào làm lập trình viên rồi thì hiểu ngay 😀 hihi. Lúc coding, thiết kế kiến trúc, có rất nhiều người chọn giải pháp “tạm bợ”, hoặc “làm tạm cho chạy đã, rồi tối ưu hóa sau”… tất cả những điều này (kể cả Tây Tàu gì cũng mắc phải) chính là món nợ của bạn sau này. Đến khi sản phẩm running rồi, go live và tệ hơn là có người dùng rồi, lúc đó mới chỉnh sửa lại architect, sửa lại code thì “cost” cho “debt” của bạn sẽ tốn hơn nhiều lần. Nói nôm na là debt thì có interest rate theo thời gian là đúng thôi keke.
  • Sau cùng, Feel the pain, Zero training và Better, not Beta. 2 khái niệm đầu tiên là mô tả quá trình hỗ trợ khách hàng (user support). Feel the pain, nghĩa là bạn cần support trực tiếp người dùng, đừng thuê các công ty call center 1 cách máy móc. Hãy hỗ trợ người dùng và hiểu cái khó khăn, bực dọc, thậm chí là khổ sở của họ khi dùng sản phẩm của bạn. Zero training, nghĩa là hãy thiết kế ứng dụng cũng như giao diện sao cho đơn giản, (less is more) dễ dùng và user có thể thao tác được ngay mà không cần đọc bản user manual. Và cuối cùng, khi ra mắt sản phẩm (web app, mobile app), hãy chắc chắn rằng nó chạy tốt, được test cẩn thận và đừng có khái niệm Beta trong đầu. Bởi Beta, theo 37Signals thì chẳng khác gì bạn tuyên bố: bọn em chạy thử thôi nhé, còn lỗi đấy, đừng kêu ca gì 😀

Còn rất nhiều điểm thú vị ở cuốn sách này, 6-7 năm sau ngày phát hành (tính đến thời điểm hiện tại là năm 2013), những bài học này vẫn còn rất mới và hữu dụng. Hàng ngày, các start-up, các công ty phần mềm, lập trình viên hay UX designer vẫn mắc phải các lỗi nêu trên. Cá nhân tôi, highly recommend anh em nào muốn thực sự làm product, lean start-up thì nên đọc quyển này 😛

Đây là 1 quyển sách đáng đọc, và đáng để đọc đi đọc lại nhiều lần với những ai làm start-up, software engineer, và đặc biệt là những người làm UX, Lean and Agile.