FEW HICCUPPS: What is the difference between Purpose and User Desire?

Hi fellow testers,

I’m committing the well known FEW HICCUPPS heuristic framework into my brain. I’m confident it will help me so much to effectively test requirements. If you’re unfamiliar with it, read that awesome post. I read it a while ago but never got around to applying it.

I understand most of them, but one that makes me scratch my head is ‘Purpose’. On the surface, it looks simple but can anyone clearly contrast how Purpose differs to:

  1. Users’ Desires
  2. Claims
  3. World (maybe this one is irrelevant as it is an inconsistency heuristic as opposed to a consistency heuristic)

How can some behaviour or thing be inconsistent with ‘Purpose’ but consistent with 1 and 2? Does anyone have an example?

3 Likes

This is a brilliant post from Michael you shared, thanks.

This one is talking to me a little about having “World experience”, IE have I looked at how someone a million miles away from my house solved the same problem, and if I have not I should do so.

  • I can learn from them maybe solving it more simply/succinctly than I have, in my product. For example is their implementation cheaper to run than mine?
  • I can learn about how they workflowed it, and perhaps use that to improve mine
  • I can maybe learn about a “locale” problem and a way of solving it which I never know I would hit later
1 Like

Thanks @conrad.braam , interesting take on ‘World’ and I agree with you on those points. My original question was more about ‘Purpose’ however, do you have any thoughts on that?

I understand most of them, but one that makes me scratch my head is ‘Purpose’. On the surface, it looks simple but can someone clearly contrast how Purpose differs to:

Users’ Desires
Claims
World (maybe this one is irrelevant as it is an inconsistency heuristic as opposed to a consistency heuristic)

On “Purpose” , that is a harder one to get agreement on. Because we all know that 80% of users only want to pay for the 20% of the code you wrote that they use. Imagine if that was even possible, but purpose is for me that, single thing, your product does. The reason that is sometimes harder to define, is that purpose becomes more removed from the product core reason for being, as time goes by and it gets added to and as markets change. When your product is an API or service, that becomes increasingly fluid because the “purpose” may be externally influenced over time.

I wonder if Michael has this heuristic there to remind testers to separate business goals from quality goals. So I think purpose is what’s the main use case we “market ourselves” as being best in the market at.

I usually use heuristics like FEW HICCUPPS to come up with possible ideas for tests. It doesn’t usually matter to me whether I tested something because of Claims, or because of Purpose. At least not for the actual testing. Maybe there is a good reason for using the “right” term, for instance for reporting purposes.

An example how it could make a significant difference, for instance, is an app, provided “for free” by a public transportation company, that helps a user find the best route through a city using public transportation.

  • The User’s desires here could for instance be “I want to know the fastest route from where I am to where I want to be”.
  • A Claim could be “When the user is shown a route request, the app gives the user the option to buy a ticket by tapping a button”.
  • And the Purpose could in this case be “The app should make it easy to buy tickets, so that we can sell more tickets”.

Each of these statements can lead to different test ideas. And as a consequence they can lead to different types of valuable feedback (bugs, improvements, …) to the provider of the app.

2 Likes

Your example is a brilliant with the transport company. I understand it much better now :grinning:.

When I look at

The app should make it easy to buy tickets, so that we can sell more tickets

My brain says: ‘Wait a minute, couldn’t this also be a claim as well? or a user desire?’. Perhaps I shouldn’t worry about being perfect on the exact definitions of each heuristic. It is possible for that sentence to belong to all three at the same time. It depends how I look at it as a tester.

Although all of them are useful, I’m focusing on the high value ones for my context. For example, I am choosing to put these as low priority:

  1. Image - It’s for the marketing department to worry about
  2. Statues/Standards - There are no external standards we need to follow right now

I know that this is going off topic now, but I’m happy with your post as the answer to my question. Thank you so much Sarah.

1 Like

I agree @sarah.teugels explains this better, above, because the goal for the tester is to produce good test cases that matter, and not get distracted by business risks they don’t control. So which heuristic you use is less important than basic understanding of each, and looking at all of them for hints.

Let me take the imaginary VIP Cinema app as an example.

The purpose of the app is to reduce the time spent on a cinema visit. The main function is to sell movie tickets, snacks, and drinks in advance, so the visitor can watch the movie without the queues.

