Yoo-zuh-buhl

Increasing Intonation of Error Messages

Posted on September 4, 2011 by Kevin Rapley

If there is a breakdown in conversation, whereby the listener ‘misunderstands what has been communicated, the speaker repeats what she said earlier, using a stronger voice intonation and more exaggerated gestures’ [Interaction Design: beyond human-computer interaction, 3rd Edition, Rogers, Sharp, Preece].

We could increase intonation of error messages to assist in repairing the breakdown in conversation on, for instance, a web form.

When an error is made, the form could provide the usual error cues that we are well accustomed to. However, if the user fails to correct the problem and errs again, rather than returning the same error message (it could be argued that not enough feedback is provided from the error screen to the new error screen, that has been repeated again) the intonation is increased to allow the interface to repair the mistake and be more explicit to the user.

With the example shown here, we are not looking to go down a route of shouting louder at the user. There are parts of their entry which were valid, so if we take these out of the equation and say “Okay, we have got your name and email address, thanks”, the emphasis is then put on just the password field issues.

To further increase the intonation and exaggerate exactly how we want the user to repair the error, the password form fields have been emphasised by placing them in a container. The form fields and labels have also increased in size, and each has ‘required’ written after it in parentheses. We are still highlighting the main crux of the problem in red, but we are emphasising the error with stronger intonation, rather than screaming in the face of the user.

How about if they are still returning an error after this stage? Rather than returning the screen for a third time, it is obvious that there is something really wrong with how the user expects to engage with the transaction. It might be better at this stage to provide contact details on how they can get in touch to overcome their problem. Either that, or perhaps they need to be shown T’s and C’s information, data-protection policy, a fact-sheet or FAQ’s. This will depend on the type of transaction and the context of the error that is reoccurring.

Posted in Interaction Design | Tagged error recovery, interaction design, usability

Interaction design analysis of BT Hi-dS Parent Unit

Posted on September 2, 2011 by Kevin Rapley

BT Baby Monitor 150 [External link]

Good points

• Easy to hold in the your hand. It has a curved back so your palm and fingers can wrap around the unit. It is a good size to be handled in one hand and operated with the other
• It can be held without covering the main features on the front of the unit, which includes the noise level indicator, LED screen, buttons and speaker
• The buttons have a raised area that not only makes them more tactile, but easier to locate and press
• The lesser used functions are still easily reachable, but are out of the way when not needed. The lesser functions are the torch and paging options
• The torch and paging buttons are labelled ‘Torch’ and ‘Talk’, describing perfectly the functionality that they operate
• It is easily identifiable, even from a distance, that the unit is on and linked up with the receiver. The light on the front of the unit is green when it is active and linked
• The temperature of the room where the receiver is based sits top centre in the LED screen of the parent unit, occupying approximately ⅙ of the screen. It is well placed and easily viewable
• The LED screen illuminates when one of the buttons is operated on the front of the unit, making the screen highly readable no matter the level of light in the room
• The menu and mute buttons simply say ‘Menu’ and ‘Mute’, so they are very distinguishable
• The unit has a clip on the back to allow it to be attached to clothing, a bag or a belt, allowing it to be carried around by the user hands-free
• Most of the weight of the unit is in the batteries that operate it. This makes the unit lightweight and easily transportable
• The light of the torch is on the top of the unit, which is a logical location in relation to its operating button which appears on the right-hand side of the unit. This allows the button to be suppressed and the unit pointed in the direction the user wishes the torch light to be directed
• Batteries can be replaced via the removable panel at the bottom of the unit. The battery cover panel does not get in the way of the normal usage of the unit
• The base is flat and has a good sized surface area, making the unit stable when placed on a flat surface
• When the parent unit picks up a lot of noise from the receiver, the lights that represent the volume received are red towards the right-hand side
• Aural feedback is given to the user when they change the volume of the unit

Bad points

