Designing for Goals
Good design is goal-based. If your product helps people with one or more of their goals, they will likely see value in it. If you do this better/cheaper than other products, you may have a successful product on your hands.
While it’s clear that we should design to support user goals, the act of identifying goals can be tricky. We don’t always have a solid definition of what makes something a goal. We tend to think of goals in terms of accomplishments — a point to reach. And there is some truth to this. But goals are more nuanced than that. And when we design, we need to understand these nuances.
I want to take a bit of a deep dive to talk about goals. This will help reframe the way we think about and talk about goals. This may untangle some of the confusion we have by introducing a few new concepts to make it clear what makes a good goal and how to support that in design.
Defining Goals
Every new year, people set ‘goals’ for themselves. Some people want to stop smoking. Others might want to spend more of their time giving back to the community. Some might want to save more money or learn a new skill.
A common goal across many people is to lose weight, and it’s a good place to begin to look more closely. For a variety of reasons (health, looks, ability to do certain activities), many people identify that they want to lose some weight. They see what they currently weigh, identify a weight they think they should be at, and set out on ways to achieve that goal.
But it turns out that the goal is not really to lose weight. In reality, the goal of every single person on earth is weight management. Yes, one person may have a goal of losing weight, but someone else might have a goal of gaining weight. A third person may be looking to keep their weight the same but change their mass (more muscle, less fat). Others are happy with where they are at, but are constantly vigilant that they stay that way. Looking at it from this perspective shifts how we think about goals.
Regardless of where you stand, your weight is just a data point at a specific time and your ideal weight represents some target range to hit. These are called limits, of which there are several types. There are:
- Performance limits — targets that you want to generally stay between (your ideal lower and upper weight),
- Operational limits — targets that define where the equipment is designed to operate within, and
- Safety limits — targets that when breached will indicate a degradation in the safety of the system (think in terms of obesity, which starts to have health effects on your body).
A common pitfall of people who are trying to lose weight is that once they get to their target (cross back within ideal limits), they relax and eventually put the pounds back on. That’s because losing weight isn’t really the goal; losing weight is the process of getting back into acceptable limits. Once there, the goal of weight management still stands and the limits still exists as guide posts for future actions.
This may not work for all domains, but the concept applies fairly broadly. It applies to many health related concepts beyond weight. While ideal human body temperature is often cited as 98.6 degrees, that is just an average (probably about 98.2 actually). In reality, there is an acceptable goal range from about 95 to 100.4. Once these limits are crossed, you need to start taking actions to correct (rest, fluids, and medicine). Beyond these, there are additional safety limits. If your temperature is higher than 104, you are supposed to go to the doctor or hospital immediately.
Any long-term activity will have management goals rather than achieve goals, so it applies especially well for business to business type products. To be sure, there are some goals that are completed when an event occurs, like purchasing a ticket. Even so, these businesses will have long term goals that they need to support at the same time (e.g, maintaining brand loyalty).
In design, we not only have to define the goals of our users, we also have to define the limits that our users must consider. These boundaries are as important as the goal itself, because they are the only way the user knows if they are successful.
One benefit of thinking in these terms is it allows us to create some fundamental rules for alerts. An alert can be triggered when a goal measure is outside of some limit condition. As the measure goes beyond new limit boundaries (beyond the operational limit, for example), new alerts are triggered and new actions need to be taken.
You can’t always know the specific limit values for each person in every situation, but you can know they exist and account for them in your product. There are many products and domains, especially physical systems (e.g., think power plants or air traffic control), where limits can be known and hard coded into the system.
Changing our mindsets about goals is important for good design. Most systems that require long-term operations are not about one-time accomplishments but sustained success. These goals need to be thought of in in terms of maintenance and management over achievement.
There Is Never Just One Goal
We often talk about goals in the singular, but this oversimplifies the world in which we live. The Jobs-to-be-Done framework talks about the job that a product is doing. A common refrain in JTBD is, “The user doesn’t want a drill, they want a quarter inch hole.” Using JTBD, it becomes easier to think in the terms of the goals of the user.
But this is just part of a larger system. Goals don’t live in isolation. We can then ask, “Why do they want a quarter inch hole?” For some people, they are trying to affix two pieces of wood together. Others may want a quarter inch hole in order to hang a picture on the wall. In each case, they might use a drill to make the hole. However, in the latter case, they may choose another approach altogether. They may want to hang the picture using some damage free hanging hooks and not need a hole at all.
Thinking about the problem this way shows two places where innovation can happen . You can innovate solutions to help with the current goal (a more powerful drill), or you can innovate solutions to help with the goal you are trying to support (damage free hooks).
When you hear about complex systems, it’s usually the number of goals and how they are interconnected that lead to the complexity. This is why I like Systems Thinking. It becomes easier to see how everything is intertwined and to see where a change in approach to one goal can have consequences in other goals. Importantly, it also becomes easier to see how unanticipated effects may result.
Facebook and other social media are being maligned for driving people to stay on their sites. There is certainly value in the goal of maintaining friendships and general news awareness. But these are in support of higher-level goals, like managing mental health. Staying on these social media sites might actually be hurting these higher level goals. When you see the bigger picture it’s easier to make design decisions that are good for the entire system.
Finding the balance isn’t easy. Since goals are strongly interconnected, it’s easy to quickly expand scope too far. You can keep asking ‘why’ questions to get higher-level, more abstract goals. Why does the person want to hang a picture on the wall (decoration, memorializing a person, tell a story)? You can keep asking ‘how’ questions to get to lower-level sub-goals (“What do I need to do in order to accomplish to do this?”). At some point you have to stop. This scoping decision is important for any product development process.
I was taught a one-away rule. Start with the high level goal of what your user is trying to accomplish and work down. But understand why your user is doing this goal and what constraints it places on them. Figuring out where to stop at lower-level goals is tougher, but is often defined for you by budgets.
Most importantly, your analysis artifacts need to capture the goals of your users, how they are related, and what the scoping decisions are. This can help you determine where to expand once the first goals are supported. If your artifacts do not support this, you need to modify your process.
Supporting Multiple Goals
Given that goals are always part of a larger system, and the completion of higher-level goals are the reason for the completion of any particular goal, one of the more difficult situations for users to face is conflicting goals. For many systems, the purpose of one goal is to help with the completion of many higher-level goals. Ideally, you can find the sweet spot where you can support all higher-level goals with a single solution.
A simple way to think about this is to picture a game of tic-tac-toe. With each movement choice, the player has to balance two goals: 1) Increase offensive advantage, 2) Limit defensive liability. If a player focuses too much on goal 1, i.e., they are too aggressive, they can leave themselves quite vulnerable to attack. A player that focuses too much on goal 2, i.e., too defensive, may miss opportunities to create an advantage. While choosing a move, the player must find the sweet spot between the two.
If you’ve ever played tic-tac-toe against a child, you have seen this in action. Most young kids are so focused on winning that they miss chances to block your winning move. Once that happens, they over-correct and play too much defense, and miss easy chances to win.
Design then, is making the goals clear and placing them in the context of the limits. In this way, the user has as the information required to make the best decision possible.
In some cases, the higher-level goals will place conflicting demands on the user and in no way can a single solution point be found. There is nothing that design can do to make this problem go away. Instead, good design will highlight this case to the user so they can act accordingly. This information plus the context of the situation will help the user satisfice — find a satisfactory solution rather than trying to find an optimal answer that doesn’t exist.
Conclusion
Pick a methodology, whether Jobs-to-be-Done, Cognitive Systems Engineering, traditional Interaction Design, or any other variant of design you know of, and at its heart you will find user goals. Using goals as the guiding light will help make sure the focus of design is in the right place. Great design will help users understand their goals, the measures to accomplish them, and the limits that define success.
Users will not talk in goals. They talk in tasks or about data they need. One of the biggest challenges in the analysis step is taking all the things that the users tell you and abstracting from this the goals that they are really aiming for. Users aren’t really going to a scale to ‘check their weight’ (a task). They are at the scale to manage their weight (the goal). They are not there to just manage their weight, they weigh themselves to maintain health or manage their self-esteem (likely both, and other higher level goals).
Your analysis tools need to carry this information. Your design needs to account for it. But danger lurks here. If your focus is to small, you cannot possibly understand the necessary context to do right by your users. If your focus is too big, your product will be too big to get off the ground. A great MVP threads this needle.
In the end, you need to know your users. Learn their goals. Design so that users can accomplish these goals. That is the highest-level goal of design after all.
