User Goals and Corporate Goals

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

User Goals

A user centered, or user-centric approach to developing software is one where you start by identifying the key persona in your target market.  For each of those personas, you identify their most important goals.  You then identify the user stories or use cases that represent the things these people do in order to achieve their goals.  These “things” are manifested as practical goals.  For these activities, you design user interfaces (process, layout, architecture, look and feel, etc) that create customer delight for those users, doing those things.  This is how your product exceeds the suck-threshold (good enough that it doesn’t suck to use your product).

Corporate Goals

There’s a reason your company is creating or improving a product.  It may be to gain market share, or improve profitability, or increase sales.  Whatever it is, there’s a corporate goal that your decisions should be supporting.  The (subset of) corporate goals that are relevant to your product could be communicated in a vision and scope document, that constrains the domain of problems to be solved, and provides nuanced insights into viable approaches to solving them (example vision and scope).

Corporate goals are achieved when customers do things with the products.  These “things” are manifested as practical goals.  For those activities, you document what should be accomplishable and why.

Alignment and Conflict of Goals

Notice that both the user goals and corporate goals manifest in terms of people doing things.  When the person (user) wants to do the same things that your company wants them to do, you’re in alignment.  When the user goals and corporate goals suggest different activities, you’re in conflict.

You can see visually that these worlds collide at the “practical goals” stage  in the following diagram, from an article on combining interaction design and structured requirements principles.

It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined.  What about when the goals are in conflict?

Vending Machine Example

Last Thursday morning, as I interacted with a vending machine, the idea for this article was dispensed along with my Diet Mountain Dew.  Yes, I know that’s odd.  Move on.

It occured to me that the process of buying a cold, caffeinated beverage can be both aligned and unaligned from the perspective of user and corporate goals.  If you imagine writing a use case for purchasing a beverage from the vending machine, your most important scenario is the one where a person wants to purchase a beverage that is available in the machine.

  • User Goal: Get refreshed and vitalized.
  • Corporate Goal: Sell a beverage.

I want to buy a Diet Mountain Dew, as a means to realize my personal goal.  The owner of the vending machine wants to realize her corporate goal of selling me the beverage I want to buy.  We’re in alignment.  Our requirements definitions and design decisions will be pretty easy – everything that increases the likelihood of and improves the experience of purchasing that beverage is good.  I put my money in the machine and push the button.

Then it occurs to me – there’s a situation where my personal goals are clearly not aligned with the corporate goals of the vending machine owner.  When there is no Diet Mountain Dew available to be purchased.

Consider the following procedure I’m forced to endure:

  1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
  2. I put my money in the machine.
  3. I push the button for Diet Mountain Dew.
  4. The tiny display on the machine presents a message in taunting, scrolling red LED lights: SOLD OUT.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

Consider an alternate procedure:

  1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
  2. I view the ‘current availability’ of Diet Mountain Dew and see that this machine is currently sold out of Diet Mountain Dew.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

The differences in these two possible procedures indicate that there is a conflict between the corporate goal and the user goal.  With the first procedure, the “Sell a beverage” goal is given more importance, because it makes me more likely to purchase a beverage that I don’t particularly want.  My utility is potentially sacrificed, while the owner of the vending machine is just as satisfied.

By failing to tell me that I can’t get what I want, until I’m further invested in the process, I am more likely to purchase something else.  That purchase creates just as much value for the owner of the vending machine, but less value for me.

If the vending machine owner had allowed me to use the second procedure, it would demonstrate that the  owner believed the improved customer experience, while risking the loss of this sale, would encourage me to purchase more over time.  The owner would have been prioritizing the requirements and design that supported the user goal ahead of those supporting the corporate goal – in hopes that my user loyalty would result in better word of mouth (more business from other people) and more business from me over time.

Generalizing User and Corporate Goal Conflicts

In this vending machine example, the annoying procedure is probably the right one – I’m going to treat the “point of use vending of cold, caffeinated beverages” as a commodity product.  This market has a very low barrier to entry, and relatively small problem being solved.  I’m not going to tell my friends about how much I love the vending machines from Joey’s Vending and encourage them to go out of their way to find and use those machines.  Nor will I purchase more Diet Mountain Dew because the emotional cost of the occasional “sold out” scenario is trivially smaller with Joey’s machines.  I would, however, be more likely to buy a Diet Pepsi when I’ve already invested time in the process and put my money in the machine – especially when the alternative is to find a water fountain.  I’m emotionally invested at this point.

However, this experience did jump out at me as one that is worth explicit consideration when defining requirements and designing solutions.  It does come up regularly.