• Glare on the LED screen makes seeing the screen difficult until the back-light is operated. It is counter-intuitive to press a button on the front of the unit that you do not actually want to operate in order to read what is on the screen
• On the front of the unit are two buttons stacked on top of one-another. The top has an upwards arrow icon, whereas the bottom button has a downwards arrow. It is not immediately clear what I will be operating if I press one of these buttons – will it change the volume? But these aren’t typical volume buttons. Will it allow me to cycle through options once I press the menu button?
• On the front of the unit is a button with a tick icon, which usually signifies that something is correct or has been completed. To put this on a button means that I will be correcting something or saying ‘yes, this is completed’. I had to think about this, so I would say it isn’t greatly intuitive
• The power button uses the universally recognised power symbol ubiquitous with electronic devices, but this could be coloured red to signify power and give it more emphasis
• The contrast levels of the button labels is moderate, this could be improved
• It isn’t clear where the microphone is located, for when the talk operation is used
• When the ‘Menu’ button is operated, the LED screen presents the question ‘Light On?’, which is not a very helpful question. I would expect ‘Turn light on?’
• Relating to the above point, I am posed the question, but I am not sure what to do with it. Do I press the button with the tick? If I do need to press the button with the tick, it would be better located nearby the LED screen where the question is posed
• When I press the ‘Mute’ button, instead of displayed ‘Muted’ on the LED screen, it instead displays the universally recognised symbol for muting, ubiquitous with electronic devices. I would expect the feedback as a word, in keeping with the button. Otherwise, why not use the mute symbol on the button as well?
• If I press the button with the tick on it when I am not in a menu option, I receive no feedback
• Pressing the torch button and releasing immediately does not activate the torch, no feedback is provided to the user to let them know that they need to press and hold for a few seconds to activate the torch

Description of the user experience from interacting with the device

Overall the experience of using the device is positive. The most important ability of being able to see the temperature of the room where the receiver is situated, and whether any noise is being made in the same room is clearly viewable, even from a distance. If the temperature is not within a comfortable range for a baby, the unit provides auditory and visual feedback in the form of a bleeping noise, lighting of the LED and flashing the volume on the screen. This also applies if the unit is low on battery power.

Secondary actions, such as talking to the child, or using the torch, are easily located and are ergonomically in suitable locations.

The lesser used actions, which are hidden away within the menu of the screen, will most likely be a learned process. This is due to the fact that it is not immediately obvious how to navigate and select the options with the buttons that are available and how they have been labelled. None of the tasks have a large cognitive load, so once the menu has been explored and the user knows how to navigate them and make selections, the processes will be easily operated.

Usability goals for evaluating the product

• Is the product capable of allowing parents to monitor the room temperature and any noise made by their child whilst they perform daily tasks around the house?
• Does the parent unit sufficiently alert parents to any noise, changes in temperature, loss of connectivity with the receiver or if the batteries are low?
• If their child is suffering from disturbed sleep, are parents able to activate the night light on the receiver, or play nursery rhymes remotely via the parent unit?
• Are parents able to navigate the menu items and perform required tasks?
• Does the unit provide an appropriate set of functions that will enable parents to monitor and assist their child during sleep and play?
• Is it possible for the parent to work out how to use the unit by exploring the interface and trying out certain actions? How hard will it be to learn the whole set of functions in this way?
• Is the interface consistent or inconsistent? What affect does this have on the device?
• Does the device provide enough affordance in the design?
• Are constraints applied to the device? If so, are they appropriate to its usage? If not, does this cause problems using the device?

User experience goals for evaluating the product

• What is the user’s immediate response to the unit, do they regard it as a satisfying device that will be helpful in assisting monitoring a child?
• Does the unit have the ability to be invisible when not in use, allowing parents to carry on with their daily tasks until they need to be alerted to an issue?
• Are user’s able to discover the secondary and tertiary functions of the device, and in doing so is this process pleasurable, enjoyable even?
• The device has the ability to create light and sound in different ways, both with the unit and remotely to the receiver. Does this create an aspect of play to the device? Can fun be had?

Which of these goals are most important

Out of the usability goals, the following two are the most important:

• Is the product capable of allowing parents to monitor the room temperature and any noise made by their child whilst they perform daily tasks around the house?
• Does the parent unit sufficiently alert parents to any noise, changes in temperature, loss of connectivity with the receiver or if the batteries are low?

It is crucial that the unit performs its primary task of alerting parents. It is also a given that parents are not going to be watching over the unit, waiting for the slightest of murmurs. The device needs to be portable and able to fit in with the daily tasks that parents perform. It is required that it does this discretely, and only alerts parents when it is necessary to do so.

This leads nicely in to our most important user experience goals, which support the above statement:

