Thursday, February 16, 2006

Software Development's Evolution towards Product Design

Occasionally, some poor fellow at a dinner party makes the unfortunate mistake of asking what I do for a living. My initial (and quite subdued) response is that I help design software for artists.

Then comes the inevitable question, “Oh, so you are a programmer?” A gleam appears in my eye and I no longer feel obligated to blather on about the rainy weather. With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim ‘And that is what I do!”. This admittedly selfish exercise usually keeps everyone involved merrily entertained until dessert arrives.



Download the printable PDF version

After dozens of napkin defiling lectures, I’ve put together an extended PDF of my sketch for download. In short, we have a one page infographic that explains:

  • The evolution of software development over four distinct eras.
  • The key goals of software development and our saddest failures
  • Where software development is moving in the future.
The diagram also contains a surprising amount of poo. But then, that is the bigger lesson lurking within the scrawls. Much of what software developers create fails to serve the full spectrum of their customer’s needs. The funny part is that the usually non-technical folks that I’m talking to laugh heartily at this point…they know exactly what I’m talking about.

You can download the full PDF here. Print it, share it with your friends. Read on to hear how we got to this point.

The Technocrat Era: Programmers serving programmers


At the dawn of software history, programmers wrote software for other programmers. This was a golden era. Life was so simple. The programmers understood their own technical needs quite intimately and were able to produce software that served those needs. The act of software development was a closed circuit. A programmer could sit in a corner and write code that he wanted. By default it also happened to apply to other programmers.

Programmers that grew up in these idyllic days still remember it fondly. There is still the programmer who will claim that all they need is EMACS and the latest version of GCC to make great software. For software intended for a highly technical audience, they may well be right.

The Early Business Era: Programmers attempt to serve others


The end of the Technocrat era was came about due to a startling discovery: the vast majority of the world was composed of non-technical people. Artists, accountants, authors, history majors and other unexpected consumers roamed the prehistoric landscape outside the hallowed engineering halls.

A new class of software entrepreneur called a ‘business man’ came into existence. This new creature realized that the hordes of non-technical people had their own needs that might be served by a well written program running on one of these new fangled “personal computers.” The business man gathered programmers and told them to build software to solve things like balancing budgets or writing letters.

The software products that the programmers created were technical marvels. They provided practical benefits far beyond what was available. VisiCalc revolutionized finance. WordStar and WordPerfect forever changed the act of writing. Even the Quantel Paintbox changed the world of art.

And yet the recently converted users, who couldn’t live without the efficient, powerful and technically amazing new software, were curiously ambivalent. They liked what these new products did from a practical standpoint, but found them to be confusing and often quite irritating.

You see, the programmers treated their customers just like programmers. They made them memorize crazy expert keyboard conventions and loaded the product with dozens of obscure features. This is what the programmers wanted out of a piece of software, so they assumed that the customers must want the same.

Unfortunately, the customer needs were a different beast. Their needs could be roughly divided into two categories:
  • Practical needs: They wanted a product that worked. For example, the product obviously needed to save time and money.
  • Emotional needs: They also wanted products the possessed less tangible benefits. They wanted applications that treated them with kindness and understanding if they made a mistake. They even wanted to use products that were attractive and conferred status. The customers desired programs that appealed to the softer aspects of their humanity.
When emotional needs were raised, the programmers quickly determined that the customers were indeed “nuts.” The pure technocrats simply did not possess the broad skill set necessary to comprehend, never mind serve, the customer’s unexpectedly important emotional needs.

The Late Business Era: Programmers and artists meet and do battle


The software market had become quite competitive at this point. Business folks, experienced in the Jedi wisdom of more mature markets, reasoned that perhaps serving emotional needs could give their companies an edge. A few companies experimentally hired non-programmers such as artists, marketing and usability dabblers. I use the term artist quite liberally here since it captures that charming, hand-waving vagueness of all classes of “people people”

Oh, the suffering that resulted. The inevitable culture clash was a bit like unleashing wild dogs upon one another and then watching them sulk afterwards.

None of the freshly introduced team members spoke one another’s language. The artists talked about fluff like color and mood. The marketing people made outrageous requests with zero comprehension about technical feasibility. The programmers were suddenly enslaved by bizarre, conflicting feature demands that they did not understand. “Make it friendlier” translates poorly into C++ code.

Let’s take something as simple as making an interface more appealing.
  • The artist would whip up a picture sporting rounded corners and more pleasing colors. They’d send it to over to the programmer with a hand scribbled note “Make this.”
  • The programmer then would either A) State that an infinite number of programmers could never finish such a technical abomination or B) Recreate the image using rectangles and the preexisting color scheme.
  • Everyone would then rage at one another about their general incompetence.
In these battles for dominance, the winners lost horribly. If the programmers got the upper hand, they produced software that, despite great technical accomplishments, was ugly, difficult to use and no better than currently existing products. If the artists got the upper hand, you ended up with lovely products that didn’t do anything worthwhile.

The best products came from those odd teams that managed to compromise. The technology was clumsy and the emotional benefits of the software shaky. But it was better than the crap that customer had to put up with before. The original Mac OS was a great example of this. Later versions of Windows also managed to address a few emotional needs.

The Product Design Era: Can programmers and artists learn to work together?


The clock of progress has moved forward once again. The competition ratcheted up one more notch, and it appeared evident that companies that fail to master the lessons of the last era would be punished by the customers. Our battle scarred software companies were left looking for a better way.

Obviously, designing for emotional needs in addition to technical needs was a winning evolutionary strategy. In the last era however, mixing multiple potent skill sets together left organizational and cultural wounds that often were difficult to heal.

The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in black despair. Many groups were so busy protecting their domain that it was surprising that software got released at all. Release dates slipped by multiple years as the development talent stagnated is a cesspool of misplaced process.

What was needed was the most dramatic of transformations: A change in the cored development process. What made it difficult is that original culture of technocratic software development would need to evolve to support a broadly humanistic approach to product design.

