At Cooper we talk a lot about goal-directed design. Usually the term "goal" is used without an explicit distinction between goals and a motivations. The distinction is an important one which can influence design.
Users enjoy the satisfaction of achieving their goals. User goals help us focus our design on solving meaningful problems for the user. If we design with the user's goals in mind, in the best case we will help them achieve their goals, at worst we stand out of the way.
Goals are defined as the "state of affairs that a plan is intended to achieve". Goals are what a person wants to do, achieve, or become. They are boundaries to states that people strive toward, and once they reach either terminate their efforts, or shift into a maintenance of the achieved status. Feeling smart, getting the best deal, and living the good life are all examples of goals. They represent a desired end-state of a set of particular actions.
Motivations are the drivers behind setting and pursuing goals. Motivation is why someone wants to do something. Motivation is what arouses and sustains action toward a desired goal. It gives purpose and direction to behavior.
In researching this, I was disappointed to find that there is little consensus on what are the core motivational needs. Some theorists claim motivation comes from stimulus-response, others from affect, others describe motivation in terms of social or cognitive drive. A survey of the major motivational theories reveals a few commonalities. Needs, desires and wants are the sources of motivation. Motivation directs behavior toward increasing, decreasing, or maintaining a specific state. Dr. William Huitt's list of motivational needs provides an overview of all of the major theories. I have distilled this list into the essentials.
People are motivated to increase or develop positive or good things. People are also motivated to decrease or eliminate negative or bad things. Finally people are motivated to maintain certain types of status quo.
- Inclusion (social)
- Pleasant consequences (reward)
- Likelihood of success
- Solutions to problems
- External restriction/control
- Unpleasant consequences (punishment)
- Threats or risks
- Negative physical sensations (hunger, thrist, etc)
Theoretically, all goals originate from this core set of motivations. If you keep asking why when someone identifies a goal, you should eventually end up with something on the list. In practice we don't have the time and users don't have the patience to answer enough questions to get to their core motivations. A more practical approach is to use the list to help with follow up questions. Notice when users express their needs, desires and wants in terms on the list.
So why is understanding user's motivation important? Knowing why someone has a particular goal gives us a more complex understanding of their goal. It can help us design solutions that scratch a deeper itch. Goals without motivations are one dimensional. Understanding motivation tells us not only the destination (goal) but the source (motive) of behavior.
Two people can have the same goal, but have entirely different motivations; for example, the goal to "stay in contact with family." Jane is motivated to stay in contact because she derives pleasure from close contact with her family. Tom has the same goal, but he is motivated by guilt. If Tom doesn't keep close contact he knows his family will give him a hard time when they see him. Simply knowing the goal won't give the finer nuance which is required to develop a solution which will serve each of the users' individual motivation.
Knowing Jane already takes pleasure in talking to her family the design focus might be on ways to increase the closeness, maybe two-way video, higher fidelity or decreasing rates in the evenings. Knowing Tom dislikes the chore of talking to his family, the design focus might be on ways to help him regain the time by un-tethering him to run errands at the same time, or to conference people in so he can get all the calls done at once.
Including motivations in goal-directed design is as simple as asking "why." You might literally ask "why" when a user expresses what their goals are in an interview. You can also notice the justifications users give for their actions. Their justifications can hint at the underlying motivations for behavior. Use the list above to help you realize when a user is talking about their motivations. It may be useful to attach the motivations which drive the goals in persona documentation.
I should point out that I'm not proposing that motivations should replace goals as design tools. Motivations help articulate goals. Using both will result in more precise, articulate solutions which will more deeply satisfy users.