Separating Business Objectives from User Goals—And Why Your Website Failed to Do It
The review that came back clean, and the portal that still failed
I once walked into a consulting engagement which consisted of a corporate website and a self-management portal (SMP) for a large direct-to-home (DTH) media company. Its marketing team had built both assets with great perseverance and was certain it was the foundation of the company's online presence. But the IT team, managing the hosting and the uptime, was circumspect, and hence I was involved in determining the problems. They felt the corporate website wasn't achieving its core objective — that of promoting online sales of their DTH products and channels. Considering the brand and its status in the media and entertainment market, I was surprised to hear this comment coming from the Senior VP and the IT head of the company. After an initial glance, I noticed that the corporate website was lacking in aesthetics and usability.
When I ran a heuristic review of the corporate website, everything looked right on paper. The information architecture went three layers deep before surfacing what mattered — channel packages, pricing, the fine print — and each layer was tidy, logical, and easy to navigate. The website even had the right tone: it read like a confident, prime DTH service provider, and its content was written for quick decisions rather than slow ones.
And yet it had failed. Users were visiting in the numbers the marketing team predicted — and buying almost none of its products or channel packages online, as expected. Instead, they preferred to walk into a physical store. A preliminary analysis revealed that the corporate website was trying to perform three roles at the same time. The intention was good but the execution went off course due to a strong confirmation bias — that the research data was considered sacred and wasn't questioned for any anomalies. It was as though the marketing team went about building the website without consideration or collaborative efforts.
On the other hand, the company built the customer SMP on top of an off-the-shelf enterprise platform, constraining my ability to provide improvements to the experience through customisation. The portal had been left to survive on its own mainly because it was third-party software — a common practice within the industry, since commercial enterprise products meet the Statement of Work (SoW) and accelerate the portal release. It can be disadvantageous in some cases if the user's journey moves from a customised corporate website or a landing page to an off-the-shelf product portal: a lack of brand messaging on the commercial product could make the user disoriented and break the flow of the journey.1
The reason became clear once I mapped out what the corporate website was actually meant to do. It had three critical intents: to act as an online retail store, to persuade a browsing user into becoming a buyer, and to give existing customers a self-service resource for managing their accounts. It succeeded at the first job and quietly failed the other two. It showcased the product line beautifully — but showcasing was never the same thing as selling, and the self-management section was so poorly organised that even the customers it was meant to serve struggled to find their way through it. Three intents that were supposed to work as one system had never been designed to.
Showcasing was never the same thing as selling.
Where the objective and the goal quietly split
The corporate website was built and owned by the marketing team, who had invested years of research into understanding the brand's target audience. That research wasn't the problem. The problem was a quiet, unexamined assumption sitting underneath it: that showcasing the product line would be equivalent to selling it.
The site's content hierarchy reflected that assumption exactly. It walked a visitor through information beautifully and then left them there — informed, but with no clear path from "I understand this product" to "I have bought this product." The language never shifted from descriptive to persuasive. The structure was built to inform, not to convert, and nobody had explicitly signed off on that choice; it had simply happened, because the team that owned the research also owned the brief. The corporate website therefore presented a marketing perspective rather than a direct sales proposition.
Where the business objective ends and the user goal begins
The marketing team's mistake wasn't a lack of research — it was treating two different questions as if they had one answer. "Did the user visit and learn about the product?" is a business question. "Did the user get what they came here to do?" is a user question. The corporate website's own analytics answered the first question convincingly and never asked the second.
Here's the test I use: a business objective is an outcome the company wants to achieve, measured by KPIs such as qualified visits, conversion rate, customer satisfaction, retention, or brand awareness. A user goal is a task the user wants finished — compare packages, check pricing, cancel a plan, understand what they're buying before deciding where to buy it. The two aren't opposites, but they aren't interchangeable either, and a digital property that reports success on the first while quietly failing the second is the most common failure mode in strategic design.
A business objective is an outcome the company wants to achieve. A user goal is a task the user wants finished.
This is precisely what happened here. The DTH product — a set-top box, wiring, installation — had always sold through brick-and-mortar stores, and the marketing team's research was built entirely around that channel: what made a customer walk into a shop and buy. That research wasn't wrong. It was answering the store's question. The corporate website, however, was being asked to do something the offline research had never had to account for: convert a browsing session into a purchase without a salesperson in the room. Nobody had asked what a user in that position actually needed — clearer comparison, reassurance, a lower-friction next step — before designing around the assumption that presenting the product would substitute for selling it.
The conflation, in other words, wasn't a research failure. It was a scope failure: research built to answer one question was quietly asked to answer another.
Diagnosing the gap: Research, Advisory, Conceptualize, Educate
Untangling this required starting with the people, not the interface.
Research. The engagement opened with stakeholder interviews, aimed at:
- Understanding the objectives behind the corporate website's existence, from the company's perspective
- Getting into the shoes of each team to understand their working styles and processes
- Spotting gaps in the story or methodology — whether detrimental or beneficial
- Understanding why the company wanted to redesign the SMP, and what it hoped to achieve by doing so
There were two distinct assets under review — the main corporate website and the SMP — each with a different user base and a different set of goals, which meant a separate line of questioning for each.
Advisory. A preliminary diagnosis was shared back with the client through a presentation: a persona built from the marketing team's own data and my own assumptions of how a customer would achieve their goals, paper sketches of alternative journeys, and a competitor analysis, all aimed at giving both teams a shared, visual reference to assess where the current experience broke down. My assumptions were later tested against the prototypes and presented to the client.
Conceptualize. This was the most contested phase. Once a prototype gave both teams something concrete to react to, opinions surfaced quickly — on aesthetics, on strategic value, on how far the new concepts had strayed from familiar territory. Every fresh idea was scrutinised against what the teams already believed the SMP and the corporate website were meant to achieve, which made this phase as much a negotiation between stakeholders as a design exercise.
Educate. Left unresolved, the conflict between the internal teams would have derailed the redesign before it reached implementation. This phase existed to close that gap: the improvements shaped during prototyping were walked through using the research from the Research and Advisory phases, and mapped back onto the personas built for the company's two primary web properties: its corporate website and the SMP, so the journeys and the underlying information architecture felt grounded in evidence rather than opinion. It gave both teams a structured setting to debate and question the changes, rather than revisit them informally later. Where the prototype fell short — because of a data gap, a flawed analysis, or simply a change in the underlying data — this phase was the window to fix it before the design was applied to the two live online channels: the corporate website and the SMP.
What breaks when nobody owns the distinction
The cost of this conflation didn't stay confined to the corporate website or the SMP. It surfaced as a turf war between the IT unit, which maintained the site, and the digital marketing team, which had commissioned it. Each was convinced the other didn't understand what the corporate website or the SMP was for — and each treated its own contribution as the reason these two online channels existed at all. The digital marketing team pointed to its research as proof the strategy was sound; IT pointed to the usability and data analytics as proof it wasn't. Neither side was positioned to hear the other, because neither had been asked to define what the two online channels were actually meant to accomplish before building them.
This is the real cost of skipping that definition upfront: it doesn't just produce a weaker product but produces two teams defending different, unstated versions of success. A redesign attempted under those conditions doesn't fix the conflation — it just conceals the strategic concerns with enhanced aesthetic value and creates clutter for the users.
A redesign attempted under those conditions doesn't fix the conflation — it just conceals the strategic concerns with enhanced aesthetic value and creates clutter for the users.
The resolution wasn't to declare a winner. It was to recognise that the two teams had never been in competition in the first place — they'd been solving adjacent problems without a shared brief. Market research and usability aren't rival claims on the same territory; they're answers to different questions, and the two online channels need both. Once the roles were treated as analogous rather than contradictory — research defining what users needed to accomplish, design determining how they'd accomplish it — the redesign had something the original build never did: a business objective and a user goal that had actually been written down as two separate sentences.
Ask the two questions separately
The fix isn't a better redesign brief. It's a smaller discipline, applied earlier: before anyone sketches a wireframe, write down the business objective and the user goal as two separate sentences — not one sentence you're hoping does both jobs.
If you can't describe your user's desired outcome except in terms of an internal metric, you haven't defined a user goal — you've simply renamed a business target.
If you can't describe your user's desired outcome except in terms of an internal metric, you haven't defined a user goal — you've simply renamed a business target.
Ask: what does success look like from the user's perspective, independent of the numbers your organisation tracks? Run your own online channel, or the one you're about to redesign, through the test from earlier: what outcome are you trying to achieve, and what task is the user actually trying to finish? If those two answers sound suspiciously alike, that's not alignment — it's the same conflation that hollowed out the corporate website, just not yet visible in your adoption numbers.
Let's talk about a complex problem.
If you're navigating a transformation, enterprise design challenge, or organisational problem where the answer isn't obvious, let's explore it together.
Footnotes
Euphemia Wong, "Principle of Consistency and Standards in User Interface Design," Interaction Design Foundation.↩