Archive for September, 2011

How to Choose the Colors for Your Website

choosing a color schemeYou may not realize it, but the color scheme that you choose for your website is one of the most important decisions you will have to make.

Color is important because it effects not only your mind, but your body as well. Studies have shown that the color red can stimulate your senses, and even raise your blood pressure. Casinos have been known to use red neon lights because it’s been said that people gamble more while under the glow of a red light. On the other hand, blue tends to have the opposite effect; It’s been shown to calm the mind, and relax the body. 

continue reading How to Choose the Colors for Your Website

© Barbara Holbrook for Tutorial Blog | 9 comments | Add to

How to Choose the Colors for Your Website is a post from: Tutorial Blog

Desktop Wallpaper Calendar: October 2011



We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one — desktop wallpapers that are a little more distinctive than the usual crowd. This creativity mission has been going on for over two years now, and we are very thankful to all designers who have contributed and are still diligently contributing each month.

We continue to nourish you with a monthly spoon of inspiration. This post features 28 free desktop wallpapers created by artists across the globe for October 2011. Both versions with a calendar and without a calendar can be downloaded for free. It’s time to freshen up your wallpaper!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?

Oct Deco

"Inspired by the granite work at Grand Central Station. I imagine this being an engraved tile on the floor as the sun sheds its last gleaming moments." Designed by Frank Candamil from USA.

Free Desktop Wallpaper - October 2011

Tribute To Lennon

"I decided to make a tribute to a great singer and peace keeper because my dad was a fan of John Lennon and the Beatles, and while I was a child I’ve consumed the art of music more then any other art! This work is also for school, and I expect to have a good final average and become a graduate graphic designer! Peace." Designed by Daniel Faria from Portugal.

Free Desktop Wallpaper - October 2011

Autumn Grunge

"Autumn Grunge is a simple wallpaper that is heavily textured and helps you to embrace the fall." Designed by Colin Whitehurst from Philippines.

Free Desktop Wallpaper - October 2011

October Faces

"In a nice Sunday morning excursion I collected the most cute and fun natures presents of Autumn — chestnuts! With a spare pen drew faces on them for fun… and then, my idea was born! They are my October faces ;)." Designed by Alkminnie Nestoridou from Greece.

Free Desktop Wallpaper - October 2011

Halloween Spooky Background

"Spooky Cartoon Halloween wallpapers for October holidays with vintage texture." Designed by Benoit Chartron from France.

Free Desktop Wallpaper - October 2011

Singing Masters

"I found this passage long ago in a very old book of poetry. It brings to my mind the images of October — haunted graves, rusty iron gates, ravens, and bonfires." Designed by Heather St. Marie from USA.

Free Desktop Wallpaper - October 2011

Ghost Halloween

Designed by Tiago Santos from Portugal.

Free Desktop Wallpaper - October 2011

Save Water Drink Rain

Designed by Marika Smirnova from Russia.

Smashing Wallpaper - october 11

October Apples

"A simple beautiful photo for an elegant country-inspired desktop." Designed by Greyarea Snc from Italy.

Free Desktop Wallpaper - October 2011

Crystal Nature

"This October you can let your imagination guide you through places that never existed — or maybe they do exist behind our screens!" Designed by Isaac Zakar from Greece.

Free Desktop Wallpaper - October 2011

Frisbee Tribute

"I love frisbee. Spending time outdoors, on a sunny day, throwing the disk with a couple of good friends makes me very happy. This wallpaper is my tribute to the disk! :)." Designed by Danijel Gajan from Serbia.

Free Desktop Wallpaper - October 2011

Dark River

Designed by Michal Loboz from Poland.

Free Desktop Wallpaper - October 2011

Sweet Monster

"Happy sweet monster special for Smashing Magazine’s readers." Designed by Ryumina Elena from Russia.

Free Desktop Wallpaper - October 2011

Colours Of Dream

"October for ComoYoDsg is a month of changes. Just this month my Web site is changing colours and layout. I want to share it with you with these wallpapers that form a part of my new design. Enjoy it!" Designed by Comoyodsg By Dovi Vausk from Spain.

Free Desktop Wallpaper - October 2011

Design Is Life

"Design is Life with all its Patches & Shades in it. Design is so closely attached to everybody’s life with nature, lifestyle, fashion, trends and so many things around." Designed by Lucky from India.

Free Desktop Wallpaper - October 2011


"Autumn is the mushroom season. Be vigilant. Do not abuse." Designed by from Russia.

Free Desktop Wallpaper - October 2011

This Is Halloween

"Scary bats and spiders, frightening skeletons, delicious candies and lollies and ominous black cats and carved pumpkins… All bundled up together and you have a perfect Halloween. Trick or treat!" Designed by Soraia Mendes from Portugal.

Free Desktop Wallpaper - October 2011

Spectral Splendor

"A wide array of spectral colors break open, this October!" Designed by Sureshsathanur from India.

Free Desktop Wallpaper - October 2011

Fallen Gold

"Elegant typography gracefully sits interlocked within a pile of golden autumnal leaves." Designed by Dave Hewer from UK.

Free Desktop Wallpaper - October 2011

Creepy October

Designed by Roland Szabó from Hungary.

Free Desktop Wallpaper - October 2011

Pale Docktober

Designed by Andreas Sofantzis from Greece.

Free Desktop Wallpaper - October 2011


"The celebration wallpaper has flowers, sprinkles of vibrant colors and sparkles of fire crackers depicting Diwali on the 26th, the biggest festival of indians in the month of October brings in joy and happiness, peace and harmony." Designed by Hiren Rawal from India.

Free Desktop Wallpaper - October 2011

Autumn Retreat

"A simple autumn we’d all like to enjoy." Designed by Allen from USA.

Free Desktop Wallpaper - October 2011

Pretty Autumn

"”I cannot endure to waste anything as precious as autumn sunshine by staying in the house. So I spend almost all the daylight hours in the open air.”- Nathaniel Hawthorne”." Designed by Barney from Hungary.

Free Desktop Wallpaper - October 2011

The Undertaker

