Over the years we have made some big transitions at The Wojo Group. Although we used to be primarily concerned with client work, over time we have directed more and more of our effort towards internal projects. Some of these projects have included Motionspire.com, a motion graphics gallery we launched a couple years ago, and SimpleCart(js), the open-source javascript shopping cart that turned out to be quite popular.

However, another project we’ve had in the works for quite some time is HelloRent.com, an apartment finder that doesn’t suck (in our humble opinion). We’re really excited about this project and we believe it has the potential to shake up the industry. Recently we have been focusing almost all of our efforts towards HelloRent. Thus, we have not been able to devote any significant time to development of our other projects, blogging, or client work.

Although we wish we could do it all, we have to be realistic with our time constraints and our abilities. Thanks to everyone who has supported us so far, either by reading this blog, visiting one of our creations, or spreading the word about what we’re up to here at The Wojo Group. We do plan to eventually return to more frequent blogging, and someday we will hopefully have the time to continue developing our other projects. In the meantime, though, please feel free to head over to HelloRent.com, subscribe to our email newsletter, and request an invite if you are interested in giving it a try. As always, we’d love to hear your feedback.

Thanks again for your support.

In the first part of this article, we looked at some of the main advantages of using a contract. Now, we’ll take a closer look at what should actually be included in a web design contract. Some of these principles apply to all contracts, but some of them apply specifically to the design and web industries.

1.) Pricing Terms

Obviously, one of the primary purposes of a contract is to spell out the pricing terms – and this is the area of the contract the client is likely to be most interested in. The way this section is structured will depend a great deal upon your pricing model. As I argued previously, a hybrid pricing model is probably the way to go, but this may depend on your company or it may differ on a project-by-project basis. If you do use a hybrid model (offering a quote that may be different than the actual price), make sure you clearly specify that the quote provided is provisional and may be subject to change. If you are using a fixed quote model, then you will have to make sure that you include a very detailed and accurate description of the project deliverables (see point 3).

2.) Payment Terms

You may include these details in the section on general pricing, but specifying payment terms is very important in a design contract. First of all, you will want to make sure that at least some money is paid up-front (generally 25-50%). Indicate that work will begin after this money is received, so that they actually have some motivation to cut the first check.

Secondly, tie each subsequent payment to a clear deliverable or to a specific time period. If they want monthly payments, this should be easy to specify in a contract. But if they pay you along the way based on the stage of the project, you will want to be very specific about what this entails. Is the design complete once everyone is completely happy with the design, or once the second-stage design comp has been delivered? Don’t tie a payment down to anything vague and unspecified.

As far as invoice term goes, in my experience you can expect companies to take as long as you give them to pay the invoice (or longer). I’m consistently amazed by how long it takes a larger company to cut and deliver a check for $1,000 to a small design firm. I’m not sure there is a good answer to this – requiring the check in less than 30 days is generally outside of industry standards and probably won’t actually result in a quicker payday anyways. My advice is simply to assume that you will have to wait approximately 30 days to receive a check for any work, and try to account for this fact as you manage your company and adjust your cash flow expectations accordingly. If anyone has any advice on getting companies to pay their invoices promptly, please let me know!

3.) Project Workflow

It’s a good idea to write the basic workflow you expect for the project into your contract. Specify the different stages you’ll go through as the project progresses and when the client will need to approve the work done. This way, the contract is not just legal jargon, but actually a useful document for both client and designer to help direct the project’s process and guide expectations.

We break our project workflow down into the following components:

1. Research
2. Information Architecture
3. Wireframes
4. Design Compositions
5. Page Creation
6. Website Launch
7. Post-Launch Research
8. Website Finalization

In fact, we have developed two standard contracts; one for smaller website projects that involve a simpler workflow, and one for big projects that require some intensive research before and after the development process.

4.) Timeline Expectations

Along with the budget, the project timeline is one of the most critical elements to many clients. You should definitely mention that timelines may frequently change, and that any estimate you offer is a good faith best judgment – but not infallible. This is also a good opportunity to hammer home the point that the client has responsibilities too – such as getting you content – and if they fall behind then so will you. Fight the temptation to offer a best-case scenario timeline, because we all know that true projects never follow the best-case scenario.

5.) Maintenance Agreement

Some clients seem to expect free maintenance for life, but as a designer you know that this is not feasible. Clearly specify what counts as maintenance vs. simply fixing problems as part of the initial contract. At the Wojo Group, we generally include customized maintenance agreements outside of the bounds of the standard contract.

