The Problem with Crumpets - on Information and Inconsistency

My 3 year old daughter has a milk allergy. I'm not talking about an intolerance, although those can be pretty bad, I mean a full on allergic histamine reaction to any dairy products either ingested or touching her skin. When we tell other parents about this a common sentiment is that they can't imagine how they would cope in such a situation. But we do cope, just as many other parents cope with similar situations and, sadly, other conditions that are much more severe. While this was a significant hurdle for us to tackle in the weeks after we found out, over time we've adjusted our own behaviour to take Millie's condition into account to the extent that for much of the time it is nowadays not at the forefront of our minds.

Accidents aside, when we do encounter problems they can usually be attributed to one of two situations.

1. A lack of information about a product
2. Inconsistency in a product with our expectations

The Known Unknowns

Lack of information hits us when we cannot tell whether a product contains milk or not. Whilst I have to say in the UK the food labelling is excellent, we do still encounter situations at home and abroad where we cannot be sure whether a foodstuff contains dairy. This is incredibly frustrating when we are trying to feed my daughter. She is a great eater and will try most things so it saddens us when we are unable to give her things that are probably perfectly safe as we don't have the information on the ingredients.

Whilst very frustrating, lack of information is not specifically dangerous. We are conscious of our absence of knowledge and can take steps to improve this, or adopt a low risk strategy in response. This usually involves disrupting a shop assistant's otherwise peaceful day to fetch packaging and read out long lists of ingredients. Sometimes, as a last resort, it involves just ordering my daughter chips / french fries.

Almost as bad as the complete absence of information is the situation where allergy information has been provided, but it has clearly not been considered under what circumstances such information might be required. Restaurant allergy lists that mark entire meals as containing dairy when actually it is only the dressing on the side salad, or list all of the ingredients that the restaurant uses but leave an almost impossible task of mapping these back to the meals on the menu, are prime examples. Information that is not available in the appropriate format or location when it is required can be as bad as no information at all. Burying the failings of your system deep in the documentations and proudly pulling this out shouting 'RTFM' when your users raise support requests is about as sensible a strategy as telling customers standing in your restaurant that your allergy list is only available on your website (this has happened to us).

My key point here is that lack of or poor quality information may not directly cause mistakes, but it certainly creates frustration and extra work. If your product is not intuitive to use and has poor user documentation then the customers may not necessarily be getting themselves into trouble but they will have to work harder to find out how to achieve their goal. Your support desk is probably busier than it needs to be answering questions, just as my wife and I use up the shop assistants time running round reading packaging. Alternatively they might act out of frustration and try to plough on regardless and get themselves into trouble. Again the result is likely to be a costly inquiry to your support team.

The danger of the unknown unknown

A potentially bigger problem that we face is inconsistency. When products, product ranges or companies are inconsistent in their use of dairy then it can have grave consequences for my daughter. At least with a lack of knowledge we are aware of our situation. When we encounter inconsistency we may not possess a similar awareness, instead falsely believing that we are acting in a position of knowledge which is far more problematic. Some examples:

• Asda brand crumpets are dairy free but Marks and Spensers are not (both are UK supermarkets).
• Jammie Dodger standard size biscuits contain no dairy, but the smaller snack size versions have milk in.
• Heinz ketchup does not contain milk but Daddies ketchup does
• Hellmans original mayonnaise has no dairy but the reduced fat mayonnaise contains cream (yes, they honestly add cream to reduce the fat content)
• McDonalds in the UK have a full allergy list in store plus a kids meal that is dairy free, thereby providing a safe (if less than appealing) food option when travelling; McDonalds in France have no allergy list and no dairy free meal options - even the burger buns contain milk.
• Some of the serving staff at TGI Fridays in my home town are aware of their allergy list but some are not and so do not consult it when suggesting safe dairy free options

As you can probably tell, all of these are examples we've personally encountered, with varying degrees of disaster. It is when we have encountered situations of inconsistency that Millie has been most at risk. We act, assuming ourselves to be in a position of knowledge, yet that assumption is incorrect. The impact can vary from having to disappoint our daughter that actually she can't have the meal/treat we just promised, to her having a full blown allergic reaction having eaten a crumpet that Millie's grandmother mistakenly believed to be safe.

The key point here is that in the presence of lack of information, customers may still act out of frustration but will be aware that there is an element of risk. With inconsistent behaviour that awareness of the risks of their actions may not be present. As testers a key part of our job is to understand the context in which the users are using the system and the associated behaviours that they will expect. Michael Bolton recently wrote a post extending the excellent HICCUPS mnemonic with regard to consistency heuristics that help to consider the different consistency relationships that might exist for our product.

Some ways that I have used to try to consider other viewpoints in our testing:-

• Developing personas and identifying the products and terminology that those personas will relate yours with.
Sometimes the context in which you are looking for consistency is not obvious and some care must be taken if the appropriate oracles are to be identified. I have a friend who once deleted a lot of photographs from his camera as he selected the 'format' option thinking it would allow him to format his photos. For the context of the SD card as a storage device the word format has one meaning consistent with computer hard disks and other such devices, but in the context of photography the term 'formatting' has quite another meaning, with which the behaviour was inconsistent.


• Researching other products associated with your market and using these as oracles in your testing.
This may change over time. My organisation has historically worked in the database archiving space and a lot of our testing oracles have been in that domain. As we have grown into Hadoop and Big Data markets a new suite of associated products and terminologies have started to come into our testing.


• Question functional requirements or requirements in the form of solutions
Try to understand not only the functionality required but also the scenarios in which people may need to use that functionality. As I wrote about here using techniques such as the 5-whys to understand the situations that prompt the need for a feature can help to put some perspective around the relationships that you should be testing and identify the appropriate oracles.


• Employing team members with relevant knowledge in the market in which your product is sold
As I wrote about in this post it is a great idea to develop a skills matrix of relevant knowledge and try to populate the team with a mix of individuals who can test from different perspectives. Testers can share their knowledge of the expectations of the roles that they have insight into and help to construct more realistic usage scenarios.

Consideration of the Situation

Most products from supermarket bakeries have somewhere on the packaging 'may contain nuts or other allergens'. If the requirement for food labelling is that it warns of the potential presence of allergens then this label does achieve that and would pass a test of the basic criteria. As a user experience, however, it is extremely frustrating and results in an approach of not buying perfectly suitable products, time consuming requests to supporting staff or unnecessary risk taking on the part of us, the customer. I'm sure that the restaurant allergy lists that I referred to above would look very different if the designers had tested the scenario of actually trying to order a meal for someone suffering an allergy, rather than just delivering the functional requirements of listing all of the allergens in their food.

A critical testing skill is the ability to be considerate of the situation and experiences of the users and their resulting expectations. Delivering and testing the required functionality is only one aspect of a solution. In addition to testing the 'what' we should also consider 'why' and 'when' that functionality will be required and the situations that demand it. If the customer cannot utilize our features without making mistakes or requiring further information due to missing information and inconsistencies with their expectations then neither your customers or your support team are unlikely to thank you for it.

As a daily user of allergy labelling it is very clear to me those companies and products aim to meet the basic requirements of food labelling and those that go beyond this to provide consistency across their range, clear labelling and useful additional information at the point at which it is required. Needless to say it is these organisations and products that we seek out and return to over and over again.

image : http://www.flickr.com/photos/theodorescott/4469281110/