The casual and power users are another example of user types. The product experience sometimes leans in favor of one type over the other--design of a product that targets professionals might focus more on the experience that supports a lot of functionality, while the design of a product that targets casual users might lean towards the 80:20 rule that states that because 80 percent of users typically use only 20 percent of features, the design effort should be focused on making those 20 percent as easy to use as possible.

Testing both types of users makes it possible to validate that the 20 percent of functionality that the casual users needs the most is as close as possible to the most frequent functionality power user need. The smaller the gap, the wider set of users can be satisfied.

There are several challenges for testing with power users, or with users who are very familiar with the product in general. For example, when testing financial websites of apps, it is extremely important to make sure that the screens show accurate data--that figures which need to add up--add up correctly, that decimal points are placed correctly, and that the data overall makes sense--people who work with financial data are easily distracted by inaccuracies in prototypes, and as a result, their feedback may be overly negative.

Low-fidelity prototypes are less effective when tested with experts and power users. Such participants will easily grasp the overall direction of the design and understand the concepts behind it, but a lack of specific details makes the prototype too ambiguous for them to provide constructive, meaningful feedback about the design's nuts and bolts.

Such users can also be resistant to change, when presented with a concept that departs from what they are familiar with. It is often the case that real improvement to a product is dependent on replacing or eliminating existing procedures and workflows--either because new technology renders them obsolete, or because the way the business works is changing as well. Some of this information may not be known to the users who participate in the testing, and if they are having a hard time mapping the new flows to what they are comfortable with, they might resist, and risk implementation of the changes in the final product.