6.) Limited Liability and Indemnification

This is the part of the contract where you try to protect yourself from some really nasty legal problems. Basically, clauses on limited liability and indemnification should indicate that you will not be held responsible for any actions brought against the client as a result of the website, and that the client will reimburse you if you are subjected to such actions.

7.) Arbitration Clause

You’ll want a clause in your contract specifying what happens if claims against you are in excess of the limit for small claims court. In this worst-case scenario, you want to limit your exposure to huge lawsuits and mounting legal fees. Arbitration is the way to go because it keeps the dispute out of the courts. Instead, both parties present their case before one or more ‘arbitrators’, and each party agrees to be bound to the decision made. This avoids the potentially nasty appeal process, leads to lower legal costs, and results in a quicker decision. Hopefully, it will never come to this…but just in case you want to have your bases covered.

8.) Design Credit Agreement

Generally speaking, you want to specify that you have the right to use the project in your portfolio. Also, you might want to have a small design credit inserted into the website, generally placed in the footer. If clients are squeamish about these items, then you can cut them out. However, as a general rule of thumb it is a good idea to keep these options open for you, especially if you are working on a project that will make a great addition to your portfolio.

9.) Additional Expenses Agreement

In the course of web design, you may need to make significant expenses for specialized fonts, images, and so forth. Make sure it’s clear that the client will be billed for these items at actual cost, and that they will always be notified before such purchases are made on their behalf.

10.) Cancellation

Neither party should be able to bail on a whim, but if both of you want out, there should be an easy way to mutually cancel the contract. Make sure you specify that you will be paid for all hours of work completed up until the time of cancellation if the client wants out.

11.) Cross-Browser Compatibility

If you’re a web designer, you know there are a seemingly endless number of browsers – especially if you count all of the mobile browsers now available. Despite the abundance of choices, however, there really are only a few browsers that have any significant percentage of the market – Internet Explorer (6, 7, and 8), Firefox, and Safari. Make sure you specify which browsers you plan on building the website for. Sure, you could design the website to be compatible with Netscape 4 – but this will obviously require some serious time commitments and call for a bigger paycheck. If you fail to mention the issue of cross-browser compatibility, then you may have clients coming after you when their website doesn’t load in their favorite antiquated browser.

As a somewhat extreme example, a recent client called us complaining about some fairly bizarre problems, which we couldn’t replicate even in IE 6. We eventually learned that the client was using the AOL browser that comes with the dial-up service. Remember that thing? You never know what browsers or devices people are going to use to view their websites – so make sure you specify up front what browsers will be compatible and include this in your contract.

12.) Client Content

Oftentimes the most challenging part of finishing a website is getting content from the client. Despite breathing down your neck to make progress on the design and programming of their project, you need to engage in medieval torture methods to get any content out of them. Make sure you clearly indicate that any delay in delivery of content from the client will result in timeline delays.

It’s also wise to specify the formats you accept for content. Frankly, we don’t want to get any WMV movie files or publisher documents. In our contract, we specify the acceptable formats for text, graphics, audio, and video content. You may also want to specify that there will be additional fees if they give you print content that you have to type in manually.

13.) Mistakes

To be fair to clients, they should not have to pay for our mistakes. However, in the design industry, ‘mistake’ can be a vague term. Make sure you clearly specify what counts and what doesn’t. You should fix a blatant error for free, but if you produce a perfectly good design composition that the client happens to hate, then you haven’t made a mistake at all and you deserve to be paid for your work.

We also have a section in our contract discussing what happens if a third party is hired to work on the website. You can’t be held responsible for someone else’s mistake, nor expected to fix them for free, so indicate that any repairs or changes you have to make as the result of third-party tinkering will be billable.

14.) Assignment of Project

It’s probably a good idea to mention that you have the right to assign subcontractors to work on portions of the project. To be fair to the client, however, you should guarantee the work of any subcontractors to the extent that you guarantee your own. However, if you get in a jam and need some extra help, you’ll be glad you left this option open.

15.) Referral Program

Word-of-mouth advertising is very important for our company, so we include a referal incentive program written right into the contract. We offer 5% of the referred project’s revenue – but you might want to try something different. Not a necessary element of a contract, but useful nonetheless.

One of the first questions you must ask yourself if you are doing freelance work or running a small business is “will I use a contract?” Conventional wisdom indicates that you should always use a contract when entering into business with somebody else. Despite this advice, many freelancers or small business owners either do not use a contract at all or use one that doesn’t spell out the agreement adequately. Our company has learned the hard way that writing effective contracts is a must. In this article, we’ll look at some of the main reasons why using a contract is a good idea.

