The seeds of a feedback ecosystem

A few posts ago I kicked off a series of talks here on the subject of a feedback ecosystem and how such a thing could enhance user engagement, particularly on mobile devices.

While I did touch on what such a thing might be, I want to explore in deeper detail tonight.  First some personal background.

How I Originally Got Into This

Nokia hired me in 2005 to be a Quality Feedback Analyst in support of cell phone factory operations.   I had never performed in such a role (I had never even owned a cell phone!) and was surprised to get the job offer.  But my new manager said she saw all the right pieces in my engineering past and that the passion I had for quality was obvious.

I was glad she gave me the opportunity, as that turned out to be the most enjoyable and rewarding job I’ve ever had.  The challenge to analyze and improve the error reporting and corrective action processes was a real thrill!  I had finally found the right home for my problem-solving inclinations.

Who Really Wants Feedback?

After a thorough investigation of the factory data systems, followed by some intense data scrubbing and SQL coding for preventive actions and reporting, I had the ammunition we needed to put undeniable facts behind production and delivery corrective action efforts.  The result was success in driving down some longstanding, high-impact defects.

So I started working on ramping up efforts, driving increased automation of feedback delivery so the information could more easily fight its way upstream in timely, efficient fashion.

I quickly ran into a roadblock.  To do what I intended required a culture of feedback consumption.  Our corrective actions had worked because a few passionate human beings personally drove them hard, fueled by data.  But another corrective action team with the same tools and prospects failed to deliver because its team was not so passionate.  They didn’t deliver the feedback to the right recipients.

I was looking to take the burden off select champions of quality and distribute the load to every single stakeholder.  I would do this by planting alert triggers and event escalation actions into our process landscape.  This would empower and enable every employee to more immediately respond to issues (rather than waiting for periodic meetings) and even better, push solutions further and further upstream where they required less effort and reaped larger rewards.  Win-win, right?

Technology vs Culture

But we didn’t have a true feedback ecosystem.  We had one excited database administrator and programmer (me) impementing things like real-time SMS alerts to supervisor cell phones, joined by a handful of hardworking believers who could not be everywhere, and that’s as far as things went.  Technology alone could not overcome cultural norms, I decided.

Or could it?

Flash forward to this year.  When I started down the path of what has become the MeeGo User Engagement Framework project, the original goal was to improve applications testing process for Maemo.  I posed some ideas on applications feedback and was met with counterpoints claiming that providing the necessary feedback was too much to ask of even some advanced users.  In a similarly-themed dialog around bug testing, the same was said of that activity.

So I got to thinking, “We’re just looking at the surface.  We have ideas that sound good in theory, and then meet a hard wall when we propose implementing them.  But do we have to give up just because people are right about user resistance?”

Some pointed to the huge gap between Maemo application download counts versus rating instances and quickly replied, “Yes.”

Well, I’m too stubborn to stop there.

In Support and Out of the Way

The key here is to integrate feedback mechanisms so tightly into supporting systems that users aren’t impeded by them and actually enjoy the engagement.  In the case of Maemo app downloads, users have to visit a specific web page after downloading to offer their views.  While this alone should not be a total impediment, the activities were too far apart to engage most users.  So why not implement ratings in, say, the N900 Application Manager, some asked.  Great idea, I thought.  Why not take it further?  Let users opt in to even richer feedback opportunities.

What if after playing a game X number of times a popup asked for your thoughts on it?  What if upon uninstalling an app the user was met with a satisfaction survey?  And why stop there?  What about bug reporting and developer donations?  After all, both are just more examples of feedback!  And why limit feedback to a single direction?  Console gamers love achievements, and the virtual  rewards have been shown to enhance customer “stickiness”.  What’s technically preventing mobile gamers from having the same privilege?

Hash and Rehash

In hindsight I could have done more to foster a culture of feedback consumption in that Nokia factory.  Built that feedback ecosystem.  I just wasn’t thinking as big then as I am now.

I’m well aware that there are significant challenges to putting some of these ideas in place in a world of mobile devices running open source operating systems.  I’ll be addressing those in upcoming articles and I’m looking for more audience participation than the first article garnered.

The feedback opportunity is very closely coupled with the output here, so chime in!  ;)  Next, I’ll go into more detail on just what I mean by “feedback ecosystem”.

4 responses to “The seeds of a feedback ecosystem

  1. IMHO, there are different types of users which can offer different types of feedback. Guess what, there are developers out there. E.g. Just watch Google´s I/O keynote about Android 2.2, they´ve enabled a cool error reporting tool which shows the developers reports including all the stacktrace of the error, while gracefully notifying the user about an error withouth any tech details.

    I don´t understand why this have to be a new improvement, specially in open platforms like Maemo, this types of mechanisms should be incorporated from the beginning. I don´t want to code sth for sending the error data to my servers, I want the platform to provide me with an API to do this.

    Anyway, this is just a very concrete type of feedback which I wanted to highlight as it wasn´t mentioned on your post.

    Finally, another tought after reading you: don´t forget the users you will face on a platform like Maemo are probably more passionate than others. They´ll be at least “geek” ot “techie” people, and perhaps developers. They will probably colaborate on any feedback ecosystem, but average user is another story.

    That´s my vision. Thanks, and keep passionate!
    – An Android developer and Maemo/Mer lover.

    • Eero Tamminen

      > Android 2.2, they´ve enabled a cool error reporting tool which shows the developers reports including all the stacktrace of the error

      I think that’s a bit simpler in Java where Google controls the JavaVM. In native optimized ARM code you need debug symbols to be able to get backtraces, and it’s the developers who have those for their apps, binaries in the repositories are stripped.

      If you just want to get your application’s core dumps and get the stacktraces yourself (you’ll anyway need to debug them…), you can ask your testers/users to install Crash reporter from the SDK tools repo and then you can provide them a trivial crash reporter configuration package that tells it to catch only your application’s crashes[1] and where to upload the resulting cores[2].

      [1] put its binary name to /etc/rich-core.include file.

      [2] put information about your www-server upload dir to:
      /usr/share/crash-reporter-settings/crash-reporter.conf
      (check crash-reporter-settings-public package for example)

      Uploaded cores can be extracted with a small/trivial tool from the sp-rich-core-postproc package. The extracted data contains the full core dump, system & process information, installed package versions etc.

      You should also ask your users to provide their contact information when uploading the cores, so that you can later contact them for instructions on how to re-produce the crashes and to verify your fixes.

      Support for that has been there at least since Diablo. I think the latest Fremantle Crash reporter also remembers the used message(s) so user needs to type the info only once.

    • Thanks Javier, that’s EXACTLY what I’m looking for! I didn’t mention the Android keynote info because I didn’t know about it yet– which is why I depend on savvy readers. 😉 However, I have already discussed the need and opportunities for advanced bug reporting in general so sure, it’s a big part of this.

      But I agree 100% with your opinion and that’s what we’re shooting for. I have been challenged the past few days to make the meta-project scope and steps clearer and thanks to some good feedback I have some ideas.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s