Problems while interfacing with development or management organization:
Working with a Team 

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

Results

Discussion

Problems working development/management

While some resistance (26 instances) and unawareness of the usability process or its benefits (22 instances) continued during the phase of working with the development team in usability activities.

Time Constraints, Testing process challenges, "no problems", developer interference during the actual test, or the lack of developer participation in usability activities also played an important role in creating challenges while working with the development team.

Resistance Comments:

• "Initially, producers and designers were concerned that I was going to radically upset their work by imposing really stringent usability rules."
• "At times, the quality of the work for various activities can suffer since many of the user-centered design activities/skills require full participation of the development staff yet there experience level (and comfort level) is quite low."
• "Dev team's reluctance to conduct feasibility studies for ideas for prototypes until I have clearly defined what it is I want which is often seen as a waste of time to examine several possibilities for prototypes - why can't you just pick one and tell me?"
• "Designers have a different sense of 'functionality' and usability. They disregard some things because they are 'ugly' (that is, it does not conform to their taste."
• "Their tendency to think their opinion is the driving factor in decision making."
• "The persistent feeling among developers that if it compiles, it's good. Therefore, it's hard to get them to redevelop for improved usability."
• "Credibility. Some (fortunately, not all) developers still have the attitude "That's just your personal opinion." vs. understanding that it's a professional opinion based on years of experience and knowledge of common, industry-accepted 'best practices'.  They don't recognize these problems, so they don't think they will bother anyone else either. They cast themselves in the role of a typical user."
• "People disagree with findings and want a retest or ignore results."
•  "Not willing to do the utmost to improve the experience (not wanting to make drastic changes that are often needed; would rather do piece-meal patchwork)."
• "I've had issues with suggestions or other IA deliverables being selectively implemented by developers/designers."
• "Key people too busy to be involved."
• "During a UI review, developers will often say "the control cannot handle that behavior"" (even when we know it can)."
• "1 developer out of 10 complained that we remove ""creativity"" from him."
• "Some developers can be very defensive and ""hide"" behind their knowledge to avoid discussion. I mean they usually end up a conversation saying "you don't understand.""
• "Some seems to have a high opinion of themselves and take whatever we say as a criticism of their work These people represent 20% of the developers we work with."
• "Tendency for development teams to focus on constraints of the timeline and the technology."
• "Sometimes development teams accept results of usability activities, sometimes they do not."
• "Developers bruised egos....Developers becoming defensive...Developers concentrating on what they want to hear and one user, rather than looking the aggregated data."
• "I know how to fix that"; no understanding of workflow and customer use lifecycles."
• "All features available all the time; tons of little understood, little used, little value features."
• "Unclear roles, unclear expectations, think participatory design takes too long."
• "Many usability changes are not "glamorous.""
• "Having them not make us a last minute option."
• "They feel it takes away from their development time, they have better things to do."
• "Takes too long; costs too much."
• "They feel it takes away from their development time - they have better things to do."

Usability Unawareness Comments:

• "They are reluctant to adhere to formal guidelines, because they don't see the value or think they're important. They often don't pay enough attention to detail, and when I try and hold them to it, they think I'm just ultra-picky. A prime example of this, at the most basic level, is even just getting them to use fonts consistently throughout an application (even when I provide a style sheet)."
• "Don't always understand time involved for iterative testing (so we're roped in often last-minute)."
• "Not fully understanding how usability fits into the design process."
• "I've had difficulty explaining the importance of recommendations due to the difficulty of providing concrete reasoning behind them - so much of being a ""usability specialist"" is having read the latest materials and keeping ongoing dialogue with others in the field - many of the ideas or possible ""rules"" that I go by are not easily quantifiable."
• "During use case and vision scope development, developers often feel that they will not benefit from the process.
• "Basic usability knowledge does not exist. It takes 50% of project cycle time before developers understand concepts. Sometimes, they never see the value of usability although they generally understand what is expected of them."
• "Pushback on how the study is being conducted (for example, one client was insistent upon training participants before each session)."
• "Developers tend to trust our quantitative research more readily. It is more of a challenge to get them to accept the qualitative work, especially if they didn't view the sessions first-hand."
• "Developers do not have clear objectives up front regarding what they want out of the usability activity."
• "They don't plan for usability testing activities, wait too long to start them, then don't have time to update the interface based on results."
• "Willingness to test prototypes or before the design is completed. Too many want to wait until it is finished."

