Maria Rauschenberger und Heike Sinning haben sich in ihrem Beitrag damit beschäftigt, wie Styleguides in der Softwareentwicklung nutzbringender eingesetzt werden können. Als Hauptziele für den Einsatz von Styleguides sehen sie: Konsistenz, Erhöhung der Qualität, Vermeidung von Fehlern, Verkürzung von Abstimmungen und Kosteneinsparung.
Aus ihrer eigenen Erfahrung berichten sie, dass Styleguides nicht verwendet werden, weil sie von Projektbeteiligten als “nicht aktuell” eingestuft werden. Sie erfüllen die genannten Ziele nur bedingt. Außerdem kommt es auf Entwicklungsseite zu Umsetzungsproblemen, da die Gestaltungsregeln nicht immer Allgemeingültig sind. Die Ablage und Organisation der Styleguide-Inhalte kann zu weiteren Umsetzungsproblemen führen. Je größer die Entwicklungsteams werden, umso höher wird der Kommunikationsaufwand.
Ihre Idee ist, Styleguides durch eine Implementierung der dokumentieren Designregeln direkt in die Entwicklungsumgebung zu ersetzen.
Der Ansatz klingt zwar interessant, löst aber aus meiner Sicht die Probleme von Styleguides nicht. Wenn Styleguide nämlich eine hohe Akzeptanz bekommen – wie das bei DATEV der Fall ist – läuft man nämlich in das nächste Problem. Werden Designregeln zu strikt befolgt, schränkt das die Innovationsfähigkeit von Entwicklungsteams sehr ein. Außerdem kann man dann beobachten, dass die Fehler beim Einsatz von Designregeln zunehmen. Dies liegt teilweise darin begründet, dass Designregeln für Anwendungssituationen verwendet werden, für die sie nicht geeignet sind. Styleguides vermitteln nämlich den Eindruck, dass man sich dadurch weniger mit der Konzeption des UIs beschäftigen muss.
Sinnvoller ist aus meiner Sicht zwingende Designregeln z.B. über UI Patterns und Styles, technisch umzusetzen und organisatorische Gestaltungsregeln über wenige Designprinzipien in den Entwicklungsprozess zu integrieren. Der Styleguide dient dann nur noch der Orientierung und Inspiration.
