Grassroots Acceptance

Grassroots acceptance, a.k.a., the bottom-up approach or team member buy in, entails getting the people working on the actual products themselves (product team members, such as programmers, designers, developers, engineers, tech. staff, etc.) to support and believe in human factors.  The rationale is that this is where the "real" work is done, and as such, it is at this level that you can most effectively implement human factors methodology. Similarly, if the grassroots personnel do not support human factors, nothing will get implemented.  The more acceptance you get from the design team, the more likely you'll be involved earlier in the design process which in turn affects the opportunities you have to affect the design process, the likelihood your ideas will be implemented/listened to, in short, how effectively you'll affect the design of the product/system.

As with most things, acceptance is not an overnight event.  It does, however, seem to follow a life cycle of its own.

• Skepticism: Typically, team members are skeptical at first.  Human factors is new and its importance is doubted.
• Curiosity:  As team members become more educated and start seeing results, they become curious as to how they can utilize and benefit from human factors.
• Acceptance:  At this point, Human factors has proven itself and has come to be a full and equal member of the design process.

Ways to encourage grassroots acceptance:

The methods to garnering grassroots support can be categorized into two approaches.  The first involves techniques which enable team members to see and experience first hand the benefits of usability testing.  The second category discusses the interpersonal interactions between human factors people and team members - ways to interact which promote a good working relationship.

Involve team members in the testing process.

Seeing users struggle has a HUGE impact on a developer's belief that a product needs to be improved.  A typical scenario goes like this: when watching testing for the first time, a developer sees a user struggle and thinks, "these first users aren't too bright "; after a few more users struggle, the developer starts to think, "the software has some significant problems"; finally, as more users struggle, the developer decides, "the software is dumb." At this point, the once skeptical developer is now "gung ho" to implement fixes

Developers learn about usability by participating.  they begin to realize how usability problems are not always obvious and why usability testing is required to uncover them

How exactly do you involve developers in the usability process?

• Ehrlich, Butler, and Pernice from the Lotus group described 4 Specific Techniques they've used effectively to involve developers into the usability process.

• Produce hands-on prototypes.  Additionally, this gives a tangible thing with which to assess.

Interacting with developers

An equally important aspect of winning over grassroots personnel is the development of a mutual level of professional respect between yourself and other team members.  Because of the intrusive/new/unknown nature of human factors/usability, this relationship requires special attention.  The following are important issues to consider:

Provide quick turnaround on results

• You'll be initially perceived as a source of added work and delay to existing processes. Do everything in your power to disprove this misperception.

Provide tangible deliverables

• Give team members the opportunity to "see" your work, e.g., hands-on prototypes. This helps to alleviate the perception that the field is mostly "soft" with no tangible results.
• Take responsibility for a specific and visible aspect of the product.

Don't be the "police"

• Don't only identify problems, also provide design alternatives, make it clear that your not "judging" the work, but your working with them to improve the product, be open to compromise and show that you understand the bigger picture (i.e., you realize there are constraints that others also have to deal with).
• People don't appreciate being constantly told that they're wrong.  If you gain the reputation of a user interface or design "cop", people will actively avoid you.

Understand that developers are "people" and treat them accordingly

• Offer to take tasks off their plates - these don't have to be human factors or usability related.
• Acknowledge their expertise - it's interesting that this is what we always want, yet it's very easy to forget that it goes both ways.
• Don't be afraid to ask for help.  When someone helps you, that person feels more powerful, gains recognition, and a sense of task ownership.
• Acknowledge successes, positive aspects, in fact, do it first
• Give them food - little things like having M&M's, or candy can become a catalyst for conversation, familiarity, regular visits, etc.

• Make "friends" - you're more likely to listen to and respect, people you like. But don't just roll over, if you're compromising, make sure they understand that so they return the favour
• Get in the trenches, become familiar with other issues that are critical, understand the hurdles, problems faced by developer and the effect of your recommendation on them

Return to the list of Qualities Associated with Success

Return Home