• Does the unit have the ability to be invisible when not in use, allowing parents to carry on with their daily tasks until they need to be alerted to an issue?
• What is the user’s immediate response to the unit, do they regard it as a satisfying device that will be helpful in assisting monitoring a child?

The device also needs to be satisfying to use, encouraging parents to explore its options and engage with it. If the device was frustrating or annoying, it would not be used.

How does the parent unit fare?

Against the most important usability and user experience goals the parent unit excels. The unit can be placed in a room, or taken around the house upon your person. It is very easy to forget that it is there, which may be a problem if you move to another room and don’t take it with you. When you do need to be alerted to an issue, the device makes its presence known.

The unit certainly is a satisfying device in the way it has been designed. It isn’t perfect, and the menu items need to be initially learned, but once a user has done so it is, the unit satisfies.

Improvements that could be made to the device

• The most prominent issue for me was the button with the tick icon. This is not a familiar icon for selecting menu items and enabling them. I believe a better suited icon could be used, or even better just a text command written upon the button.I would also look to relocate the button so that it was to the bottom right-hand side of the LED screen, right beside where the menu item question is displayed. This would couple the question with the action adequately enough to remove hesitance.

• Secondly, I would change the glossy screen, which attracts a lot of glare, with a matt finish. This will improve the visibility of the display in poor light conditions and from a distance (glancing over at the device when placed in a room)

• Thirdly, the labelling of the menu questions is poor at times. It feels like too many words have been removed from ‘Light On?’, and it hasn’t been written in an action based manner, which caused me some initial confusion

Posted in Interaction Design, Usability, User Experience | Tagged analysis, interaction design, usability, user experience

Running digital card sorts for output to concept models and site maps

Posted on June 11, 2011 by Kevin Rapley

Choosing cards to sort

Cards are best chosen from functional specifications (document defining all the interaction behaviour that will be present in the interface) or if you have the luxury, capture cards based on an existing system. If you have an existing system or prototype to capture cards from, you will need to perform a content audit, or inventory, depending on size and complexity. This will eek out the cards that will need to be created.

It is important to not mix content with functionality. Either choose to sort one or the other. Mixing the two will result in participant confusion through increased cognitive load, leading to obscure results. I have a personal preference for action based cards, focusing on the functionality and interactivity of systems.

Using xSort to run digital card sorts

xSort is free software for Apple Mac. It does nearly everything I would like from software to run digital card sorts. What I am not keen on with xSort is the felt green table top image tile that it comes with out of the box. In my opinion it cheapens the software and makes the table look like a game of patience. Luckily this can be replaced by opening the software package contents in OSX and replacing green_velvet_texture.tif in the Resources folder with an image tile of your choice. Just remember to supply it with the same name, effectively overwriting the original.

When running an open sort I always perform it as I would if I was using physical cards. I randomise the card location on the table which mimics spreading physical cards out over a tabletop. I ask participants to first group cards together that they feel may be logically grouped. I encourage them to not overlap cards so that they maintain visibility of all the cards within groups, allowing them to change their minds as the see fit. In physical card sorts I allow duplication of cards, keeping blank cards nearby in case a participant wishes to scribble down a duplicate. Unfortunately, xSort does not provide this functionality, but I still encourage this practice. I do so by informing participants of the software limitation upfront and ask them to vocalise if they wish to duplicate a card in to 2 or more groups. I capture this both in my notes and on Silverback.

I advocate getting participants to create their own concept models during a card sorting process. Once they are happy with the groups they have made, I then ask them to order the cards in to a process flow. Some gentle encouragement is useful – “What would come first in your opinion? What would come next?”

Once process flows have been created for each grouping, the cards can be added to groups and named by the participants. If participants use group names such as “Important” or “Miscellaneous” or any other term that is non-descriptive of the group, ask them to elaborate. This way you will understand the true meaning of the group name, allowing for standardisation when you come to collate the results.

At this stage when all the groups have been created and labelled, I use the clean up tool which places all of the groups neatly side-by-side. I then ask participants to reorder the groups in to a further process flow, or describe any relationships between the groups. This data will also be used in the participants concept model.

During a closed card sort, I ask participants to place the cards that they feel fit with a group underneath the group, rather than within it. This provides greater visibility of where cards are and allows participants to change their minds as they complete the process. Additionally, this provides ability to rearrange cards in to process flows; the rigidity of placing cards in groups does not allow for rearrangement (the last card in is stacked on top).