User’s Desire could be like: I would add a lot more like a parking place for my car, the sound track of the movie on my favourite streaming service, and a nice collectible cup. However, a user would have to make a lot of choices. It would increase the time spent on the visit.

Claims: VIP Cinema app is the fastest way to buy a movie ticket, a snack, and a drink in advance. If the application does not support a screen reader, then blind people or people with a bad view cannot buy anything.

World: the product owner has a user story that frequent users of the app get VIP cinema points. These points can be used to get a discount. So money and points can be used to pay a cinema visit. This would lead to a situation that a user has to spend additional time on points.

1 Like

I wonder if Michael has this heuristic there to remind testers to separate business goals from quality goals. So I think purpose is what’s the main use case we “market ourselves” as being best in the market at.

Well, you could ask me. :wink:

The difference between “user desires” and “purpose” is that purpose refers to the designer’ or builders’ explicit or implicit purposes for the product or feature, and that user desires refer to… well, to users’ desires. In other words, one is about the makers’ intentions, and the other is about the users’ intentions and needs— especially the intentions forgotten users. These sets of intentions may not be the same.

As a trivial example, a designer might intend to create an easy-to-use interface (“just click with the mouse!”), but a keyboard user might be bothered or annoyed by having to reach for the mouse.

The difference between “purpose” and “claims” is twofold. First, claims can come from different people, so claims may conflict when people have differing agendas and differing interpretations. Second, the statement of a claim may be different from the intention of the person making the claim — a misinterpretation, or something outright erroneous.

We encounted a problem like this while testing a medical device. There was a specific intention of one of the controls, but the specification had been written by someone not fluent in English — someone who habitually omitted the word “not”. So the specification indicated something directly opposite from the designers’ intentions. This happens, and we must be prepared to notice it.

With respect to the principles and inconsistency: pretty much all of the principles refer to the idea that we want the product to be consistent with desirable things, and inconsistent with undesirable things. “World” is about the idea that the product is typically modelling or representing things in the world. In general, we want the product to be consistent with the way things work in the world. Explainability refers to the idea that we want the produt to be consistent with our ability to explain it. In general, we want the product to be consistent with its own history, etc.

None of these represents a rule though. For instance, we want the product to be inconsistent with its history if there was a bug, and we’ve fixed it. We want the product to be inconsistent with our image if we want to change our image, and so forth.

Although oracles can be used generatively (as Sarah suggests, with her very nice trio of examples) to produce test ideas, they can (and I would argue must) also be used retrospectively. You are more credible when you can explain and justify why you’re suggesting that something you’re observing is a problem.

The point of the oracle principles is that they represent ways for us to recognize a problem when we encounter one in testing. That’s important, because our job isn’t really to create test cases, nor to show that the product can work (that’s a job for marketers or salespeople or TV pitchmen). Our job is to identify ways in which the product might not or does not work. A product can be okay with respect to lots of the principles, but if it’s not okay with respect to even a single principle, we have reason to suspect that there might be a bug, and to report accordingly.

I’m not exactly sure how I’d tease apart “business goals” from “quality goals”, myself. Quality is "value to some person(s) who matter(s). It seems to me that, most of the time, businesses want to produce things that have value for some person(s); and that the business doesn’t want trouble. I would suggest that if you see trouble, whether that’s a problem in the product or a potential problem for the business (or both), report it.

Finally, I’ll end this long reply with this: there’s a serious note on the “you could ask me” stuff above, and that note has relevance for everyday life at work. If someone says something that’s unclear to you, it’s usually a pretty good idea to ask that person what that person meant, since that person is most likely to know what he or she meant.

2 Likes

Thanks so much Michael, your post clarifies a whole lot. My excuse for not initially asking you is because you are well known and I assumed you are a busy bee. But if you’re willing to answer anything in future, that would be awesome.

1 Like

Hi, Philip…

I’m well known and a busy bee… but answering questions and helping people is the kind of busy I enjoy. So please feel free to ask any time, either here, in email, or via the usual online media. I’m pretty easy to find — as long as you include the string “testing”; otherwise you run the risk of confusing the singer.

Cheers,

—Michael B.

1 Like