"This is a photograph a “Felt Creature” that my sister made. I took this photo for her website and I thought it would make an excellent Halloween themed calendar for October!" Designed by Stuart Hamilton from Northern Ireland.

Free Desktop Wallpaper - October 2011

Chorapo’s Famous Stew And Tacos

"A typographic treat from your favourite October slashers!" Designed by Ryan From Embarkr from USA.

Free Desktop Wallpaper - October 2011

King Sorrow

Designed by Ladell Bryson from USA.

Free Desktop Wallpaper - October 2011


"This is my tribute to the awesome and beautiful designed videogame “Limbo”. Enjoy and share if you like this drawing." Designed by Jonas Duri.

Free Desktop Wallpaper - October 2011

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

A big thank you to all designers for their participation. Join in next month!

What’s Your Favourite?

What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below!

(il) (vf)

© Smashing Editorial for Smashing Magazine, 2011.

WordPress Essentials: How To Create A WordPress Plugin



WordPress plugins are PHP scripts that alter your website. The changes could be anything from the simplest tweak in the header to a more drastic makeover (such as changing how log-ins work, triggering emails to be sent, and much more).

Whereas themes modify the look of your website, plugins change how it functions. With plugins, you can create custom post types, add new tables to your database to track popular articles, automatically link your contents folder to a “CDN� server such as Amazon S3… you get the picture.


Theme Or Plugin?

If you’ve ever played around with a theme, you’ll know it has a functions.php file, which gives you a lot of power and enables you to build plugin-like functionality into your theme. So, if we have this functions.php file, what’s the point of a plugin? When should we use one, and when should we create our own?

The line here is blurrier than you might think, and the answer will often depend on your needs. If you just want to modify the default length of your posts’ excerpts, you can safely do it in functions.php. If you want something that lets users message each other and become friends on your website, then a plugin would better suit your needs.

The main difference is that a plugin’s functionality persists regardless of what theme you have enabled, whereas any changes you have made in functions.php will stop working once you switch themes. Also, grouping related functionality into a plugin is often more convenient than leaving a mass of code in functions.php.

Creating Our First PlugIn

To create a plugin, all you need to do is create a folder and then create a single file with one line of content. Navigate to the wp-content/plugins folder, and create a new folder named awesomeplugin. Inside this new folder, create a file named awesomeplugin.php. Open the file in a text editor, and paste the following information in it:

   Plugin Name: Awesomeness Creator
   Plugin URI:
   Description: a plugin to create awesomeness and spread joy
   Version: 1.2
   Author: Mr. Awesome
   Author URI:
   License: GPL2

Of all this information, only the plugin’s name is required. But if you intend to distribute your plugin, you should add as much data as possible.

With that out of the way, you can go into the back end to activate your plugin. That’s all there is to it! Of course, this plugin doesn’t do anything; but strictly speaking, it is an active, functioning plugin.

Structuring PlugIns

When creating complex functionality, splitting your plugin into multiple files and folders might be easier. The choice is yours, but following a few good tips will make your life easier.

If your plugin focuses on one main class, put that class in the main plugin file, and add one or more separate files for other functionality. If your plugin enhances WordPress’ back end with custom controls, you can create the usual CSS and JavaScript folders to store the appropriate files.

Generally, aim for a balance between layout structure, usability and minimalism. Split your plugin into multiple files as necessary, but don’t go overboard. I find it useful to look at the structure of popular plugins such as WP-PageNavi and Akismet.

Naming Your PlugIn And Its Functions

When creating a plugin, exercise caution in naming the functions, classes and plugin itself. If your plugin is for generating awesome excerpts, then calling it “excerpts� and calling its main function “the_excerpt� might seem logical. But these names are far too generic and might clash with other plugins that have similar functionality with similar names.

The most common solution is to use unique prefixes. You could use “acme_excerpt,� for example, or anything else that has a low likelihood of matching someone else’s naming scheme.

Plugin Safety

If you plan to distribute your plugin, then security is of utmost importance, because now you are fiddling with other people’s websites, not just your own. All of the security measures you should take merit their own article, so keep an eye out for an upcoming piece on how to secure your plugin. For now, let’s just look at the theory in a nutshell; you can worry about implementation once you grasp that.

The safety of your plugin usually depends on the stability of its two legs. One leg makes sure that the plugin does not help spread naughty data. Guarding against this entails filtering the user’s input, escaping queries to protect against SQL injection attacks and so on. The second leg makes sure that the user has the authority and intention to perform a given action. This basically means that only users with the authority to delete data (such as administrators) should be able to do it. Guarding intention ensures that visitors aren’t misled by a hacker who has managed to place a malicious link on your website.

All of this is much easier to do than you might think, because WordPress gives you many functions to handle it. A number of other issues and best practices are involved, however, so we’ll cover those in a future article. There is plenty to learn and do until then; if you’re just starting out, don’t worry about all that for now.

Cleaning Up After Yourself

Many plugins are guilty of leaving a lot of unnecessary data lying around. Data that only your plugin uses (such as meta data for posts or comments, database tables, etc.) can wind up as dead weight if the plugin doesn’t clean up after itself.

WordPress offers three great hooks to help you take care of this:

  • register_activation_hook()
    This hook allows you to create a function that runs when your plugin is activated. It takes the path to your main plugin file as the first argument, and the function that you want to run as the second argument. You can use this to check the version of your plugin, do some upgrades between versions, check for the correct PHP version and so on.
  • register_deactivation_hook()
    The name says it all. This function works like its counterpart above, but it runs whenever your plugin is deactivated. I suggest using the next function when deleting data; use this one just for general housekeeping.
  • register_uninstall_hook()
    This function runs when the website administrator deletes your plugin in WordPress’ back end. This is a great way to remove data that has been lying around, such as database tables, settings and what not. A drawback to this method is that the plugin needs to be able to run for it to work; so, if your plugin cannot uninstall in this way, you can create an uninstall.php file. Check out this function’s documentation for more information.