Getting on the Same Page

One of the biggest advantages of using contracts is it allows you and your client to get a clearer idea of what the project entails. It can be used to clearly define payment terms, the project timeline, and the expected project deliverables. Our contract actually walks through and describes in clear terms our web design process. There is no need to view contracts as a necessary evil full of legal jargon. Instead, view the contract as a tool that helps both parties stay on track.

Avoiding Scope Creep

‘Scope creep’ is the project management buzzword that describes the phenomenon of ever-growing project demands. A client starts off wanting a simple website with a shopping cart, and before you know it they’re requesting live chat features, a discussion forum, and user profiles. Scope creep can also take a more subtle, more sinister form. It may involve really little things like constant requests to upload a bit of content or a suggestion that involves making one more page for the site. But, even these minor additions to the project can add up and kill your time if you aren’t careful. If you have a well-written contract and design proposal, then both you and the client can clearly see the scope of the project as originally agreed upon.

Scope creep is not necessarily bad in and of itself, as long as you have a way to deal with it fairly. After all, it’s unlikely that the client is going to know exactly what they want right when they first begin the project, and they are likely to learn things along the way that might require a shift in strategy. It is not realistic to stick rigidly to an original agreement, because things change and evolve over time. But, a contract can help you to fairly and reasonably manage a change in scope. Make sure that your contract contains provisions that lay out the costs associated with any expansion of the workload or significant change in direction that may occur during the course of the project. If managed correctly, ’scope creep’ can actually be a good thing – allowing you to get paid for doing more work on a project you are already working on.

Provide Legal Protection

Unfortunately, we live in a litigious society, so the risks of some sort of legal action are higher than ever. Do you want to appear in court without a signed contract to defend your position? On the other hand, if you are trying to collect money on a completed project, do you want to be in small-claims court without a signed agreement in hand? Obviously, we all would like to avoid this type of nasty confrontation, but even if you would never take it this far, there is no guarantee that your client will return the favor. Protect yourself with a contract. As long as you follow your end of the deal, a signed contract will come to your defense.

Even if you never actually go to court, the mere existence of a contract can really help you out. Clients who are tempted to bail will be a bit more hesitant when they realize that they made a legal agreement.

Note that a contract also provides the client with legal protection. A contract should also ensure that you, as the designer, don’t bail on your client or treat them unfairly. Be sure to explain this benefit to the client when asking them to sign a contract. Many people tend to be suspicious of contracts and suspect foul play whenever they are used. This is a false conception, though, because a contract actually protects both parties.

Weeding Out the Bad Apples

Frankly, requiring a contract is a good way to filter potentially terrible client relationships. If a client is unwilling to sign a contract, this is a sign of trouble ahead. Rather than lamenting the loss of a project, celebrate the fact that you may have dodged a bullet.

One of the biggest lessons our company has learned over the years is that we don’t want every single client we can get. Just like clients are looking for a good fit with a design company, you should look for a good fit with a particular client and project. Perhaps you’re desperately strapped for cash, and this advice sounds a bit idealistic. However, the headaches, lost time, and frustration that comes with a bad client relationship are not worth it, and often aren’t profitable in the end anyways. It definitely won’t be profitable if they bail on you mid-project or refuse to pay. But if they sign a contract, it indicates that they take the project seriously and probably at least intend to pay you.

Why Not Have a Contract?

What are the main reasons for operating without a contract? Perhaps the biggest concern is that clients won’t like them, since they may view it with suspicion. This is particularly true for smaller clients – many big ones have a lawyer on staff to look it over (and big companies expect to deal with contracts). However, as I’ve explained before, a refusal to sign a contract is a strong indication of a potential trouble client. Also, if a client seems uncomfortable about signing, take the opportunity to explain the benefits of the contract. A good contract will actually protect them as well, and it will allow both of you to get a clear idea of what the project entails.

Another objection to contracts may be that they are too time consuming. Drafting up a contract for each client is a laborious task – and this time could be better spent doing actual design work. However, in reality, you can probably make a contract template that applies to most projects, and vary it slightly for each client as needed. And with plenty of online resources to help you, writing a good design contract shouldn’t be all that difficult. In part two of this article, I’ll go over some tips on what to actually include in a design contract and provide some more resources to make the whole process a lot easier.

