Why Great Ideas Can Fail

“Designers are proud of their ability to innovate, to think outside the box, to develop creative, powerful ideas for their clients. Sometimes these ideas win design prizes. However, the rate at which these ideas achieve commercial success is low. Many of the ideas die within the companies, never becoming a product. Among those that become products, a good number never reach commercial success.” – Don Norman

I do understand what Norman is saying here, and it’s really relevant to the games industry as well as design companies in general. The fact is that while it is fantastic to come up with a great idea, this great idea has to fit within a certain business context. Unfortunately I believe that within the video games industry this is realized at both extremes and there is no real balance of perspective.

Before Halo, there was no real console FPS to speak off, or at least none so memorable as this particular game and it at the time would have seemed like a terrible idea from a business stand point. However, as an idea, the execution and commitment to quality in the realm of video games allowed this particular idea to carve a space in popular culture guaranteeing its commercial success for the last 9 years.

But then again, this could be the phenomenon similar to that which resulted from the special design group at Lockheed Martin. In any case, the truth remains, there has to be some sort of consideration for how well an idea fits into the business life cycle. Apple’s success is completely the result of the company’s shift in focus from simply designing interesting and visually appealing consumer goods to incremental improvements on current products that already are used by individuals. Consider the Apple Newton in the picture above, and the iPad. Both were fantastic ideas, but one was designed and marketed without any real sense for the commercial success whereas the iPad was based on incremental design that grew from well established roots in popular culture.

What do you think?

The Future of the Book

Humanizing the Machine: Radical ATM Redesign

A delightful banking experience “from the moment the card goes into the machine until the moment it comes out, all the transitions are virtualized, the seamless interplay between the real and the virtual eliminates all doubts, how the bank communicates to customers is now personalized, interactive and entertaining. The result is human and tangible in a category overtaken by cold functionality.”

Software that Teaches

There is an old saying:

“Give a man a fish, and you’ve fed him for a day. Teach a man to fish, and you feed a man for a lifetime”

Too much of our software simply gives people a fish instead of teaching them how to fish. That is, most software acts as a dumb tool…can do a particular thing but doesn’t teach how to use it well.

But teaching is increasingly part of the deal…if you’re building software you might consider how to teach people to be better at what your software does. Not only give them a tool to do something simply, but actually teaches them a way to do it better.

Some software helps you organize your stuff merely by giving you an improved structure:

  • iTunes – Stores your music for you in logical ways (by artist, album, etc)
  • Salesforce – Organizes your sales process by specifying lead strength.

But some apps take it step further, actually teaching you better ways to work. This is the software of the future.

  • Mint – Teaches you how budgeting works and how to be better at saving money.
  • Campaign Monitor – Teaches you how to be good at email marketing and designing emails
  • Google Adwords – Teaches you how to run efficient ad campaigns

Software is easy to build and distribute. It’s easy to simply give it to someone and hope they figure it out and possess enough reason to use it well. But this type of software will eventually die out, replaced with software that teaches you how to get better at the activity for which it is designed.

Joshua Porter – 52 Weeks of  UX

The Research – Practice Gap

“There is an immense gap between research and practice. I’m tempted to paraphrase Kipling and say “Oh, research is research, and practice is practice, and never the twain shall meet,” but I will resist. The gap between these two communities is real and frustrating. Sometimes the gap is deliberate. Some researchers proudly state that they are unconcerned with the dirty, messy, unsavory details of commercialization while also complaining that practitioners ignore them. And some practitioners deride the research results as coming from a pristine ivy tower, interesting perhaps, but irrelevant for anything practical. Sometimes the gap is accidental, caused by a misunderstanding by both sides of the requirements and goals of the other. I have heard researchers who would like their ideas to impact practice complain that when their ideas do get used, the practitioners do it wrong, leaving out (or messing up) the most critical aspects. Practitioners, in turn, complain that the research results, even if relevant, are not in any form that can readily be translated into practice.” – Don Norman

This articleon the research – practice gap is really interesting and very applicable to the area of interaction design in games. It definitely applies to those companies that have invested in User Research groups. Essentially it outlines a problem with the fundamental way of designing anything, and concludes that most design decisions are motivated by myths and practice rather than by core established scientific principles. Essentially they are going about it the wrong way.

I don’t want to give too much away because Dr. Norman says it best in thearticleso do read it!

However, with regards to its applicability to games, having the lead interaction designer’s job be something of translating user research, and other gameplay problems that need to be solved would be ideal in developing a robust interactive product. At this time, user interface in games is an after thought that usually results in lots of issues and many game mechanics that never truly deliver the full experience just because no one knows how to use them. Most devs seem to focus too much on look and feel as opposed to actual interaction issues.

In my own experience, I have come across individual devs that design user controls with no real planning aside from “this feels good to me” or “this feels good to them” referring usually to a very small subset of press or QA who are not necessarily true representations of the general population, or the audience that the game is being marketed.

The solution then would see the user interface team structured like so: Lead Interaction Designer, Interaction Designers, and Artists. The Lead Interaction Designer’s job, along with the designers on the team, would be to translate information from gameplay design, multiplayer design, level design, and user research to synthesize ways in which this information could be effectively put into practice. Essentially identifying a problem and designing a solution, the artists would then work with the lead to make sure that the research – practice gap is addressed and filled with the solution that was developed. This process should occur repeatedly, and tested by a representative population in order to determine validity and applicability, the process should also be documented so that future problems of a similar nature could be addressed with some established basis.

Of course I still need more time to think about this, but these are my initial thoughts on the subject.