The new iPhone 3GS hardware allows tethering (using the phone as an internet-connection device for your laptop).  ATT (the exclusive carrier for iPhones in the USA) is indicating that they will charge customers an extra monthly fee for this capability, when they eventually allow it on their network.  The user already has a data plan, and the traffic that ATT would have to carry is just “data.”  The user just wants it to work.  ATT, however, may want more money, or may want to limit data traffic on its network – perhaps to improve the quality of service to all customers.  This could be ATT’s corporate goal of “provide better service quality” conflicting with the user’s “increase the flexibilty of how I use my data plan.”  The former would likely influence customer satisfaction (and abandonment) over time, while the latter would influence customer acquisition rates.  Another conflict in goals.

Think about how different goals can lead to conflicting solutions, requirements, and designs.  And tell me when you’re out of Diet Mountain Dew before I’m emotionally invested in the purchase.

18 thoughts on “User Goals and Corporate Goals

  1. Great article! I really like articles that make the reader think, like this one did. This is one of those everyday tidbits that has mired it’s way into the daily fabric of our lives.

    Being able to step back and assess the trail of goals was very insightful and helpful. Now I have to figure out how I’m going to think about this all day (personal goal) while still being able to get me job done (corporate goal).

    DougGtheBA

  2. Great example of sacrifices made in user experience to satisfy a corporate goal. The other key element that you were good to point out, is that this particular product is a commodity and that the best user experience is not actually the best way to garner sales.

  3. @DougGtheBA- Thanks, Doug. I should probably write at midnight more often. :). Corporate Goal: blog. Personal Goal: hang out with my wife. Solution – write after she goes to sleep.

    @Robin – Great point! I sometimes forget to take a moment and think about the real-world context, to make sure and apply the right design principles, instead of defaulting to “user first.”

  4. Pingback: Win Attwiter
  5. Pingback: doug goldberg
  6. Pingback: Scott Sehlhorst
  7. Pingback: Yama
  8. Hi Scott

    I’ve published an article that argues a position contrary to the one you’ve taken here.

    But perhaps further discussion will reveal there is only an apparent difference in our positions.

  9. Loryn,

    Thanks very much for checking out the article and extending the conversation! You did misinterpret one element of my article, and I apologize for not being clear in my writing.

    I’m definitely not suggesting that business analysts (or product managers) should promote the selection of a conflict winner into a design. Here’s the part I didn’t go into in this article (which was just “remember to unearth conflicts”).

    Most of the conflicts I’ve seen come when a solution is proposed, not when the goals are defined. A solution that focuses on only one goal is at risk of creating conflict with the other goal. A solution that attempts to meet both goals is ideal – eliminating the artificially induced “conflict” inherent in a particular solution or approach that only addresses one goal.

    As a design engineer, I used to use the QFD “house of quality” tool to identify conflicting goals (be cheaper, be smaller) where the degree of conflict was representative of “established approaches” to addressing the requirements. Capturing that perspective served as a good cue to inspire me to be innovative (devise a cheaper AND smaller) solution.

    That’s the mindset I’m approaching this with from a requirements perspective. Analysts should definitely be aware, but not so that they can pick one, but rather so that the engineering team can eliminate the conflict if possible, and pick the right one if not.

    There are “zero sum game” situations where goals are diametrically opposed, but I have personally seen them very infrequently.

    Imagine two kids who both wish to talk to their grandmother on the phone one evening. When forced to take turns (with the solution of “one phone”), their goals are opposed. When your engineering team proposes “use the phone at the same time” or “pick up the extension”), the conflict is eliminated.

    When you are presented with a conflict that is impractical to resolve given the realities of a situation, you need to know who the “winner” is. But the intent is to highlight a conflict so that you can resolve it if possible.

    Also – for the record, I really like Diet Mountain Dew. And I would definitely drink water before drinking Pepsi (to avoid the sugar). As to Diet Pepsi vs. water – it depends. If thirst is my primary motivator, I go with the water. If I’m drowsy, I go with the caffeine. Soft drinks are not perfect substitutes for me. Based on that, I’m willing to hypothesize that this might be true for other people – as you say, data is needed. Consider the alternative of “find another vending machine” instead of “water” if it prevents derailing.

    At the end of the day, I really appreciate your extension of the discussion, and exposure of the ideas to others. I don’t agree that including the “solution design” part of the process is lazy. The best solutions come out of a dialog of collaboration that informs in both directions. Ignoring either limits the opportunities for your team to contribute to solutions. Or perhaps I mis-interpreted your premise.

    Thanks again!

    Scott

  10. Pingback: April Dunford
  11. Pingback: Paul Philp
  12. Pingback: uxroom
  13. Pingback: Rajit Hewagama
  14. Nice article, Scott!
    I like most The Part about how different values come to light if One gets clear about conflicting goals.
    Thanks for bringing The topic up.
    Rolf

  15. Pingback: Rolf Götz
  16. Pingback: Klaus Brandlhuber

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>