The lead users of the Product Design Era
This change found root, as is the case for most dramatic transitions, from the most unlikely places.

There is a concept in product design known as the ‘lead user’[1]. This is a group of users that solves a difficult program far ahead of the mass market. Often they’ll cobble together their own tools and discover fundamental process and technology issues years in advance of mainstream users.

The old joke about writing Shakespeare with infinite monkeys randomly typing on typewriters got it all wrong. Instead give me a million customers trying to do their job with broken tools and one of them will stumble upon a process that is truly better. By watching the edges of the market place, we gain great insight into the direction that the larger market will take in the future.

The lead users in software development came from several widely divergent areas.
  • The first was the game industry. Here, small cross functional teams built products focused entirely on serving emotional needs. Due to intense competition and vicious delivery cycles, many teams were forced to innovate far outside the traditional software development methodologies.
  • The second were companies like Apple that followed curious ‘design’ philosophies more similar to that pursued by consumer good companies than software companies. What do shampoo companies and software development have in common? A remarkable amount it turns out.
  • The third were web design companies. Due to the low cost of entry and the early emphasis on the web as a marketing medium, the web design market is dominated by tiny, hungry graphic design firms. They brought with them a culture of small teams, close collaboration between artists and programmers, and a nearly slavish devotion to serving their customers.
What the next era looks like
Each of these lead users follows a variant of what is broadly known in more mature industries as “product design.” They see software development not as a pure technical exercise. Instead they look at it as an integrative process of building a new product that solves both their customer’s combined emotional and practical needs. Even when forced to use a “technically inferior” platform, the religious devotion to rapidly and effectively serving customer’s complete spectrum of needs make their product offerings more attractive than the competition.

Robert G. Cooper, a well known researcher on new product development, states that there are several core factors [2] (listed in order of importance) for any successful new product design process:
  1. A unique, superior and differentiated product with good value-for-money for the customer.
  2. A strong market orientation – voice of the customer is built in
  3. Sharp, early, fact-based product definition before product development begins
  4. Solid up-front homework – doing front end activities like market analysis well
  5. True cross functional teams: empowered, resourced, accountable, dedicated leader
  6. Leverage – Where the project builds on business’s technology and marketing competencies
  7. Market attractiveness – size, growth, margins
  8. Quality of the launch effort: well planned, properly resourced
  9. Technological competencies and quality of execution of technology activities.
Many companies in the Late Business era already emphasize a few of these factors. However, there are some differences. Notice how technical competencies are important, but last on the list. Notice also, how that creating a solution to customer needs is first on the list.

Software companies that understand product design tend to pour their efforts into the following activities:
  • Focus on a unifying team goal built around customer needs. They ensure that the product is always driven by customer needs, not internal whims.
  • Work together in cross functional teams. They build an organization that encourages the sharing of skills to promote problem solving. They discourage the formation of silos of individual ‘experts’.
  • Communicate clearly with a process that applies to all team members. They build a commonly followed process includes both fuzzy front end activities like design and production activities like coding. This process forms the language that unifies disparate groups.
  • Work efficiently with design friendly tools. The team avoids custom coding and ‘tossing it over the fence’ by adopting tools that work on common data format across all skill sets.
Benefits of a product design philosophy
The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.

Some of the highlights of a strong product design include:
  • Create highly competitive products that achieve market dominance.
  • Save money by focusing on the right features that bring customer value, not low yield ‘nice-to-have’ features.
  • Create passionate customers that accelerate the spread of your marketing message.
To the losers, the success of their rivals appears miraculous. “How is it that a slow web app can take away market share from our superior desktop application?” they ask in surprise.

The answer will be simple. The successful company identified the correct emotional and practical needs of the customer and poured their efforts into serving those needs. The richer companies - flush with silos of ‘wise’ experts - fought with one another and threw random features at the customer. It is rarely about doing more; it is about grokking customers and doing the small set of correct things necessary to succeed.

Dangers of the Product Design Era
As with any process transition, some groups are adopting these techniques slower than others.
  • Even within game development there are huge swaths of publishers and development teams that are ignorant of techniques used to incorporate market research, concept testing and new-to-the world innovation into their process.
  • Many web developers still create new products by following their ‘gut’ without clearly identifying their ultimate customer.
  • Most traditional desktop software developers are just barely escaping the Late Business era of functional silos and warring factions.
Most laggards who hold desperately onto their aging processes will die off in the face of advancing competition. Those with larger war chests merely buy a small period of additional learning time.

Unfortunately, many companies that attempt to adopt a product design philosophy will also fail, despite their best efforts. Cultural change is hard work. To adopt product design you must alter the most basic DNA of the company’s values.
  • It involves asking vice presidents to give up their empires that they’ve fought decades to establish. What is the point of an organization of engineers when engineers are all just members of small cross-functional teams?
  • It involves asking the men and women in the trenches to give up their own dreams of building their own empires according to the old rules.
  • If the ultimate reward of the old system is an isolated corner office with windows, try convincing people to work together in a common war room that has walls covered with whiteboards.

Such traumatic change is absolutely necessary. If you want to make great products for happy customers, you need to make the transition to a broader product design methodology. We may have once been a clique of technocrats. But now we must take our place in the broader society by providing human solutions to the very human customers that we serve.

Dessert
After I’m done drawing all this out on my little napkin, I point to one of the designer fellows in a beret and say, “See that guy? That’s me. I work on a team full of crazy, wildly talented people trying to make the world a better place. We make products that you can love, not just products that you use.”

Folks nod. They get it. They like the idea of software that not only works, but makes them feel good about using it. At one meal I was sitting with an older woman who listened most politely to my wildly gesticulating explanation of modern software development.

At the end she said, “Well, it is about time.”

Take care
Danc.

PS: This cute little illustration was done in a program I'm busy renovating called Expression Graphic Designer. It will be part of a suite of design friendly tools that seeks to ease the bloodshed between programmers and their more artistic team members. You can't build a cross functional production pipeline without the right tools.


References and Random Clippings

Edit: Added reference numbers to a couple of data points so the connections are more clear.

43 comments:

  1. Ah, always nice to visit this site when spacing.

    The Programmer looks very much like...well...a programmer! I wonder who the Designer resembles...hehehe.

    Ok, enough for now, back to work!

    ReplyDelete
  2. Nice visuals. I’ll have to check that program out.

    I just finished reading two books slightly related to product design this week—“On Intelligence” by Jeff Hawkins and “When Ideas Start To Think” by Neil Gershenfeld. I’m fairly new to the subject, but they have wet my pallet quite a bit. Got any good product design book recommendations?

    -Sage

    ReplyDelete
  3. Thank you for this article. I've been reading for a while, but as a programmer I didn't have much to identify with outside of the consumer aspect. This article, on the other hand, impacts me directly.

    I serve as the Sr. Developer and Lead Designer for my company's main product (a blend of your programmer and green beret), and because of that I don't do a great job as either. I'm going to share your diagram with my team and hopefully show them where we've been going wrong all this time. Thank you and I hope this influence can help my company get back on track and deliver an outstanding application.

    ReplyDelete
  4. A friend sent me the PDF, and I'm glad I wandered over here to read the entire article. You nailed it. Nice work.

    ReplyDelete
  5. nice article, but because it was designed for a larger screen than this laptop i was forced to copy it into a text editor to read it. ironic don't you think

    ReplyDelete
  6. Interesting. This is a good example of a customer interaction in progress. :-)

    The Design Intent (which is rarely the reality)
    - The website is designed so that both the side bar and the article are readable at 1024 x 768.
    - The article should be readable at 800 x 600 (I'm running that right now on a laptop)
    - The images in 'large' mode are 800 pixels wide, which barely fits on the 800 x 600 display.

    My target audience was 1024 x 768 and above, but the site was designed to be useable on small screens if necessary.

    Design Reality
    - Question, what resolution are you running at?
    - Which aspects of the article didn't come through?
    - Which browser are you using?
    - Did you maximize your browser window or is it only using part of the screen?

    take care
    Danc.

    ReplyDelete
  7. This is a must read for anyone in the software industry. I'm blown away.

    You've also captured just exactly it is that Steve Jobs & Jonathon Ives at Apple do and why most of the rest of the industry can't figure out why it works.

    Thanks.

    P.S. As I was posting this as anonymous and looking at the Word Verification I had to laugh. Ironic. :P

    ReplyDelete
  8. Can you elaborate on what you mean by "production pipeline" and "design tools"?
    What processes/software would constitute a production pipeline and design tools?

    Could you give an example of a tool that "work on common data format across all skill sets" ?
    Thanks

    ReplyDelete
  9. Danc,

    Outstanding! Got a lead on this from over at the Joel on Software/Business of Software forum. (http://discuss.joelonsoftware.com/default.asp?biz.5.310394.2)

    Now, how does a micro-ISV (1-5 person, self-funded, internet-based, software startup) apply your insights?

    ReplyDelete
  10. Interesting read!

    The article is very well written and I enjoyed reading it.
    I don't think anyone has put it quite that way before.


    -Satheesh

    ReplyDelete
  11. A very good article for product development ! I bumped into this thru joel on software n thank god I did !
    Enjoyable to read conveying the message at the same time ! a programmer can get loads of inputs starting here itself (from the way this article is written) ....

    Good Work !

    ReplyDelete
  12. off topic: I was reading the article until realised that I'm missing diagrams. They so looks like banners!

    ReplyDelete
  13. Nice piece. It could use more thinking through of what precisely you mean by "deliver superior, unique benefits to the customer." In one sense, this is the sort of thing that is obvious ex post facto, and that apply to stage II landmarks such as Visicalc. In other words, it sounds a little like you are saying "the most important thing in making great software is to make a great product."

    I think you want to say something about how you frame the problem the software is trying to solve and how you envision the solution, but that's not clear from the language you choose. I'm also not sure that the "voice" of the customer is really what you want to build in. Most essays about great design emphasize that they create something new--that they answer a question that may not have been asked.

    See also recent posts at www.joelonsoftware.com

    ReplyDelete
  14. Regarding, "The website is designed so that both the side bar and the article are readable at 1024 x 768", I notice that is the case in IE and Safari, but interestingly, not in the current Mozilla line of browsers Firefox and Netscape. The article column is much wider in the latter browsers than in the former; a little more than half the sidebar is visible at 1024 x 768 screen resolution.

    ReplyDelete
  15. always fun to read stuff from another Cooper fan

    don't you find that marketers are at least as likely to produce bizarre product design demands as software engineers?

    in my own experience as a product marketer (admittedly very focused on media products), the engineers are the ones more likely to ask the hard, canonical product-design questions about use cases, user contexts, emotional resonance the product is supposed to have, etc.

    whereas Web-software marketers, in particular, too often start from the right standpoint - the user-centric stuff mentioned above - but then their aesthetic short-circuits the connection between that user-centric stuff and good product design

    again, this is only my own experience, but because the software engineers i've worked with have been adamant about the importance of separating the articulation of requirements from assumptions about their implementations, they're also far better at seeing the DESIGN of the product, in its aesthetic aspects, from the same standpoint

    ReplyDelete
  16. Enjoyable essay. Will share it with business friends and colleagues.

    I have an arts and a computer background, so I'm comfortable with both the arts and the technical folks. But maybe it's past time for improved process with, in our case, Biz Gal. Few of us can speak her jargon at her speed.

    "Oh, the suffering that resulted. The inevitable culture clash was a bit like unleashing wild dogs upon one another and then watching them sulk afterwards." "Cultural change is hard work. To adopt product design you must alter the most basic DNA of the company’s values." So true! Thanks for the perspectives. Hopefully, they will help us make more of the transition from clash to change.

    ReplyDelete
  17. I started out with a science (physics) and art background. I picked up enough CS to make programmers laugh with me instead of at me. But business eluded me completely. My ideal was the world of the Scandinavian demos coders...cool wasn't measurable, it was just something you knew instinctively. Money was the anti-christ.

    Finally, after creating multiple products that struggled financially, I bit the bullet and got my MBA. What an incredible eye opener. A business education is no panacea. It does however, provide a very useful grounding in economics and entrepeneurship. If engineering is concerned with the pragmatic mechanics of physical systems, business is concerned with the pragmatic mechanics of human systems and the exchange of value...not in the scientific manner of a psychologist, but a practical manner of a craftsman who has been practicing his art for ages.

    They ask questions like "how do I make people buys something?" Over many years and countless mistakes, techniques abound. None of them are perfect, but they are a useful. When a product like the iPod comes into existence, a good business man will not treat it as a bizarrely inexplicable occurance. They don't assume that Apple 'got lucky.' Instead, they dissect the process used to create the market busting product. Again, they are pragmatists. It does not matter to them if the lessons they learn are technical or psychological. They record them and use them to their advantage.

    I remain an artist at heart. However, the tools of the business man (or woman) are an invaluable addition to anyone's knowledge. (At the very least, it allows you to communicate why choosing the correct shade of white for your music player is really a rather important decision. :-)

    take care
    Danc.

    ReplyDelete
  18. > Kadimiros said...
    Regarding, "The website is designed so that both the side bar and the article are readable at 1024 x 768", I notice that is the case in IE and Safari, but interestingly, not in the current Mozilla line of browsers Firefox and Netscape. The article column is much wider in the latter browsers than in the former; a little more than half the sidebar is visible at 1024 x 768 screen resolution.

    Yeah, I get that with Camino too. (A Firefox derived Mac browser with looks and speed.) Odd to see IE and Safari getting something right when Mozilla doesn't!

    I see that this article has been getting great reviews. Note to Danc: use graphics regularly!

    ReplyDelete
  19. Interesting read, and fairly cute too. One quick comment though: "programmer" is spelled wrong a few places :-) whoops!

    http://lostgarden.com/uploaded_images/Evolution-TechnocratEra-733552.jpg

    It has two m's.

    Thanks for sharing your thoughts :-)

    ReplyDelete
  20. "Some of the highlights of a strong product design include:

    Create highly competitive products that achieve market dominance.
    Save money by focusing on the right features that bring customer value, not low yield ‘nice-to-have’ features.
    Create passionate customers that accelerate the spread of your marketing message. "
    Um I could be wrong but does this actually mean something? Or is it just a commercial? What does a "highly compettive product" look like when I am working at an auto manufaturer for example. Where is the line between cunstomer value and 'nice to have'? Passionate cusntomers??

    ReplyDelete
  21. "Odd to see IE and Safari getting something right when Mozilla doesn't!" Well, it could be one of those things where browser makers interpret HTML or CSS standards differently, possibly legitimately.

    Hmmm...It has something to do with the the References section of the article. Some browsers have wordwrapped the longest link ("Development of Mac Paint") to fit, while others expand the width of the container.

    I use Firefox extensively but stopped recommending it to clients because of a printing bug that happened to impact a mission critical application.

    ReplyDelete
  22. Great article - really enjoyed it. On the strength of it I tried subscribing to your feedburner feed (that was the only feed link I found on the page), but it appears that feedburner objects to your page at the moment... :-(

    ReplyDelete
  23. Such a great article. Nice and concise. But what does it have to do with game development (as distinct from application development)?

    I get that this sort of approach is a way to build a better app (like the way that Itunes is so much better than Winamp despite them both doing many of the same things), but games are a bit different than apps in several ways.

    One being that games are built to restrict you and provide entertainment through surprise and challenge that comes of restriction. In any customer consultative process, the goal is to make their usage of the product more accessible and more convenient. They come to love the product.

    But is that actually what they want from a game? Design-for-customer versions of RE4 would be likely to drop the no-strafing decision, for instance, because it intentionally makes the customer's life difficult. Design-for-customer Chess is likely to lose the Knight piece in favour of something more apparently useful, especially if this is in the early stages of the game's development before its full use can be completely understood.

    You see, this is my central issue with this kind of thinking: I'm not so sure that games qualify as products. In the same way that I don't view any other form of art or entertainment as a product because the goal of the entertainment industry is often not to please the customers' known wants, but rather their unknown wants.

    Going with audience wants on a movie's development, for instance, means that the hero always gets the girl. Bye bye Casablanca.

    And that's what I'm sort of saying. The problem here is that the games industry is not a part of the software industry which happens to do entertainment. It's part of the entertainment industry that happens to use software. And the entertainment industry is notoriously resistant to systemic methodologies and not for the want of trying either.

    ReplyDelete
  24. Tadhg, I think you're not giving the non-entertainment industry enough credit. First, every industry deals with a customer's unknown wants. History is filled with successful products that simply fulfilled a niche no one thought of before. ("Only six computers will ever be sold in the commercial market." -Howard Aiken) Second, your design-for-customer thoughts are flawed because they treat difficulty as something simple to be eradicated, which isn't the case.

    Let's see how difficulty factors into applications and games. Difficulty measures how hard it is to complete goals. There are two aspects of difficulty: challenge (which the user enjoys) & frustration (which the user doesn't). High difficulty doesn't mean a bad product, high frustration does. For most products, the challenge is provided by external sources, like a report you need to write. Therefore, they concentrate mainly on reducing frustration. Games are one of the few products that combine both challenge & frustration in a single package.

    Removing the Knight piece would remove part of the challenge, hurting the product. Adding a strafe function to RE4 would remove a bit of the frustration but a lot more challenge, hurting the product again. A customer could want more difficulty in the form of more challenges. However, one customer's challenges is another's frustrations. That's why focusing on a specific customer works for games as well.

    ReplyDelete
  25. Jeff,

    "A customer could want more difficulty in the form of more challenges."

    That's where I think you're wrong. One of the most difficult things in any development environment is designing for features that are not yet fully implemented because the natural instinct of people playtesting the half-completed product is to become frustrated with it.

    Now, in a car manufacturer environment, this sort of feedback is vital because the whole objective of designing a great car is one that the user finds great to use. Therefore sources of frustration are eliminated, the car becomes a better car, and the customer happy.

    The problem for a game's development is that sometimes the frustration is the point of the product, sometimes it is not. Half way through development and prototyping, *everything* is frustration, and so relying on feedback-centric results as in car manufacturing often produces destructive results.

    It is often only late in the day when design features are implemented, where the content comes together, that the prospective customer or testing group can start to distinguish frustration from challenge. The Knight makes perfect sense once you can see all the other pieces and the board and actually play a game. By itself, it looks a bit pathetic.

    And that is the problem with entertainment in general. Unlike a car or a beer or a tube of toothpaste, the goal of the entertainment industry is to produce emotional reactions in the audience that are pleasant and unpleasant in equal measure, and yet it is often only very late in the production of any piece of entertainment that this quality emerges or not.

    Pacing, structure, emergent effects and the other tropes of entertainment are reliant on seeing the whole and not just the parts. The use of the Knight in Chess is only apparent once you see the whole game, the lack of a strafe in RE4 only makes sense in the context of the game's environment. They are inter-dependent.

    This is completely different from the goals of software application design. As I said, Danc is right on the money if he's talking about an Itunes vs a Winamp, because the goal a product-oriented goal.

    But the games industry is NOT the software industry. It's not a "product" industry because what we do is based on a sort of interdepence of elements that are at their best when they both enrage and enchant in equal measure.

    ReplyDelete
  26. The argument that games are not products, but instead holistically created entertainment that is harvested from rare crops of creative geniuses is a commonly held opinion.

    I suspect, it is the intellectual equivalent of intelligent design. "I cannot imagine a process that allows me to target customer needs, so therefore games must be created by visionary." I mean no insult by this since it is a common human response in the face of a non-obvious problem.

    Tahg, the idea that feedback based improvements to an existing design is impossible goes against the experiance of almost every successful game on the market. Most modern games have adopted rigorous play testing cycles. Most games prototype early and tweak the game continuously. Games may appear to pop forth fully formed from the consumer perspective, but from the developer perspective, games are anything but fire and forget type activities.

    A broader definition of listening to customers
    The concept of listening to costumers is widely misunderstood, particularly amoungst technical folks. The immediate thought that comes to mind is sitting down with a 14 year old fanboy and having him rant on and on about how "guns are cool and you need more explosions"

    Customers at the middle of the market tend to be extraordinarily poor solution designers. "Listening to customers" mean digging into their unspoken desiress. You can use surveys, interviews, public prototypes, testing labs and more. Rarely however, do you take the comments at face value. You use your expertise to seek broader underlying trends that can be distilled into a useful model that guides development. The developers still generate the solutions to these desires using their expert knowledge.

    Many game companies already practice customer focused game design. Here is a fun question. Assuming teams of equal technical skill, who will make the better game
    - A team that has full access to customers for play testing, initial concept reviews, etc.
    - A team that is locked away from all external contact for the entire length of the game development (including concept generation)

    It reminds me of early thoughts about where mold comes from. The predominant theory of the time was that mold was spontaneously generated in food. Then some clever fellow put the food in a closed container and waited for spontaneous generation to occur. It didn't. It turns out that the air around the bread was wafting spores from the outside onto it.

    Listening to customers is already part of our industry. We just happen to do it by osmosis, reading magazines and playing other games. The result unfortunately is that we have very little conscious knowledge of what we suck up. Consciously seeking information about customer needs not only improves the quality of the information you recieve, but it also lets you filter out the fanboy drek that clogs the airwaves.

    Games are a product sold to customers. There are tools and techniques from other industries that are applicable. Simple enough, though perhaps new to our young industry.

    take care
    Danc.

    ReplyDelete
  27. "The argument that games are not products, but instead holistically created entertainment that is harvested from rare crops of creative geniuses is a commonly held opinion."

    It may well be, but that's not exactly what I said.

    What I said is that entertainment *in general* is a kind of work where results are sketchy in half-complete cases, and that's because the goal of said entertainment is not founded on one sense of experience. There are different aspects to them that normal product design doesn't really address. Like the fact that they often set out to make us feel *bad*, and we laud them for it.

    I don't recall every hearing of a car that was intentionally designed to make anyone feel bad. The problem is not that it's a quality hoarded and understood by only a few geniuses. In fact, it's the opposite. It's understood by no-one. Most artists talk about the mystery of art in one form or another. As William Goldman famously coined about the movie industry, 'Nobody knows anything.'

    Some creators create their great works by complete chance, some are on again/off again in terms of form. Some novelists strike genius and then turn around and write absolute pap for sequels. Nobody knows ANYTHING. And that drives the would-be product designers of the world abolsutely screamingly mental because, let's face it, it sounds like bleeding voodoo.

    Voodoo indeed. And yet the proof is all around us. The vast majority of movies made by commitee and audience testing STINK. The vast majority of books written according to a market dictum likewise. The vast majority of games created within a corporate production environment that adopt most of the practises that you describe are ball-less, soul-less pieces of shit that are forgotten in a weekend.

    And guess what, the majority of from-the-heart books, films and games also stink. But not so much.

    Not like the ipod. Not like Coca-Cola. Not like SmartCars or Macs or certain items of gaming hardware like the DS. We relate to the ephemera of media in a fundamentally different way to the way that we relate to things. Things are quantifiable, understandable, and People Know a Great Deal about them. In the media, Nobody Knows Anything.


    "I suspect, it is the intellectual equivalent of intelligent design."

    You suspect incorrectly.

    It's the practical experience of many a writing teacher or painting instructor before you. Both can teach technique, but Nobody Knows Anything about why the greats are great and the stinkers stink. There is no recognisable formula (or, as I once red, there are three rules for writing a great novel. Unfortunately nobody knows what they are).

    The only reason that it's not the practical experience of many a game design scholar is simply that we haven't really had the chance to discover it yet. The game's gone from the silent movie phase to having just discovered talkies. Everyone's terrified of the costs involved, and so methodologies are the first port of call thereafter.

    Basically, we haven't really attained a body of wisdom yet (as distinct from a body of knowledge) or a means of valuing self esteem, so this attempt to rationalise the process to a set of understandable abstractions (which is basically what you're doing) is a perfectly understandable move. I maintain, however, that it's a sign of systemic immaturity to think this way, and that the problem is not one of learning how to treat our audience as pleasure-seeking drones, but to treat them as intelligent human beings who are a lot smarter than we usually give them credit for.

    In that vein, the first duty of an entertainer is to be honest, and that requires a quality from developers which they are heretofore unfamiliar with: introspection. Game development up until now has pretty much all been the dog and carnie show routine of a circus. But even the circus has an underside and a pathos. This is the quality that we lack.

    Applying the 'which perfume smells better, what are you looking for in a perfume' school of thought to game development is a perfectly rational means of escaping from introspection. Hell, presented in the right way it even seems kind of noble, empowering even, to present that as a vision of the future. The problem is that it doesn't work.

    Especially not in an age of niche markets. You blogged a while back about the idea of the touring band (your best article to date imo, btw) and the development of niche markets. You wrote that community building is very important, customer service is very important and relationships are very important in that framework. And you're right. But in later articles you seem to have missed WHY they are important. You assume that the relationship is one of providing the right product to fill the right need.

    This is incorrect. Niche customers (or intelligent adults as I like to call them) come looking for specialist experiences not because they want to be best served. It's because they want to find something that feels honest, which those things in the limelight rarely have. They go looking for media that don't make them feel like targeted drones. It's the very un-product feel of the stuff that draws them to it in the first place, and hallelujah be praised the internet gives the means to do it.

    "Tahg, the idea that feedback based improvements to an existing design is impossible goes against the experiance of almost every successful game on the market."

    No, it depends on the point at which that feedback is brought into play. I've seen it first hand. Feedback introduced too early is EXACTLY like a novelist's half-completed first draft getting edited to buggery and back. It causes generalisation, platitudes and blandification, followed by political support from within the company from those people that brought the feedbackers in in the first place.

    On the other hand, all novels need to be edited. But editing works best in the proper order, i.e. once the novelist has had a chance to present a completed structure (i.e. iterative drafts hammered out into a book), THEN it becomes obvious to the editor not only what the novelist is not doing well, but what it is that they are trying to reach for.

    It's exactly the same with games. Of course feedback is important, but at the right time. Once the gameplay is in, once the controls are implemented, once the visuals and the audio are at least vaguely working, that's when you can begin to see what works and what doesn't. It's the Knight and Chess all over again. When you've gotten to that point, you can begin to distinguish the structure, the intent and what makes it better. Too early is like the too-early novel. Everybody only notices the gaps.

    "Most modern games have adopted rigorous play testing cycles. Most games prototype early and tweak the game continuously. Games may appear to pop forth fully formed from the consumer perspective, but from the developer perspective, games are anything but fire and forget type activities."

    Yeah, I do work in development Danc, I am aware of that. The difference is that for the most part those iterative cycles are done within an internal team working on the trust that it'll come together. The single best quality that a team can have is faith in the design and the designer to pull it all together somehow, because 80% of the time it all looks like a big pile of shit that no-one understands (including to the designers, in private).

    And by the way, you really are short-changing the creative process by labeling it 'fire and forget'. It is anything but fire and forget. What is fire and forget is garbage. Mills and Boon is fire and forget. Cheap nasty cash-in games are fire and forget. Most original games are not fire and forget. They're pain. A whole lot of pain and frustration and re-working, and yeah, we could do with some better means to cut through a lot of the crap that goes on, but you're doing the people who built this industry (you know, the creative ones) a huge disservice in your phrasing and choice of language.


    "Many game companies already practice customer focused game design. Here is a fun question. Assuming teams of equal technical skill, who will make the better game
    - A team that has full access to customers for play testing, initial concept reviews, etc.
    - A team that is locked away from all external contact for the entire length of the game development (including concept generation)"

    The latter. I'd say it depends entirely on the creative talents of said teams, the personal politics within them, the ambitions of the people involved and their interests. Games are an entertainment field and those are the qualities that make entertainment. Technology is just the way that we get there.

    Here is another fun question. Name some games that have been designed from scratch with customers present all the way from initial concept review and see which ones have done well in the marketplace and remained in the public consciousness for longer than a Christmas. Because I don't know of any.

    I know of quite a few that have brought customers in late in the cycle to help see the problems that the team cannot see because they're too close to it. Some of those have been very successful games. Most haven't.

    "Games are a product sold to customers. There are tools and techniques from other industries that are applicable. Simple enough, though perhaps new to our young industry."

    And until we realise that they're an entertainment product, where the rules of the road are different, we're just gonna keep on assuming that making better games is like trying to build a better bar of soap and then wondering why people don't care for the suds.

    And to finish this ridiculously long reply, a pithy quote:
    "Write something to suit yourself and many people will like it; write something to suit everybody and scarcely anyone will care for it."

    ReplyDelete
  28. This really seems pretty selfevident.

    In the very least, listening to customers helps prevent a developer from developing a big pile of poo.

    And considering the number of "piles of poo" software customers are willing to purchase, the fact that NON-"piles of poo" sell better or are more popular, really should come as no surprise.

    Then again, I think Danc's missing a component of development which is the debug cycle... while lead customers tend to prime the pump, it sure would be nice if some of this non-pile-of-poo software worked the way it was designed to work all the time. :)

    --Ray

    ReplyDelete
  29. But writing for yourself is the whole idea behind Stage I (by programmers, for programmers) and a root cause of gaming audience implosion. (If hardcore gamers make games for themselves, where does that leave casual gamers?) It is possible to write games for customers without pandering to a generic mass: in On Writing, Stephen King says when he writes his novels, he writes them for a single Ideal Reader, a person whose reaction he's constantly thinking about. As he says, "Someone once wrote that all novels are really letters aimed at one person."

    So why not designate an Ideal Player and consider whether he would enjoy this game? That would keep your view focused but prevent obsessive introspection. Danc has already posted a great example of this:
    http://lostgarden.com/2005/06/space-crack-why-space-crack.html

    "I have a friend named Ray. He is quite a bit over 30, has a wife and some kids. He grew up in the glory days of PC games, but the market has changed and so has his life. He still wants to play games, but there is very little on the market that fits his needs.

    "He has a craving for a simple turn-based strategy (TBS) game that he can play against his friends. Unfortunately, the number of polished strategy titles on the market is A) depressingly slim and B) targeted at people who have far more spare time than Ray does. For Ray’s sake and all the millions of people just like him, let’s create a casual internet game that brings back the ‘sitting around the table’ beer and pretzel game experience."

    ReplyDelete
  30. "In the very least, listening to customers helps prevent a developer from developing a big pile of poo.

    And considering the number of "piles of poo" software customers are willing to purchase, the fact that NON-"piles of poo" sell better or are more popular, really should come as no surprise."

    As I said already, when brought in for feedback at the proper time, yes of course they do. Brought in from scratch, on the other hand, they really don't. In entertainment, the voice of criticism or feedback, however constructive, can be the thing that kills an original idea stone dead.

    And again, this is another reason why using analogies of how the software industry works don't really apply. The games industry isn't a branch of the software industry.

    ReplyDelete
  31. "But writing for yourself is the whole idea behind Stage I (by programmers, for programmers) and a root cause of gaming audience implosion."

    No, it's different. The games industry isn't the software application industry, and the whole objective of designing games is not the same as designing a tool that does something in a particular way.

    A good example is Elite. Elite was a game conceived of and created by two guys (Braben and Bell) in the mid-80s off the back of their love of spaceships, astronomy and the Traveller roleplaying game. They wrote it for themselves, basically. It's not a tool, it's not a customer-designed application. It is, however wildly popular and spawned a generation of fans.

    Interestingly enough, as Braben in particular developed his career, he returned to the idea again and again, but eac iteration became more of an exercise in programmer-fu, like a novelist who keeps working on the same series of books for just a bit too long. Frontier was pretty good, and if lacking something of the spirit of the original game, it had some charm in other ways. First Encounters, on the other hand, was awful, clunky and dull.

    As Braben moved further and further away of the original spark of the idea, of the love from which it created it and turned it more and more into a product, an early attempt at a franchise I guess, the worse the game got.

    It's a similar story with many games. The original FIFA way back on the megadrive/genesis was actually a pretty nifty little whose controls were a bit admittedly fudgy controls, but still a charming game. The modern FIFA, which is designed from the ground up with customers in mind, focus groups and whatnot, are awful, soulless affairs that probably cost millions to make and sell millions more thanks to the brute force of marketing campaigns. It's a regular money spinner, but no individual version of it is memorable or desirable.

    So that's the difference. Does it mean that a lot of games created in the 'write for yourself' mode are poo. Of course. The majority of films, novels and albums, however much created from the heart, are indeed poo. It's just unfortunate. Applying product design methodologies right from the start just kills the small ratio of those ideas that actually are worthwhile.

    Maybe we just don't love ourselves enough or something :)

    "(If hardcore gamers make games for themselves, where does that leave casual gamers?) It is possible to write games for customers without pandering to a generic mass: in On Writing, Stephen King says when he writes his novels, he writes them for a single Ideal Reader, a person whose reaction he's constantly thinking about. As he says, "Someone once wrote that all novels are really letters aimed at one person.""

    A lot of novelists do that, but it is just a version of 'write for yourself'. It's creating in the vein of entertaining someone. It's not getting that someone in and having them consult on the thing thatbeing created for them. If a stage magician brought an audience member in to help them design a trick from the start, do you think that the once the trick is designed and performed, the audience member would find it entertaining?

    Does Stephen King think that if he brough readers groups in from the start, got them to do concept approval, got them to provide feedback on each chapter every step of the way and so on (basically product-designed his novel) that he'd end up with a great novel? I bet 50 dollars he thinks no such thing.

    In the same vein, I think the Ideal Player is a good idea and I think many of the most creative people in the industry do have an ideal player that they think of when designing. I do (not saying I'm one of the most creative people in the industry, just that the method is good) because it helps me analyse my ideas and think whether they work or not. I try to imagine out the effects of something that I've created on the end user, to think whether it works or not, or whether it relies too much on inferred knowledge. That's just good creative process, but it's not product design.

    I'm not the magician taking people back stage and quizzing them on whether they like rabbits out of hats. I'm the magician working front stage putting on a show and listening to feedback at the right time (the oohs and ahhs) to make the show better.

    ReplyDelete
  32. You're using Elite as an example of wildly popular? >snarfle!<

    Danc's not suggesting you ignore your own likes and wants, but you just have to understand how your personal games tend to go off on the general public.

    Some people think that we should go back to textbased games... then again, when my mom start with computers, I found it plenty entertaining watching her learn to double-click a mouse.

    Wasn't particularly profitable, alas... ;)

    --Ray

    ReplyDelete
  33. Greetings:
    So, you're telling me that your designers have such a poor understanding of your target audience, what their desired experiences are, and how they interact with the game, that you need a whole separate person to clue them in about these things? And they can't communicate these needs effectively to the programmers?

    In that case, I think you have deeper problems than process...

    Eyejinx.

    ReplyDelete
  34. Folks seem to be fixating on the 'interaction dude' and assuming that I'm suggesting that teams need to add more people in order to be success.

    What I'm saying is that teams need to:
    - Target customer needs
    - Work together, not in silos
    - Communicate clearly and openly with one another. Often this requires a common process and an integrated tool chain.

    Now where does the interaction dude come into all of this? On the teams that follow a design-centric philosophy, I've noticed that there will often be one or two people who end up bridging disciplines. Sometimes they'll be called technical artists or sometimes they are programmers who excel at the scripting and content side of things.

    So the interaction dude is not a prescription to 'add more people'. That's silly. Instead, it is a picture of what these sort of teams generally end up looking like. When you communicate, you end up find out that your team members aren't nearly as one dimensional as the silo-oriented processes claim they are. "Oh, he's a tester, all he does is test" is generally complete BS when you deal with real people with their wildly divergent interests and talents.

    Happy day,
    Danc.

    ReplyDelete
  35. Great article!

    I'm currently working in the "accessibility" universe as a programmer/designer. A very small company that aims to produce accessible applications and web pages.

    If you look at the design issues we are dealing with you might see that we're still in the "golden age" of programming still. Or maybe "early business era", on the verge to the late. We're not designing new applications that will cater to a blind persons needs, but rather taking existing designs of finished applications and then converting them to suit visually impaired peope as well (...and people with other disabilities). This is done because no company would buy an expensive application that ONLY suits blind people for example, since there are so few of them...They would rather have their existing application modified, than buying a new one for their 2 disabled employees.

    You can probably imagine the issues we're facing when trying to "change a car into a carrot". The experience of using an application for a visually impaired user is crazy-different than for seeing user.

    Point I'm trying to make is that user-feedback is amazingly important for us when designing these solutions. "WHAT works?" is the question we're asking ourselves the most, and not "what would be cool and what would the user appreciate". Those questions are far off at the moment.

    I truly see the potential though, for completely and truly accessible applications which feel awesome for both seeing and blind people.

    Wouldn't it be cool if a blind user could get emotional feedback from an application like us seeing users do?

    What kind of "artists" could help doing this?

    Would the production line need to be altered for these kinds of applications, or should they look the same as you are proposing, danc? With a mixed "lead users" group being visually impaired (all types) and seeing? If you add motion-impaired (english is my 2nd language...sry...what is it called?) to the "lead users" group, you get wildly different arguments to "what works" and "what feels good"... Should you cater to all tastes, or design different UI's to each user-group? Making a "best for most" solution isn't viable since it closes out the rest, making it non-accessible by default.

    I personally think that my area of programming has ALOT of challenges, and that all programmers should start looking into this field, because in the end, the lessons learned here will benefit all users and developers in the end.

    ReplyDelete
  36. Making a game versus any other software is a huge challenge. At the end of the day a game has to be fun - software apps do not. Yes they should both utilize good UI - menus should be easy/concise to navigate but there is that underlying theme of fun.

    When working on God of War we tested the hell out of everything - making people on the team that were different levels of gamers played it, focus test it with outside players, etc. And even though a design had merit, if it was not fun it got cut. Near the end of the game we were testing it maybe once every 2 weeks to finetune it.

    -Derek Daniels
    http://lowfierce.blogspot.com

    ReplyDelete
  37. It used to be that games had to be fun and software did not.

    This is changing as user experiance, not merely functionality becomes a critical selling point. Compare MSN search and Google search. Both are roughly functionally equivalent. Yet Google is certainly more 'fun' with it's 'feeling lucky' button and playful graphics. Such differences are critical to the user. One is charming and the other wants me to stick my finger down my throat.

    The same can be said for iPhoto and other consumer applications. The line becomes even more blurred with products like Brain Training on the DS. These are certainly software applications, but they gain success through a rather large dose of emotional impact.

    In the emotional areas of product development, games are certainly far ahead of traditional software and will be for many years. The gap is closing. Much of the testing that is done in game companies is starting to have strong parallels with user experiance testing that occurs on apps.

    Software can be fun too. By paying attention to the broad range of user needs (functional and emotional), you gain a competitive advantage.

    The challenge for games is refining it's understanding of emotional needs in a more systematic fashion. For example, there are different kinds of gameplay that appeal to different types of players...you can segment emotional needs. Wouldn't it be nice to have mental tools that helped you balance a game like Animal Crossing or the Sims to be 'more fun'?

    The testing you mention is equally important. This is iterative development at its core. How early can such a practice be integrated into development? What techniques can be used in the structure of the team to ensure that the feedback makes the biggest impact? How does all of this change the types of games that we make? Fun stuff.

    take care,
    -Danc.

    ReplyDelete
  38. Nice job. I took the liberty of referencing you from here

    Keep it up!

    Angelo

    ReplyDelete
  39. Please, give us the references for "well docuneted" facts:

    The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.

    I think that product design may replace requirement analysis in a software development process, and I try to find similar opinions. This article is the best one so far :)

    Nebojsa

    ReplyDelete
  40. Please, give us the references for "well docuneted" facts:

    The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.

    I think that product design may replace requirement analysis in a software development process, and I try to find similar opinions. This article is the best one so far :)

    Nebojsa

    ReplyDelete
  41. In our Requirements That Work seminar, we reference the role of designer and I'm astounded at how few vendors have introduced the role in their organizations. As a result, product managers end up dabbling in the design and moving from writing requirements to writing specifications. I referenced your article here on my blog. Contact me if you'd like to publish the article in our magazine.

    ReplyDelete
  42. very Useful info for the programmers and developers, In getting the work easier and faster....Software Development

    ReplyDelete