User Assistance Walkthroughs

Mike Huges berichtet in seinem lesenwerten Artikel auf über seine Erfahrungen mit Walkthroughs bei Hilfesystemen.

A walkthrough is a review of a user interface within a context in which a user might experience it.

Er sieht die Vorteile von Walkthroughs wie folgt:

* let designers share the rationale for design decisions they make
* identify common design approaches—across designers and even across design teams
* enable the development of consistent methods
* subject design approaches to collective scrutiny, honing them into best practices
* get organizational buy-in for those best practices

Die Unterschiede zwischen einem Walkthrough bei Bedienoberflächen und bei Hilfesystemen sieht Mike Huges darin:

A major difference I have found between UX walkthroughs and user assistance walkthroughs—specifically those for reviewing Help content—is that the team is less diverse for Help walkthroughs. Help walkthroughs generally include information architects, information developers, and editors. One reason for this less diverse set of participants is that such walkthroughs typically get down into the weeds of technical writing at a level that would induce comas in stakeholders. For example, there might be a ten-minute discussion over “clicking” versus “if you click” versus “when you click.” Coders avoid such discussions for the same reason writers avoid discussions about Java classes and methods. Each is happy that smart people in another specialty are worrying about such things and content to have them do so.
User assistance walkthroughs achieve diversity of viewpoint by having multiple writers participate—sometimes writers from different product teams. Such cross-team participation offers the added benefit of enabling writers to shape consistent approaches across all user assistance products and synthesize best practices.
Another difference between UX and user assistance walkthroughs is user assistance is driven less by formal requirements and use cases and, instead, more by the information requirements a given user interface presents. For example, the Help for a well-designed form might be entirely different from the Help for a less elegant design—even though the designers of both forms created them in response to the same set of requirements and use cases.

Hilfreich sind auch die Tipps und Empfehlungen, die er für die Durchführung eines User Assistance Walkthrough gibt.

Siehe auch:

User Assistance Walkthroughs: Helping Best Practices Emerge

War dieser Artikel hilfreich für Dich?


Scroll to Top