BlogmyQuery – BMQ

I was a competitive road cyclist for four years. My bikes were good, but my race results were much less impressive. Instead of medals and trophies, all I had to show for it were shaved legs and a farmer’s tan.

Regardless, on the road to becoming a competitive athlete, I followed a rigorous training plan with concrete goals. These goals were specific, measurable, attainable, realistic and timely. With this training plan, I was able to quantitatively and qualitatively assess my progress and adjust my routine to match.

(Image: Stig Nygaard)

In the years since, I’ve hung up my racing jersey and replaced it with a designer’s hat. While wearing this hat, I (and many others) have been told to “create a good user experience.� We’ve heard this in creative briefs, project kick-off meetings and critiques. It may have been a bullet point in a PowerPoint presentation or uttered by someone trying to sell a client or company on the value of their services. But there’s a fundamental problem with stating that your goal is to “create a good user experience.�

It’s not specific, directly measurable, actionable, relevant or trackable. Thus, it will create disagreement and disorganization, sending many projects into chaos. However, we can avoid this by using S.M.A.R.T. goal-setting criteria when defining user and business goals.

Bad Vs. Good Methodology

Before we get started, let’s look at how a poor methodology can derail an entire project.

There was once a project to redesign a significant section of a company’s website. This section introduced visitors to the brand’s history and technology, and analytics indicated that customers who visited this section had a much higher conversion rate. Stakeholders believed that improvements to the content and navigation could result in even higher conversions. This was seen as a golden opportunity to increase sales by improving the awareness and presentation of the brand’s story. Thus, a complete project to redesign this section of the website was born.

Here is a summary of the project from the stakeholders’ perspective:

• High-level project goal
  Increase conversions and sales.
• High-level project strategy
  Leverage the history and technology section of the website.
• High-level project tactic
  Improve the content and navigation of the section to increase user engagement, better communicate the benefits of the products, and drive users into the conversion funnel.

Unfortunately, rather than communicate this to the design team, the goal for this redesigned section of the website was presented as follows:

Create a good user experience.

Sigh. There’s that phrase again.

The Problem

The designers were given a nebulous tactic masquerading as a goal. This meant that they had minimal understanding of the true objective of the project, which put them in a poor position to understand the problem and to hone the strategy and tactics to solve it.

To make matters worse, the lack of well-defined high-level goals, strategies and tactics made it difficult for the designers to define the architecture of the experience, in turn making it nearly impossible to set user goals and business goals for every page that needed to be designed.

(Image: numberstumper)

To make a long story short, the designers spent four months working through unsuccessful concept pitches and design revisions. The concept behind the designs constantly changed, and the content and features failed to support a cohesive user story. Meanwhile, designers and stakeholders had different expectations of what this section of the website was meant to accomplish, so solutions rarely satisfied both parties. Nobody knew the needs of the user, and the needs of the business were but a neglected thought in the shadow of “creating a good user experience.�

After these four months, there was zero progress. Not only was the project’s situation dire, but the lack of approved and delivered work was eroding the team’s morale. With no concrete user or business goals to satisfy, the team aimlessly pursued a “good user experience.� It was like being told to drive but not given a destination.

The Solution

I was subsequently pulled into this team as the project and design lead. My first priority was to bring awareness and understanding of the high-level project goals, and then lead the team through a comprehensive exercise to document the user goals. Although we didn’t have access to detailed user studies and customer information to create data-driven personas, we did our best with anecdotal experiences, competitive analyses, and website analytics to create user goals for each page. We then worked with the cross-functional teams to understand the business goals and KPIs.

Using these goals, I led the designers to write thorough content and feature requirements. The benefit to this approach was that all content and features were made to serve documented user or business goals. This encouraged product simplicity and reduced scope creep. These goals and requirements were then reviewed and refined with all stakeholders. Once expectations were universally understood and accepted, the team proceeded to create the architecture, interactions and designs.

This comprehensive methodology took less than three months. But the magic is not the methodology itself, but the discipline to identify concrete goals that satisfy five basic criteria.

UX S.M.A.R.T. Goal Criteria

As I mentioned earlier in my competitive cycling example, my improvement as an athlete was based on goals that each met the five criteria of the S.M.A.R.T. goal-setting technique:

1. Specific,
2. Measurable,
3. Attainable,
4. Realistic,
5. Time-based.

This technique can be applied to documenting the criteria for user goals and business goals:

1. Specific,
2. Measurable,
3. Actionable,
4. Relevant,
5. Trackable.

With these criteria in mind, what would be considered a S.M.A.R.T. goal?

S.M.A.R.T. User Goal Examples

Let’s use the product detail page for a fictional e-commerce website to illustrate. A product detail page is a page on which shoppers can learn more about a product for sale and add it to their shopping cart. It typically includes images of the product, the price, a description, and an “Add to Cart� button. Here is an example from a well-known fruit company:

The product detail page for earbuds in the Apple Store. Notice the images, price, description and “Add to Cart� button.

Based on a competitive analysis of many e-commerce product detail pages (and on personal experience from working with and studying how consumers make purchasing decisions), here are some user goals for the product detail page of a fictional e-commerce website.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Secondary user goal (UG2):

I want to purchase this product.

These goals meet the UX S.M.A.R.T. goal criteria because they are:

• Specific
  By stating exactly what the user needs to accomplish, these goals help us maintain scope and stay focused on designing content and functionality that is critical to our user’s success.
• Measurable
  For the primary goal, we can measure clicks to determine how users are engaging with the content. Alternatively, one-on-one interviews or customer surveys could provide qualitative insight into whether your content is relevant to the user’s interests. For the secondary goal, we can measure the percentage of visitors to the page who click “Add to Cart.�
• Actionable
  Because the goal is specific, we can readily identify content and functionality that satisfies the user’s goals. In this example, because users want to learn more about the product’s design, large product images should be included.
• Relevant
  These goals are appropriate for a product detail page, but not for a return policy or terms and conditions page. By keeping the goals highly relevant, the content and features that we introduce to satisfy those goals will be relevant, too.
• Trackable
  There’s no point being measurable if the data cannot be tracked over time. This is essential to determining the immediate, short-term and long-term success of our design and its future iterations.

In contrast, here’s a DUMB user goal:

I want a Web page that’s easy to use. (i.e. I want a good user experience.)

That’s not a witty acronym, and it doesn’t hide the fact that this user goal is not specific, measurable, actionable, relevant or trackable. It fails all five criteria because it fails the first: specificity. A good user experience has many facets, and without targeting a specific aspect of the page or product experience, there’s no action (strategy and tactic) to address it. If a goal is not actionable, then it has no reason to exist because there is no end towards which effort and action can be directed. Similarly, if the goals are not measurable, then there is no way to gauge the successes or failures of our actions, and subsequently no way to understand the product’s performance over time.

S.M.A.R.T. Business Goal Examples

UX S.M.A.R.T. goal criteria can also be applied to business goals. They are particularly relevant because businesses are run by numbers: number of clicks, number of customers, number of dollars, the list of measurable metrics continues. So, let’s take real-life business goals for the same product detail page of our e-commerce website as an example:

Primary business goal (BG1):

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Just like the preceding user goal examples, these business goals meet the UX S.M.A.R.T. goal criteria because they are:

• Specific
  By stating exactly what metrics the design needs to affect, these goals help us maintain scope and stay focused on designing content and functionality that will put us in a position to hit our targets.
• Measurable
  For the primary goal of increasing conversions, we can measure the number of page views and how many resulted in an add-to-cart. For the secondary goal of increasing cross-sells, we can measure the number of clicks on cross-selling products.
• Actionable
  Because the goals are specific, we can create more targeted strategies to accomplish them. For the primary goal of increasing add-to-carts, this could mean making the content on the page more relevant to users’ goals, or something as simple as improving the success of the add-to-cart button. For the secondary goal of increasing cross-sells, this could entail changing the visibility of cross-selling items (assuming we have already done a good job of selecting which related products to promote).
• Relevant
  The relevance of this goal depends on the high-level objectives of the project. If the objective is to reduce the number of customer support calls each day, then this goal might not be relevant. But if the objective is to increase total sales revenue across all products, then it is very relevant.
• Trackable
  We can count the number of page views and add-to-carts over an extended period of time.

By contrast, here’s a dumb business goal for the product detail page:

I want to make more money.

This is a poor business goal because it’s not specific and might not be relevant to this page at all. There are many ways to make more money, and without specificity in the strategy to accomplish this, creating a successful plan of action will be much more difficult. Remember, if a goal is not actionable, then it has no reason to exist because there’s no end towards which effort and action can be directed.

UX S.M.A.R.T. Goals Applied

So, now we understand the criteria behind well-defined S.M.A.R.T. goals and have applied them to the user and business goals for the product detail page of a fictional e-commerce website. How can we use this to our advantage as we move forward with the architecture and design of the page?

Associated Content and Feature Requirements

Because the goals we’ve defined are specific and actionable, we are able to propose content and features that directly satisfy them. Let’s revisit the four high-level goals of our product detail page and attach appropriate requirements to them.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Content and features required to satisfy this goal:

• Relevant images that represent the product as a whole;
• Relevant images (such as enlarged views and alternate angles) that show the product in detail;
• General description that provides a brief overview of the product’s purpose and benefits;
• Specifications that are relevant to consumers of this product type;
• Product variations or options (such as color, size);
• Selling price.

Secondary user goal (UG2):

I want to purchase this product.

Content and features required to satisfy this goal:

• Selector for product variations or options;
• Customer satisfaction guarantee (such as return policy, privacy policy);
• Quantity selector;
• “Add to Cartâ€� function.

Primary business goal: (BG1):

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Content and features required to satisfy this goal:

• Reference user goal 1,
• Reference user goal 2.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Content and features required to satisfy this goal:

• Related products that the user might also be interested in (for example, if the user is looking at the detail page for a small digital camera, recommend a small case to put it in).

Because everything must serve a documented goal, scope creep during the project’s lifecycle is reduced. This is not to suggest that content and features beyond these goals cannot be included. Components such as global navigation or a site-wide search box might be required even though they are not the purpose of the page. Determining what belongs on a page is admittedly not as black and white as these example might lead one to believe.

That said, setting content and feature requirements based on S.M.A.R.T. goals does help to determine the visual hierarchy of information on the page. This is extremely helpful during the wireframing stage.

A wireframe for the product detail page of a fictional e-commerce website. The user goals (UG1 and UG2) and business goals (BG1 and BG2) correspond to those outlined above. Download the complete wireframe for this example.

As we can see in the above annotated wireframe, the content and features that satisfy primary user and business goals (labelled UG1 and BG1) are more prominent in scale and placement than those that satisfy the secondary goals (UG2 and BG2).

Now, having applied S.M.A.R.T. goals across the planning and architectural phases of a project, we can see the benefits of this UX strategy, as follows:

• Goals are specific, measurable, actionable, relevant and trackable.
• Because the goals are specific and actionable, we can attach appropriate content and feature requirements to each one. Because the goals are relevant, these requirements are relevant, too.
• The hierarchy of the content and features is determined by the hierarchy of the goals that they are attached to. This informs the architecture of the wireframes.

With these benefits in mind, we can begin to understand how this positively affects other stages in the project’s lifecycle:

• Wireframes with well-informed structures and content are solid foundations on which to design higher-fidelity mock-ups.
• Because the goals are measurable and trackable, we can determine the success of the design during testing, learn from it, and make improvements in subsequent iterations.

Ultimately, these all contribute to our ability to understand the problem and craft an appropriate strategy and tactic to solve it. Our discipline in gaining focus in the earliest stages of a project will determine our ability to maintain focus when designing the functional aspects of the product at the end.

Conclusion

A great user experience is the result of setting concrete goals that meet both user goals and business goals. Unfortunately, I have seen many teams kick off a project with nothing more than a goal of, “Let’s create a great UX!� While a noble thing to strive for, it’s not specific, actionable or measurable. It contributes nothing to the planning or design phases, and it is the UX equivalent of a motivational high-five.

(Image: Dickson Fong. Original artwork: Banksy.)

Banksy once said:

“Artwork that is only about wanting to be famous will never make you famous. Fame is a byproduct of doing something else. You don’t go to a restaurant and order a meal because you want to have a shit.”

Likewise, a good user experience is the byproduct of many brand, product, design and development decisions. As designers, we must collaborate with our clients and ensure that we thoroughly understand the needs of their business and target audience. Only then can we be empowered to create appropriate strategies and tactics to achieve them.

So, don’t try to “create a good user experience.� Create a S.M.A.R.T. one.

Additional Resources

• “Locke’s Goal-Setting Theory,â€� MindTools
  A brief overview of Dr. Edwin Locke’s research on goal-setting and motivation, explaining how goals provide a major source of motivation and improve employee performance.
• “What Does Usability Mean: Looking Beyond ‘Ease of Use’,â€� Whitney Interactive Design
  Explains how user needs can be translated into user goals and requirements that are specified within a range of acceptable values.
• “Defining Actionable and Business-Driven KPIs,â€� Kaizen Analytics
  Explains how to define actionable business-driven KPIs based on business goals.

(al)

© Dickson Fong for Smashing Magazine, 2011.

Anyone designing Web-based properties today requires a basic understanding of interaction design principles. Even if your training is not formally in human-computer interaction, user experience design or human factors, knowing the fundamentals of these disciplines greatly enhances the chances of your design’s success. This is especially true for visual designers. Many visual designers are formally trained in art school and informally trained at interactive agencies.

While these institutions focus on designing communications, neither typically provides a strong interaction design foundation. Having a broader skill set not only makes your designs more successful but makes you more valuable and employable (i.e. you become the unicorn). While in no way exhaustive, to get you started, here are five key tactics to understand and implement in your next project.

Image credit: Kristian Bjornard

1. Talk To Your Customers

The most important thing to understand when designing an online experience is your audience. Understanding who they are, what they do for a living, how old they are, how they work, what they know about the Web, how they use it, on what devices, where and so on provides invaluable insight into their pain points that you are out to solve.

Setting clear constraints on your design also helps. For example, if your audience will predominantly be using mobile devices to access the Web in hospitals, then your design must be responsive to those devices and be compatible with the environments where the devices will be used. In addition, understanding your audience builds on a communication design foundation by revealing your users’ sensitivities (physical or cultural, for example) to things like color and typography.

Understanding your audience requires conversation with target users. These conversations can happen in a variety of forums. While impersonal approaches such as surveys work well enough, nothing beats face-to-face conversations with your customers. Depending on who you’re targeting with your work, finding your target audience may be as simple as going down to the local coffee shop, buying a handful of $5 gift cards and striking up conversations with the patrons there. Most people will gladly exchange 10 to 15 minutes of sharing their opinion for a coffee shop gift card. Other ways to find users are to post ads on websites like Craigslist, pull names off your customer lists, reach out to trade organizations (for specific user types, like nurses) and spend time in locations where your audience spends time (for example, music fans at a concert).

The initial conversations will be awkward, but as more and more take place, a rhythm develops to the questions. Also, patterns begin to emerge, allowing you to tailor the questions more appropriately with each interview. The lessons you take away from these activities can be used to create personas — i.e. aggregate representations of typical users of your design — that can help provide context to future design decisions.

A persona document. (Image: Todd Zaki Warfel)

2. Orient The User

Now that you’ve got an understanding of who your user is, orienting them when they use your design is important. Orienting your users gives them a sense of place in a non-static experience. To effectively provide that sense, your design should tell users three things:

1. Where they are
   Critical to any online experience is understanding where, in the broader context of the website, the user is currently transacting. If it’s clear to the user where they are, then there is a greater chance they’ll understand what you need them to do on that page. For example, if the user is aware they are on a “product page,� they should expect to see a purchase link and perhaps some other product options.
2. How they got there
   If providing clarity on the user’s current location provides context for expected actions, then showing them the path they took to get there provides a safety net. That safety net is the comfort of knowing that if the user has wound up in the wrong place, they can back out and try again.
3. Where they can go from here
   You’ve made it clear where they are and how they got there; if they are in the wrong spot they can backtrack and try another path. But if they’re ready to move forward or they believe the path back won’t provide the content they desire, then letting your users know what options are available from this point on is imperative. Never leave a user in a dead end. There should always be an option to proceed. A perfect example of this is a search results page that yields no results. While you should let the user know that nothing matches their search query, there should be options that lead them to the answers they seek (for example, related search terms). Ways forward can be manifested in your website’s navigation but can also be implemented as affordances. Affordances are elements in the interface that are obviously clickable, such as buttons and sliders.

Amazon does a good job with its no-results page.

(For a great primer on affordances, pick up Don Norman’s The Design of Everyday Things. While a bit dated, it lays a solid foundation for how product designers should think about their products.)

Clear website orientation provides comfort to users. It also reduces the chances that users will make mistakes and increases the chances that, when they do, they’ll be able to recover quickly.

3. Simpler Is Better

Visual designers are driven to add elements to a layout that may be aesthetically pleasing but don’t necessarily serve an interaction purpose. While certainly much is to be said for aesthetics adding to the polish and feel of an experience, when designing an interactive experience, consider opting for simpler design. Simplification means reducing the elements on the screen down to the most basic ones, the ones that will facilitate the task that the user has to complete. Start with that as a baseline, and then add ornamentation sparingly. Consider the brand of the website. The brand is a reflection not only of the aesthetic but of the experience. If a website is gorgeous, but its beauty makes completing a transaction impossible, then the website (and brand) will ultimately fail.

Aesthetics will always have a place and powerful purpose in any experience, yet ensuring that the experience is usable first is critical.

4. Design For A Dialog

Where visual design training focuses primarily on communication, interaction design puts a heavy focus on feedback loops — in essence, a conversation between the user and the website. As you work out an experience, provide ways for the system to communicate back to the user when they’ve done something right or wrong. Ensure that your experience makes clear when the user has succeeded and when an action is required to complete a transaction. Use your visual design and communication skills to build a visual language for this feedback dialogue. Ensure that no matter where the user is in the experience, any information that is coming from the website is consistent in design and presentation method. Different types of information will require different treatments. The user will learn the system quickly, and a dialogue with the website will begin to occur. In essence, you’re humanizing the experience (and the company behind it) by proactively predicting your users’ needs and presenting information and actions that mitigate user frustration.

Think Vitamin keeps the conversation going with its readers.

5. Workflow: Understanding The Before And After

Visual design is beautiful. It’s also static. Interaction design builds a workflow from page to page and from state to state. As you design each page, consider what the user can do on this page and how the next step in the process fits into the workflow. If you’ve just added a sign-up form to the page, think about what will happen when the user presses the “Submit� button. Will the page refresh? Will there be a confirmation page? What if there are errors in the form? What if the user hits the “Back� button? These are all components of the workflow of the experience. Each page or state is just one small component in the user’s click stream. The challenge is that each user might have a relatively unique click stream, depending on how they got to your website and why they came. You’ve used your knowledge of the user to orient them, and you’ve provided a simple interface that creates a successful dialogue with them: now ensure that each interaction has a logical next step. That next step should fit into the experience and visual language that you’ve created, so that the experience feels whole and consistent. These elements are what add credibility to the brand and increase users’ trust in your design.

Bonus Tip: Understand Your “Materials�

Jonathan Ive, designer of the iPod (among other things), promotes the idea that designers of all types must understand the material they’re working with. This hold true for interaction design as well. Understanding the “materials� that make up the Web is critical. A cursory education in HTML, CSS, JavaScript and related technologies will only enhance your understanding of the medium and provide a realistic perspective on your designs. A great resource for this is the group of developers who will be implementing your work. Strike up regular conversations with them about your design, and get a taste of whether your proposals are feasible given the technologies they employ. Even better, start learning the basics yourself. You don’t have to become a star coder, but knowing enough about how the medium in which you work behaves can greatly shape the interactions you design.

Summary

Interaction design is a multi-faceted discipline that links static communications together to form an experience. Understanding the basic principles of this discipline is core to designing websites that are not only aesthetically pleasing but that actually solve business problems and bring delight to their users. This article just scratches the surface of interaction design. For Web designers of any kind, considering these fundamentals when designing any transaction or interaction is imperative.

(al)

© Jeff Gothelf for Smashing Magazine, 2011.

