Developer diaries: A way to build community and foster innovation

[Karen Bachmann]

The online games I play have both released major updates. These exciting and long-anticipated events have been tracked regularly by game reviewers and fans alike. I've been reading for weeks before and since the releases about these expansions in forums, release notes, reviews, and developer diaries.

Developer diaries are particularly interesting artifacts. A developer diary discusses the motivation, goals, and/or design thinking that went into a particular aspect of product design. The writing is generally too neat and complete to be verbatim from an actual daily diary, but these posts do seem to summarize what might actually have been in a real diary leading up to the final product. They also have noticeable variations in voice, suggesting that the authors are different people, not the same authorized public communicator, even if they are obviously edited for grammar.

Let me correct myself. When I said "product design," I really meant game design. A Google search for developer diary revealed nearly 900,000 hits. In the first 10 pages of results, only 2 were not for games. Those were not about a product, but are personal-professional blog posts that used the name.

This surprised me. Why would such an interesting and engaging communication be largely limited to a single genre?

One of the really amazing things about games is the importance and priority of community around those games. The best game communities are not limited to those who play the game, but include the developers, designers, game masters (a variable title that can be read as "in-game tech support"), and other people who work for the developer. Developer diaries are a way of recapping why particular decisions were made and sharing this information with the larger community invested in the affected game.

In a passionate game community, such communication might be self-defense. If gamers feel passionately about a design direction — especially if they do not like it — the company will hear about it. A lot. Explaining the decision-making process is one way that the company can steer the overall conversation into the most constructive channels. The openness on their side allows posters to make more thoughtful comments (yes, they do happen) about the merits of the decision, whether the actual experience delivered on the design goals, and what additional thoughts might need to be considered.

Some developer diaries describe how decisions drew from user feedback and suggestions. In effect, they summarize the discussion for product improvement to date, describe the action taken on the discussion, and provide a launching point for the next round of discussion. This further strengthens and validates the lines of communication.

Developer diaries, therefore, offer an interesting way to engage in an ongoing, profitable discussion with users. So why don't other products release these? Developer blogs (for those companies that allow them) sometimes touch on the same information to a point, but I cannot recall any as focused on a particular area of the design or detailed about the design thinking.

Interviews with developers (including game developers) and case studies in presentations or articles touch on design rationale, but seldom present a detailed picture. In my own consulting, I provide a design rationale for user experience designs and sometime describe the path leading to a given design for my clients. I find that sharing this background helps facilitate discussions with stakeholders. Still, even I typically convey these in a few bullet points, call outs, or a short paragraph.

The resulting discussions that developer diaries (and even my limited form of this) generate lead me to conclude that the benefits of sharing this information are many, although I admit to a bias for open, free-access communication. I can certainly imagine the arguments against talking about the design process. The first one that comes to mind is that companies might consider such discussion proprietary.

I'll leave you to think of others, but let's consider this one a bit. With very few exceptions, most companies cannot innovate in a vacuum. Consider, as a corollary example, difference that published research can make across products compared to patented proprietary technologies. Certainly, the originating company benefits in the short term from patents. Published research that describes the process not just the end results, however, generates extensions and refinements of the idea that can benefit everyone, potentially even the originating organization. In the extreme, restricting access to discoveries can actually stifle innovation. (Some interesting reading addressing this last point include The Gridlock Economy by Michael Heller and Open Innovation: Researching a New Paradigm, edited by Chesbrough, et. al.)

If this comparison stands, sharing design rationales and background (effectively publishing design research) offers the potential to raise the standards for UX design across not just throughout related companies, but across industries. The free feedback and discussion that developer diaries generates open up communication channels between users and developers. This communication, in turn, regularly generates new and fresh ideas leading to innovation.

As a UX designer, I personally learn a lot from reading the background of a successful design — more than I would just from merely emulating the design itself. I wish sometimes that I could share more of my own design rationales with peers for critique and feedback to improve it and to pass on anything I think served its purpose particularly well. Even though my contracts usually prohibit such public openness, I think that I may be more disciplined in keeping a designer diary, beyond just a few bullet points, in future projects.

What are your experiences with this? Do you keep some type of design diary, even for your own later review? Do you share your design thinking? With whom? How much of it? What concerns do you have about sharing your design thinking?

[Davin Granroth]

Hi Karen…I used to lead a web design team at a major university, and we were aware of a developer diary kept by a web team from another university. Topics from their diary prompted discussions amongst our group, and one of my employees wanted us to start our own developer diary. We never did…I think it was more about lack of time (thereby, lack of priority) than lack of willingness.

However, while I haven't brought the idea to my management, I suspect that in my current design job, our work is considered too proprietary and sensitive to be so public about it. I'd guess our execs would see it as a threat to intellectual property.

That said, I do think it would generate some really interesting responses from our customers, and in my opinion, it could really pay off.

There are so many questions though, like do you bother posting about developments that may never see the light of day in an actual product release?

I could see writing about a recent round of research we did on navigation for a yet-to-be-developed customer-only website. This could benefit from further ideas from our customers and it would help those who participated in the research feel included in a feedback loop with us.

Neat post. Thanks. I may bring this up with my boss.