Saturday, October 29, 2005
the two cultures of usability
From time to time I have seen passing references to the existence of two tribes in usability: those who make interfaces, and those who critique them. It is a strange cohabitation of roles: ultimately striving toward the same ideal, but involving different skill sets, different temperaments, and an uneasy combination of synergy and contradiction.
One's understanding of usability is often colored by which tribe one is most involved with. In the largest companies, their may be dedicated usability testers, who are separate from UI designers and IAs. Usability consultancies often dominated by non-designers (testers and other user researchers), while agencies tend to hire designers and IAs. Many of us get involved in all aspects, researching, designing, testing, though we find ourselves doing some things more often than others.
In my experience, it is rare for someone to be equally talented at user research and UI design. Still, there are good reasons to have experience with both roles, though it can be problematic to do both roles on the same project. The tester who also has experience with design can overcome some of the limitations of the testing mentality. Testers tend to focus on what's wrong and not working, and offer didactic advice frequently containing the word "should." UI designers can get caught up in the rigidities of style guides and uniformity, which can get abstracted from the realities of what users want and need. A tester who has experience with UI design is more able to offer useful suggestions to designers on how to fix a usability problem that has emerged during testing. A UI designer with testing experience might be more sensitive to contextual peculiarities.
While the two cultures use complementary approaches, their basic temperaments are different enough to limit a fluid change in perspective. UI designers are focused on constructing an interface, while testers are focused on de-constructing it. Testers are more focused on what is not possible, rather than what is possible. They often are reluctant to offer any "solution" at all to a problem, out of fear their solution will test poorly. Some usability engineers shun offering any design advice at all.
UI designers can get invested in their solution, and can lack emotional and mental detachment to let go of it. It is no fun seeing a technical UI solution that has been developed over weeks get dinged by users. Unlike their more artistic web designer brethren, UI designers are presumed to be experts utilizing empirically developed principles and good practice. Clients are very happy to believe that a solid body of best practice exists that can be drawn upon to design a flawless UI from the start. Experts can be reluctant to take risks, and play with options, when prior experiences suggest a possibility of user hesitation, or implementation problems.
If one attempts to do design and testing on the same project, the potential for inner conflict escalates. Extraordinary self-discipline is needed to remain open to user suggestions in the UI design phase, despite one's fears that the design is getting too complex and won't test well. In testing, one needs to push one's elegant solution to the breaking point to assure that it isn't just you who is in love with the concept. Testing one's own UIs means turning off any hint of enthusiasm, to avoid getting a "want to please" reaction from users.
Playing both roles involves maintaining enthusiasm for nascent ideas, while ditching ones that don't work without a loss of pride when the client seems confused why you were so keen on one approach only to drop it cold. To bridge these paradoxical demands, one needs to be able and willing to criticize one's own ideas, to undermine one's own self-confidence that you have figured it out.
One's understanding of usability is often colored by which tribe one is most involved with. In the largest companies, their may be dedicated usability testers, who are separate from UI designers and IAs. Usability consultancies often dominated by non-designers (testers and other user researchers), while agencies tend to hire designers and IAs. Many of us get involved in all aspects, researching, designing, testing, though we find ourselves doing some things more often than others.
In my experience, it is rare for someone to be equally talented at user research and UI design. Still, there are good reasons to have experience with both roles, though it can be problematic to do both roles on the same project. The tester who also has experience with design can overcome some of the limitations of the testing mentality. Testers tend to focus on what's wrong and not working, and offer didactic advice frequently containing the word "should." UI designers can get caught up in the rigidities of style guides and uniformity, which can get abstracted from the realities of what users want and need. A tester who has experience with UI design is more able to offer useful suggestions to designers on how to fix a usability problem that has emerged during testing. A UI designer with testing experience might be more sensitive to contextual peculiarities.
While the two cultures use complementary approaches, their basic temperaments are different enough to limit a fluid change in perspective. UI designers are focused on constructing an interface, while testers are focused on de-constructing it. Testers are more focused on what is not possible, rather than what is possible. They often are reluctant to offer any "solution" at all to a problem, out of fear their solution will test poorly. Some usability engineers shun offering any design advice at all.
UI designers can get invested in their solution, and can lack emotional and mental detachment to let go of it. It is no fun seeing a technical UI solution that has been developed over weeks get dinged by users. Unlike their more artistic web designer brethren, UI designers are presumed to be experts utilizing empirically developed principles and good practice. Clients are very happy to believe that a solid body of best practice exists that can be drawn upon to design a flawless UI from the start. Experts can be reluctant to take risks, and play with options, when prior experiences suggest a possibility of user hesitation, or implementation problems.
If one attempts to do design and testing on the same project, the potential for inner conflict escalates. Extraordinary self-discipline is needed to remain open to user suggestions in the UI design phase, despite one's fears that the design is getting too complex and won't test well. In testing, one needs to push one's elegant solution to the breaking point to assure that it isn't just you who is in love with the concept. Testing one's own UIs means turning off any hint of enthusiasm, to avoid getting a "want to please" reaction from users.
Playing both roles involves maintaining enthusiasm for nascent ideas, while ditching ones that don't work without a loss of pride when the client seems confused why you were so keen on one approach only to drop it cold. To bridge these paradoxical demands, one needs to be able and willing to criticize one's own ideas, to undermine one's own self-confidence that you have figured it out.
Link to this article. posted by Michael Andrews @ 4:01 PM 
