Problems while interfacing with development or management organization:
During Usability Activity Follow-up or Resolution 

Engaging With a Team | Working With a Team | During Follow-up | Home

Results

Discussion

Problems during usability activity follow-up or resolution

General resistance (24 instances) during follow-up to tests continued while implementation challenges (22 instances) and testing follow-up challenges appeared.   Time, financial, and resource constraints arose as obstacles to implementing usability recommendations.

Resistance Comments:

• "We don't want to change the UI now."
• "Pressure to undertake new development rather than do benefits measurement and follow up."
• "Inability or unwillingness to make changes."
• "If the developers can't watch every test, they sometimes see an outlier and get weird ideas that are hard to overcome."
• "Having usability issues be taken seriously or acknowledged."
• "People don't want to read the report."
• "People don't like what they hear."
• " People not understanding that there's always room for more testing and improvements."
• "Don't want to make changes to interface."
• "Convincing developers that major changes are really needed is still tough even though they may see the general need for a good usability."
• "Developers often disagree with the severity of usability defects."
• "They say that findings from usability activities are in functionality that 'most users will never see' or they will say that the defect is accounted for in a training class or help system somewhere."
• "Changing preconceived notions of what users will find valuable, even after usability testing has proven otherwise."
• "User groups sometimes take usability results and 'pick fights' with development teams."
• "The development team is under no obligation to act on my suggestions. They can decide to proceed down whatever path they prefer."
• "Project manager is very resistant, generally."
• "Most frequent reoccurring issue is "we really didn't need the information architect"."
• "We run into resistance if there are major changes that warrant another set of tests."
• "Often the developers have other priorities."
• "The will of marketing is greater than the will of the user."
• "They like to ignore the results of usability and pretend problems don't really exist or aren't critical."

Implementation Challenges Comments:

• "Clients often reject suggestions even in the face of multiple forms of data. Very frustrating."
• "Problems with integration of proposed solutions."
• "Product is shipped everybody moves on and the problems remain."
• "Project managers not including usability team members in detailed design and/or maintenance activities."
• "Things that get pushed to 'the next release' typically lose visibility quickly and can be lost."
• "There are always more serious code issues to contend with. Even when documented as a bug, they usually put it off to 'the next release'."
• "Only want to fix bugs or to add new features."
• "Documentation of whose decision to implement a feature found troublesome is essential."
• "Changing personal attachment to labels, layout, etc. that users find hard to use, but developers have begun working on."
• "Implementing changes is difficult once the project has been developed."
• "Lack of follow through on their part on taking the recommendations."
• "No clear indication of when or if changes are going to be made; instead, development teams say "we need to scope that" and then we never hear back from them."
• "Sometimes they agree to changes, but do not follow through."
• "Occasionally, there is the tendency to ignore certain recommendations due to the fact that it would require too much work to make things right, but carefully made and supported recommendations are often received favorably and implemented if at all possible I've found...it really helps when the developers observer test sessions directly."
• "Pushing off improvements to 'later' releases that never become 'now'."
• "Sometimes the suggested fixes are things that the developers are not willing to do. Other developers get side-tracked on large programming issues and never really get around to doing some of the smaller fixes." 
• "Disagreement on importance of changes - what are must-have's versus nice-to-have's."
• "If design doesn't work, change it, but don't bother testing new design."

Time Constraints Comments:

• "We don't have time to do that."
• "Timescales are very short due to this activity not being billable and past clients being very busy."
• "Convincing management this must be an iterative process - conflict between pushing on and stopping to measure effectiveness of what we have done."
• "The only issue is timing constraints."
• "Lack of time to implement recommended changes."
• "Schedule often constrains what can problems be fixed or how they can be fixed."
• " Feedback given supposedly 'too late' to make changes."
• "Resolutions not being implemented due to time constraints."
• "Time elements involved in the actual launching of a completed project.. Use and changes need to be done before actual launch of the programs."
• "Tight schedules create an adversarial atmosphere."
• "Problems with the time for follow-up activities. Perception that if you fix some of the problems (cutting the list according to the time available) then you'll have a usable product."
• "Implementing changes (cost, time) etc."
• "Can't afford the time it takes to correct all the mistakes."

Testing Follow-up Challenges Comments:

• "New errors are sometimes generated upon attempting to fix a problem. This could be a simple as an instruction rewrite that actually becomes muddier or as mundane as Dreamweaver munching our Cold Fusion scripting when we try to fix a simple problem."
• "The biggest problem is ensuring follow-up testing is done after the project's completed to ensure usability requirements have been met."
• "Usability defects are logged as bugs."
• "Since we are new to this field, we are still finding ways to tie usability into the development process. For example, for usability issue resolutions, I add them to the team's design 'bug' list."
• "If usability reports have low usability(!!) we found the recommendations are unlikely to be adopted. We have opted for mostly table format, with the problem resolution summary table receiving the most attention and use."
• "Biggest problem has been getting information back to the development team." 
• "Integrating usability reports with other software validation reports: usually, trying to scoop up their messy reports into an ordered set of answers to development objectives."
• "People wanting more than inferential statistics."
• "Finding a good way to track usability issues. Many need a design discussion so don't really fit in the bug database. Many are also trivial and would be assigned a low priority in the bug database but what makes them important sometimes is the number of trivial problems (too many makes one big problem for the customer!) and/or they are easy to fix."
• "Interpretation of usability results."
• "We currently have no ability to enforce compliance with usability suggestions. We must convince developers that our recommendations are the right thing to do, based on user feedback."

"I Don't Have Any Problems" Comments:

• "I have not experienced any difficulties (as unusual as that may seem)."
• "Once they've seen the results I find it fairly easy to get them to re-work. This is not really an area that concerns me - my job is to give them the opportunity and information they need to improve, not to push the improvement."
• "Again, usability bugs have full bug status in our defect tracking system, so they get followed up and resourced like any other defect."
• "It goes a lot better in this phase actually."
• "Usability testing can be powerful when observed by the dev team members."

All Other Comments:

• "Once our product is turned over, we rarely have opportunity for follow-up."
• "They believe users are stupid."
• "People thinking users are morons."
• "Unable to meet user expectations across the board."
• "Everyone except usability specialist works at home 3-5 days a week. "

Resource Constraints Comments:

• "Resource implications."
• "The only issue is resource constraints." 
• "Resources for fixing problems is always the biggest issue."

Financial Constraints Comments:

• "Deciding who is responsible for paying to fix a problem (us or the client) is often difficult." 
• "Resolutions not being implemented due to money constraints."
• "Implementing changes (cost, time) etc."

Original Question

(7) Describe any problems or resistance you encounter while interfacing with development or management in your organization. 

Problems during usability activity follow-up or resolution: