As people, it's all too easy to stick with the familiar. We tend to prefer to visit the same places, do the same things and eat the same foods because its comfortable and feels safer. There is nothing wrong with the desire for the familiar, but its important to recognize our tendency towards this and push out and away from the familiar - to explore.

In software, we often spend time building more-or-less the same feature, slightly-differently, many many times over. People look for the 'current trend' and then build just it over and over. We are prone to never imagine outside the suggested usages of the framework or CMS we're currently using, we are risk adverse and hesitate to try new things. We pursue this conformity to the point that we don't even think about trying new interfaces, ways of storing or creating content, or new solutions to old problems.

I want to caveat here that being risk adverse is good. Clients don't want their site to be an experiment (especially not one that fails). There are ways to mitigate risk and still innovate though. I think the best starting place for this is an iterative process, one where you can try small changes in short time frames and change quickly and at low cost to fit the outcomes. This requires that the ideas be broken into small, valuable chunks which can be built quickly and in series. With this approach, if something doesn't work then you've lost a week, maybe two, but not a month or a year (or several years).

So how do we break out of the mold in our thinking? Everyday we're presented with good but ubiquitous interfaces like GMail, tabbed browsers, Excel spreadsheets, Microsoft Word and Google search results. In the CMS world, we have the ideas of field based content types (post types), WYSIWYG editors, header navigation and list pages. When we are imagining new features, we tend to bucket them into our go to solutions e.g. "We need a table to display the new type of data in our application".

First, think about the data, the human workflow and the end user's goals instead of the implementation. Each feature should start out as a problem statement tied to a desired value. Its important to begin with as few assumptions about the implementation as possible and focus on solving the problem or creating the value.

Then acknowledge the assumptions that kept you in the old approach and reevaluate them in the context of the problem. Are they true here? Were they ever true?

Then remove the obvious (if its obvious we don't need to spend time on it) and think about what is actually important in the current situation. (From The Laws of Simplicity by John Maeda). Obviously, the client wants to edit the content. Ok, what is different or new about the situation? Where are the problems and places to provide unique value?

The second part of breaking out of the mold and finding creative solutions is freedom. Without freedom, its hard to take initiative, to try new things, to be motivated or able to think of truly innovating solutions. In my experience, one of the most important aspects of being innovative is being inspired and free - technically and from a requirements standpoint - to try new things. When the framework, CMS or technical environment makes it really difficult to do anything other than the 'norm' its very difficult to truly innovate. Likewise, when the stakeholder environment is one of 'Just build it the way I want', when the design process creates a situation where the designs are 'thrown over the wall' or when there is a lot of time pressure and stress, its much more difficult for the team to really solve problems and be creative.

I am always happier when I'm able to create a really good solution to a problem. No-one wants to just be an implementer (aka 'Code Monkey').