A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Getting team members to attend user feedback sessions, usability being very important (Part 1)..

In the previous post (Needing user feedback?), I was talking about a case where there needs to be a balance between having user sessions to get feedback about new proposed plans, vs. the case whereby a lot of new stuff is such that users may not have thought of and where getting feedback may not be the right approach.
This post however takes the classical case whereby the team is looking at some changes in some workflow in the product and wants to get these validated by a cross section of users. Consider whereby the team has got a lot of feedback about some of the features in a product release and has decided to try and make some changes in the feature set and the workflows. There is a certain conception when such changes need to happen, and the product manager and the experience designer would have figured out how to modify the workflows in order to incorporate the user feedback. However, such changes can be tricky to get right. Even earlier, when the workflow was designed, it would have been done to optimize user workflows, and the fact that users had more feedback means that getting the workflow right is not as easy as it seems.
The problem is that when teams start thinking about a new design and get involved in the discussions, there is a strong tendency to get so involved that you start to feel that whatever you are designing is the right way of doing things. It needs interaction with the users to ensure that the team members keep an open mind and keep on thinking about whether the design will work for them or not. You would be surprised to discover some of the outputs from usability testing, whereby users tend to spend a lot of time on workflows that you would have thought were very intuitive, and also seen other areas whereby the users found a particular feature so interesting, but on which the team had not really given a second thought.
The problems comes in terms of budgets, whereby when there is a need for usability testing, it is typically the product managers and the experience designers who get to spend time in terms of usability, and who get to interact with the users. So they tend to be more understanding of the areas where the users may get stuck, but the average team member does not really have this kind of understanding. For this purpose, what is required is to ensure that a cross section of team members is exposed to this usability testing, and spend as much time as possible with the users on whom the usability testing is being carried out. As much as possible, there is a need to make budgetary allocations for the same, and always have some of the team members being able to observe the usability testing. Doing so ensures that team members get a lot of experience with how users actually think (in many cases, I could see that the team members were getting a rude shock in terms of how they could see the users interacting with the software application, and this in turn caused some changes to the way in which team members thought.

A Common Sense Approach to Web Usability The FlowingData Guide to Design, Visualization, and Statistics Designing with the Mind in Mind

Will continue this in Part 2 (link)

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>