What is the difference between site objectives and business requirements?

Question

A lot of generic ux processes usually start with defining a sites goal and objectives such as "reduce customer calls by 5%" or attract new customers by 10%" etc. Then it is recommended that you interview internal stakeholders that are affected by the objectives and ask them about what they require in order to accomplish them. You'll gather answers such as we need a better faq or we need to invest in seo.

To me requirements and objectives are the same. Can someone explain the difference and why it is important to include business requirement in the process.

Answer 1

Objectives are the targets. Requirements are the cornerstones to the perceived path to them.

An objective is to win a football match, by shooting at least one more goal than the opponent. A requirement is to catch most of the incoming balls as the goalkeeper.

This is the theory, and it is well expressed by adrianh's answer.

In practice however, requirements are what the business needs or wants (the two doesn't necessary meet!), while objectives are the meaningless bullsh.t they were requested to give as a reasoning on why do they want to have those.

In short: in average cases, nobody cares if you met the objectives, but fail to provide even a single one of the requirements, and you're fired. Most organizations aren't conscious enough to actually track the objectives, but requirements are sure to be tracked rigorously.

When I watch marketing or UX presentations, sometimes I feel that objectives are completely made-up. And then I ask myself: were the needs of the users (consumers) met?

There are times, when it's an objective to increase sales by 10%, and we only succeed to increase it by 5%, but in the meanwhile, we made a comfortable user experience for all customers and even administrators. Does it really matter that we didn't reach 10%? Depends.

Even if you don't meet the objectives, you can still satisfy all the requirements in a well-done way

On the other side, there are times when meeting requirements means nothing if you don't meet the objectives. If the objective is to win an olympic gold medal, it doesn't matter that the dress you designed would also look good while standing on the rostrum if the objective wasn't met.

Even given that all the requirements were met, Kayla wasn't impressed that her primary objective wasn't reached

Deciding wether the objectives were real business needs or just something made up in order to look like a serious businessman needs expereince and good "smelling": nevertheless aim for them at all times, but make sure the requirements are met - as they're required.

Answer 2

One way I've seen it defined is roughly.

Objectives: What the business wants to happen.

Requirements: How you plan to make the objectives happen.

(Not everybody defines them exactly like this - but you will generally find the two different categories even if they have different labels)

For example.

I have the objective of "Increase the lifetime value of customers by 10%".

After some research I find that customers are leaving the service never having used key feature Foo.

So I theorise that adding a nice drip-feed reminder email to the customers who haven't yet used Foo after one month, reminding them how great Foo is, may get them to stay so increase customer lifetime value. That becomes a requirement.

If it works - yay. Requirement and objective both ticked off.

If it doesn't work then the objective still stands - but now the requirements to meet that objective need adjustment.

Objectives - what we want - are fairly static. Requirements - how we achieve what we want - may change.

Answer 3

Objectives

There are business objectives and user objectives.

Business objectives come from managers or stakeholders, like in adrianh's example: "increase the lifetime value of customers by 10%". They are related to the purpose of the business behind the site. There is a root objective, like "let's sell goods online", which is the core purpose of the business and everybody takes for granted.

User objectives against our site are more like "get a wireless mouse".
Thy come from (end) users, or from personas if the end users are not available with ease.
Alan Cooper explains the user's objectives clearly in "The inmates are running the asylum" and other books.
The wishes of the end users (generically "purchase goods") are complemented by marketing findings, like "bluetooth mouses are trendy".

The success of the (let's assume it's an) e-commerce site depends, among a lot of other things, on how both objectives are aligned. But, it depends much more on the user's objectives, thus repurposing the business should always be an option.
All this pertains to high level business strategy.

Requirements

Coming down to the site level, here is where requirements appear.
The strategic objective of increasing customer value can be pursued in one or more ways.
Like reminding them of a feature (adrianh's example), and also by offering the goods that are trendy, lowering the shipping costs or times, you name it...

As UX practitioners our most powerful tool to support the company's objectives is by enhancing the site's usability.
We can guess that a user that made a purchase with ease might come back to out site the next time, and the other, and so on, thus supporting the 10% customer value increase.
So we analyze and think (this implies a lot of competitive sites browsing), and come out with a few ideas, changes to make to the UI. This is an analysis phase, soon to be followed by requirments writing.
A related success story is Jared Spool's 300 millions button.
Depending on the organization level of the company, we can communicate the changes to a developer on a napkin, or do something more formal like writing use cases and drawing wireframes.
These are the requirements. In IT parlance (because we have moved the action from business analysis to software development) the requirements are the documents handled to the people who will write the code, containing an unambiguous specification of the outcome expected from them.
The napkin counts as requirements too, only it's way more informal and risky than a UC.

A word about use cases

Or two ...

First, use cases might be regarded as extremely formal documentation, that one is forced to do only in big companies using UML, SEI's CMMI and the like.
Not so. UCs can be simple and informal, grounded in actual users using our UI. In UC writing, less is better. It is said that if an UC set is too heavy nobody will read it and thus it's useless.
Also, you don't need to be an IT propeller-head to write UCs. Actually, you are better off.

Second, the beauty of UCs is that they are the hinge that articulates the worls of normal people and the world of software devlopers.
An UC can be understood by an end user and also be a clear specification for an IT type.
When we handle well-written UCs to developers, the chances of getting back something like what we wanted are greatly enhanced. Also, we will get is sooner which means less dev time, a.k.a. lower development costs (this was measured, the numbers are significant, like 30%).
This is so because writing a good UC forces those who write it to ask themselves all the questions that the developers will stumble upon, and preempt them.
Also, because the UC can be monitored by the end users (or checked against the personas) which ensures that the resultant UI will be usable once it's finished.