Everybody loves creativity

I saw a rerun of the Working Girl episode of Everybody Loves Raymond last week. In this episode, Debra gets a job at an advertising agency. Her first project is an advertising campaign for a pizza account, so she comes up with a character called “Professor Pete Za.” She was fired on the first day because her boss didn’t like the idea but Debra kept fighting for it. The episode concluded with Debra and Ray talking about how silly her ideas were and how she should have realized that and backed down.

Apparently I didn’t have the intended reaction. I thought the Pete Za idea was pretty good and Debra shouldn’t have been fired for fighting for it. Creative ideas often look silly at first and they require some fighting. These challenges show what the creative process is supposed to look like!

Having creative ideas is easy—selling them is hard

If you want to foster a creative environment, but want to limit your team to only the creative ideas that everybody immediately gets and don’t have any problems, you might as well pack it up because it isn’t going to happen. People don’t always appreciate creative, innovative ideas right away. And there are always problems—lots of them.

While it’s challenging to come up with creative ideas, often the bigger challenge is selling them and working through the problems. It’s a mistake to abandon them too early just because there are issues. And it’s a mistake to expect everyone to immediately get your creative ideas without you standing behind them and selling them.

So simple, a caveman can do it…but would an executive?

The episode was about advertising, so let’s look at a real advertising example. My favorite ad campaign is for Geico. I think their ads are extremely creative, fun, and memorable; and do a great job of selling their product.

Imagine being at the meeting where the Martin Agency first pitched their ideas to the Geico execs. It might have been something like this:

Martin: People have trouble pronouncing “Geico”, so we were thinking of having a talking gecko with a cockney accent. And we’ve got a great idea for a series with sensitive cavemen who are constantly being insulted.

Geico: Interesting…what else do you have?

Martin: We were thinking of a series with a pile of money called Kash to represent customer savings.  Then there’s a series featuring old sayings being taken literally. Oh, yeah…there’s the one about talking pothole with a teenage southern accent.

Geico: Um…OK! Thank you for your time. We’ll get back to you.

Is this really a good way to sell auto insurance?

What would you have thought had you been there? Would you think these ideas would be successful?

I’m pretty sure that I wouldn’t have. All these ideas have the same, obvious problems: what in the world do they have to do with selling car insurance? They all seem a bit crazy. And with so many different ideas, won’t the campaign lack focus? Won’t people get confused?

While I think that the people who came up with these ideas are brilliant, the people who persuaded the Geico execs to go with them are just as brilliant. Perhaps the Geico execs who gave it all a green light were the most brilliant. I’m sure most executives would have turned these campaign ideas down.

Many creative ideas are losers

One thing we will never know is how much effort went in to making these ideas work. We’ll also never know now many bad ideas the Martin agency went through to find the few winners.

That’s why the creative process requires brainstorming. Many creative ideas aren’t winners—especially the risky ones, so the process is to come up with as many ideas as you can, identify their strengths and weaknesses, work through the problems, and see what holds up. Then sell them! I think the only mistake Debra Barone made was working with a single idea.

Developers have a hard time with creativity

Developers can have a tough time with the creative process because they tend to view all ideas through the lens of how difficult they would be to implement. Developers are trained to take an idea, pick it apart, and identify all the problems. We love doing that! But it’s harmful to the creative process.

While feasibility and development challenges are important, they aren’t important during brainstorming and the creative phase of the design process. That analysis is for later. It is important for developers to understand this.

Getting everyone on board

Given the challenges with creativity that I’ve just outlined, it’s important to get everyone on your team on board so that their contribution is as constructive and impactful as it can be. Make sure that everyone on your team:

  • Has an open mind. The creative process requires looking at a wide range of ideas. You can’t make a choice if you don’t have a range of options to choose from.
  • Doesn’t say no. Not all the ideas are going to be winners, but effective brainstorming requires the free flow of ideas. The worst thing you can do during brainstorming is critique ideas or say no.
  • Is patient. Even the best ideas are going to take a while to appreciate and work through the problems. Don’t expect the winners to be perfect right off the bat.
  • Fights for ideas, but doesn’t dwell. Creative, innovative ideas require some fighting—never expect to lob out an idea and have everybody love it immediately. But don’t dwell, which is when you continue to pursue it after it’s clearly not working or you refuse to seriously consider alternatives.
  • Focuses on creativity now, feasibility later. Feasibility and development challenges are important only after you have figured out what you want to do. Before then, these concerns are a tax on the creative process.

If you do only one thing: The creative process requires skills that most people haven’t fully developed. This is especially true if your team is highly technical. To make the creative process effective, get everybody on board first by reviewing how the creative process is supposed to work.

