How much does it cost to build a website? what does building a website entails? there are no universal answers to those questions.

Client: "Enough talking, let's get down to business. What will 50$ get me?"
Brad: * looks at wrist watch *
Brad: "About 5 more minutes of my time."
Brad Colbow on Time

In fact, there is so much variation, that a recent client told us post-project completion that when he was shopping around for offers from various firms, he got offers between 2000$ and 60,000$. That's a factor of 30 between offers!

He picked us since we conveyed the best value (quality / price) of all offers, even though he had much cheaper offers (we were about midway in the range). All things being equal, all he had was his gut-feeling and our resume to guide him. That is, if we didn't engage in client development.

The client-provider relationship in web development is complicated. Most would-be clients are lay-man, possessing no insight on what goes into every feature and pixel you see on a website. They are also, most likely, unfamiliar with their prospective provider and how to evaluate him - is he a hack? what are the qualities that he brings to table? how can I quantify the value he gives me?

That's where the process we term "Client development" comes in. It involves several activities, most of which are not directly related to web development:

Matching expectations

This is a basic rule of engagement in most business operations, and web-development is not excluded - especially since it is such a misunderstood and technical field.

A lot of clients look at website features and think "that's easy! you just put the thing there and do that...". Well, in the real world things are usually more complicated. What might look simple on the surface could involve a lot of back-end work and a lot of custom integration with various services... and the user interface itself is probably more work than you'd think.

The first thing we try to do is lower expectations to some degree. Our stance is that if it takes any amount of time to design / develop / test, then it will be priced in the proposal. That might sound harsh - but it's the only way to properly evaluate and convey the value of the project.

As I've written in conveying value to clients, creating a transparent and fair price proposal can go a long way to matching up the client's expectations with yours. It should be accompanied by a well written specification document, composed interactively with the client and which is completely understood by him (or her).

Educating clients

To help clients really get a sense of what they are getting in return for their money, it's important to explain some basic terminology and elaborate on the process of web development.

Explaining terms such as usability, user experience, mockups, layouts, client-side / server-side, testing, maintainability, standards and the interactions between them can really shed light on the considerations and work involved in building a website.

This in turn allows clients to better understand the price-stamp put on features, and feel more secure overall in decisions they make since they better understand what is involved.

Knowing when to say "No"

In some cases, clients get over involved in day-to-day decisions, especially in something as tangible as design. The design of a website is very visible which makes it very susceptible to micro-management and over-feedback from clients as they watch it evolve into a finished product. Convincing clients to trust our experience and expertise is imperative.

Another aspect that is constantly under-pressure is scope. Scope-creep is a common yet undesirable side-effect of perfectionism inherent in most of us (including clients). This tendency to think how things could be improved beyond what was originally specified is something that needs to be properly monitored.

This often means just saying a strict "No" to client suggestions and ideas when it's appropriate to do so. If features and requirements change (and they will), they have to come at the expense of some other features deemed less important. The project scope must be maintained.

Selecting clients

Client development is a two way street. Consider for example the following project outline:

US Company looking to develop financial website

Requirements:
Budget 10,000$-25,000$
Maximum Billrate per Man Hour: $6/hour
Minimum Number of Men assigned to Project: 30

We require a well established firm that meets these basic requirements in addition to being able to delivery quality and accuracy in its work.

(This is an actual posting on Elance, in case you were wondering)

In short, this person wants a financial website, but gives no project requirements / specifications or feature list of any kind. Instead, the requirements are that the provider:
A) Has a minimum of 30 men (why gender biased?) assigned to the project, and
B) No one should be paid more than 6$ an hour (which is less than what a register clerk at McDonalds makes)