We all just spent a few dedicated days listening to talks and having long hard discussions about building web apps in Miami at FOWA. There’s so much to take away that it’s impossible and far out of the scope of this blog to cover it all here. However, we thought we’d share some of the bigger points that really struck us.

Build as little as possible to start.

If you build a massive app with 300 features, then your users may be stuck using what you’ve given them. However, if you launch your app or new feature with the bare minimum, then your users will use what you’ve given them and tell you what direction to go to make improvements. A great analogy brought up by Daniel Burka of digg is the story of an MIT architect. This architect built a building and instead of sidewalks outside it they just covered everything in grass. Then they came back a year later and got on the roof. They took a picture of all the wear and tear on the grass made by the foot paths of all the people going to and from the building and covered them with cement to make the sidewalks. Let your users pick the direction of your app.

The future of web applications is people.

This was a point brought up many times by multiple speakers. It revolves around the idea that we’ve started and built the web first, then we added people. We are going to focus greater attention on how to build the web more around people and less around technology. Facebook Connect is a huge example that seemed to be everywhere at fowa, including a presentation by Dave Morin on the topic. Facebook Connect is just an example of the broader concept – if you build an app that brings about a lot of new tools and tech for users than you need to learn how to make those tools and tech revolve around people, not their function. Build your apps around people, not just good function.

Be a skeptic.

Don’t ever think that because this tip helped person A it’s going to help you. Don’t listen to how this new tool coming out can really help person B and assume it can help you. Really, really think about the hundreds of tiny factors that made it work for them. Through that search you’ll find out what might work for you and you’ll see it’s nearly always somewhat different. Moral of the story, facebook connect is awesome but I don’t care (though lots of other people probably do). Atlas from 280 north brought a tear to my eye it’s so good, but I don’t think it’s going to work out for me as well as he made it seem it would. Percentage coupons work for 37signals but why on earth should I think it will give me the same results? Be careful of anecdotal tips, find out what works for you.

Twitter, WTF?

Seriously it’s gotten out of control. When I heard, “for the first time ever you can tweet to space” I thought, really? Is that surprising? Is twitter that old that we really view that as a breakthrough? I heard twitter said at fowa as much as I used to hear “web 2.0″ thrown around. Don’t get us wrong, we’re not knocking it. We even have our own twitter page to prove it.  However, we did see 10+ people within twelve feet of us using twitter at once (in fact, we started tweeting just to see how many screens we could see our tweet on). Google is not the Internet. Neither is twitter- and don’t forget that.

Recognize the value of what you are creating.

One of the first things mentioned at the conference by the opening speaker Jason Fried (of 37signals) was that web developers need to start charging more. Many of us feel that we have to develop an awesome web app and provide it for free to get anyone to even pay attention. Jason argued that it hurts the industry. Rather than succumb to this temptation, we need to develop sustainable business models. If we create something that is truly of value, there is nothing wrong in charging a fair price for that value. Free is dying, start making money.

Give people a reason to love you.

Consumers have more power than ever before. Not only do they have a growing number of choices, they have more information (and more potential influence over others) than in the past. If people are going to stick with you, they have to have a good reason to. And this comes back to truly caring about your customers. As Gary Vaynerchuk put so eloquently, “You want a marketing strategy? CARE!!!”

Design matters. A lot.

I tend to be a functionality guy. But the importance of compelling design was a theme that ran consistently throughout the conference. Delicious Library was offered as a telling example; this program made millions by taking something that could already be done (making a catalog with Excel) and giving it an attractive and fun interface. Even though functionality is important, at the end of the day we enjoy using things that are well-designed. Make your apps fun to use and good to look at, people lust for movie stars, not old fat balding men.

Overall Future of Web Apps Miami 09 was an excellent experience and we wouldn’t hesitate for a second to go back again. Great job to all the folks at Carsonified.

Ok everyone, we here at the wojo group are getting pretty excited for next week. On Saturday, we’re packing up our cars and driving straight through the night. We’re not stopping until we hit Miami. Why, you may ask? FOWA 2009!

For those of you who are a less of a geek than I, FOWA is the Future of Web Apps Conference. It is one of many wonderful events that Carsonified puts on every year.  We will have the pleasure of spending 3 days in downtown Miami, attending workshops, presentations, parties, and fraternizing with the ‘web-developers A-list’.

We are going to try to keep all of you updated from the conference this year, using this crazy thing called ‘Twitter’.  So, check out twitter.com/thewojogroup next week (Feb 22-24) for updates, pictures, and stories from FOWA Miami 2009.  

And for those of you lucky enough to be going to FOWA also, we’ll see you there!