Time Constraints Comments:

• "If there is time for the testing, it's usually at the end of the phase, so that it is hard to implement changes."
• "Tight deadlines cutting into implementation of good UI solutions and low prioritization of usability issues."
• Time. They don't have the time to attend a usability session."
• "Everyone except usability specialist works at home 3-5 days a week."
• " Usually there is no time built in for usability testing. If there is time for the testing, it's usually at the end of the phase, so that it is hard to implement changes."
• "There's always limited time." 
• "Making deadlines is a challenge given the amount of resources available for research."

All Other Comments:

• "Developing an eye for subtle problems. The usability tester often will "figure out" a problem when the end users aren't that savvy."
• "Sometimes we do not have enough staff or resources to do what we would like."
• "Database and API limitations."
• "Lack of awareness and concentration resulting in development of unusable services after designs were communicated."
• "Different perspectives about what the users need."
• "Developers on the project feel they do know their users, we sometimes have to debunk closely felt beliefs."

"I Don't Have Any Problems" Comments:

• "I have not experienced any difficulties (as unusual as that may seem)."
• "None - development group is interested in our usability findings and will look to our group to incorporate our findings into the products."
• "I have a close, informal working relationship with the ui designers, software engineers, and tech writer to provide on-going consultation."
• "None. as we design, I am the user advocate."
• "If I am allowed to be part of the team on a given project, I have not really had problems with the development team."
• "Developers have generally been interested in the results of tests with users." 
• "Developers feel its an obligation to implement our recommendations."

Testing Process Challenge Comments:

• "Getting participant descriptions and tasks in a timely manner."
• "Definition of user tasks that are considered fair and realistic."
• "Getting participant descriptions and tasks in a timely manner. Note that we get 'drafts' of these from the product team, then create what we need for the usability evaluations based on the drafts."
• "Limiting the testing session to the right people. That is - keeping non-appropriate people in a test. Managers, directors, etc. Those who would not be using the system."
• "Trying to resolve issues during the activity (pre-maturely)."
• "Understanding the need to move quickly to create early prototypes for testing purposes."
• "Scheduling tests."
• "Getting timely feedback on planned activities, screeners and questionnaires."
• "Development teams do not always recruit users that match the profile of their intended user audience."
• "Preparation is usually rushed with scenarios being delivered at the last minute."
• "Developers do not have clear objectives up front regarding what they want out of the usability activity."
• "Another problem is getting developers to delay coding until we know the results of usability tests."
• "Sometimes developers are required to prepare the prototype and they object to doing that instead of coding the actual application."
• "Not getting prototypes ready in time for testing."

Developer Interferes/Ignores Test Comments:

• "We have found it is difficult for developers to be in the room when running user testing as they have a tendency to want to ""help"" the user through problem areas, rather than allowing them to fumble over design areas where usability issues lead to difficult interaction."
• "Sometimes there's too much talking in the observer room! People are designing solutions right there and then of course they miss interesting findings that are still coming."
• "Apart from continually needing to remind them not to help the users."
• "Sometimes developers do not attend at all or only attend one session."
• "Commitment to sit through a day or two of usability testing by key development staff or management."
• " Distraction, lack of attention." 
• "Some developers do not have the time to observe a test session." 
• "Development team often wants to show how something works when a customer is struggling. Team will often jump and talk about adding new functionality based on customer feedback, instead of focusing on current issue."

Original Question

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

Problems working with a development team during usability activities: