Big Data. Big Decisions
InformationWeek
Special Coverage Series

Commentary


Web Design Contracts 101: Don't Get Snookered

You know your company needs help with its Web site, but how do you sign a Web design contract that will ensure you get what you need at a fair price? These tips can help!

Resource Nation provides how-to purchasing guides, tips for selecting business service providers, and a free quote-comparison service that allows business owners to compare price and service offerings in over 100 categories from Web site hosting to graphic design.

Setting up an engaging online presence for your business is just about a given these days, right?

Well, maybe not. According to a Nielsen Online study earlier this year, almost half of small businesses don't even have a Web site. What's worse, the vast majority of those that do have a Web site spend a mere three hours a week marketing it, spending less than 10% of their marketing dollars on Internet-based efforts.

There's already plenty of great information out there to convince you why your company needs a well-designed Web site, but not every small business knows how to get there. Assuming you're going to hire a Web designer to create your site, how do you figure out what should be in the contract to make sure you get what you need at a fair price?

The Basics
Law school courses break down contracts into three parts: Offer, Acceptance, and Consideration. For practical purposes, this means that a contract can take many forms. Approving a written e-commerce Web design proposal, making payments on invoices for design work, and other actions can all constitute binding agreements -- agreements whose terms might not be entirely in your favor.

When it comes to Web design, it's important to have a formally drawn up, written agreement that outlines the basic responsibilities of both parties. The contract itself doesn't need to go into design specifics ("logo to contain pantone color X")-- in fact, many Web designers use service level agreements (SLAs) to describe the details of the design work. While it can be helpful to have an attorney draft this document, most designers have standard forms that they modify for each individual project.

Here's an outline of what should be addressed in a typical Web design contract:

Statement of Work
The Statement of Work (SOW) is a broad outline of the project scope, or a roadmap for the project. Since planning out the project can be a job in itself, many designers charge clients to prepare an SOW -- some call it a consulting fee or a project proposal. That's not unreasonable.

Whether free or paid, the scope of work or work description should include

  • Number of pages and/or page templates to be created
  • Number of programs or scripts (for browser compatibility)
  • Integration of other programs/applications (form set up, social media integrations)
  • Amount of written content
  • Ongoing work (hosting, maintenance)

Some designers also include graphic design time, browser compatibility efforts, and the time it takes to train the client how to update the site themselves (for example, changing product information on an e-commerce site) in the scope of work. The statement of work should describe the project, not the site itself.

Timeline
A project timeline is a key component of any Web design contract. Web design is a very collaborative process -- from a designer's point of view, the provider is never fully in control of the timeline because the client has to approve elements like layout, content, and other design work before the project can move forward. The contract should include "benchmarks" for the completion of certain items, and a specified duration for ongoing services like Web hosting (if it's provided by the designer). With your launch date in mind, you can work backwards with the designer to identify the dates when each element of the job should be completed. Be prepared for the designer to hold you to this timeline and charge more if approval deadlines are not met.

Definitions
The way a contract is worded is very important. Avoid ambiguity at all costs -- if your contract has an upcharge for "major revisions" to the design plan, it should also define the differences between a "major revision" and a "minor revision." "Design elements," "design changes," and other terms can be pretty ambiguous, which can lead to misunderstandings and even legal action down the road if the designer/client relationship goes sour. You should never assume the meaning of an industry term that appears several times in a contract. If you're not absolutely sure what it means, get the definition included in the agreement.

 1 | 2  | Next Page »


Related Reading


More Insights




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

BYTE encourages readers to engage in spirited, healthy debate, including taking us to task. However, BYTE moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. BYTE further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.

Follow InformationWeek

By The Numbers

What Are Your Primary Concerns About Using Big Data Software?

Base: 417 respondents at organizations using or planning to deploy data analytics, BI or statistical analysis software
Data: InformationWeek 2013 Analytics, Business Intelligence and Information Management Survey of 541 business technology professionals, October 2012

What Do You Think?

What's your attitude about SQL analysis on top of Hadoop?
We want fast, standard SQL analysis capabilities on Hadoop ASAP
Hadoop is for unstructured data; SQL is for relational databases
We'll give SQL on Hadoop a try, but relational DBs will remain the mainstay
Given strong SQL support on Hadoop, we'd nix the data warehouse
We're not interested in Hadoop
No opinion



Related Content

From Our Sponsor

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Business leaders often need a visual snapshot of data to quickly grasp and use it. This paper identifies five challenges in presenting data and how visual analytics can resolve them. Solutions are suggested to overcome the challenges of: speed, data clarity, data quality, displaying meaningful results, and dealing with outliers.

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Today's competitive advantage requires a deeper understanding of your business, your market and your customers. As an IT executive, you can drive that knowledge transformation. In this white paper, learn how to make decisions as a strategic business leader and three steps to begin an analytics initiative within your enterprise.

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

High-performance data visualization turns sophisticated analyses into meaningful graphics, leading to faster and smarter decision making. In this white paper, learn how visual analytics can transform big data, with additional features such as real-time functionality, mobile compatibility, robust applications for technical groups and accessibility for nontechnical users.

Big Data: Lessons from the Leaders

Big Data: Lessons from the Leaders

Financial performance, competitive advantage, operational efficiency, strategic decision making - every business goal can extract value from big data, and the time for doubt or inaction has long passed. In this Economist Intelligence Unit report, in-depth interviews with data pioneers reveal the link between the effective use of big data and the bottom line among other results.

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Which came first, the data or the decision? This white paper makes the case for having a decision in mind, then tailoring big data's volume, variety and velocity to achieve business results such as overcoming customer dissatisfaction or creating well-informed strategies in real time.

Informationweek Reports

Research: The Big Data Management Challenge

Research: The Big Data Management Challenge

The challenge of big data is real, but most organizations don't differentiate 'big data' from traditional data, and nearly 90% of respondents to our survey use conventional databases as the primary means of handling data. We'll help you understand what constitutes big data (it's not just size) and the numerous management challenges it poses.