As web designers and developers we tend to view the web somewhat differently than most. Our work keeps our focus tuned to the finer points of the field as we browse, even in our time off. We tend to get inspiration from this way of seeing the web. Hints of techniques or approaches to attempt for our next projects emerge from all corners of the web. And given that our next client could emerge from any arena, we need to be prepared for any and everything. Like for instance our next client could be some sort of charitable organization that works off of donations, and as such, they might need us to design them a site complete with a donation page.

Now there are many considerations that need to be made when we are designing, especially a page whose calls to actions are often vital to the mission for the client behind it. Which is why we have gathered together a showcase of well designed donation pages for our readers, complete with some resources at the end of the post to help prepare them for those potential clients to come calling. Take a peek down through to see some examples of both subtle and more extravagant designs that have tackled this task with style.

The Showcase

Operation Warm is a nice site with comfortable, welcoming color scheme. The donation page calls vary in color, however the main calls to action blend with a majority of the site given that they are the same color. The secondary calls stand out a bit more as they break from the blue.

Manna FoodBank uses a natural, earth-tone color scheme which goes well with their mission. The call to action button stands apart nicely even with only the slight changes in color, next to the information about their cause.

The Red Nose Day site uses a simple two tone color scheme. The red colors pervading the donation page denoting the passion for the mission, and driving people to take action.

Oxfam is another site whose donation page design focuses all of its attention on the necessary mission and calls to the readers.

Network for Good has a wonderful design, with three courses of action that their readers may follow. Each with a large, eye catching call to action button.

Save the Children has a sleek design for its donation page with designated avenues for assistance that the users have at their disposal. With so many courses of action for users, it could easily become a cluttered mess, but the design keeps it all organized well.

The Make-A-Wish donation page, while constructed well, does suffer from a lack of distinction for its calls. The blue becomes somewhat overwhelming with the amount of information it contains.

Mozilla has a subtle donation page design with a creative header attached to their site where fans and users can donate to keep their mission alive.

American Heart Association‘s donation page is stylish and focuses the users attention directly towards the calls. The color scheme works well, with the subtle uses of white inserted into the blue.

The Kiva site’s donation page is sharp and focused on multiple routes to lending a helping hand, and the large boldly colored call to action buttons stand out from the rest of the page nicely.

Doctors without Borders has a great donation page design, using tabbed windows to separate the various paths that users can take to pitch in. Overall the design is simple and effective.

Virgin Money Giving is a unique donation page, with a category breakdown so users can find the type of charitable organization they are looking to support.

Giving to Johns Hopkins has a stylish design pushing its cause. The contrast in colors on the header and call to action button work wonderfully in making them stand out.

Humane Society‘s donation page uses large images and bold buttons to draw the users attention and persuade them to take action.

Keep a Child Alive has a very sleek design with large buttons with various ways to contribute to the mission. With a slight grungy effect used to highlight areas of the page, the design stands out.

ASPCA has another subtle donation page design with the purple calls standing out from the overall orange design colors. Soft coloring imparts a sense of comfort and eases the readers into the cause and taking action.

Invisible Children has a donation page that is as stirring and emotive as their mission. With large images of the children the world tends to overlook connects the design with the cause in a simple yet effective way.

MJFF uses warm and inviting colors which work well for engaging the readers. The gradient on the actual donate button does help it stand out, but the coloring is still a bit too similar to the rest of the accents to really draw the eye.

The Natural Resources Defense Council has a very simplistic design with overly large and bold call to action buttons. This no frills approach puts pure focus on the mission.

Planned Parenthood‘s donation page uses a form for the main appeal to the readers, with secondary (more subtle) calls in the upper right corner. Overall, the large header and large body text compliment each other leading the reader into the ‘action center’.

Donate Life California has a somewhat whimsical design, with pink calls to action buttons that really stand out from the rest of the site, yet match with the logo of the organization.

Red takes minimalism to stylish levels with their donation page design. The overly large typographical elements really do wonders for boldly drawing the eyes to the action areas.

The Nature Conservancy has another simple, sleek donation page. Mostly text covers the page, with two subtle calls positioned under the header where users tend to expect the navigation to be.

Charity: Water‘s donation page is keeps the focus on the mission with the aid of this understated design.

The Action for Children page design has a large, eye catching call to action area which sets off the donation area nicely and effectively pulls the reader to it.

Tutorials & Tools

Below are a small handful of resources that you can use for making the most of any donation page you have to design. Go through them now, or save them for when your next client needs their site to go this route. Either way, we hope you find them useful.

Donation Page Optimization Basics

WordPress Donate Plugin

Increasing Online Giving: 10 Tips to Optimize Your Donation Landing Pages

Paypal Custom and Donation Forms

How To – Create A Donation Page for WordPress

The Most Effective Online Donation Page Ever

(rb)

You’re developing a new website and have decided to use some CSS3 and HTML5, now that many of the new specifications are gaining widespread support. As you’re coding the theme and thinking of how much easier these new technologies are making your job, you decide to stop for a while and test in other browsers, feeling a bit guilty for getting carried away and having forgotten to do so for a while. “Please work,� you whisper to your computer, while firing up all of the browsers you have installed. Browser A, check. You smile, feeling a bit relieved. Browser B, check. Your smile widens, and you start to feel better already. Browser C, “FFFFUUUUUUUUUUU…!�

Sound familiar? You might be surprised to hear that this is not necessarily your fault. With the competition in the browser market these days and the fast pace at which the new specifications are developing, browser makers are implementing new stuff in a hurry, sometimes without properly testing it. CSS3 and HTML5 are much more complex than their predecessors. The number of possible combinations of new features is huge, which leads to the most common cause of bugs: two (or more) things that weren’t tested together. As a result, developers these days stumble upon browser bugs much more frequently than they used to.

Why Should I Bother Reporting Bugs?

If you don’t, perhaps no one else will. Maybe the bug you’ve discovered is so rare that no one else will stumble on it. Or maybe they will, but they won’t know how to report it. They might think that it’s their fault, just as you originally did. Besides, if you’ve used these new technologies in a way that triggers the bug now, you will likely do so again in the future as well, so you would directly benefit from the bug getting fixed. And in the process, you’d be helping thousands of other developers avoid the frustration you’ve faced.

You might think that reporting the bug would be pointless, because it would take ages to fix, and would take even longer for users to upgrade to the fixed version. However, for all browsers except Internet Explorer (IE), this is not true anymore. Users of Firefox, Opera, Safari and Chrome upgrade really quickly these days, because the software pushes them to do so or (in the case of Chrome) doesn’t even give them a choice. Also, some bugs get fixed quite quickly, especially the ones that come with a decent report. Keep reading, and your own bug reports will likely fall in this latter category.

Making A Reduction

The first step is to reduce the problem to its bare minimum. If it turns out to be a browser bug, you will need to include this “reduction� in your bug report. Also, this will help you figure out a potential workaround until the browser vendor fixes it. Even if it’s not actually a browser bug, doing this will help you realize what you did wrong and fix it. Lastly, it’s a valuable aid in debugging in general.

Here is the process I follow to create reductions:

1. Make a copy of your project. If it includes server-side code, then first save the rendered page locally; the rest of the process will be identical from this point on.
2. Start removing CSS and JavaScript files. Eventually, you’ll find that removing one makes the problem go away. Add that one back and remove the others (except any files it depends on). In some rare cases, you might find that the bug persists even after removing all CSS and JavaScript code. In these cases, the bug is more than likely HTML-related.
3. Now you need to find the exact code in the file that triggers the problem. Start commenting out parts of the code until the problem goes away (being careful not to introduce any new problems in the process). I find that the quickest way to do this is like doing a binary search: first, comment out around half of the code; if the bug persists, then remove that code and comment out half of the remaining code, and so on; if the bug disappears, then remove the uncommented code and proceed with that. You might find that deleting and undoing is quicker than commenting and uncommenting. Sometimes you have to do this process twice in the same file, because some bugs can be reproduced only with a particular combination of different code parts.
4. Put the remaining CSS and JavaScript code inline by transferring it from the external file to a <style> or <script> element in the HTML document. This will make the reduction even simpler because it will be contained in only one file.
5. Now, simplify the HTML. For example, if it’s a CSS bug, then remove everything that CSS rules don’t apply to. If the rules apply to a nested element, try applying them to the <body> instead and see whether the bug reproduces. If it is, then remove all of the <body>’s descendants.
6. Change the document’s <title> to something relevant to the bug. Check the whole thing carefully for details that you wouldn’t want other people to see, because you usually can’t edit it after attaching it to your bug report. (I learned this the hard way.)

Now that you have your reduction, examine the code. Is it actually correct? Browser makers can’t be held accountable for the way their products handle invalid code — except for HTML5 markup, which has strictly defined error-handling. Validating the code might help, but take its output with a grain of salt. (Note that CSS vendor prefixes are valid, even if the CSS validator disagrees.)

If you have some time and want to be extra nice, here are some other things you can do to make an even better reduction:

• Test to see whether the bug is more general than the case you have discovered. For example, if you discovered that an engine doesn’t handle border-radius: 50% correctly, then test whether the same thing happens with other percentage-based values. Or if a CSS gradient from black to transparent does not display correctly, see whether the same thing happens when you use a transition from background-color: transparent to background-color: black; if it does, then that would mean the problem stems from general interpolation and is not limited to CSS gradients. Even if you find that it’s not more general than the case you originally stumbled on, do mention your experiments in the bug description, so that the developers don’t have to repeat them.
• Try to find a workaround. Can you change or add something in the code to make the bug go away? This could be as easy as converting ems to pixels or as hard as adding a whole new declaration. Be sure to mention the workaround in the bug report.
• Make it function like a test case, or create an additional test case. These are the special kinds of reductions that QA engineers make for automated testing systems. Such tests show the color green in browsers that don’t have the bug and red in the ones that do. Other colors may be shown, but not red and green at the same time. This is an easy task with some bugs, and incredibly hard with others.

Sometimes the nature of the problem is quite obvious, so creating a simple test case from scratch is quicker. I’ve found JSFiddle to be an invaluable aid in this. However, bear in mind that browser vendors usually prefer that you upload your own simple HTML files rather than provide JSFiddle links. If you do decide to use JSFiddle, then uncheck the “Normalized CSSâ€� setting, remove any JavaScript libraries (unless your bug needs them to be reproduced), and append /show to the URL, so that it leads only to your test case, without the rest of the JSFiddle UI.

If you don’t have the time to make a reduction, reporting the bug is still a good idea. A bad bug report is better than none at all, and the same goes for reductions. In this case, the browser developers will have to create the reduction themselves. The difference is that they’re burdened with doing this for many more bugs than you can imagine. You only have to do it for one: yours.

Should I Report It?

There are many reasons why you might not need to report the problem as a bug after all:

• It turns out it’s not really a bug,
• It has already been fixed in the latest nightly build,
• It has already been reported.

Let’s tackle these one by one.

Is It Really a Bug?

In most cases, when you isolate the problem to a simple reduction, it’s fairly obvious whether it’s a browser bug or not. However, there are some caveats to this.

A while ago, I realized that even though outline-color: invert was in the CSS specification, it didn’t work in all browsers that support outlines. In particular, it didn’t work in Webkit browsers or Firefox. Those browsers didn’t drop the declaration, but just treated it as though it was currentColor. So, I went ahead, created a reduction, and filed bug reports with both browsers. After a while, I was informed that a footnote in the specification actually permits user agents to do this, so it wasn’t actually a bug. The moral of the story is to check the specification carefully — not just the table that is included in every CSS property, but the whole thing. Knowing these details will make you a better developer anyway.

On another occasion, I was reading the “CSS3 Backgrounds and Bordersâ€� module and found that it allowed percentages to be used for border-width, unlike CSS 2.1. I tested it, and it didn’t work in any browser. So, I filed bug reports in some of them, only to be informed that this was dropped in the “devâ€� version (i.e. the not-yet-published version) of the specification. The moral of this story is that, for specs still under development, don’t check the published specifications to determine whether your issue is actually a bug. Instead, look at dev.w3.org, where the most up-to-date versions of the specs reside.

Of course, in many cases, a bug is not really a bug or a lack of understanding of the spec, but just one of those stupid mistakes that we all do (aka brain farts). I remember once how distraught I was over my JavaScript not working at all in Safari, even though it gave no errors. After a while of struggling to make a reduction, I realized that I had previously disabled JavaScript in that browser to test how a website worked without it and had forgotten to enable it.

Likewise, a few days ago, my SVGs weren’t displaying as backgrounds in Firefox, even though they displayed when I opened them in new tabs. I then realized that I had two background images in the same declaration, the other one being a CSS gradient, and I had forgotten to add the -moz- version.

The one I’m most embarrassed about is when I actually reported a bug to Opera about pointer-events not working in <select> menus and was then informed that Opera hadn’t implemented pointer-events in HTML elements at all. D’oh!

In some rare cases, the bug is indeed a bug but not a browser bug. Specifications have their fair share of bugs, too. If the spec defines something other than what happens or if it defines something that conflicts with the rest of the spec, then it most likely has a bug. Such bugs should be reported in the relevant mailing list (www-style for CSS) or the W3C bug tracker. Even if this is the case, many of the guidelines mentioned below still apply.

Is It Reproducible in the Latest Nightly Builds?

If you haven’t already installed the nightlies of browsers, you should. These are the latest (potentially unstable) versions of browsers. Download them from these links:

• IE 10 Platform Preview 2
• Firefox Nightly
• Opera Next
• Chrome Canary
• Webkit Nightly Builds

