Als ich zu Centigrade stie\u00df, fragte ich mich, warum eigentlich der Zusatz \u201eUser Interface Architectures\u201c\u00a0 im Firmennamen steht. Neue Begriffe sind in dieser Branche nicht \u00fcberraschend; die Fachsprache ist jung und ver\u00e4ndert sich schnell, viele versuchen, sie mit eigenen Begriffen und Definitionen zu pr\u00e4gen. Aber ich wunderte mich, warum gerade Architektur dort auftaucht, und vielleicht ging es Ihnen auch so.<\/p>\n
Die kurze, vordergr\u00fcndige Antwort: Aufmerksamkeit. Dass man an dieser Zeile h\u00e4ngenbleibt ist intendiert. Nat\u00fcrlich soll sie auffallen, Assoziationen wecken und Centigrade differenzieren.<\/p>\n
Trotzdem ist \u201eUser Interface Architectures\u201c keine Worth\u00fclse, und das bringt uns zur langen, tiefgr\u00fcndigeren Antwort. Dieser Begriff beschreibt unsere Arbeit nach au\u00dfen pr\u00e4zise und anschaulich. Wir m\u00fcssen immer damit rechnen, dass Kunden, Benutzer und externe Dienstleister keine genaue Vorstellung von unserer Arbeit haben. Indem wir unsere Leistung mit traditioneller Architektur vergleichen, helfen wir ihnen einen Zugang zu finden. \u00a0Dagegen sind wir und andere Interface Designer vertraut mit den Aufgaben, Prozessen und Ergebnissen. Wenn wir aber das Gef\u00fchl bekommen, betriebsblind zu werden, kann uns der Vergleich zur traditioneller Architektur und zur Arbeit von traditionellen Architekten neue Ideen und neuen Antrieb geben. Intern ist \u201eUser Interface Architectures\u201c ein Ansto\u00df, unsere Arbeitsweise zu \u00fcberdenken und in einem breiteren Kontext zu sehen. An vier Gemeinsamkeiten mit der traditionellen Architektur zeigen wir in diesem Artikel, wie der Vergleich zur Architektur nach au\u00dfen und innen wirken kann.<\/p>\n
Die meisten User Interfaces werden f\u00fcr jahrelange Benutzung gestaltet. Um Kunden diese Langfristigkeit und Best\u00e4ndigkeit zu verdeutlichen, hilft die Assoziation zur traditionellen Architektur. Zwar werden Bauwerke viel l\u00e4nger, Jahrzehnte oder Jahrhunderte genutzt, aber Interfaces sind l\u00e4nger haltbar als andere typischen Designbereichen wie Werbung, Zeitschriften, Verpackung oder Mode. Auch in f\u00fcnf Jahren wollen Benutzer ihre Aufgaben effektiv, effizient und elegant l\u00f6sen k\u00f6nnen. Daf\u00fcr m\u00fcssen wir die nutzungsbezogene, \u00e4sthetische und technische Entwicklung bei unserer Arbeit im Blick haben, und genau das deutet \u201eUser Interface Architectures\u201c an.<\/p>\n
Wir f\u00fchlen uns nicht eingeschr\u00e4nkt davon, vorauszudenken \u2013 im Gegenteil, wir gestalten ausgesprochen gerne f\u00fcr die Zukunft. Wie hilfreich diese Perspektive ist, zeigt das popul\u00e4rste Beispiel f\u00fcr gute User Experience: Apple. Nat\u00fcrlich hing der Erfolg des iPhones von vielen Dingen ab, aber einer war sicher Bewusstsein f\u00fcr gute User Experience. Es war\u00a0 revolution\u00e4r, als Steve Jobs es vorstellte, heute ist es der allt\u00e4gliche Standard, den auch kleine Kinder bis zu einem gewissen Punkt beherrschen. Um dieses wunderbare Ergebnis zu erreichen, haben die Designer von Anfang an darauf geachtet, dass die revolution\u00e4re Technik den Benutzern t\u00e4glich hilft, Probleme zu l\u00f6sen. Sonst w\u00e4re die Neuerung von den K\u00e4ufern schnell als Ablenkung, St\u00f6rung oder Hindernis abgelehnt worden. Auch wir pr\u00fcfen unsere Arbeit st\u00e4ndig, damit Aussehen, Animationen und Interaktionsverhalten den Benutzern helfen. Wenn uns das gelingt, steigt die Chance, dass das Ergebnis auch in einigen Jahren noch wertvoll sein wird.<\/p>\n
Jeder, der die Arbeit an einem User Interface kennt, wei\u00df, dass sie das Wissen, die Erfahrung und die Zusammenarbeit vieler Spezialisten erfordert. Aber auch Menschen, die zum ersten Mal den Begriff User Interface h\u00f6ren, sind mit dieser Arbeitsweise eigentlich schon vertraut: aus der traditionellen Architektur. Komplexe Projekte mit ausgedehnten Planungsphasen, mehreren Bauherren, einem Bauleiter, mehreren Umsetzenden. Die Interface-Design-Neulinge wissen, dass traditionelle Architekten in dieser Situation viele Aufgaben und Verantwortlichkeiten haben: zusammen mit den Bauherren den Grob- und Detailentwurf zu erarbeiten, alle Anforderungen, W\u00fcnsche, das Budget und die technischen Einschr\u00e4nkungen zu verbinden, und bei der Umsetzung Bauingenieure, Bauarbeiter und Handwerker zu koordinieren, ohne unterwegs die urspr\u00fcngliche Vision zu verlieren. Wir vergleichen unsere Aufgaben mit ihren, weil auch Benutzeroberfl\u00e4chen-Projekte von uns verlangen, dass wir bei Gestaltung von der ersten Vision bis zum Einsatz den \u00dcberblick behalten.<\/p>\n
Bei einem typischen Projekt lernen wir in Ruhe die Aufgaben, f\u00fcr die das Interface gedacht ist, die geschmackliche Richtung und technischen Einschr\u00e4nkungen kennen und halten sie fest \u2013 zusammen mit Schl\u00fcsselpersonen des Kunden, aber auch mit Dritten, zum Beispiel externen Entwicklern. Kommunikation ist f\u00fcr die Arbeit an User Interfaces entscheidend, da viele Gewerke und Kompetenzen nahtlos ineinandergreifen m\u00fcssen. Dabei hilft uns das Bild vom traditionellen Architekten in wei\u00dfem Hemd, Gummistiefeln und Bauhelm. Traditionelle Architekten vermitteln zwischen Planung und Umsetzung. Auch wir m\u00fcssen uns in beiden Welten bewegen, selbst wenn wir dazu keinen Helm aufzusetzen brauchen. Weil Centigrade neben Interaction Design und Management auch selbst entwickelt und visuell gestaltet, k\u00f6nnen wir uns gut in die Perspektive der anderen am Projekt Beteiligten versetzen. Wir wissen, dass der Architekt den \u00dcberblick behalten muss. Deshalb sind wir auch gute Handwerker, wenn wir unter der Leitung von anderen Architekten \u2013 Kunden oder anderen Interface Designern \u2013 arbeiten.<\/p>\n
Erst die Benutzung haucht Bauwerken und Interfaces Leben ein. Am Anfang eines typischen Bauprojekts steht nicht die gew\u00fcnschte Wirkung, sondern die Nutzung: Wohnen, Lagern, Arbeiten, Verbinden. Mit dieser Anforderung gehen Bauherren zum traditionellen Architekten, und erst wenn sie klar definiert ist, werden Gr\u00f6\u00dfe des Hauses, finanzielles Budget, Zeitrahmen, Form und Materialien in Einklang gebracht. Auch User Interfaces sollten um die Benutzung herum entstehen. Der Vergleich zur traditionellen Architektur kann diese Grundlage allen klar machen, die an der Entstehung des Interfaces beteiligt sind: wir m\u00fcssen die Nutzung kl\u00e4ren und verstehen, um effektiv zu arbeiten. Jesse James Garrett erkl\u00e4rt in seinem Buch \u201eThe Elements of User Experience<\/a>\u201c\u00a0 die Nutzung bekannter Software, indem er sie auf ein einzelnes Verb reduziert: Google \u2013 Suchen. Word \u2013 Schreiben. Skype \u2013 Telefonieren. Diese T\u00e4tigkeiten, zerlegt in Interaktionen, bestimmen das Interface. Und das Interface bestimmt mit, wie Benutzer die Software erleben.<\/p>\n Die W\u00fcnsche und Bed\u00fcrfnisse der Nutzer sind komplex und nicht auf den ersten oder zweiten Blick vorhersehbar \u2013 auch f\u00fcr traditionelle Architekten nicht. Deshalb baute beispielsweise Alaska Airlines 2003 einen Prototyp ihres neuen Check-In-Schalters<\/a>, um zu sehen, wie Passagiere und Mitarbeiter damit umgehen, und die Erkenntnisse sofort testen zu k\u00f6nnen. (via Jason Fried und David Heinemeier Hansson, Rework) Aus dem gleichen Grund wurden der erste Apple Store 2001 und die neue Generation 2012 als Prototypen getestet<\/a>, \u00fcberarbeitet und wieder getestet. Die verantwortlichen Architekten wussten einfach, dass sie nicht alles im Voraus planen k\u00f6nnen.<\/p>\n Der Ansatz ist jedem, der Interfaces gestaltet, bekannt: Beobachtung, Prototypen und User Tests, in mehreren Iterationen. Wir User Experience Designer wenden \u00e4hnliche Methoden wie traditionelle Architekten an, weil wir beide komplexe Gestaltungsaufgaben l\u00f6sen. Durch die Einbeziehung der Benutzer beobachten wir Verhaltensmuster, aus denen das Interface Konzept entspringen kann. Wir lernen die Benutzer, ihre Umgebung, und ihre Ziele kennen, und bekommen direkte, ungefilterte Erkenntnisse. Mit Interface-Prototypen k\u00f6nnen wir sie schnell aufnehmen und wieder beobachten, wie die L\u00f6sung sich in der Realit\u00e4t bew\u00e4hrt. Mit diesen Iterationen wird das Interface robuster und passt sich an die Nutzung an. Und von Projekt zu Projekt sammeln wir Erfahrung, welche L\u00f6sungen in welchen Situationen am besten funktionieren.<\/p>\n Das Konzept der Patterns geht auf den Architekten Christopher Alexander zur\u00fcck. In dem Buch \u201eA Pattern Language\u201c stellte er sie 1977 als Entwurfsmethode in der traditionellen Architektur vor. Schnell wurden sie auf Informatik und Systemdesign \u00fcbertragen und kam auf diesen Weg ins Interaction Design. Dabei geriet ihre theoretische Grundlage in Vergessenheit. User Interfaces k\u00f6nnen von einer Wiederentdeckung der Ideen hinter den Patterns profitieren, um sie besser zu verstehen, zu erkennen und einzusetzen.<\/p>\n Christopher Alexander formulierte die Pattern Language als leichten Weg, Bauwerke zu gestalten und umzusetzen, die selbstverst\u00e4ndlich, bequem, zeitlos und an ihre Umgebung angepasst sind. Seine Patterns f\u00fcr die traditionelle Architektur sammeln typische Beziehungen zwischen Menschen und Umwelt. Zum Beispiel das Pattern \u201ePositive Outdoor Space\u201c: Menschen bevorzugen G\u00e4rten und \u00f6ffentliche Pl\u00e4tze mit klaren Grenzen, weil sie alles \u00fcberschauen k\u00f6nnen und den R\u00fccken frei haben. Ein anderes Beispiel ist das Pattern \u201eHigh Places\u201c: Menschen sitzen gerne auf Treppen, Gel\u00e4ndern und Mauern im \u00f6ffentlichen Raum, weil sie von dort besser sehen, ohne sich abzugrenzen. Solche Situationen haben wir alle schon selbst beobachtet. Genauso k\u00f6nnen wir beobachten, dass es typische Beziehungen auch zwischen Menschen und seiner digitalen Umgebung gibt \u2013 wie wir Informationen bearbeiten, wie wir sie durchsuchen, ordnen und verbreiten.<\/p>\n Die Patterns der traditionellen Architektur beschreiben den Kontext, nicht die L\u00f6sung. Auch wenn sie bekannte Konventionen widerspiegeln, liefern deshalb diese Patterns keine Musterl\u00f6sungen. \u201eHigh Places\u201c legt nicht fest, ob eine \u00f6ffentliche Treppe, eine Veranda oder ein nat\u00fcrlicher sanfter Hang die L\u00f6sung ist. Diese Entscheidung treffen Architekten oder Bewohner im konkreten Kontext. Nur sie k\u00f6nnen die Situation unmittelbar erleben und gestalten, zum Beispiel, wenn sie in Kooperation ein Wohnhaus planen und bauen.<\/p>\n Entwurfsmuster wie \u201eWizard\u201c oder \u201eBreadcrumb\u201c aus Interface Design-Libraries wie Quince oder UI Patterns<\/a> sind konkreter als die Patterns aus der traditionellen Architektur. Sie enthalten eine L\u00f6sung, die allerdings immer noch nur in einem bestimmten Kontext passt. Auch diese Entwurfsmuster m\u00fcssen in der Anwendung angepasst werden. Screenshots und Codebeispiele verf\u00fchren allerdings dazu, diese L\u00f6sungen schnell zu kopieren, ohne auf den Kontext zu achten. Dadurch steigt das Risiko, sie ungewollt falsch zu verwenden.<\/p>\n Anders als zum Beispiel die traditionellen Architekten eines Wohnhauses lernen wir nie alle Benutzer unserer Interfaces kennen. <\/strong>Aber wir k\u00f6nnen mit Kontextanalysen, Prototypen und Usability Tests den Kontext zusammen mit einigen Benutzern am Beispiel verstehen, um die Patterns f\u00fcr das gesamte Interface zu erkennen. Diese Tests sollten mit dem Einsatz von Patterns fest verbunden sein: Patterns stammen aus der Beobachtung, ihre Anwendung fordert ebenfalls Beobachtung.<\/p>\n Die vier Beispiele zeigen die Gemeinsamkeiten zwischen traditionellen Architektur und \u201eUser Interface Architecture\u201c: beide m\u00fcssen vielen Faktoren und Beteiligte zusammenbringen, und beide verbinden \u00c4sthetik und Technik, Entwurf und Umsetzung. Schon deshalb fasst \u201eUser Interface Architectures\u201c unsere Arbeit gut zusammen. Wir lernen aber auch von der Erfahrung der traditionellen Architektur \u2013 die Bewohner und Benutzer stehen im Mittelpunkt, und wir m\u00fcssen sie beobachten und mit einbeziehen, wenn wir erfolgreiche \u201eUser Interface Architectures\u201c gestalten wollen. Deshalb werden wir auch in Zukunft auf die traditionelle Architektur schauen, um alte Ideen zu pr\u00fcfen und neue Ideen zu finden.<\/p>\n Update 2017: W\u00e4hrend die Idee von „User Interface Architecture“ noch immer ihre Relevanz hat, konnte sich Centigrade als Unternehmen in den letzten Jahren dar\u00fcber hinaus entwickeln, um Unternehmen noch ganzheitlicher bei dem Thema User Experience Design unterst\u00fctzen zu k\u00f6nnen. Finden Sie unser erneuertes Mission Statement auf unserer \u00dcber uns<\/a> Seite.<\/p>\n iPhone ist eine Marke oder eingetragene Marke der Apple Inc. in den USA und\/oder anderen L\u00e4ndern. <\/span><\/p>\n","protected":false},"author":26,"featured_media":0,"template":"","tags":[173,166,100,16],"class_list":["post-2821","blog","type-blog","status-publish","hentry","tag-architektur","tag-design-prinzipien","tag-design-prozess","tag-prototyping"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/2821","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/26"}],"version-history":[{"count":3,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/2821\/revisions"}],"predecessor-version":[{"id":11309,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/2821\/revisions\/11309"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=2821"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=2821"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Mustererkennung<\/h4>\n
4 \u2013 Patterns<\/h3>\n
Patterns in der traditionellen Architektur<\/h4>\n
Patterns im User Experience Design<\/h4>\n
Fazit<\/h3>\n