Send me a pic: Did you put it up at work? Is it looking good? Take a pic and mail it to me or upload the pic and send me a link. I’d love to know where you’ve put it up and how it looks. You can mail me at hello at conetrees dot com
A usability test consists of the following steps:
1- Usability test planning
2.1- Participant Recruitment
2.2 Scenario & Task creation
3- Execute the usability test/ conduct usability test sessions
4- Data Analysis
6- Usability test recommendation incorporation checkpoint
I will follow up with another post to explain the steps in detail, but for now, here is some detail on step 6. Step 6 is not mentioned in most generic usability testing processes, but I want to stress upon it since it is plays a good role in optimizing the usability test process.
After you report the usability test findings and recommendations, stakeholders will agree to incorporate a certain number of recommendations. After the period for incorporating usability test recommendations has passed, you should hold a checkpoint meeting for the following purpose:
To see how many of those suggestions agreed upon have actually been incorporated. There is no point of conducting usability test after test if recommendations (that everyone agrees will improve the usability of the product tested) are not incorporated. You don’t want to keep conducting usability tests where you come out with recommendations, stakeholders agree on incorporating some, and then everybody forgets about it. And in the next test, you come out with many of them same old ones— this is simply not a very optimal way of doing things. This checkpoint thus helps you mitigate what I think is a concern worth addressing.
Using data, conclude whether those suggestions did or did not improved the usability of your product (or the portion/ section you tested upon), recommendation by recommendation. In case they did, you may want to find out if there is any further scope of improvement. And in case they did not, you may want to understand what wrong assumptions were made while giving particular recommendations and learn from them so you can avoid them in similar cases in the future.
Out of the near 50 posts that were made at Cone Trees in 2009, here is a compilation of what was most popular with you, dear readers. You will also find my list of suggested readings for each section (except for the articles section, where there were only three posts I made in the year).
I am pleased to let you know that my tutorial proposal for India HCI 2010 has been accepted. I will be presenting a slide based interactive lecture/ tutorial on ‘Tips for Effective Usability Testing in India’ in the morning on 21 March, Sunday at the India HCI 2010 conference and would like to invite you to attend it.
Who should attend: Usability engineers and user experience practitioners who conduct usability testing of all experience levels, though this will be especially beneficial for those who work in a organization with an nascent usability engineering. or user research team or interested in creating one.
Here is a detailed description of the tutorial at the conference website. Details about the tutorial are also given below.
India HCI 2010- tutorial 16: Tips for Effective Usability Testing in India
Duration: Half day Schedule: Sunday, 21st March 2010, Morning Fee: Rs. 3,000 Participants: 10-25
‘Tips for Effective Usability Testing in India’ is based upon my experience working in an agile setting in an Indian organization that is set in stage 3 of Nielsen’s Corporate Usability Maturity description. The organization I work in creates Alexa Top 200 consumer websites where I conduct field and lab-based and summative and formative usability tests on both prototypes and the released product.
India has a different cultural system as compared to the west. Its culture, values and language and ways of working and interfacing with people are different from those in the west. The difference is illustrated through Geert Hofstede’s cultural dimensions.
No book written on usability testing in India- All of the popular books on usability testing are written by western counterparts and understandably so, these are written in context of western users.
As an industry member, I would estimate that the vast majority of Indian organizations are between stages 1 to 4 of Nielsen’s Corporate Usability Maturity description.
At a stage where usability testing is not formally integrated into the product development lifecycle, technical capability is only half the contributing factor to successfully establishing the usability practice as an essential organ of the company. The ability to engage with stakeholders in a way that they continually offer support to the usability initiative is the other half contributing factor to maturing the usability practice within the organization. It is therefore necessary that technical knowledge has to be supplemented by the addressing of ‘soft’ issues that to tackle organization bottlenecks in order to successfully execute usability testing so that value may be derived from it that is recognizable by stakeholders.
Specific to usability testing in India, the tutorial in particular talks about various practical tips dealing with usability test moderation to avoid introduction of bias that may occur because of the PDI dimension (moderator-participant) of Geert Hofstede’s cultural dimensions.
Usability testing can only take place if concerned stakeholders realize its value and see it as an integral part of the SDLC. They ultimately hold the key to deciding how much of a role will usability testing play in the SDLC. Since Indian organizations have a different way of working from MNC’s and foreign firms, the other half of the tutorial will talk about how to work towards successfully demonstrating the value of usability testing into Indian organizations (set in stages 2 to 4 or Nielsen’s Corporate Usability Maturity description). It will talk about what challenges may be faced, what mistakes should one avoid, about why business cases and generic deliverable templates don’t work, how to deal with time and budget constraints, and how to deal with attitudes and successfully connect with stakeholders.
Usability engineers and any user experience practitioners who conduct usability testing of all experience levels.
A short biography of the tutor
Abhay Rautela works as Senior Human Factors Engineer at a leading internet services company in Noida and is responsible for planning, execution and oversight of user research and usability evaluation across projects that mostly include Alexa Top 200 websites. He has conducted formative and summative usability evaluations on low (paper) to high fidelity prototypes and the actual product in all phases of the SDLC. He has also authored usability testing deliverable templates and guidelines and has defined an optimized usability testing process to streamline the usability testing process in his current organization, in addition to authoring other user research deliverable templates.
Abhay has a BA (hons) Multimedia Arts degree with specialization in usability and accessibility from Middlesex University, UK in which he was batch topper. He has around 5 years of experience working in different areas of user experience, most of it being focused on interaction design and usability evaluations and user research. He has conducted trainings in the past on accessibility, streamlining the usability testing process and card sorting at Sapient (a leading international IT consultancy) and InfoEdge (a leading Indian internet services company) in addition to presenting at Bar Camp on usability testing in India.
Abhay has also recently been requested to contribute a chapter for a book on user experience which includes other known contributors who have authored and co-authored UX books. Abhay runs a website on usability engineering that is featured in AllTop along with other authoritative websites on user experience. His articles, posts, UI prototyping libraries and website visual design have been published, featured, included, pointed and showcased in Usability News (BCSCHI), Wireframes magazine, Evolt, Axure prototyping application website, SlideShare front page, Business Week’s Business Exchange and WaSP Interact among other places (links here).
Update (Mar 28, 2010): I noticed today that they (finally, one and a half months later) fixed up the issue.
Setting focus on text field to increase usability
Having to tab through elements on the page (using the keyboard) in order to set focus upon the ‘username’ input field.
Or moving the mouse to position it over the user name text field and clicking upon it in order to begin entering account details.
This is because when scripts download, nothing else can be downloaded along with it in parallel (in contrast, multiple images could have come through at the same time). So that is why moving them to the bottom gives a chance for the rest of the page to load up faster.
The above two combined form the issue
Everything is fine and as intended. Focus is set on ‘username’ text field. The user can proceed to typing in credentials.
Beginning to type in the password
But won’t users notice their password appearing in the username text field? Most probably not until most of or the complete password has been revealed- novice to intermediate computer users will look at the keyboard while typing in the password. Expert users may not have to do so, but since there is also a possibility that expert users will choose complex passwords as compared to novice users, it is probable that they will look at the keyboard too while they type in the password too.
Already typing in password
Severity of the issue
This could be labeled as a usability issue medium to high error severity since the issue translates to a security concern.
Having the password reveal itself without the wishes of the user is bad usability because the application is not behaving as the user expects it to. When a user enters data in a text box, the user expects the data being filled to appear in the text box- either masked or as is depending on whether it is a password text field or not. What the user does not expect is to see the focus of the text box change to another and their password get revealed.
Of equally serious concern is the consequence of the issue- the user’s password is partially or completely revealed, without their intentions of the user wanting to do so. This password may be observed by a passerby who the user does or does not notice, who may then go on to compromise the account.
This issue is certainly something Twitter should fix immediately considering low level of effort (LOE) required to plug it up. There are two solutions to the issue, both very simple both with their pros and cons.
By shifting the code and placing it above the ‘username’ field of the login form, it is guaranteed that the script will load before the form loads. And thus, the focus will always be set on the ‘username’ text field.
Pro: Focus will always set on ‘username’ field before the user can attempt to do so Con: Page loading speed may however be compromised.
The solution is to modify the code logic and keep it at the position it is currently at- so page loading speed is uncompromised and the issue is not caused either.
Currently, the script simply sets focus on the username text field when the script loads. The script may be modified to set up a condition where the script first checks if the focus is already set on either the ‘username’ or ‘password’ text field of the login form. If so, we do nothing since we can assume that the user is busy entering account details. But if the focus is not set upon either of the fields, then we can, as the script, earlier did, set focus upon the ‘username’ text field.
The advantage here is that we do not compromise page loading speed. We also ensure that the user’s password does not accidentally get revealed. What we don’t ensure is the fact that the user may set focus manually upon the ‘username’ text field before the script does so.
Pro: Page loading speed remains uncompromised and the unintended consequence of password revelation can never occur. Con: The goal of the ‘text field focus’ solution which was to always set focus on ‘username’ before user can attempt to do so is not met.
Here’s hoping to see Twitter patch this up as soon as possible. What are your thoughts?
Interaction Design, Security & Usability
Balsamiq Mockups is an reasonably priced application for creating wireframes that is easy to learn and use suitable for smaller projects. Creating interactive prototypes out of Balsamiq wireframes is now possible with the release of another application called Napkee. This review talks talks about:
Balsamiq Mockup specifications
Balsamiq’s distinct visual character and how it work both in favor and against Balsamiq being adopted by users
Pros and cons of the application
A conclusion with a recommendation on who should use and what to use Balsamiq Mockups for
This review is based upon the latest Balsamiq Mockups available at the moment- version 1.6.25. Line-throughs (like this) indicate notes about the earlier version.
Balsamiq Website:Balsamiq Mockups How much does it cost? $ 79 Number of controls in UI library:66 73 Download user contributed Balsamiq UI components:Mockups To Go Application: Available as an installable. A web application is in the works. Also available as a plugin for Confluence, JIRA, XWiki & FogBugz. Platforms: An Adobe Air application, hence runs on currently Windows, Macintosh and Linux. Balsamiq Mockups will be cross platform once the web application version is out.
Lets first talk about Balsamiq’s distinctive hand drawn style that makes it look like a scanned paper prototype. What can be seen as Balsamiq’s defining characteristic that differentiates it from other wireframe and prototyping applications- the unconventional hand drawn style and the character of the application, works both as an advantage and disadvantage for it.
1. Unconventional style as an advantage
1.1 Balsamiq- The Visceral aspect
What strikes many immediately about Balsamiq Mockups is its (well implemented) sketchy hand drawn styling and its cheery character. It is the visceral aspect where Balsamiq Mockups scores, allowing it to make a good quick first impression with many a user, who do not mind trying it out with a positive mind or spreading the word on it. It is a popular application talked about and recommended in the interaction design community, despite (as I discuss ahead) the fact that it does not possess (a deliberate decision I would think) the features that would make it an efficient tool to use for the more seasoned interaction designer or information architect.
1.2 Discussion stays at blueprint level without detracting to styling of elements
A wireframe is used to communicate the basic structure (layout and interactions, flow, not content) and working of a product before heading on (optionally but ideally) to higher fidelity prototypes, visual design and subsequently to the development of the product itself. The wireframe is discussed with various stakeholders and constantly refined till it reaches a stable state where the basic structure can be frozen and the team can move ahead to a lower level of detail.
This process can be time consuming and while the scope of discussion of the wireframe should be limited to what wireframes are designed to communicate- the basic structure, in reality, this is not the case. Almost all wireframe and prototyping applications allow for the possibility of moving the wireframe from a basic structural indicator towards a graphically stylized mockup (whether or not it is intended to indicate the visual design of the product). As a result, it is not uncommon to find that time and again stakeholders stray from discussion on basic structure and comment about graphic design which the wireframe is concerned with at this stage.
This is where Balsamiq scores again. Creating a wireframe to move beyond basic structural indication in Balsamiq is practically out of scope (unless you want to load up a hundred images). This ensures that the wireframe is taken and discussed as a wireframe, and there is no possibility of critique on look and feel. In Balsamiq, the only style here is the hand drawn style and there is literally no possibility of stakeholders confusing it for the actual design of the product.
2. Unconventional style as a disadvantage
In his session for MIX ’09, Dan Roam, (author of the book- The back of the Napkin) says “I do not know the cognitive reasons behind this, but I have never seen this not be true. The more human your picture, the more human will be the response”.
While this may be the case, enjoying the benefit of encouraged participation in wireframe discussions can occur only once the application is adopted by the user. Prior to this, a decision has to be made on whether to adopt the application or not, and in Balsamiq’s case, just as the visceral aspect works in its favor, the same sketchy rendering and cheery character could lead to Balsamiq being rejected by users.
In a consultancy, one may consider whether all clients would prefer being presenting with wireframes rendered in a sketchy hand drawn style in comparison to the standard lines and boxes that they are used to seeing. Based upon the unconventionally light natured visual character of the application, a client may view the consultancy as not being as professional or capable as they otherwise took it to be.
Similarly, for internal use in a product based company, especially those at or below stage four of Nielsen’s Corporate Usability Maturity model, where a considerably stable usability group is yet to emerge, usability practitioners will want the company to take usability as seriously as can be taken. In such a scenario, using a tool to create wireframes (in a hand drawn style using a presentation feature with a big cartoon like pointer) that will be discussed by stakeholders beyond the user experience department brings the concern of other departments not taking the usability group seriously enough.
Since the problem is with perception here, you should find it helpful to convince them by letting them know that a giant like Microsoft also chooses to use a similar hand drawn sketchy style in SketchFlow which is a as part of their Expression Blend product.
Balsamiq Mockups- Pros and Cons
While there are many other points that I can add to both lists, these are the ones that I feel are at the major ones.
Easy to use and a low learning curve
Balsamiq has been kept fairly simple and has a low learning curve and it is easy to get considerably productive right away.
It’s widget library
Balsamiq Mockups provides a fairly well stocked UI control library that will let you wireframe with ease. You will find iPhone controls present as well.
Community shared controls
Mockups To Go is a user-contributed collection of ready-to-use UI components and design patterns built using Balsamiq Mockups. This is handy in helping you speed up work since there is always a possibility of finding a part or whole of the wireframe you need to build already available for you to download and customize.
At $ 79, the price is good for everybody, there is nothing more to say.
Responsive customer support
While I have not required required any customer support or requested for any new features, customer service is an aspect that Balsamiq is known to perform well in. I have heard users rave about the fact that Balsamiq is extremely responsive to its users, always hearing what they want and responding to their needs and issues.
‘Quick add’ is useful
Quick add is a useful feature that lets you find the widget by typing in its name instead of having to go through the various categories of controls that exist. Of course, the labels given to controls may differ from the ones you use and this may limit its effectiveness but this continually reduces with time spent on the application
This is useful when presenting the wireframe to stakeholders, especially with the newly introduced ability to toggle annotations in presentation mode.
Interactive Prototypes through Balsamiq
This is in the works and yet to be released. With the release of the third party tool called Napkee, users will be able to use Balsamiq to create interactive prototypes.
Absence of the ability to Zoom and Pan, create custom controls, no concept of masters or backgrounds and multiple pages
Besides other features required by more experienced interaction designers and information architects to execute and manage their their work both quickly and efficiently, the absence of these features slows work down and makes it unideal for large-sized projects.
Memory usage over time shoots up
In all fairness, this is an issue Adobe needs to address in the Air Application and there is nothing Balsamiq can really do about this.
Notepad Background image stretch
The background image vertically stretches if you increase the height of the mockup instead of simply vertically tiling a seamless pattern to make the notebook background. Adding a seamless tile vertically would have made much more sense. Replaced by a neat and clean grid now.
Conclusion- Who should use it, what to use it for and when to use it
Balsamiq Mockups is a reasonably priced, easy to learn and use wireframing tool that comes with limited features. Based upon these simple facts, I wrap up saying:
Since Balsamiq Mockups application has been kept simple and is extremely easy to learn and use, I would recommend it for use in startups or any organization where there is a single or a few interaction designers who are relatively new to wireframing but are required to get productive right away. I would also suggest Balsamiq Mockups to be used by interaction designers of higher expertise levels give it a hand for smaller projects and personal projects and see whether it fits their needs or not.
For the same reason as above, I would recommend Balsamiq Mockups to all those who are not interaction designers and information architects- for use by the technical team to brainstorm UI in organizations or smaller projects that do not have the luxury of having an interaction designer or team on board.
I would not recommend it for large-sized projects where wireframe creation speed and management is crucial, when you are creating a large number of wireframes for a project and linking them together carefully so every one of them stays current through minimum effort when you are required to update common components.
I think it would be interesting (and this I will try as I plan and execute usability tests every month of the year) to use Balsamiq Mockups to quickly recreate paper prototypes in Balsamiq Mockups and print them out for testing instead of the paper prototype itself, for a bit of neatness and order.
Hand drawn style that makes it look like a trace of a paper prototype may or may not work for your organization or client. So if you decide to use it, make sure your stakeholders- whether internal or external are comfortable with a sketchy rendering instead of the conventional lines and boxes.
The issue with HP laptops that have a touch pad with a scroll zone contained it (as shown in image A) is that they do not provide a tactile cue for the user to help interpret what section of the touch pad the finger is positioned at. In the absence of a tactile cue, it is difficult for the user to determine whether the finger is on touch pad or the scroll zone without looking at it, resulting in the accidental scrolling on the screen when actually the user simply wants to move the cursor. The issue and multiple solutions are discussed ahead.
The issue with HP laptop touchpads with scoll zones- Absence of a tactile cue
To be more precise, the issue described in this post refers to HP laptops and all other laptops that have touch pads with ‘scroll zones’ similar to the image (of the HP 6510B model) above.
In the above illustration of the touch pad, you can see that the top view provides the user a visual cue to differentiate the mouse area and scroll zone. The side view however, illustrates the absence of relief to translate the visual cue to a tactile cue.
The users will receive the same consistent tactile feedback whether the finger is on the mouse area or the scroll zone. It is this absence of a tactile cue that reduces chances of error free operation of the touch pad without the aid of visual feedback (the user looking at the touch pad).
While the user can estimate the position of their finger in the touch pad’s horizontal space by either orienting through visual feedback or by tactile feedback alone (by feeling the edges of the sunken touch pad to get an idea of the width of the entire touch pad), relying upon the user to do so correctly in all situations is a design compromise. Especially when the user is working in a hurry or busy, there is not much attention the user can allocate to such a task when concentrating on accomplishing an important goal. Error in touch pad operation at this time will understandably be more frustrating for the user.
Error criticality in this case might not be significant but frequency of the issue definitely is. Considering that Image A is a picture of an HP business laptop (6510B), and the fact that business laptops are all about increasing productivity, this should be a valid case for HP to work upon the stated touch pad usability issue.
Solution- Introduction of a tactile cue in the touch pad
A logical solution to the issue is to providing a tactile cue will allow the user to operate the touch pad in an error free manner with the tactile cue acting as an effective indicator of the different sections contained in the touch pad. This will allow the user to only rely on their finger to determine accurately where the finger is on the touch pad without having to resort to utilizing to their sense of sight which should be focussed towards the monitor.
What would be an effective tactile cue? The solutions described below describe two different concepts to building a tactile cue in with the common goal of helping the user effectively determine which section is the finger placed upon. through tactile feedback alone.
1. Using a tactile cue to notifying the user of zone boundaries
The above illustration elevated the surface along a line to create a ridge to serve as a demarcation. This ridge acts as an effective tactile cue for the user to interpret whether the finger is upon the mouse area or scroll zone.
2. Tactile differentiation
Tactile patterns can be used to provide differentiated tactile feedback for the different touch pad sections.
2.1 Tactile differentiation through utilization of a horizontal line tactile pattern
This solution uses the visual marking (see Image A) to form a tactile cue. The visual cue (horizontal lines) is converted to a tactile cue, that is- the horizontal lines are converted to low relief. This might be done by using an ink that creates a low relief when printing the horizontal lines. It is important that the relief be extremely low and just enough for the user to sense differentiation in texture from the smooth mouse area.
2.2 Tactile differentiation through application of a solid-rough tactile pattern
A solid-rough tactile pattern or otherwise may be used to create extremely low relief on the existing touch pad surface that will allow the user to differentiate the scroll zone from the mouse area’s smooth surface.
What are your thoughts on such touch pads without tactile cues? Have you used a laptop with such a touch pad? Was it easy to use, tough or frustrating? I would like to know.
If you’ve been looking for them, here they are: Two Axure widgets (clear text on focus of text field & clear text on focus of text area) for the Input Prompt design pattern are available for download in Axure project file (.rp) and widget library (.rplib) format.
The following two Axure widgets are for the Input Prompt user interface pattern:
Clear text value on focus of Input Field
Clear text value on focus of Text Area
What is the Input Prompt UI pattern?
The Input Prompt UI pattern refers to using the input field text for communicating to the user what the label or hint text otherwise would. On focus of the input field (with the exception of a dropdown list), the text contained in the input field disappears.
When to use
The Input Prompt pattern is used to address the problem of space constraints where:
The label for an input field can not be provided due to space limitations.
The label for an input field is provided but hint text required to help with user entering information can not be provided for the input field due to space limitations.
Makes use of input field space to communicate label or hint text.
Higher probability of text being noticed by the user in comparison to label or hint text since it is placed within the input field itself rather than around it.
Text disappears upon focusing on the input field (solution- don’t clear text upon focus of input field). This isn’t a substantial issue when used in a text field since the text that can be used is only a few words. It is a considerable issue if the text consists of a few lines or more to be used as an example of what is to be filled into a text area. In this case, making hint text available is a good idea.
Demo the Clear Input Field Value on Focus Axure widgets
All UI bugs cannot be captured through images. Some UI issues are not only state based, but time based as well- where the bug might occur in transition of states or the time taken to change states (transitions and states are explained at the end for the unaware).
For example, you might want to illustrate the usability problem of a pull-down menu which has a zero time delay, thus making the selection of items down and up the hierarchy difficult for the user as the slightest overshooting of the target results in disappearance of the desired item.
In this case, it is not possible for an image to describe the issue. For such scenarios, video is effective method of capturing the issue, and there is a tool that makes it as easy and fast to execute as is capturing a screenshot.