Obviously, if your bug is not reproducible in the latest nightly of the browser, then you don’t have to report it. Just wait until the build propagates to a stable release. In other words, all you need is patience, young Padawan.

Has It Already Been Reported?

If after checking the specifications and the latest nightly, you’re still confident that it is a bug, then you need to search whether it has already been reported. Your best bet is to use the search engine of the relevant bug tracker. Don’t forget to search all statuses, because the default on some bug-tracking systems is to search only confirmed and open bugs (excluding unconfirmed and fixed or otherwise closed ones).

Be vague in your search, especially if the bug affects a feature that’s not very popular. For example, for this Webkit bug, a search for “multiple fileâ€� would show the bug, whereas a search for “input file multiple dom propertyâ€� would not; I was inexperienced when I filed it and didn’t know the exact terminology at the time. If the bug tracker is public, sometimes searching on Google also helps (adding site:url-of-bug-tracker after your keywords).

If your issue has indeed been reported, some bug trackers allow voting. Mozilla’s Bugzilla gives every user a limited number of votes (the limit is in the thousands), which the user can use on any bug they wish. Also, Chrome’s bug tracker features a star in the top-left corner, which you can click to indicate that you consider the bug important. I’m not yet sure whether the developers take this into account, but voting certainly doesn’t hurt.

Different Engines, Different Bug Trackers

Every browser has its own bug-tracking system (BTS).

• Internet Explorer (new bug)
• Firefox (new bug)
• Opera wizard
• Webkit (new bug)
• Chrome (new bug)

Safari and Chrome share the same engine (Webkit), so bugs that can be reproduced in both should be reported in Webkit’s BTS. Chrome has its own BTS as well, intended for bugs that are reproducible only in it. Also, if you’re dealing with a JavaScript bug in Chrome, report it to the V8 bug tracker.

You will need to create a free account to file bugs with any of these bug trackers (except Opera’s Wizard). But it’s a one-time thing, and it’s useful because it allows you to easily track bugs that you’ve reported.

All of the browsers’ bug trackers are public, with one exception: Opera’s. You can report Opera bugs through the public form I linked to above, but to access the BTS and to discuss your bug and monitor its progress, you will need to become an Opera volunteer (or an employee!) and sign an NDA. Volunteering is by invitation only, but if you submit a lot of good bug reports, there’s a good chance you’ll be invited.

Filing A Good Bug Report

The most important part of a good bug report (and the one most commonly done wrong) is the reduction. Hopefully, you’ve done that already, so the hardest part is over with. The rest probably won’t take you more than five minutes.

Providing a Good Summary

A good summary is the second-most important part of a bug report. Don’t be afraid to be verbose, if it actually adds something (don’t just babble). To take one from an actual report,

Background image disappears when body{display:table} is used (common CSS hack for correct centering + scrolling in Firefox)

… is better than “Background image disappears when body{display:table} is used,â€� which in turn is better than “Disappearing background image.â€� Of course, all three are better than “CSS broke. Please fix!!!!11â€�

Sometimes you may want to add keywords to the beginning of the summary to make the report more findable. For example, if your bug is about CSS3 gradients, you could prepend the summary with “[css3-images].â€� To get an idea of the exact tags used in a module, look at other bug reports. It will usually be the same as the id of the specification, which is located at the end of its URL path. For example, for the CSS3 module “Backgrounds and Borders,â€� the URL is http://www.w3.org/TR/css3-background/, and the spec’s id is css3-background. Also, these summary “tagsâ€� can be OS-specific. For example, if your bug is reproducible only in Mac OS X, then prepend your summary with “[Mac].â€� If the bug is about something that used to work fine in previous versions, then prepend your summary with “[Regression],â€� or add “regressionâ€� as a keyword if the BTS has such a feature.

Categorizing the Bug

The category to which your bug belongs is usually quite obvious, provided you take a few seconds to check them all. For CSS bugs, these are the most common candidates:

• Internet Explorer: “CSS and HTMLâ€�;
• Firefox: “Style System (CSS),â€� all the “Layoutâ€� components;
• Opera Wizard: “Web page problemâ€�;
• Webkit: “CSS, Layout and Renderingâ€�;
• Chrome: doesn’t let you categorize bugs (its developers do it for you).

John Resig suggests some ways to categorize JavaScript bugs.

Other Fields

• You can be as verbose in the “Descriptionâ€� field as you need to be. Explain the bug in detail (what you expected to see, what was actually displayed, etc.) and any interaction needed to reproduce it. Then mention any workarounds you found, how other browsers handle the case, and any other notable observations. But don’t start babbling about what you were doing when you discovered the bug, no matter how funny or interesting you think it is. QA time is precious; please don’t waste it with irrelevant detail.
• The “Productâ€� will usually be “Core.â€� If you have a choice between “Coreâ€� and the browser’s name, choose “Core,â€� because bugs filed under the browser’s name are usually for the UI.
• Regarding “Platformâ€� and “OS,â€� try to test in other operating systems if you can. (You do test your websites in different operating systems, right?) If the bug is reproducible in all OS’, then select “All.â€� If it’s reproducible in only one, then mention that in your description and/or summary.
• Avoid changing the “Severityâ€� or “Priorityâ€� fields, because you will tend to overestimate.
• Most people who report bugs don’t fill in the “CCâ€� field. But if you know someone who works for a given browser vendor, especially someone who frequently replies to similar bug reports (browse the reports if you’re not sure), then cc’ing them might help the bug get noticed more quickly. In some cases, this could mean the difference between a bug report getting noticed in a few days and one going unnoticed for months.
• If you have the time to take a screenshot, by all means do so, especially if the bug is reproducible in only one OS.

What Not to Do

Never, ever report multiple bugs in the same report. Handling these is very hard for browser developers. Think about it: what status should they assign to a report if they fix one bug, but the other turns out to be a duplicate? Or only one of the two turns out to be a bug? You get the idea.

I can understand that you might be frustrated from having had to deal with that bug, but being rude won’t help. Stay polite, and keep thoughts like “I can’t believe you can’t even get this right, you morons!� to yourself.

Some Examples

Example 1: Reducing the Original Problem, Realizing It Was Your Mistake

While developing twee+, a handy little app for posting long tweets (and my entry in the 10K Apart contest), I found out that even though it worked in mobile Safari for reading, it crashed when you tried to make an edit. I had no idea what might have been causing this, so I made a copy and started reducing. After commenting out parts of the JavaScript, I found that if I removed the onresize event handler, the problem stopped occurring. And then it made total sense: I adjust the rows of the textarea when the user resizes the window. However, in Mobile Safari, this triggered a resize event, resulting in a dreaded infinite loop. So I removed the resize event handler for mobile. It’s not like the user can resize the window there anyway.

Example 2: Making a Reduction From Scratch, Filing a Bug

A big part of my upcoming CSS3 workshop in Amsterdam is hands-on challenges. Attendees will download my slide deck (which is essentially an HTML + CSS + JavaScript app) and try to solve some 5- or 10-minute challenges on everything taught. A challenge slide would look like this:

I prepared a lot of the slides in Chrome. When I opened them in Firefox, I was greeted with this ugly sizing of the textarea:

In this case, I didn’t follow the reduction process laid out above, because I had a hunch that the bug was related to the way I sized the textarea. So, I fired up JSFiddle and made this simple example, in which the bug could still be reproduced. I then tested it in Opera and observed that it behaved like Firefox, so it was probably Webkit that was buggy. I tested it in the Webkit nightlies and saw that it hadn’t yet been fixed.

Before going any further, I tried to see whether the bug was more generic. Does it happen only with textareas or with all replaced elements? I went ahead and tested <img> and <input> and found that it happens only with form fields. I did another test to see whether it also happened with top/bottom rather than left/right. It did not. I also tested on Windows, and it’s reproducible there as well.

The specification confirmed that it was indeed a bug: “The used value of ‘width’ and ‘height’ is determined as for inline replaced elements.� After a bit of searching on Google, I found this blog post, which describes the bug but does not mention an official bug report. So, I searched Webkit’s bug tracker for “textarea absolute,� “textarea positioned� and “input positioned� and couldn’t find anything relevant. It was bug-reporting time!

I went ahead and created this bug report. Let’s hope it goes well.

What Happens Next?

At some point, usually after a few days or weeks, someone will modify your bug’s status. If it turns out to be a “duplicate,� don’t feel bad: it happens to the best of us, even employees of the browser vendors themselves. If the status gets “confirmed� (usually with the status “new�), this is a good indication that it is indeed a bug and that you did the right thing by reporting it. Last but not least, if the new status is “assigned,� it means someone is actively working on the issue (or plans to do so soon), so it has a high chance of getting fixed soon.

When your bug gets a status of “resolved,� check the “resolution� field. If it says “wontfix,� it means that they’re not planning to rectify the issue, for reasons usually stated in detail in an accompanying comment. The reason is usually either that it’s not a bug (in which case, the most appropriate resolution status is “invalid�) or that they just don’t want to work on it for the time being. If the latter, you could argue your case and explain why the bug is important, but don’t get your hopes up. Last but not least, if it’s “fixed,� you can congratulate yourself on doing your part to make the Web a better place.

Further Reading

• “A Web Developer’s Responsibility,â€� John Resig
• “Test Case Reduction,â€� Webkit
• “The Most Important Field in a Bug Report: The Summary,â€� David Baron
• “How to Submit Good Bug Reports,â€� Opera
• “How to Submit a Good Bug Report,â€� Internet Explorer

Thanks a lot to David Storey, Divya Manian, Paul Irish, Elika Etemad and Oli Studholme for their helpful tips and reviews.

Front Cover: Image source

(al)

© Lea Verou for Smashing Magazine, 2011.

It’s a pretty safe bet to say that the vast majority of people like movies. They’re usually entertaining and sometimes even informative or thought-provoking. But most designers probably don’t pay too much attention to how they might be able to offer inspiration for website or other designs.

But most movies, especially those with large budgets, have extensive art direction and production design happening to make sure the entire look of the movie is exactly the way the screenwriter and director have envisioned it. Whether it’s a fantasy film, a family movie, a historical drama, or anything in between, there’s a good chance that a team of dozens of people worked hard to make sure the visual design of the film was absolutely perfect.

Below are a number of popular films from the past few years. Many of these have won awards for their art direction and production design, but not all of them have. In addition to the stills included below, try to watch some or all of these films with an eye on the design of the sets and costumes, as well as how the characters interact with them.

Harry Potter and the Deathly Hallows: Part 1

Harry Potter and the Deathly Hallows: Part 1 (also referred to as Harry Potter 7) had some phenomenal art direction. It was nominated for an Academy Award for Best Art Direction in 2010.

In this image, there are a few different design principles going on. First of all, it’s a beautiful example of asymmetrical balance. The men in the image are considerably larger and darker than Dolores Umbridge in this shot. But the pink of Umbridge’s dress gives her more visual impact, balancing out the men in the image.

Speaking of the pink of Umbridge’s dress, that’s another great design element. Because of Umbridge’s undeniably evil nature, the pink is a surprising choice. These kinds of unexpected choices add interest and irony to the production design, and can be applied to any kind of design.

The last design element in this particular shot, and one that almost goes unnoticed, is the pattern in the floor. The circular nature of the flooring creates a natural flow and directs the viewer’s eye from right to left. Flow like this is an important element that indicates to your visitors where they should be looking on the page and helps control their interaction and user experience.

This still of the Weasley twins offers some ideas that aren’t often discussed in terms of web design, but can add a lot more visual interest to your designs. The main take-away from this image is the idea of repetition, but with subtle changes made. The twins are identical, visually the same, and yet there are subtle differences in their costumes and general appearance. The shift in color and pattern, while maintaining the same basic shape and size, adds a lot more visual interest while still maintaining the consistency that repetition provides.

The King’s Speech

Period films, by their very nature, have extra attention paid to the details of their production design, because anything that is out of place can ruin a viewer’s experience by pulling them out of the story. The King’s Speech is no different.

This still from the film is an excellent example of creating priority in an image without going over the top. The entire color palette consists of three basic hues in various shades: brown, gold, and black (with just a hint of white). So how do you make the King stand out in such a muted color scheme?

The answer is simple: you make him slightly lighter and brighter than his surroundings. This is an easy one to accomplish in web design, and goes to show that you don’t need something to be jarring in order to draw attention to it. Using a highlight color that still blends seamlessly into the rest of your palette for the most important element in your design sets it apart while still remaining elegant and understated.

Pride and Prejudice

There have been a number of adaptations of this novel by Jane Austen, but I’m going to focus on the one from 2005 with Keira Knightley and Donald Sutherland. This film had fantastic production value, perfectly capturing the mood of the novel.

The first thing Pride and Prejudice can teach us about is contrast. And particularly how contrast and color can contribute to our perception of things and the mood created. In this particular scene, Mr. Darcy is shown wearing almost entirely black, while Lizzy is in a white, flowing dress. It creates stark contrast between their characters, painting Darcy as the villain while Lizzy is pegged as the heroine. This example of color and contrast is a simple, yet effective, way of creating a positive/negative relationship.

By the end of the film, though, Darcy’s costumes have lightened considerably, while Lizzy’s have darkened. Basically, their characters have now arrived at the same place. Here, the lesson is that reducing the contrast creates harmony between potentially conflicting elements.

Alice in Wonderland

Tim Burton’s reimagining of Alice in Wonderland won the Academy Award for Art Direction in 2010, and rightfully so. It’s a masterpiece of visual design, and used a surprising number of practical set elements, rather than just CGI.

If there’s one thing that Alice in Wonderland can teach us about design, it’s not to be afraid to play with the scale and size of elements. Alice changes size numerous times throughout the film, often requiring interesting alterations to her costumes. Other characters, namely the Queen of Hearts, have disproportionately large body parts. The results in every case are stunning, and show the potential of unexpected scale. In your website designs, consider creating very large or very small elements that can surprise your visitors.

This still from the film has important lessons about working with complex, busy designs. The background elements in this particular shot are very busy, but through creative use of lighting, the focus is placed squarely on Alice and the direction in which she’s going. This makes it easy for viewers to know where they should direct their attention, and keeps the busy design from feeling overwhelming. Clear direction like this is invaluable in web design, and can be created by placement of elements, color choices, and scale.

Sweeney Todd: The Demon Barber of Fleet Street

Sweeney Todd is another Tim Burton film, and won the Academy Award for Best Art Direction in 2007.

The biggest lesson Sweeney Todd can teach us is the importance of mood in a design. Throughout the entire film, the mood is kept consistent through the use of various design elements. In this case, the mood is macabre and run-down, and is established through the use of dull, lifeless colors and dark lighting. There are very few flashes of color (and most of them are from blood). The result is a film that is completely immersive and draws the viewer in. It wouldn’t have been nearly as effective if the sets had been more typical of period pieces, or if brighter colors had been used throughout the set designs.

Regardless of what mood you want to establish with your site, making conscious choices throughout the design that establish and reinforce that mood will certainly result in a more immersive experience for your visitors. It also strongly influences how your audience will feel about the site, and whatever that site is offering, whether it’s selling a product or providing information.

There Will Be Blood

There Will Be Blood is another Academy Award nominated film for Best Art Direction, from 2007.

This particular shot from There Will Be Blood shows us a lot about the importance of what isn’t there, and how it reacts with what is. White or negative space in a design is just as important as any other design element, and yet it’s often overlooked or not used as well as it could be.

Note here how the character, Daniel, interacts with the negative space created by the blue sky. There’s no clear delineation between the occupied space and the negative space because of the way he bridges the two.

Another prominent feature here is the contrast created by the muted greens and browns of the main elements in the scene and the blue of the sky. But even though the blue contrasts the rest of the scene, there’s still a muted quality to it which ties everything together.

The Imaginarium of Doctor Parnassus

The Imaginarium of Doctor Parnassus is a whimsical, off-beat film with lots of set changes, costume changes, and even actor changes. It was also Heath Ledger’s final onscreen performance.

The biggest thing we can learn, as designers, from this film is not to disregard the importance of a sense of whimsy. The scenes from inside the Imaginarium are off-the-wall and unexpected (if not a bit creepy at times). They had no problem trying new things, and blending elements that might not normally be included together.

Water for Elephants

Water for Elephants is another period piece, this time set in the early part of the 20th century.

The main thing this image can show us is how to use different textures to create contrast between elements. Jacob’s costume and props are all rough materials: leather, burlap, and denim. In contrast, Marlena’s dress is satin, the opposite of everything Jacob is wearing. It reinforces the differences between them. Texture is relatively easy to incorporate into website designs, but is often only there to provide visual interest. Consider using it, instead, as an integral part of the page’s design, one that provides visual clues to the relationships between different elements.

The Chronicles of Narnia: The Voyage of the Dawn Treader

The third installment of The Chronicles of Narnia series, based on the books of the same name, was released in 2010.

This image is another great example of how to handle visually complex designs. There’s a lot going on here, between the background and foreground elements, the characters, and the lighting effects, but it’s all made less overwhelming by the use of a clear focal point. Lilliandil is cast in a circle of light, making her significantly brighter than her surroundings. The light orbs in the rest of the image reinforce her position as the focus of the scene.

Make sure that any complex design you create has a clear focal point. This provides grounding for your visitors: they know where they’re supposed to be looking. It gives clear purpose to your design, allowing you to create a design that is rich and visually complex without being cluttered.

Stardust

Stardust, based on the Neil Gaiman graphic novel and novel of the same name, was released in 2007.

This still from the film has a few lessons to teach us. First of all is the Golden Ratio (which is similar to the rule of thirds, but places important elements just a bit closer to the center than the rule of thirds does). Tristran and the gap in the stone wall are both positioned almost perfectly in regard to the Golden Ratio in this image. The right-hand side of the wall is also positioned along the Golden Ratio, which lends further balance to the composition. Using the Golden Ratio in your own layouts creates a more balanced and harmonious design.

Another element here is the angle of the stone wall. It leads our eye further into the image, creating a sense of depth and motion. The same can be done through the use of perspective and lines in your designs. It adds a more dynamic layer to your designs, giving a sense of energy that’s often missing.

Star Trek

The JJ Abrams reboot of the Star Trek franchise has been polarizing to say the least. But the set and costume designs used were undeniably well done.

This may sound a bit too simple, but one of the biggest things Star Trek can teach us is not to be afraid of a white background. Throughout the film, white sets on the Enterprise are prominent. What this does is allow the important elements—the characters and the action—stand out.

Now, that doesn’t mean that the backgrounds are just plain, stark white. There’s still a lot going on there. Take that as your cue to play with texture and pattern, while maintaining a light and neutral background color.

Monsters

Monsters was an indie movie set and filmed in Mexico. There are a couple of important things it can teach us about good design.

Designers tend to shy away from splitting their designs right down the middle, or putting the focal point of a design right in the middle, with little else on either side. This still from Monsters, though, shows us just how much impact that technique can have. When you want to make a statement with your design, creating a more symmetrical layout with your focal point right in the center can be a powerful way to do so.

Another thing that Monsters teaches us, that’s harder to capture from a movie still, is that hinting at things can be just as powerful as showing us something outright. Throughout the film, the Monsters are rarely seen or even heard from, which creates a sense of suspense—we know they’re out there, but we don’t know where or when they might attack. A similar sense of suspense and mystery can be applied to your designs in various ways.

Defiance

Defiance is set in Germany during WWII.

This still from Defiance shows us the impact that creating a sense of motion around a stationary focal point makes that focal point stand out more. At the same time, the motion keeps the design from feeling stagnant, as can happen when the focal point is too strong without much happening around it.

Conclusion

If there’s one thing film art direction can teach us, it’s that paying attention to all the little details in a design can have a big payoff in the end. Would Alice in Wonderland have won an Oscar for Best Art Direction if so much effort had not been put into the look and feel of the film? Certainly not. The same can be said of any of the others above.

The next time you watch a film, look carefully at the background sets, the costume choices, and even the lighting of each scene. Look at the mood it creates, and how sometimes unexpected elements can offer a lot of extra visual impact and irony to the overall production. Then think of ways to incorporate the same kinds of things into your own designs.

(rb)