For this he wants quality and accuracy. Is his expectations unreasonable? might be (I'm voting no).

Even more common is the "work for minor shares" offer in what is probably "the next big thing". Somehow people believe that having an idea by itself is sufficient leverage, and should prompt serious firms into developing their products.

The fact that there's no market for startup ideas suggests there's no demand.
Which means, in the narrow sense of the word, that startup ideas are worthless.
Paul Graham on Ideas for startups

People in the industry seem to agree that execution is the main key for the success of a startup. We do execution (and also concept development, but that's for another article).

The point I'm making is that a good relationship with a client can only be achieved when both sides understand and respect each other. This is not just about money, it's about the value generated by both sides.

What does this mean? it means that in order to get the right clients, we need to be selective ourselves. Clients not only choose us, but we get to choose them as well. For this reason, we should never undercut our price-proposals. We need to believe they represent not only fair, but great value.

It's the client's privilege to agree or disagree, but we want to work with people who understand the value we represent. If they want to pay less, they need to drop features. It's give-and-take and there are no freebies - this is a business after all. Nobody gets rich from web development, the least they could do is get paid on par with the value they represent.

This feeling out process usually happens during the expectation matching phase. If both sides can not bring their expectations to the same level, it's best to part ways and wish each other the best than trying to hammer in a shaky relationship.

It's up to you

Client development is a process that a lot of small businesses and freelancers skip (and sometimes larger firms as well). Whether you put the time and effort to make prospective clients your partners instead of your employers is up to you.

Why spec?

Specifications encapsulate a project's goals, requirements, features and scope. This is very important for several reasons:

Understanding project requirements

Understanding what a project sets out to achieve might seem obvious, but in reality, when at least two people are involved - some difference in perception of the project goals and needs is inevitable. Putting in writing the goals and requirements goes a long way towards resolving such differences.

Writing specifications will often reveal requirements not thought of initially, as a result of detailing and thinking through the initial set of requirements. This is very important for determining project scope.

Developing a project scope

The scope of a project is probably the single most important attribute for determining project success. A well defined scope will determine the time-frame, costs and requirements with good precision.

In essence, a scope is the sum of a project features, requirements and deliverables or in other words - the sum of the work required for project completion.

Scope is the main element against which projects are priced at Lionite.

The more complicated and/or innovative a project is, the more likely it is that features will change during the project lifetime (sometimes even drastically).

We can allow that to happen by adhering to scope instead of individual features. With good specifications it is much easier to avoid scope-creep.

Estimating project time-frame and pricing

Accurate time and cost estimates are important are as important to project success as anything else, and specifications are what it should be based on.

The better the written specifications are, the more accurate those estimates would be.

Creating a workable reference for development and design

Working with a good specifications document can do wonders for productivity and focus in the design and development stages. At the very least it can serve as a task list for project completion.

Well thought through description of features and relevant mockups can solve a lot of potential dillemas for both designers and developers and save a lot of time.

The specifications process itself should be used for ironing out as many issues as possible, helping the implementation phase to be as productive as possible.

Having a standard to test against project delivery

Specifications outline the agreement between parties on what constitutes a successful project delivery. Contracts, if relevant, will point to the specifications as the legally binding document for this purpose.

A good specifications document can resolve many potential disputes simply by stating clearly what should be delivered.

How to create better specifications

Creating good specifications entails some ground work, there's no around it. Keep in mind the effort you put in will pay itself back as the project progresses.

Break everything down

Decompose every requirement and feature to a list of small tasks. Add relevant detail that might affect completion time. The level of detail and scope of each task should be enough so that it could be accurately estimated in work hours (and not days, and certainly not weeks).

Research what you are not sufficiently familiar with. This will greatly help avoid nasty surprises later, and will make your estimates that much more accurate.

Be thorough

Try to make sure there are no gaping holes in the specifications - are all requirements and features accounted for? are there any hidden prerequisites you might have over-looked? read everything twice and then give it to a colleague to read.

Don't forget to add more technical detail such as security concerns, coding standards, post-project technical support and supported browsers.

Compose interactively with clients

It is very important for the specifications to capture correctly the vision the client has for the project. Specifications writing can be used to correctly align client's expectations with your own.

Your interaction with the client can (and probably will) lead to more insights on project requirements and features. It is not at all uncommon for a project to change direction somewhat during specifications writing - and it is much better that it happens at that time than at mid-project.

Be clear and concise

Be clear and and use as much detail as necessary. Be concise, since overly descriptive texts are harder to consume and understand.

Don't skimp on rewording and reorganizing bulky / technical paragraphs and edit out unnecessary detail.

Read more articles like this one

Joel Spolsky on painless functional specifications - part 1, part 2
Allen Smith on functional specifications
Jason Fried of 37Signals on avoiding functional specifications (basically refuting everything I've written here. A good read for counter arguments.)

Despite this, the application of those business models in the web arena is still very much experimental, and it's often hard for web businesses to find and implement a model that works well for them.

Got ads?

The most basic misconception about web business models is that you can never go wrong choosing an advertising-based model. If it was really that easy, then everybody would be making mad cash - however, advertising based revenue is actually hard to come by.

In fact, those who can actually make it stick are few and far between (Mike Speiser shows the numbers don't lie). The amount of traffic you need to generate in order to make substantial revenue from online advertising is out of reach for the vast majority of websites.

So when is an advertising model appropriate?

• When generating traffic is the main purpose of your web service. Such sites include all flavors of traditional content sites, social networks, user-generated content sites and the like.
• When your service has the ability to deliver targeted advertising. Targeting advertising at user activity, search criteria and the like, greatly increase the relevancy of ads and thus conversion rates. A little-known company has made targeted advertising its main business to devastating effect.
• Advertising is incorporated as a part of a hybrid model, to subsidize free parts of the service (see below for more details).

The important attribute here is that advertising must target a large enough audience with sufficient relevancy in order to generate significant revenue.

Subscription is king

Subscription business models are nothing new but have been gaining popularity on the web, especially with the proliferation of on-demand online services in which subscription payments often make the most sense.

A subscription-based model is often appropriate when the service / content offered is unique and hard to find elsewhere. For site visitors to shell out even a few dollars, they need to be convinced that they are getting something they can't get elsewhere (since much of the web is available for free). This is doubly true since the process of handing out payments details online is often a barrier by itself.

Whether it's entertainment or productivity, when the value to users is higher than or equal to the monetary cost subscription becomes a very viable model. Niche sites and web services often fall in this category when they provide something of value.

I'd note here that by subscription model I don't necessarily mean just recurring annual subscriptions - there are also milestone-based subscriptions (pay-as-you-go) and feature-based subscriptions (pay-per-feature). Those three types can be mixed together to create many different hybrids, with the common denominator being the "subscribed user" - a person willing to spend money to use the service.

The freemium model

Freemium is a trendy new name for a familiar model - offer basic or limited services for free, and charge for advanced (premium) features. The freemium model is often a derivative of the subscription model, with the basic subscription plan as the free part of it.

Using a freemium model can be very useful for businesses who are counting on long-term users instead of one-time purchases. By getting limited services for free, a user can have a taste of what the web service has to offer thus lowering the barrier of entry. The balance of free to premium is important in creating the right incentive for paying for the premium services (example - basecamp).

One common application of the freemium model is combining the subscription and advertising models, by offering free services that display ads and premium services that are ad-free - this basically allows the site user to decide how he will support the service.

When we are conducting business development with clients I Personally lean mostly to subscription based freemium model, as

The brokers

Brokers are services that bring together buyers and sellers thus creating a marketplace. Revenue is generated by charging usage of the marketplace in a variety of ways:

• Sellers can be charged for being listed by the broker (one time / per listing)
• Buyers can be charged for gaining access to the listing of sellers
• Fee / commission on successful transactions

The best known example of the broker model is Ebay, a giant marketplace that succeeds on the strength of its reputation system and internal policing. A couple of good examples for creative application of the broker model are threadless and crowdspring (which I described in a previous post on web business models).

The partnership, the exit

Partnerships can be the basis of viable business model in certain circumstances - such as affiliates and sponsorships, or can be another part of the whole for others. It is often used as a hybrid with other models (such as advertising or subscription) being the driving force behind revenue.

An extreme case of this model is the outright takeover of the business by another company, often called "an exit". Though some businesses set out with this strategy in mind, its very unpredictable nature makes it very risky without an adequate backup model. I call this strategy the "no-model" model, with businesses basically saying that they'll figure out as they go along, hoping that some giant company will swoop in and end all their problems.

Picking the right one

Deciding on a web business model can be tough for early stage start-ups and traditional offline businesses transitioning to the web. Each model has its pros and cons and the fear of making a mistake can be paralyzing. Sometimes the perfect business model is very obvious but more often than not it's a journey of self discovery for the business.

When we engage in business development with our clients, we usually ask them the following questions:

• What is your target audience?
• How much would you pay for your service?
• Who are your competitors? What is their business model?
• When (or how fast) do you expect web revenue to cover operating expenses?

Those are mostly introductory questions, aimed at helping the business orient itself on what it needs to know to determine its business model.

Analyze, improve, rinse, repeat

Choosing a business model is only the beginning. Constant collection and analysis of related data - such as conversion and churn rates, usage data and statistics - is essential for tweaking and evolving the business model and increasing its chances of success. The process of testing how much customers are willing to pay for services is sometimes called bounding-box pricing.

There are no strict rules for choosing a business model, so don't be afraid to experiment and look for business opportunities in unexpected places. You never know when or where your big break will happen, but if you believe in your product and your team your business model will reveal itself eventually - be prepared for it when it happens.

Some very well known and successful online entities can be considered as such - Wikipedia in which users contribute knowledge, Digg in which users help others find interesting articles by voting and facebook which is the current golden standard for social networking (in which user generated content - UGC - is a given).

However, those sites are not thought of as having strong business models. Wikipedia, of course, is free. Digg and facebook rely on advertising, which is the fallback business model on the web - conversion is relatively low and you can only count on decent revenue when you reach the size of the aforementioned sites.

As can be guessed from the title of this article, I would like to discuss a couple of sites / services that use UGC as the basis for a viable business model:

Case 1: Threadless

Threadless is an online t-shirt retailer with a twist - the concepts for the t-shirts are submitted by users, voted on by the community and finally hand picked by the staff. A winning design will be printed and sold through the site, and its creator wins a nice sum of 2,500$. That's the basic premise - there are several variations such as contests and reprints, but at its base - its a marketplace for ideas.

Threadless is already an established online brand, existing since 2000. It proves that you can crowd source creativity for fresh product ideas in a way that is both beneficial for the product distributor and the creative contributor. Threadless builds on this premise and succeeds because of their excellent blend of branding, community integration and good service. I have personally purchased at threadless multiple times and I've had nothing but satisfaction and enjoyment from the service.

Threadless currently has revenue in excess of 30$ million, and income of 10$ million annually. Not bad for a startup funded with a 1000$ seed (earned in an online t-shirt content, no less).

Case 2: crowdSPRING

I had just recently discovered crowdSPRING, an online service that mates graphical design talent with design related projects. The concept is to try to improve traditional design projects proceedings for both sides:

- Project requesting parties (called buyers) are guaranteed to get at least 25 different concepts for their needs (be it a logo, website design, print and others), with a money-back guarantee.

- Graphical designers (called creatives) are given a global stage to show their work and generate income. Also, since buyers pay in advance, the winning piece is guaranteed to receive payment - there is no scenario in which a buyer can say he doesn't like anything and walk away.

- crowdSPRING itself takes a small commission on top of the project award money. This is the main business model for the site.

What drives the service is the interaction between buyers and creatives. Creating a project and watching the concepts improve as both sides learn more about the requirements through iteration and communication is a very interesting experience.

We've recently created a logo design project on crowdSPRING, and the reaction has been phenomenal. Though we have a couple of designers on board at Octabox, we felt we needed a fresh approach as we have been too deeply involved for a long time now. There are still 9 days (out of 14) till the project ends, and we already have an incredible amount of entries (over 300).

The process itself was worth the price of admission - through the interaction with the many contributors, we achieved some insights on what we want in a logo and a design direction for our new website.

crowdSPRING is not yet an established entity like Threadless, but it is well on its way to becoming one. Another example of how to crowd source creativity in a win-win situation for all involved.

Web 2.0 as a viable business model

Those two sites are just a small sample of many successful sites / services built on UGC as the driving force. I believe this market is still mainly untapped - there are plenty of possibilities to be explored. Despite that the basic premise is always the same:

- Create a community around a product / service concept
- Allow / encourage the talent within the community to offer their skills to the rest of the community
- Facilitate the interaction between the talent and the community, while trying to interfere as little as possible

What other successful web2.0 business models have you seen?

Users consume applications through the interface - one chance to either deliver a satisfying experience or fail miserably.

It is a topic I have very strong and passionate opinions of, and motivated by this beautiful prose by Jono over at Not the User's Fault, these are my guidelines for user interaction design:

Know your users

The first step in interaction design is to know who it will be interacting with. Users can be profiled on many criteria, such as age, technical orientation, vocation, cultural background and more. The user profiles created from segmentation of those criteria are called Personas.

While defining Personas is a common practice for designing user interactions, it might not be possible to engage in all the steps required to fully understand the needs and tendencies of the users they represent - such as interviews, surveys, focus groups etc.

This is especially true on the web, where projects have limited funds and are very quick from inception to implementation. In this case, experience and common sense rule the day - but it is still important to define the base Personas for which the interaction under design applies. Going through the process brings out some considerations that can influence design decisions.

Watching actual users go through an interaction is very important to learn about its effectiveness. Watching live users in action is the best learning experience in interaction design.

Know yourself

Knowing your users is the most basic step to interaction design. Yet, for each user type and interaction requirements there are as many possible implementations as there are interaction designers. At this point the interaction designer has to make choices for his users based on his experience, attitude and style.

It is sometimes hard to avoid designing an interaction for yourself rather than for your users. It is a natural tendency to try to solve interaction problems in a way that seems most natural to you, however that might not always be in the user's best interest.

Ideally, the interaction designer is a part of the target audience. When that is not the case, observing prospective users is very important to understanding their needs and deciding on the approach to solve their problems.

I believe that good UI design is more intuitive than science, and in that respect it is not so different from graphical design. However the two should never be confused - as I've argued in my post on common misconceptions in web development.

Keep it as simple as possible

This old mantra is very much an integral part of a successful user interface. By keeping interactions as simple as possible you will:

• Have less opportunities to fail your users
• Give your users less to think about, allowing them to make easier decisions
• Reward your users quicker (at the completion of the interaction)
• Increase the chance that the interaction will get completed at all

A large part of the success of web-based services can be attributed to the simpler interfaces they provide compared to desktop solutions. Some of this is a result of technological limitations on the delivery software (ie, web browsers), but it's hard to argue with the results.

There are several common ways to simplify interactions:

• Use intelligent defaults
• Hide optional paths (or form fields) by default (progressive disclosure)
• Remove unnecessary steps from the interaction (and do so aggressively)
• Reduce mouse clicks. Make each click do more

This is obviously a very partial list, but it's a good start.

For me as a developer, the KISS principle is deeply ingrained in my thought process. Translating it into user interface design took some getting used to, but once it happened it became second nature.

In fact, many parallels can be drawn between UI design and software architecture design almost to the point you wonder why most developers aren't interested in designing interactions (actually I know why - most developers resent users for constantly breaking their code. I know this since a couple years back I had the same mindset).

Don't break conventions - And if you do, make it obvious

The tools available to us developers have evolved much in recent years, allowing us to create richer interfaces and interactions. With power comes responsibility - we need to apply discretion when using advanced techniques and tools, as to not confuse users.

Breaking interface conventions by using new technologies where they are not needed is a mistake.

Conventions should only be broken when they result in a bad user experience or when the alternative is significantly better. The latter is very uncommon when the former does not apply, so be advised.

If you do design a unique interaction (or at least, one that isn't in common use) - make it as obvious as possible for the user. A user can only begin to understand your new interaction when he realizes that something is different. Disguising buttons as links, hiding drop down menus in small target zones, making background changes to the document without notifying the user - all result in user confusion and a bad user experience.

The more you need to educate the user on how to complete an interaction - the less likely he will bother to. Good interactions are self explanatory.

Interactions should be fun

Users interact with your application since they want to achieve a goal. That goal might be to complete an item purchase, to indulge a curiosity, to gather information and many others. There are several factors that affect the user's motivation to complete an interaction:

• How important is the interaction to achieving the user's goal
• How unique is your application (ie, how easy would it be for the user to find a better place to achieve his goal)
• How hard it is for the user to complete the interaction

Negative factors can be offset by a fourth one:

• How fun is it to progress through the interaction

The fun factor in interactions is often ignored as they are considered strictly functional. It's no coincidence the word functional begins with fun. The fun factor of an interaction increases motivation for completing it - it makes your application more unique and it increases the user's tolerance for the interaction.

There are several ways to increase the fun factor of an interaction:

Increasing aesthetics

Making your interface prettier will have a positive effect on your users' perception of it. It's no secret that most of the illusion of Apple's superior OS interface is made on the grounds of aesthetics.

Make it gamely

Computer games have some of the best interfaces of any computer software, and it's no coincidence. You can make your interactions more gamely by adding feedback, reward the user for completing steps and transmit the feeling that the interaction is a part of the user's journey towards his goal, rather than a functional requirement that he must take care of.

Make the interaction do more with less

The user's time and patience are limited. Advance the interaction as much as you can with each user input. Make the user feel the interaction is smart and that it is working with him towards completion.

Learn from others

Those are my thoughts on user interaction design, born out of my experience in web development and of my introspection as a long-time user.

If you are interested in user interface design, the GNOME Human Interface guidelines is as good a reference as you will find.

My favorite web authors on the subject include Jono at Not the User's Fault, Bill Scott at Looks Good Works Well and Aza at Aza's Thoughts.

I recently stumbled upon a presentation by Mike Speiser (on his blog) which promotes the notion that good ideas should be shared. He writes:

Sharing your idea will expose you to diverse feedback on it. Your idea will get pressure tested. You should iterate based on that feedback, staying true to the core idea but improving it using the power of logic.

This is as good advice as you can get. Ideas circulating in your head need to be tested against the real world in order to develop into something useful. You should ignore your instincts to protect it and share it with other people. The risks of someone stealing your idea and beating you to the punch are irrelevant since:

1. If you believe your idea is good, you probably have passion towards it. Others are less likely to experience your enthusiasm since they do not see your vision the way you do, and therefor unlikely to try to develop it themselves.
2. Suppose others do try to develop the idea themselves. It is rare that separate people have the exact same vision regarding an idea, so if you believe your vision is a winner you have nothing to worry about. If you think others have a better vision of your idea, you should try to recruit them into your start-up (!)
3. Competition is good. If others are liking your idea and try to develop it themselves, they are proving to you (and potential investors) that your idea has a market.

The benefits of getting real-world feedback and allowing your idea to nurture and grow far outweigh the danger of losing creative rights over it.

Having said this, a good idea will only take you so far. The single most important asset for a start-up is the team - A strong team can take a mediocre idea into the stratosphere, while a mediocre team will fail with a great idea.

It's that simple - a strong team will win on execution, which is by far the most important factor for start-up success (not all agree on this of course).

Stash your NDA's, start sharing your ideas and recruit talented people. Success is only a few iterations (and an investment from Sequoia Capital) away.