Posted On March 30th, 2011 Author Kyle Racki
Filed Under Business, Marketing, 0
You’ve come up with the perfect idea for a website! A social-media application that let’s users (insert brilliant idea here). You’ve secured the funding, and have done your due-diligence to find, interview and ultimately assemble a dream team of talented designers and developers to make your ingenious idea a reality.
When you’re asked how much traffic and revenue you expect from the site, you modestly predict that within the first month alone, you’ll get anywhere between 10,000 - 100,000 unique visits. Sure, during that first month, you only expect to cover your overhead and break even. But two months after launch? Heck, you’ll already be preparing for early retirement! The ad revenue alone is going to top the $1 million mark, and that’s not even taking into account the third month, when you sell the website to the highest bidder (they’re naturally going to be clawing at each other to become the lucky buyer of your fortune 500 enterprise).
I realize that this is coming across as sarcastic and condescending — so I digress…
This exaggerated scenario resembles how some entrepreneurs approach a new internet business venture. It’s exciting to come up with an idea that has legs, and even more so to see it come to fruition. However, I believe that over-confidence has a counter-productive effect on a web business and that it’s far better to be over-zealous. Let me explain the difference:
Over-confident website owners
Over-confident website owners feel that just because an idea seems good and because friends and family think it’s great, that it will require almost no work to make a success, or that it will require work only short term and then become self-sustaining. To inexperienced website owners, once we website it built, the work is done and now it’s just a matter of marketing it.
What happens is that these people realize shortly after launch that the site is not getting the traffic or attention they feel it deserves, and it puts them in a re-active state, changing the site on the fly and quickly running out of the money required to make these changes.
Zealous website owners
On the other hand, a more experienced website owner knows how much time and effort it takes to successfully run a website and then be able to monetize it. So instead of becoming over-confident, she become over-zealous (in a good way). She starts small, maybe with only a simple website, and she pour her energies into it. It becomes her hobby. For the first while, this person isn’t worried about how much money she’s making, just how much quality content is being generated and how much discussion can be ignited.
Many simple websites have been gradually built to the point that they are ready to be commercialized, but only once they have built a steady following and respect among users. This cannot happen overnight. It can only happen with hard work and determination.
Start simple, plan for complexity
In the case that your website idea is not just a content-driven blog or community site, but rather a larger, more complex web application, the advice here is still to start as small as you can. The reason? You will need more money to maintain and improve the site over time. Don’t blow your wad of cash at the very beginning when you don’t even know what kind of update you’ll get. A successful web application is never a one-shot deal, it always evolves over time. Plan for that growth.
If you build it, they won’t necessarily comment
Another scenario in which website owners can become over-confident is with user-commenting. All too often I’ve been asked to build the ability to comment on a website blog, only to told later to remove it because the owner is afraid he will receive too many comments to have the time to moderate.
There are two fundamental problems with this line of thinking.
- If you don’t have time to approve or moderate comments, then you don’t have the time to write content quality regularly for a blog. This is like someone who wants to have a dog but doesn’t feel they’ll have the time to walk it. If you can’t make the time, then don’t have one. There is no way to “automate” a blog in any kind of genuine manner.
- These people are grossly overestimating how much commenting their site will actually get! It’s hard to get users to comment.
Most users read so many blog posts, tweets, wall posts and news articles on a daily basis that the only time they will actually take the time to comment is if they either know the writer or if they really feel what they have to say is valuable. As a website owner, you may have a lot of readers but still find it tough to ignite much in the way of good conversation. It’s hard. It takes patience and determination to write content that really encourages users to interact.
So lower your expectations, but don’t curb your enthusiasm. Approach a website like it’s going to be an uphill battle, but one you won’t lose. It’s just going to take hard work and a long attention span, then when if finally does become a success, you’ll be that much more satisfied with the results.
Posted On March 15th, 2011 Author Kyle Racki
Filed Under Design, Business, 0
Over the years, we at Headspace have developed a pretty tight process for creating websites. However, I find in some cases, clients have a very fuzzy idea of what they want out of their website in the beginning. Even after our in-depth planning stage, clients will make fundamental change requests to their website very late in the game, and often at a time it will impact the budget and timeline of a project.
So how do we avoid this? First of all, let’s examine our planning process (which is probably more-or-less similar to many web design company’s processes):
After a proposal is accepted and our client is ready to move ahead with us, we schedule a kick-off meeting. The goal of this meeting is to:
- acquaint the client to the project manager and lead designer
- review the needs of the project and what came out of the RFP/Proposal process
- discuss really specific details that will help form the website strategy.
After this meeting, we internally compile each others’ notes from the meeting (as soon after the meeting as we can, actually). We then deliver 3 important pieces of documentation to our client:
- A Statement of Work, which in high-level detail, indicates what we will perform, what the agreed upon fees are, and some other legal mumbo-jumbo which serves as a contract between the two parties.
- A Strategy Brief, which outlines in more detail what we want to achieve with the website and how we plan to achieve it. It includes parts of the kick-off conversation, such as target-audience, competition, conversion goals etc.
- A Function Spec, which includes a site-map (showing all of the pages views on the site), a wireframe for each main view (which shows where we will allocate each content block visually on the site without getting into the look and feel just yet), and a written, technical document that verbally describes what happens on the site.
The function spec is particularly important because it serves as a technical reference between the client and developer, and sums up the “scope” of the project. In other words, if the agreed-upon spec defines a part of the website functionality in a drastically different way than what the developer delivered - the developer would be responsible to correct it. On the other hand, if the client asks for something that wasn’t defined in the spec, it will probably be considered “out-of-scope” meaning it would require more time and budget to include. This protects both parties by making sure that both agree upfront how the site will work and honour their commitments.
Rushing along
At this point, when the 3 documents are delivered, we expect a LOT of feedback from our client. After all, like the blueprints on a house, these documents are essentially paper-versions of their website. This is the part of a project where you can really let loose with ideas, but it’s also where the project should get very real. All the ideas are now on the table, and we are planning in precise detail exactly what the website is and how it works.
I find that often clients will hurry this process along and agree to virtually everything assuming that this is the boring part so saying yes to everything will make it finish faster. In reality, this is the part of the project where the client has the most control and room for input.
A cold, hard shock
And I’m sure you know how the rest goes; Client reviews the design, makes changes until they approve it, we build the site, load the content and show them the close-to-finished website… and then… suddenly…out of nowhere there is a massive list of changes back from the client! These changes may include a massive overhaul of the site-map and wireframe, along with a completely re-thought-out list of fundamental changes to how the site actually works. And naturally, they aren’t happy to be told that now it will cost more money and it will delay the launch.
Why it costs more
This might seem unfair to some people, so it often helps to compare the building of a website to the building of a house. If you hire a contractor to build your house, and you sign off on the blue-prints and give them the green light to build, but then after the house has been constructed, you decide you don’t want the bathroom on the main level, you want it moved upstairs—do you think that’s going to be a problem? Of course! Now walls need to be knocked down, plumbing needs to be completely re-worked - this is going to cost more money and you’re going to have to wait longer to move in.
Or how about if you told an interior designer you wanted marble counter-tops, waited until she installed them, and then decided you want granite. Obviously, it’s going to cost more to change now. So in a similar way, decisions you make early on when planning your website are going to affect the final outcome of what gets produced.
But what can help you if you need to commission a company or freelancer to build your site?
Know what you want
First, know what you want before you even pick up the phone. Now that’s not to say that you need to design the site yourself - the last thing a web designer wants is to be handed a design from a client and be told to make it look exactly like that. Definitely remember that you’ve hired professionals, so be prepared to accept their advice. But at the same time, remember that this will be your site for years to come and as the website owner, you need to be the champion of it, so it’s your job to know what you want and the web teams job to help you get there in the most practical way.
So come to the kick-off meeting armed with information; Why you need the site, who it’s for and why they need it, how you plan to fulfill users expectations, when you need it launched (which is usually different than when you want it launched), how much you have allocated for spending, where it will live and so on.
The wonders of napkins
Better yet, come to the kick-off meeting with doodles. The wonderful thing about paper is that it can change. On paper, you can change a search bar to a list of check-boxes instantly, or you can remove an entire section by simply scratching it out. If you have sketches of what you want, no matter how crude they may be, they will help not only your hired web experts know what you want, they will help you know what you want because you’ll get an instant idea of what works and what doesn’t. If it doesn’t work on paper, rest assured, it won’t work in code - and all it cost you was a napkin to find out.
Once your web team understands all of this, they will be able to tell you in realistic terms what is feasible, and if necessary, propose alternate solutions.
We launched a website recently for Tattoo Tree, an online resource for tattoo artists. Our client approached us for a proposal with complete hand-drawn sketches of the entire website, and a document outlining how she wanted it to work. We didn’t always see eye-to-eye on how things should work, and there was some compromise on both sides, but the point is, our client knew what she wanted, had a vision, but was willing to accept our advice - and you know what? It was one of the most smooth projects we worked on, and we launched a fairly complex website in less time than we would have launched a simpler site whose owner couldn’t make a decision.
Look at examples
9 times out of 10, if something hasn’t been done already on the web, it’s because it’s impractical. So to get a good sense of how your website can/will work, look at examples of good websites and see how they allow users to accomplish certain tasks. Show them to your team, and let them bring other examples to the table. You can find beautiful websites on sites like Site Inspire and Drawar.
Write your content now!
Too often, clients wait until the site is built using dummy copy before they even think about what content is going to actually end up on the site for launch (having no copy ready in time is also the #1 reason why projects don’t launch on time).
If you have hired a web copywriter, make him or her part of the development team early on. The writer is as important to the success of your site as the designer and programmer. Think of the content as what the designer will design the site around. It’s why users are actually coming to the site in the first place.
For some reason, clients seems to understand this concept when getting a print piece designed, they provide copy to the designer up-front whereas websites often get misinterpreted as being blank templates that will work with any type of content. In some ways that’s true, but the sooner you produce actual copy/images/video, even if you plan on changing it or adding to it later, you will assist the designers and you will get a better grasp on what the final product will contain.
Content takes way longer than most people think it will, so starting immediately once a project begins will ensure you give yourself a good head-start and actually get the copy done in time for the designer.
Obsess over the spec
Finally, when your web team shows you a function-spec, pore over it. Read it like you would read the blue-prints to a house you are building. Visualize it. If you don’t understand parts of it, ask questions. Sketch it yourself as you read it. If it doesn’t make sense, ask the site planner to explain it further over the phone or in person and if necessary, provide follow up wireframes or examples on other websites.
Don’t make any assumptions at this stage thinking “Of course the developer will remember to include feature A, because every website I visit has this feature!”. If it’s not expressly written down, ask for it. If the spec doesn’t mention anything about RSS feeds, don’t assume there will be one. If it’s to be included in the scope, ask for it now. If the spec mentions a list of search results, don’t assume they can be sorted alphabetically by the user. Think long and hard about what is outlined.
Also don’t think that because you mentioned something about a social widget in the kick-off meeting that it’s automatically within scope. Things get missed in conversation which is why the notes are presented back to you. The spec is a summary of what conversation took place, so if you feel something is missing, now is the time to voice it.
These are just some suggestions to make your new website the best it can be, and at the same time, keep it on-budget and on-time. As the saying goes, measure twice, cut once. Your web developer’s will thank you for it.