Mindlessly going through the design process motions

I have to admit that I still read Mini-Microsoft regularly (and occasionally sneak in a comment) even though I’m no longer a Microsoft employee. Mostly a combination of schadenfreude and getting insights on how to lead, manage, and reward software projects (mostly how not to do them.)

Hamilton Verissimo’s story

Today I read Hamilton Verissimo’s story that someone posted on Mini on why he left Microsoft. I found the following two snippets especially interesting:

For PMs, like me, some manager pushes idiot time-consuming exercises like scenario validation…two months to produce collateral that is bound to be useless in six months, since everything is likely to change.

I’m a big believer in scenario-based design and believe that, when done properly, is the best way to make a good design great. Consequently, I found this slam disturbing.

BTW: I’m not impressed by the “bound to be useless in six months, since everything is likely to change” claim. That’s a classic technologist argument to weasel out of something you don’t want to do. (Disagree? Try this exercise: The iPhone was released in June 2007—well more than 6 months. Identify the 10 top original iPhone scenarios that have completely changed since then. Should be easy to do if this claim were true. How about 3? OK, give me just one.) But I think what he’s really saying is that giant specs aren’t effective, which I completely agree with.

But then Hamilton goes on to describe the challenges he faced:

One thing that really frustrated me was that those random suggestions come from intuition, instead of actual scenarios/facts/data, and commonly show how disconnected MS employees are from the real world. In my case, as I worked in the developer division, it demonstrated how people there were disconnected from how developers work, and what they value. I had to constantly remind them that we should strive for simplicity since developers don’t have the time to become expert on our product, since it would be another tool in their toolbox.

Here, Hamilton has just made an excellent case for why scenario-based design is so important. We have a natural tendency to design for ourselves—to make decisions based on what we think is best given our own personal preferences and context. Scenario-based design, when properly done, forces us to make design decisions based on our target users’ point of view, by considering their personal characteristics, goals, and context. (Isn’t this what that “idiot”scenario validation is supposed to do?) Scenarios are a model of the facts and data we have about our customers. And designing from the target users’ point of view makes a huge difference!

Mindless process is evil

So, what’s going on here? Does Hamilton support scenario-based design or does he think it’s a waste of time? I’d love to ask him in person, but in the meantime I’ll have to speculate. The key words above were “when properly done.” My observation while at Microsoft was that the typical scenario-based design effort was a waste of time. The “scenarios” were actually just thinly-veiled feature advertisements, that did nothing but support the existing plan and inevitably ended by claiming a thrilled user. Such “scenarios” are just a process tax and don’t lead to better design.

While it’s good to have a design process, mindlessly following a design process without understanding the point behind it is just a waste of time. If your team is just going through the motions without making things obviously better, you’re doing it wrong!

If you do only one thing: Make sure everyone understands the goals behind each step of your design process. (A bit of training is a good thing!) Constantly evaluate what your process is buying your team and your product. If the benefit of a step isn’t worth the cost, find out why. Either fix the step or get rid of it.

UX Design Training Survey

I need your help to make our UX design training courses more effective. Please fill out this UX Design Training Survey so that we can better fulfill your UX design training goals.

  • By Everett McKay on May 11th, 2011
  • Quizzes and interview questions

Take the UX Design IQ Challenge

I like quizzes because they are a fun way to learn. I prefer quizzes that are challenging—so you have to know your stuff and think about the questions carefully—but not so challenging that they are impossible or trivial.

With this in mind, I’ve created the UX Design IQ Challenge. I’ve carefully selected questions that are challenging but not impossible. I hope you find this quiz to be a great way to learn, or even prepare for your next job interview.

Please give it a try!

This quiz is a work in progress. It currently has 15 questions, but I’m aiming for 30. I’d love to get your feedback on other good UX design questions or ways to improve the existing questions. I’d especially love to hear your favorite UX design job interview questions. Feel free to email me or post comments below. If I get enough material, I’d like to break this into separate targeted quizzes.

Guidelines-based design—A developer’s guide to intuitive UI

Last night, I presented Guidelines-based design—A developer’s guide to intuitive UI to the Vermont.Net User Group.

Guidelines are rules, based on design principles, experience, and convention.Following guidelines will help your program communicate to users effectively, feel “intuitive”, and have a familiar, consistent appearance. The thing I like most about using guidelines is that there is no other practical way to get to a high level of quality and consistency as quickly. The traditional design process (of brainstorming, prototyping, testing, iterating) won’t do it, nor will user-centered design techniques like scenarios and personas—they just don’t address the same level of detail.

Please contact me if you would like me to perform a Design Principle and Guideline Review of your product.

For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge