Chat with us, powered by LiveChat
zurück zum blog

Warum Web-Frameworks für designer wichtig sind


Last updated: 28.11.18
Warum Web-Frameworks für designer wichtig sind

Öffne die Silos. Finde heraus, was Deine Kollegen auf der anderen Seite der Wand für eine bessere Teamarbeit und weniger Kopfschmerzen tun.

Maslow machte einmal die Beobachtung: "Ich glaube, es ist verlockend, wenn das einzige Werkzeug, das man hat, ein Hammer ist, alles zu behandeln, als ob es ein Nagel wäre." Hier nimmt Maslow die klassische Beobachtung über Hämmer ein wenig weiter und weist auf eine besondere Versuchung hin, einfach aufzugeben und zu sagen: "Ich weiß, dass ein Hammer nicht das richtige Werkzeug dafür ist, aber ich werde den Hammer trotzdem benutzen und hoffe, dass es funktioniert".

Nun möchte ich dieses Problem in eine flache / hochautonome / selbstorganisierende Möbelproduktion übertragen. Angenommen, die Tischlerei hat einen Haufen Hammer-Genies, sie schwingen den Hammer wie keine anderen und können Holzbretter irgendwie erfolgreich nach den Vorgaben zusammenfügen, indem sie Nägel in sie einschlagen. Aber jetzt ist die Oberfläche des Holzes um den Nagel herum ruiniert und die Polsterer haben es schwerer, ihre Arbeit zu erledigen, weil der Stoff, das sie benutzen, auf dem gesplitterten Holz hängen bleibt.

Die offensichtliche Verbesserung besteht nun darin, sicherzustellen, dass die vorgelagerten Akteure die Bedürfnisse der Polsterstation besser verstehen. Zimmerleute könnten real Zeit mit Polsterern verbringen, um ein besseres Gefühl dafür zu bekommen, was sie brauchen. Oder Leute, die Spezifikationen für Zimmerleute schreiben, könnten ausdrücklich festlegen, dass die Oberfläche um die Holzfugen herum glatt sein soll.

Es ist nicht immer einfach, außerhalb der Komfortzone zu lernen.

Vielleicht brauchst Du kein Silo.

Das altmodische wissenschaftliche Managementdenken hat eine Lösung für dieses allgemeine Problem. Die Zusammenfassung sieht wie folgt aus: Die Geschäftsleitung entsendet einen Experten, der die Polsterer bei der Arbeit beobachtet. Dieser Experte soll erfolgreich ableiten, dass die Probleme durch gehämmerte Nägel verursacht werden. Vom Experten wird nicht einmal erwartet, dass er mit den Polsterern spricht. Sie sollen einfach sowieso nichts über andere Organisationssilos wissen. Wenn der Experte die Ursache des Problems richtig ableitet, geht er/sie und überprüft die Zimmerleute, um die Ergebnisse zu vergleichen. Er/sie recherchiert dann einige Informationen in Fachbüchern und übergibt einen Bericht an die Geschäftsleitung. Von der Geschäftsleitung wird dann erwartet, dass sie den Bericht korrekt interpretiert und in eine Liste von umsetzbaren Aufträgen für die Produktionslinie umwandelt.

Das wissenschaftliche Management hat herausgefunden, wo das Problem liegt. Die Grundannahme, dass Feedback gesammelt und dann in umsetzbare Pläne umgesetzt werden sollte, ist richtig. In der Praxis scheitern solche harten Top-down-Ansätze des wissenschaftlichen Managements jedoch an verschiedenen Kommunikationsproblemen, die organisatorischen Silos innewohnen. Empathie kann nicht von einem technischen Experten vermittelt werden.

 

Manchmal ist die Existenz von Silos das Problem.



Agile schlägt vor, die zusätzlichen Schritte zu beseitigen, indem wir die Silos niederreißen und die Mitarbeiter direkt miteinander sprechen lassen. In unserem Beispiel müssen Tischler offen sein für Beschwerden von Polsterern. Wenn sie wirklich nur Hämmer kennen und verstehen, wie sollen sie dann die Beschwerden über verfangene und zerrissene Stoffe bearbeiten? Dieser Grad der Überspezialisierung erzeugt Menschen, die Feedback aus anderen Perspektiven nicht verstehen können.

Menschen mit agilem Mindset lesen die Handbücher anderer.

Lass uns dieses Beispiel wieder mit der Softwareentwicklung verbinden. Abhängig vom Geschäftsfall kann ein visueller Designer eine Station im Workflow sein, wie die Tischler, oder ein Planer, dessen Ergebnisse de facto GUI-Blaupausen sind. So oder so sind sie wahrscheinlich Upstream-Lieferanten für Entwickler und beeinflussen direkt ihre Arbeitsqualität.

Es ist eine schlechte Idee, einem Team von Codeschreibern einen Haufen Screenshots zu geben und ihnen zu sagen, sie sollen sich beeilen. Datenbank-Mitarbeiter arbeiten mit unveränderlichen Datenstrukturen. Bei der visuellen Gestaltung ist zu beachten, dass diese Datenstrukturen im Wesentlichen das Ausgangsmaterial für die Gestaltung der Benutzererfahrung sind. Ihre Transformation in Frontend oder Middleware ist nicht frei. Wenn man eine bestehende Datenbank und eine Reihe von Screenshots erhält, werden Codeschreiber einen Weg mit dem geringsten Widerstand zwischen den beiden finden und bis zum Ende dabei bleiben.


Die Vermeidung von schlechtem Füllmaterial in einem Produkt erfordert ein einheitliches Design, eine Bottom-up-Integration verschiedener Disziplinen in ein einheitliches Design erfordert eine einheitliche Sprache. Manchmal können solche Sprachen gefunden und von der Stange verwendet werden. In den meisten Fällen müssen Praktiker der Disziplinen zusammensitzen und tatsächlich im Team an Projekten arbeiten, um lokal eine gemeinsame Sprache durch Ausprobieren zu entwickeln.


Als Individuum kann jeder von uns diesen Prozess beschleunigen, indem er/sie daran arbeitet, alle anderen auf halbem Weg zu treffen und etwas Zeit in angrenzende Wissensgebiete investiert. Deshalb sind Menschen mit agilem Mindset für die agile Teamarbeit wertvoll; sie haben bereits viel Arbeit geleistet, um andere Menschen zu einem hypothetischen Mittelpunkt zu bringen.