If your plugin tracks the popularity of content, then deleting the tracked data when the user deletes the plugin might not be wise. In this case, at least point the user to the location in the back end where they can find the plugin’s data, or give them the option to delete the data on the plugin’s settings page before deleting the plugin itself.

The net result of all our effort is that a user should be able to install your plugin, use it for 10 years and then delete it without leaving a trace on the website, in the database or in the file structure.

Documentation And Coding Standards

If you are developing for a big community, then documenting your code is considered good manners (and good business). The conventions for this are fairly well established — phpDocumentor is one example. But as long as your code is clean and has some documentation, you should be fine.

I document code for my own benefit as well, because I barely remember what I did yesterday, much less the purpose of functions that I wrote months back. By documenting code, you force good practices on yourself. And if you start working on a team or if your code becomes popular, then documentation will be an inevitable part of your life, so you might as well start now.

While not quite as important as documentation, following coding standards is a good idea if you want your code to comply with WordPress’ guidelines.

Putting It Into Practice

All work and no play makes Jack a dull boy, so let’s do something with all of this knowledge that we’ve just acquired. To demonstrate, let’s build a quick plugin that tracks the popularity of our articles by storing how many times each post has been viewed. I will be using hooks, which we’ll cover in an upcoming installment in this series. Until then, as long as you grasp the logic behind them, all is well; you will understand hooks and plugins before long!

Planning Ahead

Before writing any code, let’s think ahead and try to determine the functions that our plugin will need. Here’s what I’ve come up with:

  • A function that registers a view every time an individual post is shown,
  • A function that enables us to retrieve the raw number of views,
  • A function that enables us to show the number of views to the user,
  • A function that retrieves a list of posts based on their view count.

Preparing Our Function

The first step is to create the folder and file structure. Putting all of this into one file will be fine, so let’s go to the plugins folder and create a new folder named awesomely_popular. In this folder, create a file named awesomely_popular.php. Open your new file, and paste some meta data at the top, something like this:

   Plugin Name: Awesomely Popular
   Plugin URI:
   Description: A plugin that records post views and contains functions to easily list posts by popularity
   Version: 1.0
   Author: Mr. Awesome
   Author URI:
   License: GPL2

Recording Post Views

Without delving too deep, WordPress hooks enable you to (among other things) fire off one of your functions whenever another WordPress function runs. So, if we can find a function that runs whenever an individual post is viewed, we are all set; all we would need to do is write our own function that records the number of views and hook it in. Before we get to that, though, let’s write the new function itself. Here is the code:

 * Adds a view to the post being viewed
 * Finds the current views of a post and adds one to it by updating
 * the postmeta. The meta key used is "awepop_views".
 * @global object $post The post object
 * @return integer $new_views The number of views the post has