Silverback

I run Silverback during the digital card sorting process to capture the screen and any comments made by the participants. This documents confusions over cards, misinterpretations, where cards should be duplicated and generally any other insights or issues that the interface could have. I usually coincide user interviews with card sorts and these can be captured through the Mac iSight using Silverback too. Playback of the sessions can be paused on poignant moments, such as when all the cards have been grouped and arranged in order, and then screen grabbed ready for output to concept model diagrams.

I let the participants know that sessions are being recorded, and get their permission for doing so. Using Silverback, I can forgo lots of note taking allowing me to concentrate fully on the participants. It is worthwhile running a stop watch as you start the session, noting down the time when participants say something of particular interest. Sessions I run normally last around an hour; noting down times prevents having to trawl through hours of video content.

Directing the card sort

I encourage participants to think aloud during the process. I find that sitting at a computer and performing a sort, tends to make participants “close-off” and focus on the task without describing what they are doing. When they begin to make groups, ask them what decisions they are making and conclusions they are coming to. The same goes for when they decide to move a card from one group to another. These cues allow us to identify thought processes and whether a card needs to be duplicated or was initially misinterpreted.

Card sort analysis spreadsheet

xSort comes with a built-in analysis suite that provides detail on correlations via a distance table and cluster tree via a dendrogram. As Shanshan Ma describes in her article for UX Matters, ‘Dancing with the Cards: Quick-and-Dirty Analysis of Card-Sorting Data’ –
“Clients seem to have difficulty understanding a cluster analysis and all that’s going on with dendrograms. So, basically, we need a quick-and-dirty way of analyzing and presenting card-sort data that conveys the value of the card-sorting method.”
I completely agree with this statement and favour Donna Spencer’s readily available card sort analysis spreadsheet to compile all the results. I do however expand upon the spreadsheet by adding a sheet by duplicating the ‘Correlation’ sheet and renaming it ‘Clusters’. I then proceed to rearrange the cards in descending order of correlation strength by groupings, as described by Shanshan Ma in the before mentioned article. This provides a clear visual of how cards have been grouped and by how many participants.

The toughest part, I find of sorting analysis, is standardising the group labels in open card sorts. It takes re-watching of the Silverback recordings and reading between the lines of what participants are describing, and what they actually mean. It will take intuition to gain good standardisation of the group labels. I normally do this over more than one sitting. Look over the data in front of you, listen to the users and make decisions. Is a group a sub-group of another? Is the label too granular or broad?

Producing concept models

With the card sort analysis done, we can now focus on what the results output to. We have already captured the individual concept models of participants. These need to be reproduced in to diagrams. My software of choice for producing concept models is OmniGraffle. Once you have a set of concept models for each participant, you will need to look for patterns and commonalities amongst all of the sessions. To do this, I print out the concept models of each participant for as many groups that have been produced. I then take a set of concept models and for each group begin to mark corresponding cards (the same card across all participants) with a coloured pencil. A different colour for each card. The set of concept models is then stuck on a whiteboard. The colours allow you to identify patterns, such as location, proximity to like cards, and whether they follow or lead certain cards. This part takes some intuition again: decide on an overall flow based on the patterns emerging for all the sessions for the particular group observed. Write these down on the whiteboard beside the concept models. Take a photo of the group (it is a good idea to add the group label to title the board) and then proceed to do the same for the next group until all are complete. You will also need to pay attention to where the groups have been placed in the group flow (remember we asked the participant to order the groups once all the cards were in place during the xSort session). From all the results, you will now be able to create a ‘best-fit’ concept model.

A separate concept model I produce is a representation of the ‘Clusters’ sheet in our card sort analysis spreadsheet. I use smaller font sizes and lighter shades of grey to represent weaker correlations. Broken box lines to represent secondary areas that content may fit in to, or where cross-links should occur. Like how I used the colour pencils to mark same cards in the previous concept models, I do the same for this diagram too (with coloured dots in OmniGraffle) in order to represent where cross-links should occur.

User journeys and site map

Armed with a set of concept models, based on user data, you can now go fourth and create user journeys and site map diagrams for the interface. You will be able to back up your decision making for this, including where linking should occur, based on all your hard work preparing, executing and analysing the card sorts.

Posted in Information Architecture | Tagged card sorting, concept models, OmniGraffle, Silverback, site maps, user journeys, xSort