function awepop_add_view() {
   if(is_single()) {
      global $post;
      $current_views = get_post_meta($post->ID, "awepop_views", true);
      if(!isset($current_views) OR empty($current_views) OR !is_numeric($current_views) ) {
         $current_views = 0;
      $new_views = $current_views + 1;
      update_post_meta($post->ID, "awepop_views", $new_views);
      return $new_views;

As you can see, I have added phpDocumentor-style documentation to the top of the function, and this is a pretty good indication of what to expect from this convention. First of all, using a conditional tag, we determine whether the user is viewing a post on a dedicated page.

If the user is on a dedicated page, we pull in the $post object, which contains data about the post being shown (ID, title, posting date, comment count, etc.). We then retrieve the number of views that the post has already gotten. We will add 1 to this and then overwrite the orignal value with the new one. In case something goes wrong, we first check whether the current view count is what it should be.

The current view count must be set; it cannot be empty. And it must be numeric in order for us to be able to add 1 to it. If it does not meet these criteria, then we could safely bet that the current view count is 0. Next, we add 1 to it and save it to the database. Finally, we return the number of views that the post has gotten, together with this latest number.

So far, so good. But this function is never called, so it won’t actually be used. This is where hooks come in. You could go into your theme’s files and call the function manually from there. But then you would lose that functionality if you ever changed the theme, thus defeating the entire purpose. A hook, named wp_head, that runs just before the </head> tag is present in most themes, so we can just set our function to run whenever wp_head runs, like so:

add_action("wp_head", "awepop_add_view");

That’s all there is to the “mysticism� of hooks. We are basically saying, whenever wp_head runs, also execute the awepop_add_view function. You can place the code before or after the function itself.

Retrieving and Showing the Views

In the function above, I already use the WordPress get_post_meta() function to retrieve the views, so writing a separate function for this might seem a bit redundant. In this case, it might well be redundant, but it promotes some object-oriented thinking, and it gives us greater flexibility when further developing the plugin. Let’s take a look:

 * Retrieve the number of views for a post
 * Finds the current views for a post, returning 0 if there are none
 * @global object $post The post object
 * @return integer $current_views The number of views the post has
function awepop_get_view_count() {
   global $post;
   $current_views = get_post_meta($post->ID, "awepop_views", true);
   if(!isset($current_views) OR empty($current_views) OR !is_numeric($current_views) ) {
      $current_views = 0;

   return $current_views;

This is the same piece of code that we used in the awepop_add_view() function, so you could just use this to retrieve the view count there as well. This is handy, because if you decide to handle the 0 case differently, you only need to change it here. You will also be able to extend this easily and provide support for cases when we are not in the loop (i.e. when the $post object is not available).

So far, we have just retrieved the view count. Now, let’s show it. You might be thinking this is daft — all we need is echo awepop_get_view_count() . "views", no? That would certainly work, but what if there is only 1 view. In this case, we would need to use the singular “view.â€� You might also want the freedom to add some leading text or some other tidbit, which would be difficult to do otherwise. So, to allow for these scenarios, let’s write another simple function:

 * Shows the number of views for a post
 * Finds the current views of a post and displays it together with some optional text
 * @global object $post The post object
 * @uses awepop_get_view_count()
 * @param string $singular The singular term for the text
 * @param string $plural The plural term for the text
 * @param string $before Text to place before the counter
 * @return string $views_text The views display
function awepop_show_views($singular = "view", $plural = "views", $before = "This post has: ") {
   global $post;
   $current_views = awepop_get_view_count();

   $views_text = $before . $current_views . " ";

   if ($current_views == 1) {
      $views_text .= $singular;
   else {
      $views_text .= $plural;

   echo $views_text;


Show a List of Posts Based on Views

To show a list of posts based on view count, we create a function that we can place anywhere in our theme. The function will use a custom query and loop through the results, displaying a simple list of titles. The code is below, and the explanation follows.

 * Displays a list of posts ordered by popularity
 * Shows a simple list of post titles ordered by their view count
 * @param integer $post_count The number of posts to show
function awepop_popularity_list($post_count = 10) {
   $args = array(
      "posts_per_page" => 10,
      "post_type" => "post",
      "post_status" => "publish",
      "meta_key" => "awepop_views",
      "orderby" => "meta_value_num",
      "order" => "DESC"

   $awepop_list = new WP_Query($args);

   if($awepop_list->have_posts()) {
      echo "
    "; } while ( $awepop_list->have_posts() ) : $awepop_list->the_post(); echo "
  • ".the_title('', '', false)."
  • "; endwhile; if($awepop_list->have_posts()) { echo "
"; } }

We start by passing a bunch of parameters to the WP_Query class, in order to create a new object that contains some posts. This class will do the heavy lifting for us: it finds 10 published posts that have awepop_views in the meta table, and orders them according to this property in descending order.

If posts meet this criterion, we create an unordered list element. Then, we loop through all of the posts that we have retrieved, showing each title as a link to the relevant post. We cap things off by adding a closing tag to the list when there are posts to show. Placing the awepop_popularity_list() function anywhere in your theme should now generate a simple list of posts ordered by popularity.

As an added precaution, place the call to this function in your theme, like so:

if (function_exists("awepop_popularity_list")) {

This ensures that if the plugin is disabled (and thus the function becomes undefined), PHP won’t throw a big ol’ error. It just won’t show the list of most popular posts.


By following the theory laid down in this article and using only a handful of functions, we have created a rudimentary plugin to track our most popular posts. It could be vastly improved, but it shows the basics of using plugins perfectly well. Moreover, by learning some patterns of WordPress development (plugins, hooks, etc.), you are gaining skills that will serve you in non-WordPress environments as well.

You should now be able to confidently follow tutorials that start with “First, create a WordPress plugin…� You now understand things not just on a need-to-know basis, but at a deeper level, which gives you more flexibility and power when coding your own plugins. Stay tuned for the upcoming article on hooks, actions and filters for an even more in-depth resource on the innards of plugins.


© Daniel Pataki for Smashing Magazine, 2011.

Humble Freelancer, Assertive Businessperson – A How To


If you’re a freelance designer, or you work for another company, you got there not because you love business, but because you’re a designer at heart. The business side of things came as a necessary evil, but you really love nothing more than to doodle all day, mess around in photoshop, or bang out semantic code. There are a lot of traits of being a good designer which are counter-intuitive to being a good business person. But if you learn to embrace both sides of the coin, your business will prosper, and you’ll get to do more design.

It’s great to create beautiful works of art for Art’s sake, but the reality is, you can only afford do so if you’re getting paid. Yes, being a great designer means you need to be humble, accept criticism, have an open mind, listen to other points of view, be idealistic and possess all sorts of wonderful character traits of the enlightened and creative individual. But to afford to do so, you need learn how to run your business.

Be Assertive

Like many freelancers find out the hard way, there will come a day or a client that will act as a tremendous lesson and taught you to be assertive. Now remember, assertive doesn’t mean yelling and stamping your feet; it just means sticking up for yourself and not letting yourself get bulldozed. Being assertive sooner in the process will help you avoid being angry later! An unfortunate truth we find, is that some clients will take advantage of you if you give them the opening. Make sure you don’t let them!

Don’t Set a Price Until Everything is Scoped Out

That means, not just features and functionality, but timeline, urgency, number of revisions, how many other people will be involved – the whole works. Everyone’s expectations, both yours and the clients needs to be on the table, and part of the discussion. Without knowing these vital specifics about the project, we are sure to misquote the job and probably end up costing ourselves before we can call the project closed.

Don’t Be Afraid to Ask For a Deposit

This might be obvious to some of you, but many of us have had clients balk at this. Many of those new to the field are not comfortable with doing this. And as many clients are also not too keen on handing over money for work that has not been done, or even in their minds, begun, we need to approach this situation both delicately and confidently. The more hesitant we are, the more our discomfort comes across, the more likely the client is to pick up on this and allow their resistance through.

We need to simply let them know that we are completely committed to their project, and as we will be investing a large amount of time in it, we need to be assured that they are committed as well. The deposit not only shows they are fully on board, but you can assure them that it will guarantee priority and timeliness of the project on your part. It can be an uncomfortable subject to broach, but if you do not, then you might end up doing a lot of work and not getting compensated at all for your time.

Let Them Know You’re the Expert

Sometimes, no matter how you run your business, you can still run into the occasional person who wants to lean over your shoulder and tell you how many pixels to move something over. The trick is try and not take on the projects for those kinds of people. However, you need to let your clients know you’re the expert at your business, and respect that they’re the expert of their’s.

We don’t often dispute the word of our doctor, we accept their expertise. We need our clients to believe in us this way too. Image by Clarita

Whenever a client makes a specific request for something you know is a bad idea, try turning it around and asking them what it is that’s bothering them. Exactly what are they trying to solve? This allows you to first try and get to the root of the problem so that you can come up with a more appropriate way to solve it; rather than just implementing the bad idea.

Even then, that sometimes doesn’t work, and they insist on the bad idea. This is when you want to assure them that you know what they are trying to achieve and you gently push for them to allow for your expertise and knowledge to give them the best website possible. Strongly discourage going down this path, informing them why the idea could actually work against their goals. Let them know that you will do it if they insist, because you want them to be happy in the end. At which point you will want your objections to this course noted in the paperwork, pointing out that this is what they requested.

That sometimes works. Writing it down makes it into a dramatic moment where they realize you don’t want to be “responsible” for doing what they are asking, and they will then think twice.

Frame Client Input

You can almost never escape needing client approval on a design piece, but there is a way to elicit feedback properly without leaving yourself open to accepting inane or subjective input. When you approach your clients for feedback, rather than leaving the door wide open, you want to frame the questions in ways that the client will effectively be choosing between options that you are already on board with.

If you have a question about the navigation, take them some variations on the idea to choose from. Instead of simply asking, “what are your thoughts on the navigation?” This prevents them from asking for something that is simply unachievable. This can also save time if they are not very clear on what they want. And sometimes they will know what they are looking for out of certain elements until they see it.

Always use a contract!

Having a contract doesn’t mean you don’t trust the client. A contract is for protecting you and the client, and makes sure everybody is clear on exactly what is being delivered and when. It’s not an issue of honesty, but of making sure everybody is on the same page. Never start work before a contract is signed.

Because nothing is written in stone, so to speak, until the contract is signed. Image by Mary R. Voght

And we have to remember that if we receive a contract, we need to check it over carefully. If there are any parts that are unclear or make you uncomfortable, do not be afraid to voice those concerns or ask for clarification. Most of the time, we will find the client receptive to these requests, we need only ask.

Often times, a contract will be written by lawyers who are only looking out for their client, and they write for an apocalypse. You need to look out for yourself and make sure you are comfortable with the agreement, too.

Don’t Do ‘Work For Hire’

…unless you’re actually being employed full-time! Work-for-hire is a term used in copyright law which grants full ownership and copyrights of your work to the person hiring you. By default, all freelancing and contract work is not work for hire. However, it can be written in to a contract (and even then, you still might have a case for arguing it, should you choose!). Technically, something is deemed work for hire if you created it while at a job which demands you be there full-time. Working from home, on a small project is not.

You might think, “What’s the big deal?” Well, if your client wants to retain full ownership and copyrights of the work, they need to pay a premium! Think of the difference of royalty-free stock photography versus rights-managed or full ownership. Owning the full-rights costs a lot of money. Also, most of us will want to include the piece in our portfolios, so taking that away comes with a price, too.

Never Do Spec Work

Working on speculation (“Do a home page design for me, and if we like it, we’ll pay you.”) is a terrible idea. Other people have said it better, so we will not go into a lot of detail here. If you would like a full rundown on the numerous reasons that spec work is bad for you and the industry overall, then go to No!Spec and read why it’s so bad.

Don’t Give Up Passwords or Files Until You’re Paid

Let’s look at it this way. The client has seen the flattened artwork and knows how things look and that you’ve spent the time on their project. At this point, it makes no sense for them to worry about you not delivering on the final product. You just want to be paid. If you turn over the files before you get paid, the client has nothing more to gain by paying you. You’re just hoping that they end up being honest…

It is usually in your best interest to keep yourself password protected. Image by Szilard Mihaly

Make sure the client knows this up-front. It’s unfair to make it a surprise if they have a tight schedule to keep. The least amount of surprises in the end tends to work out in everyone’s favor. So include this in the contract, and be sure to highlight this point once or twice when initial talks are beginning. The internet is full of freelance stories where the designer failed to put their foot down about this, and they ended up waiting months to get paid…if they were paid at all.

Note: There might be some who would argue you shouldn’t give up layered PSDs to the client. That’s a separate discussion. For web design, when you’re working with other developers, you kind of have to.

Write Down Your Policies

It may seem trivial, but for some reason, if you say, “It’s my policy…” and you have shown this to them in the beginning, people will argue with you less. If it’s a policy, people just accept it. Not entirely sure why this works, but it has often come in handy and proven itself as a worthwhile course of action for freelancers.

In Conclusion

Being assertive is not being mean. It’s having rules and standards and ways of doing business, and then sticking to them. It’s drawing clear lines and boundaries and making sure everybody is on the same page. It’s making sure you don’t get bullied around by a bad client. Ultimately, clients will respect your ability to manage your business and they’ll come back for more.

What are your thoughts on ways to effectively assert yourself with clients? Leave us your two cents and personal experiences in the comment section below.

Conversation Techniques For Designers



Conversation Techniques for Designers

Designers are visually literate creatures. We use visuals to express our ideas, whether by building wireframes, sketching interfaces or pushing pixels. As a result, the majority of knowledge captured when we design a product is some form of “corporate memory�: a combination of assets and documentation. This creation of visual artifact is widely regarded as our most effective means of communicating thought through a product. However, creating a product takes more than just documentation, and much of it is communicated not visually, but verbally.

Product design and development is a combination of creativity and analysis. But it depends on communication.

– Michael Bremer

Why Are Product Conversations Important?

Due to the growing popularity of iterative product development, the spoken word has become an integral part of the design process. The shift in focus from documentation to collaboration has put greater emphasis on communication. Now more than ever, there is a need to articulate a design “voiceâ€� during the early stages of conversation about a product, and to maintain it throughout the process — although this is easier said than done. While conveying one’s findings and opinions in discussion is important for designers, deciding what to say and how to say it often proves difficult.

Because team members and stakeholders sometimes hold different opinions on a product, navigating these conversations can be quite challenging. This social facet of designing digital products has been described by Löwgren and Stolterman (PDF) as follows:

If a design process aims to create an information system in an organization, then individuals, groups, and teams can be seen as kinds of material. The challenge is to design the social “components� together with the technical components as a systemic whole.

Influencing the Product Conversation

The extent to which design is embraced in a project varies greatly. At an organizational level, it is influenced by numerous factors, such as the company’s culture, leadership and strategy. At a product level, one could argue that it is largely determined by the team itself. That being said, teams often struggle to discuss the subtler, more experiential aspects of their digital products. As a result, technical terminology can dominate the conversation, prematurely steering the conversation towards “How should we do this?� without giving adequate consideration to “What should we do?� and “Why should we do it?,� thus minimizing the influence of design early on.

To avoid this trap, good designers need to become good conversation starters. By developing our conversational skills, we become better equipped to discuss the conditions required for a great user experience and to influence any decisions that affect it. Maintaining a healthy dialogue on design is important also because the conversations that are conducted as the product is being created will influence the implicit “conversation� that the product will have with the user. Tim Leberecht of Frog Design highlights the importance of conversation to both the design process and the product experience itself, by suggesting that designers should focus on…

… creating a memorable, auratic and yet reproducible experience for consumers. Conversations are part of this experience; they are integral to the “aura.� Designers visualize it. They unearth, discover, and articulate the consumer stories. They invent the product stories. And then they connect both.

In this article, we’ll examine the role of conversation in the design process, and how the words we use shape the products we ship. We’ll outline nine ways by which designers can maintain a consistent design conversation during a project, helping to create a better product.

Get T-Shaped

Get Multilingual

Better collaboration leads to better products. Designers need to ensure that they can communicate effectively with their team members from various other disciplines. To do this well, familiarize yourself with the kind of language used in each discipline, such as business and engineering. Being able to conduct a conversation using the appropriate vocabulary enables you to find out what you need to know faster, and it helps to establish your credibility on the team.

While each discipline on the product team has its role to play, it is the true teamwork and collaboration of a cohesive product team that makes great user experiences possible.

– Pabini Gabriel-Petit

Designers should also be knowledgeable across the various domains that an issue spans within a project, which will give them a broader perspective on the problem they’re trying to solve. Tim Brown of IDEO maintains that designers should try to become “T-shaped.� This is achieved by cultivating deep analytical skills (the vertical stroke of the T), as well as broad empathy towards the other skills and disciplines encountered in business (the horizontal stroke of the T).

Familiarity with the dialects of various disciplines is important not only in a practical sense, but strategically, too. At a recent AIGA event, it was suggested that it is up to designers to learn the vocabularies needed to be able to communicate the value of design to business managers and executives. In doing so, designers will better justify their representation in the boardroom in future. By becoming skilled communicators and demonstrating the value of design, we increase the likelihood of this happening. Aspiring Chief Experience Officers (CXOs), take note.

In assuming the role of “generalizing specialist� on a multidisciplinary team, designers establish a clearer picture of the problem and the means to address it. They also become armed with the necessary vocabulary to communicate with all those involved in the project.

So, don’t retreat into a silo. Get T-shaped!

Ask The Simple Questions

Ask The Simple Questions

Question everything generally thought to be obvious.

– Dieter Rams

We often forget that simple questions are a powerful way to spark conversation. Designers sometimes back away from asking such questions, for fear of coming across as poorly informed. Canadian designer Bruce Mau describes it thus:

The fear for so many people is that, in asking these kinds of questions, they will appear naïve. But naïvety is a valuable commodity in this context. Naïvety is what allows you to try to do what the experts say can’t be done.

Apparently stupid questions can lead to illuminating discussion. At the outset of a design process, asking such questions is especially important, because they provoke a deeper consideration of the purpose of a product. In this situation, the onus is on the designer to put forward these questions. You might be surprised by the assumptions of stakeholders and, more importantly, by how enlightening it is to question them. Question absolutely everything, especially those things that are considered obvious.

  • Who is this product for?
  • What problem is this solving?
  • Is this really a problem?
  • Are we trying to do too much?
  • Is this feature for you or our users?
  • Do you think this solution is good enough?

A good team will always appreciate a thorough approach and a close examination of its strategy. Try to avoid posing elaborate questions that imply the answer you are looking for. Instead, formulate your queries to spark a conversation and to discourage monosyllabic responses. Both stakeholders and users can reveal a lot by answering such disarmingly simple questions. Nobel Prize-winning physicist Richard Feynman, one of the brightest minds of the 20th century, was a great believer in the value of asking dumb questions. He encouraged people to question accepted solutions and to be unafraid to look ridiculous.

Asking the “stupid� questions is one of the smartest things a designer can do. But be respectful and tactful in how you go about it.

The only stupid questions are the ones you don’t ask.

Define the Problem, Continually

Define The Problem, Continually

When you start with the idea of making a thing, you’re artificially limiting what you can deliver.

– Peter Mehrolz in “Experience Is the Productâ€�

In order to solve a problem, you must first define it. Such an assertion might seem obvious, but you’d be surprised by how many people fail to recognize this. When a project commences, there is often a tendency to start designing a solution without having thoroughly discussed the problem itself. Basing a product’s direction on a set of assumptions or hunches is a very risky strategy, often resulting in a design that fails to address the user’s needs. Luke Wroblewski notes:

In many organizations, [the] problem is defined with a written or numerical representation of a market opportunity. Think business model, business requirements document, etc. While these documents are great at defining the aspirations (or net present value) of a product, they rarely fully define the problem a product team needs to address.

By diving headfirst into a solution, a team might find it difficult to overcome the oversights that they failed to recognize early on in the process.

Learning what the problem is rests on the designer’s shoulders. It’s your responsibility to ensure that the problem that a product aims to solve is discussed in depth at the start of the project. In addition, there should be a continuing conversation to evaluate the problem as it is being addressed. This is necessary because a lot can change during a project. A team will often lose sight of these changes, so make sure you don’t. If this does happen, adjust your approach accordingly, and discuss the changes with the team.

Noted design thinker Horst Rittel once wrote:

A design problem keeps changing while it is treated, because the understanding of what ought to be accomplished, and how it might be accomplished is continually shifting. Learning what the problem is is the problem.

By conducting an open conversation on the problem throughout the project, the designer ensures that all new information that affects the situation is quickly shared and absorbed into the solution.

Problems change — this is inevitable. Plan for it.

Find The User’s Voice, Then Use It

Find The Users Voice, Then Use It

Don’t confuse yourself with the user, and don’t confuse the user with the customer. It’s not uncommon for a team to lose sight of who exactly they are building a product for. Marty Cagan of SV Product Group wrote an excellent article highlighting typical product management mistakes. To find your user’s voice is to develop empathy for them and understand their situation. For if you don’t understand your users, then you likely won’t fully understand their problems.

We systematically overestimate the value of access to information and underestimate the value of access to each other.

– Clay Shirky

The phrase “going native� is often used by anthropologists and ethnographers to describe their immersion in a user’s environment. One of the pioneers of user-centered design was industrial designer Henry Dreyfuss (author of Designing for People, which came out in 1951). When commissioned by the company Singer back in the ’60s to design a new sewing machine, he and his team enrolled in an intensive sewing class. He knew that if he was to design a better machine, then he needed to know exactly what operating one felt like. The lesson here is that rolling up your sleeves and putting yourself in your user’s world has no substitute; it’s one of the most effective ways to develop a sense of who they are and what their problems might be.

Where resources allow, conduct research to find out more about the people you are designing for. When possible, get out of the office, spend a day on site, and put yourself in the user’s environment. Find out what they do and how they do it, and observe their daily routine. By doing this, you will gain insight into how the product might fit into their life and find meaningful ways it could assist them. If the nature of the product or budget constraints do not allow this, then spend a day conducting one-on-ones with prospective users. And if that is not possible, then at least carry out telephone interviews or Web-based surveys.

Designers are responsible for introducing the user’s “voice� into the design process. When required, we should act as a conduit for the user, voicing opinions from their perspective. By understanding their problems and regularly weaving their voice into the conversation, we can help ensure that the user’s needs stay central to the process.

Know whose problem you are solving, and speak on their behalf.

Tell a Story, Sell a Story

Tell A Story, Sell A Story

To be a designer is to be a storyteller. Everything we produce has a narrative, whether accidental or intentional. Because design at its core is concerned with communication, storytelling is a natural extension of any thorough design process.

Stories reveal a user’s-eye view of the landscape and provide an extremely effective way for getting people, both users and designers, involved and talking with one another.

– Tom Erickson

Sometimes, a lack of a coherent vision can run a project askew. Joseph Selbie observed the following, based on his firm’s study of in-house Web design teams:

Members of teams performing less well not only tended not to understand the application as a whole, they saw no need to understand it as a whole: programmers did not care to know about users, user researchers did not care to know about programming limitations, and stakeholders were uninvolved and were considered “clueless� by the rest of the development team.

Communication breakdowns such as this are a recipe for disaster.

To prevent these situations, designers can call on storytelling as a means of optimizing collaborative effort and understanding among team members. Compelling stories can clarify the direction of a product and strengthen a team’s empathy with users. In sharing a narrative, all parties have a cohesive vision of the project’s goals and, as a result, are more likely to create a better product.

In his excellent essay “Design as Storytelling,� ex-Apple researcher Tom Erickson notes the following:

Stories are a sort of equalizer. It doesn’t require much expertise or training to listen to and tell stories. Team members from any background can be made part of the process of telling and collecting stories. And once stories have been gathered, team members can discuss the stories, argue about their interpretation, and generate hypotheses about users’ problems, needs and practices.

By reducing the mystery of the disciplines involved in a project and putting focus on what needs to be built, a story helps to establish a common language among everyone involved.

Cindy Chastain also highlights the need for such an approach in her article “Experience Themes,� in which she expands upon the storytelling process and explores how innate characteristics such as pleasure, emotion and meaning can be infused into the product experience.

Storytelling doesn’t just describe relationships: it also helps to build them. Try to translate your stories into the priorities of your users and weave them into your product. While the methods and materials of design give form to a digital product, Roger Sametz and Andrew Maydoney argue that the ultimate goal of manipulating type, color, imagery, space and time is to tell stories, “to engage ‘teller’ and ‘listener’ in a dialogue that builds comprehension, commitment, participation, loyalty and trust.�

Employ storytelling methods not only to strengthen the team but to strengthen the product’s relationship with its users.

Express Your Doubts

Express Your Doubts

If a man will begin with certainties, he shall end in doubts. But if he will be content to begin with doubts, he shall end in certainties.

– Francis Bacon

Doubt may seem like an unusual quality to voice in any product conversation, but it is essential for designers. Positive doubt is the beginning of wisdom, not the end of it. To be able to investigate and synthesize effectively, you must first remain open to all possibilities. Doubt calls on reason, encouraging the application of more rigorous evaluation methods. Questioning assumptions ensures that potentially unusable or redundant features are carefully filtered. It encourages a more thorough exploration of a concept, a product and its goals.

Gordon MacKenzie, author of Orbiting the Giant Hairball cites “attachment to outcome� as one of the biggest obstacles to creativity. As soon as you become attached to a particular outcome, you feel compelled to control and manipulate what you’re doing; and, in the process, you shut yourself off to other possibilities. Milton Glaser observes the same:

Doubt is better than certainty, If you think you know everything, you’re wrong. Rather doubt your abilities a little to give yourself room for improvement, but don’t doubt them so much that you’re too scared to try.

The designer’s responsibility is to ensure that many possibilities are explored and tested — prototypes are your friend. “Petâ€� functionality often lingers in products without adding value. Don’t be afraid to test the viability of such features and to eliminate them when necessary. Bear in mind that stakeholders sometimes need to see a bad idea realized in order to realize that it’s a bad idea.

Voicing concerns over whether a product is “good enough� isn’t whining. It simply demonstrates that you actually give a darn and that you possess the ability to recognize quality in your craft. Don’t compromise: view conversations as opportunities to refine and improve the product.

If you think something is not right, speak up and explain why.

Inform Your Intuition

Inform Your Intuitions

Designers will have to learn a foreign language to win them [managers, business analysts and developers] over. That language is data.

– Louis Rosenfeld

During product discussions, designers will regularly contribute opinions on the spot about various aspects of a design. If this occurs too early in the process, though, the information available to inform the decision might be limited — and so our intuition comes into play.

A designer’s intuition is developed over time through a combination of knowledge and experience. We can use this intuition to make the quick decisions that are often required during a design process. However, intuition-based decision-making is potentially problematic in team situations, where decisions usually need to be made collectively. If other people disagree with your choice, you cannot simply state that your intuition is more relevant or valuable than that of others.

In this situation, designers can use analytical methods to inform their decisions. Some relatively quick techniques exist to gather data, such as A/B testing and user surveys. The results of these can be interpreted and used to support your argument — when they actually do support it.

Nevertheless, striking a balance between data and design is important. Data should inform the process, not dictate it — otherwise, every product would be designed by statisticians! Adam Mosseri, a product designer at Facebook, gave an enlightening presentation on the subject called “Data-Informed, Not Data-Driven.â€� He details how Facebook intelligently interprets its vast amount of data but doesn’t allow itself to become a slave to it. James Landay, a researcher with Microsoft, sums up this need to compromise by calling for…

… a balance between analytical approaches to design (e.g. computer science, data mining and quantitative HCI experimentation) and more design-oriented approaches that are good at creating products that make an emotional impact on people and create a desire to own them.

The difficulty with pushing certain recommendations about the user experience of a product is that not everyone will always agree. When discussing a design, use soft words and hard arguments to confidently communicate your view. Where necessary, use data to support your intuition, but never blindly follow it through the process.

Great products are designed by people, not pivot tables. Never let anyone convince you otherwise.

Explain Your Decisions

Explain Your Decisions

Designers get up in front of people and explain why they’ve made the decisions they’ve made. And if you can’t do that, you can’t call yourself a designer.

– Mike Monteiro

Designing a digital product requires many decisions to be made. Collaborative decisions will be made via numerous media, such as meetings, instant messaging, email and even informal chats over lunch. Designers will also make many decisions independently, based on their own research and intuition. Over the course of a project, these decisions combine to form a long chain of interconnected thoughts, as the product begins to take shape. Keeping a mental record of all of this information is not feasible, because we would forget why certain decisions were made.

Kees Dorst captures the situation in Understanding Design:

Every designer knows the moments of complete disorientation while leafing through piles of sketches (What was the reason for this!).

To avoid this scenario, keep track of decisions and the reasons they were made, so that you can explain them when required. Simple annotations on wireframes might be sufficient to jog your memory.

  • “We chose this approach because…â€�
  • “The team preferred this concept because…â€�
  • “I decided to place this here because…â€�
  • “Users prefer this method because…â€�
  • “This prototype was deemed least usable because…â€�

When presenting a design, whether to an internal team or to a client, discussing the evolution of the product is sometimes useful. Avoid the lure of the Ta-dah! moment, revealing a concept without any context. Instead, introduce the work and briefly explain how you arrived at it. Engage your listeners.

A record of decisions is also useful when reviewing a project. If a stakeholder comes along in six months and asks, “Why were radio buttons used here instead of a drop-down menu?�, or “What happened to the mock-up that had modal error messaging instead of a status bar?,� you’ll need to have an answer. These conversations will be a lot more amicable if you can explain why those choices were made. Having a simple log on hand of those long-forgotten decisions can be invaluable.

Explain your decisions. Transparency will bring people on board.

Embrace Failure

Embrace Your Failures

Failing sucks; there’s no getting around it. Having said that, no one should ever be ashamed of failing. If you’ve never failed, then you probably haven’t achieved much either — unless you’re one of the lucky ones. A designer will experience various kinds of failure in their working life, some small and easily rectifiable, others large and valuable in their lessons.

If a product or even a feature is rejected, yet the team is still functioning as a unit, that in itself should be considered a small victory. Many successful designers in all disciplines often recall the many false starts and dead ends they had to experience before finding a great solution.

I made 5,127 prototypes of my vacuum before I got it right. There were 5,126 failures. But I learned from each one. That’s how I came up with a solution. So I don’t mind failure.

– James Dyson

When something is rejected, try not to sweep it under the rug — only then would it become a true failure. Avoid pointing fingers and attributing blame. Instead, focus on the product and the ways in which it failed to deliver. Get the team together, put your product up on the autopsy table, and ask the difficult questions.

  • Why did users reject this product?
  • Why did this feature tank in our usability testing?
  • Was this the right feature in the wrong place?
  • Was it the right product at the wrong time?
  • How can we avoid making the same mistakes again?

Nothing is morbid about conducting a post-mortem, as long as you identify the probable cause of death. You may never know for sure which factors contributed to the product’s downfall, but you will have a good idea. Learn from them. Ryan Jacoby recently suggested that in order for designers to get it right, they need to be “interested in being wrong.� He goes on to say:

Great designers and innovators see evaluation moments as learning opportunities. They couple confidence with humility and curiosity.

This captures well the incessant curiosity and mental dexterity of a good designer — traits that enable us to learn from our mistakes.

By conducting a frank conversation on the product and its shortcomings, designers can turn a negative situation into a positive one. The experience and insight gained will help you avoid similar errors in judgement in future projects. When the critique is complete, chalk it up to experience and move on.

Failure is probably the most expensive form of feedback you’ll ever get, but also the most valuable. Make sure to use it.


The path of every project will be unique, as will be the conversations that guide it. What we can do, however, is plan for more productive conversations, using approaches such as the ones explored above to guide the process along. The examples provided are but a few of the many conversations we can have while working on a product — they are not a bulletproof formula. Over time, a designer will learn to cultivate the conversations that they feel are necessary — and these will likely vary from project to project.

While a certain amount of solid documentation will always be needed, it is less important now than it may have been in the past. A 10-minute chat in the hallway today will often prove more informative and productive than a 20-page document next week. Fast iteration demands clearer lines of communication. By becoming keener listeners and speakers, designers can help secure the information and decisions that are needed to advance the product in the right direction.

Remember: there is no formula for a great solution, but rather many paths. Nevertheless, clear communication can make the path smoother and the solution smarter.

Related Articles

Related Books

  • Designing for People, Henry Dreyfuss
  • Orbiting the Giant Hairball, Gordon MacKenzie
  • Inspired: How to Create Products Customers Love, Marty Cagan
  • Storytelling for User Experience, Whitney Quesenbery and Kevin Brooks
  • Understanding Design, Kees Dorst

Illustration by Damien Weighill, in collaboration with Blast Design, for Conqueror: Endless Possibilities


© Darren Geraghty for Smashing Magazine, 2011.

  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress