Kategorie: User Experience Seite 1 von 2

On Tour: O’Reilly Software Architecture Conference 2017, London

Am 16.-18. Oktober findet in London The O’Reilly Software Architecture Conference 2017 statt. Wir freuen uns schon sehr, dabei wieder auf unterhaltsame Weise unseren Zuhörern nahezubringen, wie eng die Verbindung zwischen User Experience und Softwarearchitektur ist (oder sein sollte!):

How do Software Architects find the way to User Experience? With Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von Softwaresystemen. Unser Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Wir freuen uns auf spannende Tage mit inspirierenden Vorträgen, Begegnungen und Diskussionen. Alle Informationen zur Konferenz gibt es hier.

On Tour: OOP 2017, München

OOP 2017

Wir freuen uns sehr, bei der OOP 2017 als Sprecher dabei sein zu dürfen. Mit 8 Tracks zu spannenden Themen rund um Softwareentwicklung verspricht die OOP wieder ein echtes Highlight zu werden.

Who is engineering the Software, which is eating the world?

Software revolutioniert fast jede Art von Business durch neuartige Ökosysteme. Die Erstellung erfordert Kompetenzen, die weit über das klassische Systems- und Software-Engineering hinausgehen. Zentrale Herausforderungen sind höhere Komplexität bei kürzerer Time-To-Market, geteilte Verantwortung und Kontrolle über mehrere Unternehmen und Domänen hinweg sowie die immer höher werden Anforderungen an Sicherheit, User Experience, und andere Qualitäten. Wir charakterisieren Softwareökosysteme und zeigen notwendige Kompetenzen, um diese zu bauen.

Ereignisorientierung im App-Ökosystem – Architekturdetails als Garant für erfolgreiche Integration

Ereignisorientierung ist in vielen Aspekten für IoT-Systeme geeignet, weil reale Ereignisse verarbeitet werden. Die passende Architektur und Implementierung ist aber alles andere als offensichtlich und erfordert, dass sich Architekten und Entwickler gemeinsam um viele Details kümmern. Wir zeigen Lösungen für ein skalierbares und erweiterbares App-Ökosystem mit Logistikfokus: Error Handling, Schnittstellen, Daten- und Eventmodellierung mit Generierung von Entwickler-spezifischen Sichten, Einfluss auf die Clients und Umsetzung in AWS mit Reactor.

Dieser Vortrag ist zusammen mit unserem Kollegen Balthasar Weitzel.

Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen. Hier geht es zum vollständigen Konferenzprogramm.

UX MADE of STEAL – Kreative Beschaffung von Ideen (UX Day 2015)

UX MADE of STEAL
Wir brauchen immer mehr tolle Ideen! Aber woher nehmen, wenn nicht stehlen? Anregungen zur kreativen Beschaffung von Ideen aus meinem Vortrag vom UX Day 2015.

Gestern hatte ich meinen Vortrag beim UX Day 2016 am 13. November in Mannheim angekündigt. Auch im letzten Jahr war ich beim UX Day 2015 in Mannheim dabei, mit einem Vortrag zum Thema:

UX made of STEAL

„Bringt mir neue, innovative Lösungen!“, „Seid doch endlich mal kreativ!“, „Wir müssen uns neu erfinden!“ und ähnliche Aussagen hören wir vermehrt in letzter Zeit. Es scheint jedoch so, als wäre alles schon von anderen erfunden, und die anderen haben sowieso immer die besseren Ideen, so dass wir uns zur Lieferung neuer Ideen fragen müssen: Woher nehmen, wenn nicht stehlen? Ob das vielleicht sogar eine ernsthafte Lösung ist oder wie wir unser Wissen über existierende gute Lösungen gewinnbringend zur Erarbeitung von neuen Ideen einsetzen können, wird in diesem Vortrag diskutiert.

Die Nachfrage nach neuen, kreativen Lösungen oder Produkten steigt stetig an. Immer mehr Menschen sollen in ihrer täglichen Arbeit innovativer werden. Sie sollen ihre „Komfortzone verlassen“ oder „um die Ecke denken“. Das ist aber für viele Menschen leider sehr ungewohnt und oft auch unangenehm. Erschwert wird die Situation zudem dadurch, dass dem ersten Eindruck nach, jede erarbeitete Idee schon lange von anderen bereits erfunden oder erdacht worden ist. Es erscheint vordergründig, als ob es täglich schwerer wird, etwas Neues zu erschaffen. Dies wird zudem noch oft von den eigenen Mitarbeitern bestätigt: „Gibt’s schon. Das brauchen wir gar nicht erst zu versuchen. Das haben andere schon ewig.“ Schnell kann man sich in dieser Situation fragen „Woher nehmen, wenn nicht stehlen?“

Im Vortrag wird diskutiert, ob vielleicht gerade das eine Lösung unseres Problems darstellen könnte, selbstverständlich im übertragenen Sinne. Warum sollten wir unser Wissen über bereits existierende gute Lösungen immer destruktiv nur zur Ablehnung der eigenen Ideen verwenden? Schließlich können wir die bereits bekannten guten Lösungen als Inspiration konstruktiv nutzen. Bei genauem Betrachten sind nämlich meistens die selbst erdachten Ideen doch nicht ganz genauso schon einmal von jemand anderem erdacht worden (wie die Kollegen aber angeben). Aber gerade weil schon mal jemand zuvor eine gute Lösung für ein (sehr) ähnliches Problem gefunden hat, kann man bestimmte Aspekte dieser Lösung auf das eigene Problem übertragen. So geht es hier nicht um Kopien oder gar Diebstahl von Ideen sondern vielmehr um Inspiration, Transformation oder einen „Remix“. Auch können wir aus vielen bereits existierenden Lösungen für Teilaspekte unseres Problems eine Gesamtlösung zusammenbauen.

Der Vortrag zeigt mit vielen anschaulichen Beispielen, wie diese „kreative Beschaffung“ bereits von erfolgreichen Unternehmen eingesetzt wird. Zudem motiviert der Vortrag sich mit vielen Bereichen und Domänen auch außerhalb der eigenen Arbeit zu beschäftigen, um Lösungsideen von dort in die eigene Arbeit zu übertragen.

 

Beim UX Day 2015 gab es viele tolle Vorträge, Insbesondere möchte ich auf den super guten Vortrag von Roman Rackwitz zum Thema „Gamification – human performance design“ verweisen. Weiter Informationen zum UX Day 2015 findet ihr hier.

Wenn euch mein Vortrag gefallen (oder auch nicht) oder wenn ihr Anregungen und Fragen zum Thema habt, dann schreibt einfach einen Kommentar.

On Tour: UX Day 2016, Mannheim

Mannheim - Rheinufer - Sonnenuntergang

Am 13. & 14. Oktober findet in Mannheim der UX Day 2016 statt. Ich freue mich auch dieses Jahr wieder mit dabei zu sein. Mein Vortrag dieses Jahr trägt den Titel:

„Wir müssen reden!“

Gute Kommunikationsfähigkeiten sind eine wichtige Voraussetzung für nahezu jede Rolle im User Experience Engineering. Selbst unter besten Voraussetzungen:

  • wenn genau der richtige Stakeholder,
  • zum genau richtigen Zeitpunkt zum Gespräch eingeladen wurde,
  • das Gespräch perfekt vorbereitet wurde und
  • in den perfekten Räumlichkeiten stattfindet,

so kommt es dennoch zu einem erheblichen Maße auf die persönlichen Kommunikationsfähigkeiten des UX-Experten an, wie gut oder schlecht die Ergebnisse des Gesprächs sein werden. Dieser Vortrag liefert konkrete Tipps und Tricks von Kommunikationsexperten aus unterschiedlichsten Domänen (Kriminalistik, Jura, Journalistik, uvm.) zur Verbesserung der Kommunikation in persönlichen UX-Stakeholder-Gesprächen.

Das persönliche Interview ist immer noch eines der wichtigsten Instrumente zum Erheben und Validieren von UX Anforderungen. Es gibt viele Techniken, Methoden und Werkzeuge, die uns dabei unterstützen, die Interviews zu planen und die richtigen Stakeholder für diese Interviews zu identifizieren. Noch mehr Unterstützung gibt es, die UX Experten helfen, die zu erhebenden Informationen festzulegen und somit auszuwählen, welche Fragen den Stakeholder genau gestellt werden sollen. Jedoch egal wie gut das Interview vorbereitet und aufgesetzt wurde, im Interview selbst, hängt es dann jedoch erheblich von den persönlichen Kommunikationsfähigkeiten des UX Experten ab, ob das Interview erfolgreich verläuft oder nicht. Es gibt somit viel Unterstützung für das WANN, WER und WAS aber fast keine Unterstützung für das WIE. Die im UX-Stakeholder-Interview benötigen Kommunikationsfähigkeiten unterscheiden sich nicht (stark) von den Kommunikationsfähigkeiten von Experten aus anderen Domänen, in den es ebenfalls wichtig ist, Informationen zu erheben und zu validieren. Polizisten müssen Informationen von Zeugen und Verdächtigen erheben und auf ihren Wahrheitsgehalt hin beurteilen. Ähnliches gilt für Anwälte, die zudem noch die Aussagen von Gutachtern einschätzen müssen. Auch für Reporter ist das persönliche Interview ein wichtiges Mittel zur Erhebung von Informationen. Aber auch die Gesprächsführung beim Dating oder im Job-Interviews ist ähnlich zum UX-Stakeholder-Interview, da auch hier versucht wird, Informationen vom Gegenüber zu erhalten und diese auf ihren Wahrheitsgehalt hin zu überprüfen. Es gibt viele Tipps & Tricks aus diesen Domänen und Disziplinen, die auch in UX-Stakeholder-Interviews angewendet werden können. Dies gilt nicht nur die verschiedenen Phasen des eigentlichen Interviews, sondern auch die Interview-Vorbereitung und -Nachbereitung.

Ich bin seit vielen Jahren ein großer Fan der Veranstaltung und freue mich daher schon jetzt wieder auf einen tollen Tag in Mannheim. Alle Informationen zum UX Day 2016 gibt es hier! Dieses Jahr gibt es zum ersten Mal einen zweiten Veranstaltungstag, an dem die UX Masterclass stattfinden wird.

On Tour: The Architecture Gathering 2016, München

München

Am 12. und 13. Oktober findet in München The Architecture Gathering 2016 statt. Letztes Jahr war die Veranstaltung ein voller Erfolg mit vielen Teilnehmern, hochkarätigen Sprechern und tollen Vorträgen. Dieses Jahr sind wir auch mit einem Vortrag dabei und freuen uns schon sehr auf die Veranstaltung:

Wie finden Softwarearchitekten den Weg zu User Experience? Mit Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von Softwaresystemen. Unser Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Wir freuen uns auf zwei spannende Tage mit inspirierenden Vorträgen, Begegnungen und Diskussionen. Alle Informationen zum Architecture Gathering 2016 gibt es hier.

On Tour: Bitkom AK Softwarearchitektur, Frankfurt

Bitkom AK Softwarearchitektur

Der Bitkom AK Softwarearchitektur trifft sich am 07. Juni 2016 in Frankfurt zum Thema: Moderne Rollenbilder für das Software Engineering

Wir sind auch mit einem Vortrag dabei:

Who is engineering the Software, which is eating the world?

Software revolutioniert die Welt und fast jede Art von Business durch Digitalisierung und neuartige Ökosysteme. Die Erstellung solcher Systeme erfordert Kompetenzen, die weit über das klassische Systems- und Software-Engineering hinausgehen. Zentrale Herausforderungen dabei sind domänenübergreifendes Arbeiten, immer höhere Komplexität bei trotzdem geforderter kürzerer Time-To-Market, geteilte Verantwortung und Kontrolle über mehrere Unternehmen hinweg sowie die immer höher werdenden Anforderungen an Sicherheit, User Experience, und andere Qualitäten. Wir stellen in diesem Vortrag die Charakteristiken von Softwareökosystemen vor und welche Kompetenzen notwendig sind, um diese zu bauen.

Hier geht es zur Agenda und zu Infos zum Veranstaltungsort.

Wir freuen uns auf spannende Diskussionen zu vielfältigen Facetten zukünftiger Rollenbilder im Softwareengineering.

Die Grüne Wiese ist nur noch eine Illusion!

Kreative Entwickler wünschen sich Projekte auf der Grünen Wiese. Jedoch zerstören weit mehr Einschränkungen als nur Legacy-Systeme diesen Wunschtraum.

"Die Grüne Wiese ist nur noch eine Illusion!"

Wir Softwareentwickler fühlen uns zunehmend eingeschränkt, beengt und nahezu erstarrt in unserem Schaffen und unserer Kreativität. Statt möglichst viel zu gestalten sind wir den Zwängen historisch gewachsener Systeme, überbordender Wartungsaufwände, verschleppter Modernisierung und veralteter Technologien erlegen. Das liegt daran, dass wir häufig in sogenannten Brownfield-Projekten arbeiten müssen, bei denen wir uns mit Legacy-Systemen rumärgern müssen.

Deshalb wünschen wir uns sehr oft, endlich mal wieder ein System auf der Grünen Wiese (Greenfield) hochzuziehen und die volle Freiheit zu genießen. Die Grüne Wiese lockt uns mit allem Gestaltungsspielraum und verspricht uns, mit unserer Kreativität die kompromisslos beste Lösung zu erreichen.

Gerne würden wir alles was wir haben hinter uns lassen und nochmal komplett neu entwickeln (siehe auch „Das neue System muss aber das Gleiche können …“). Noch lieber würden wir wie ein neues Startup, losgelöst von eingefahrenen Prozessen und Vorschriften, agieren und ein komplett neues System auf der Grünen Wiese hochziehen.

Was zerfurcht die Gründe Wiese?

Leider ist die Grüne Wiese heute nur noch eine Illusion und ihre Bebauung bleibt damit ein Wunschtraum. Nachfolgend zeigen wir 4 Kategorien von Einschränkungen, die uns die Grüne Wiese so gut wie immer verbauen, obwohl weit und breit kein Legacy-System zu sehen ist.

  1. Integration
  • Zunehmende Vernetzung: Fast kein System wird heute noch in Isolation gebaut. Daher zerfurchen uns die Vorgaben und Schnittstellen der Partner-Systeme die Grüne Wiese.
  • Ökosysteme: In Ökosystemen sind wir nie alleine. Deshalb verschandeln uns Kompromisse mit unseren Ökosystem-Partnern die Grüne Wiese.
  • Social Media: Die Erwartungshaltung von Nutzern ist heute eine tiefgreifende Integration mit globalen sozialen Netzwerken (z.B. Login mit Facebook oder Twitter). Die damit einhergehenden Vorgaben torpedieren die Grüne Wiese.
  1. Technologien
  • Frameworks: Frameworks und Technologien ermöglichen uns, dass wir uns besser auf unsere Kernfunktionalität fokussieren können. Die damit einhergehenden Einarbeitungsaufwände und Beschränkungen verhageln uns die Grüne Wiese.
  • Cloud Computing: Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) bieten uns extreme Skalierbarkeit. Die Einhaltung der dazu notwendigen Architekturvorgaben verbaut uns die Grüne Wiese.
  • Mobile: Wenn wir erfolgreiche mobile Apps anbieten wollen, kommen wir an iOS und Android nicht vorbei. Die Entwicklungsplattformen, die Bereitstellung über App-Stores und die aufgezwungenen Geschäftsmodelle untergraben die Grüne Wiese.
  1. Richtlinien
  • Styleguides: Eine konsistente Benutzung und positive User Experience wird durch die Einhaltung von Styleguides erleichtert. Dadurch sind der Kreativität und Innovationen Grenzen gesetzt, die die Grüne Wiese ramponieren.
  • Enterprise Architecture: Mit der Vorgabe einer Enterprise Architecture verhindern große Unternehmen unkontrollierbaren Wildwuchs auch bei der Technologieauswahl. Diese Einschränkung zerstört die Grüne Wiese.
  1. Erwartungen
  • Erwartungshaltung der Nutzer: Bei vielen Nutzern hinterlassen weit verbreitete (de-facto Standard-) Anwendungen (wie z.B. Microsoft Word) eingebrannte Erwartungshaltungen bezüglich Benutzung und Funktionalität. Diese verbrennen die Grüne Wiese.
  • Aktuelle Trends: Was Nutzer als zeitgemäße und moderne Anwendungen wahrnehmen unterliegt sich ändernden Trends (wie z.B. Flat Design). Die Berücksichtigung dieser Trends verhunzt die Grüne Wiese.

Offensichtlich treffen diese Einschränkungen leider nicht nur auf Großunternehmen zu, sondern auch auf Startups. Lediglich die vorherrschenden Einschränkungen unterscheiden sich je nach Umfeld, in dem wir arbeiten.

Vergessen wir also den Wunschtraum von der Grünen Wiese. Verwenden wir lieber unsere Energie, um die verbleibenden Freiheitsgrade optimal auszunutzen, statt dem Phantom „Grüne Wiese“ hinterherzujagen.

"Verbleibende Freiheitsgrade ausnutzen!"

Kennt ihr noch weitere Einschränkungen in unseren oder weiteren Kategorien, dann schreibt diese bitte in den Kommentarbereich. Und vergesst nicht ein schönes Verb, wie dadurch die Grüne Wiese in Mitleidenschaft gezogen wird 😉

Wir müssen gute Nachbarn sein! (WWDC 2015)

Panorama - Ausblick vom Moscone Center Balkon

App-Entwickler müssen gute Nachbarn sein und wieder sorgsamer mit knappen Ressourcen (Speicher, CPU, Akku) umgehen, sonst werden ihre Apps wahrscheinlich bald von Benutzern gelöscht.

Die World Wide Developer Conference (WWDC) 2015 in San Francisco ist nun schon wieder weit mehr als einen Monat vergangen. Ich habe von der Veranstaltung eine Aufgabe bzw. Herausforderung für uns Architekten, Programmierer und Designer mitgenommen, die ich für sehr wichtig halte:

"Wir müssen gute Nachbarn sein!"

Diese unterschwellige Nachricht habe ich über die gesamte Veranstaltung hinweg immer wieder wahrgenommen. Obwohl wir alle auch in der realen Welt gute Nachbarn sein sollten, meine ich das natürlich im übertragenen Sinne. In einer Wohnnachbarschaft trägt jeder einzelne Bewohner zur Lebensqualität der Stadt, des Bezirks, des Viertels, der Gegend, der Straße oder des Blocks bei. Genauso trägt jede einzelne App zur User Experience eines Smartphones, eines Tablets, einer Smartwatch usw. bei. Es wird erwartet, dass sich alle an „geltende Regeln“ halten. Regelverletzungen werden in Nachbarschaften meist recht schnell „geregelt“.

Gute Nachbarn halten sich jedoch nicht nur an die Regeln, sondern unterstützen sich gegenseitig über diese Regeln hinaus, um das Leben in der Gemeinschaft zu verbessern. So parken gute Nachbarn mit eigenem Parkplatz auch auf diesem und belegen nicht die wenigen frei zugänglichen Parkplätze, auf die andere Bewohner ohne eigenen Parkplatz angewiesen sind. Diese guten Nachbarn gehen offensichtlich rücksichtsvoll mit der knappen Ressource Parkplätze um.

"Rücksichtsvoller Umang mit knappen Ressourcen"

Ein rücksichtsvoller Umgang mit knappen Ressourcen wird auch in der App Entwicklung wieder wichtiger. Durch den schnellen technologischen Fortschritt wurden wir in der jüngeren Vergangenheit verwöhnt und sind es gewohnt, dass sich ein Speicher- oder Performance-Problem unserer Software oft mit der nächsten Hardware-Generation quasi von selbst löst („Hit it with Hardware!“).

Ressourcenknappheit im zeitlichen Verlauf

Ressourcenknappheit im zeitlichen Verlauf

Die Einführung von Smartphones und anderen mobilen Endgeräten hatte zwar zunächst einen ressourcenschonenderen Umgang gefordert, aber auch hier bringt jede neue Hardware-Generation mehr Ressourcen mit sich. Spätestens jedoch mit der Einführung von Wearables und Kleinstgeräten für das Internet of (Every)Thing(s) müssen wir auf Softwareseite wieder schonender mit knappen Ressourcen umgehen. Zu diesen knappen Ressourcen gehören unter anderem Speicherplatz (Disk Space), Hauptspeicher, Rechenleistung und Akku-Kapazität.

Speicherplatz

Obwohl der Speicherplatz auf Mobilgeräten immer größer wird, reicht er meist dennoch nicht aus. Wir speichern nämlich immer mehr Bilder, Apps, Musik usw. auf unseren Geräten. Apple trägt jüngst seinen Teil dazu bei, die knappe Ressource Speicherplatz besser zu nutzen. So benötigt beispielsweise schon jetzt das Betriebssystem nach manchen Updates sogar deutlich weniger Speicherplatz als zuvor, obwohl oftmals sogar neue Features hinzukommen. Eine solche Verschlankung sollten wir auch berücksichtigen, wenn wir für unsere Apps Updates zur Verfügung stellen.

App Slicing

Um dieses „App Thinning“ zu unterstützen, stellt Apple mit „Slicing“ ab iOS 9 eine neue Funktionalität zur Verfügung. Apps, die für verschiedene Geräte entwickelt wurden (z.B. iPhone 4, iPhone 5, iPhone 6, iPhone 6 Plus, iPad mini, iPad), wurden bisher vollständig auf die unterstützten Geräte übertragen. Zur optimalen Darstellung auf dem jeweiligen Geräte werden hierzu aber mehrere Versionen einer Grafik in unterschiedlichen Auflösungen erstellt. Bisher werden alle Versionen auf jedem Gerät gespeichert. Mit Slicing werden ab iOS 9 automatisch nur noch genau die Versionen übertragen, die vom jeweiligen Gerät benötigt werden.

Um gute Nachbarn zu sein, sollten wir jedoch diesen neu gewonnen Speicherplatz nicht verschwenden, sondern vielmehr darauf achten, wo wir in unseren eigenen Apps noch zusätzlichen Speicherplatz freisetzen können. Reicht vielleicht mal ein stärker komprimiertes JPG aus oder muss es wirklich immer ein PNG sein? Falls es ein PNG sein muss, reichen vielleicht auch mal die 256 Farben eines 8-Bit PNG? Kleine Dateigrößen sind auch gerade für den Austausch zwischen iPhone und Apple Watch hilfreich. Denn wenn wir auf die Uhr sehen, dann wollen wir eins definitiv nicht sehen: Das Lade- bzw. Synchronisations-Symbol. Eine verbesserte Speichernutzung trägt damit auch zu einer besseren Performanz und somit zu einer besseren User Experience bei.

Hauptspeicher und Rechenleistung

Der sorgsame Umgang mit knappen Ressourcen gilt neben dem Speicherplatz ganz genauso für den Umgang mit Hauptspeicher und Rechenleistung (CPU und GPU). Auch hier gilt zunächst, dass die eigene App auf den ersten Blick nichts davon hat, dass sie sorgsam mit diesen Ressourcen umgeht, solange man nicht an die Leistungsgrenze kommt. Dennoch trägt auch die sorgsame Nutzung dieser Ressourcen zur User Experience des Smartphones bei. Benötigt die aktuell (im Vordergrund) benutzte App weitere Ressourcen, so wird beispielsweise diejenige App vom Betriebssystem beendet, die momentan im Hintergrund die meisten Ressourcen benötigt.

Dies beeinträchtigt nicht nur die Ladezeiten für deren nächstes Öffnen sondern ggf. sogar deren Funktionalität, da Hintergrundoperationen nicht mehr durchgeführt werden können. Wir tun somit gut daran, auf die Ressourcennutzung unserer Apps zu achten (so dass wir zumindest nicht die meisten Ressourcen verbrauchen bzw. verschwenden und damit oben auf der Liste stehen). Dies wird mit der Einführung von „echtem“ Multitasking mit iOS 9 auf dem iPad Air 2 noch wichtiger. Wir können dann nicht mehr davon ausgehen, dass unsere App alleine im Vordergrund ist, sondern sie muss sich die Ressourcen ggf. mit einer weiteren App teilen. Der eigenen App stehen dann ein Drittel, die Hälfte oder der ganze Bildschirm zur Verfügung. Apple empfiehlt hier „Nice-to-Have-Funktionalitäten“ zu opfern, wenn die eigene App derzeit nur zur Hälfte oder einem Drittel angezeigt wird. Die Benutzer werden es danken.

Akku-Laufzeit

Der sorgsame Umgang mit Rechenleistung wirkt sich zudem positiv auf die Akkulaufzeit aus. Wir erwarten heute, dass wir unser Smartphone den ganzen Tag lang nutzen können („All-day Battery Life“). Im besten Fall müssen wir es tagsüber nicht aufladen. Dies ist jedoch bei intensiver Nutzung des Geräts leider immer noch nicht möglich. Zwar werden die Akkus immer größer und leistungsfähiger, jedoch müssen wir als Softwareentwickler auch hier unseren Teil dazu beitragen. Mit Bezug auf die Rechenleistung gibt Apple hier die Faustregel an „Schneller = weniger Energieverbrauch“.

Wenn wir somit eine rechenintensive Operation durchführen, so braucht eine „naive“ (Algorithmus-) Variante ohne Optimierung am meisten Energie, gefolgt von einer optimierten Operation. Noch weniger Energie benötigt eine Operation, wenn sie parallel von mehreren CPUs ausgeführt werden kann (Multicore-Optimierung). Optimiert man die Operation dann noch durch OpenCL oder GPU Nutzung, so spart man noch mehr Energie. Dies erscheint zunächst nicht offensichtlich, da eine Operation, die parallel mehrere CPUs und die GPU in Anspruch nimmt, natürlich viel mehr Energie benötigt. Laut Apple kann die Operation aber so viel schneller ausgeführt werden, dass es sich am Ende auszahlt. Es lohnt sich somit nicht, einfach naiv jede Operation so umzusetzen, wie man es schon immer gemacht hat, sondern beispielsweise Bibliotheken zu verwenden, die für Multicore-Nutzung optimiert sind.

Diagramm - Prozessorleistung Algorithmen-Varianten

Schneller = weniger Energieverbrauch. Operationen die bezüglich Multicore, OpenCL und GPU Benutzung optimiert wurden beanspruchen zwar den Prozessor mehr, sind aber deutlich schneller. Operationen mit naiv umgesetzten Algorithmen beanspruchen zwar den Prozessor weniger, durch die lange Rechenzeit wird jedoch am Ende deutlich mehr Akkuleistung verschwendet.

Neben der Multicore-Optimierung habe ich folgende weitere Empfehlungen zur Optimierung der Akkulaufzeit mitgenommen:

  • Nur dann transparente Overlays in Videos verwenden, wenn wirklich nötig, da diese Overlays energiesparende Mechanismen aushebeln.
  • Networking (Bluetooth, WLAN, LTE) minimieren. Muss die App wirklich immer im Hintergrund synchronisiert werden, oder reicht es vielleicht die Synchronisation bei der nächsten Benutzung durchzuführen?
  • Sleep Zustand nicht verzögern.
  • Operationen erst dann durchführen, wenn der Benutzer deren Ergebnis benötigt.
  • GPS Nutzung nicht übertreiben. Man muss auch nicht immer gleich alles in der App aktuell halten. Man kann z.B. auch Minutenlang die Position einfach von der Hardware tracken lassen (M7 Motionprocessor) und aktualisiert die App erst später, z.B. sobald die App wieder in den Vordergrund kommt. d.h. verwendet wird.
  • Operationen dann durchführen, wenn der Benutzer das Gerät gerade aktiv verwendet.

Apple hat zudem iOS 9 hinsichtlich Akkulaufzeit verbessert und verspricht mit iOS 9 auf gleicher Hardware 1 Stunde mehr Akkulaufzeit als mit iOS 8. Hierzu werden beispielsweise folgende Änderungen eingeführt:

  • Liegt das mobile Gerät mit dem Display nach unten (Face Down), wird das Display nicht eingeschaltet, um eine Benachrichtigung anzuzeigen.
  • Die Sleep Timer wurden optimiert. So wird das Display beispielweise schneller wieder ausgeschaltet, wenn der Benutzer schon aktiv mit einer Benachrichtigung interagiert. Ohne Interaktion bleibt das Display länger an, da der Benutzer die Benachrichtigung ggf. noch nicht gesehen hat.
  • Benutzer werden in den Einstellungen informiert, was viel Energie verbraucht und es werden Vorschläge gemacht, wie man den Energieverbrauch verbessern kann.

Außerdem wird mit iOS 9 ein „Low Power Mode“ eingeführt, der bei gleicher Hardware zusätzliche 3 Stunden Akkulaufzeit bringen soll. Aktiviert der Benutzer diesen Mode, so werden beispielsweise keine Background-Downloads durchgeführt und keine E-Mails im Hintergrund abgerufen.

Nicht immer das Letzte rauspressen

Es bleibt natürlich abzuwarten, ob Architekten, Programmierer und Designer gute Nachbarn sein können und (augenscheinlich) uneigennützig ihre Apps bezüglich des Umgangs mit knappen Ressourcen optimieren. Vielleicht pressen sie auch weiterhin alles bis aufs Letzte aus den verfügbaren Ressourcen raus („Nach mir die Sintflut.“). Hiervor möchte ich auf jeden Fall waren. Es geht nämlich nicht nur um die Optimierung der User Experience des Smartphones für den Benutzer. Ein rücksichtsvoller bzw. rücksichtsloser Umgang mit knappen Ressourcen hat ggf. auch einen Einfluss auf das eigene Business. So kann beispielsweise eine App, die wenig Speicherplatz und Akkulaufzeit „frisst“, momentan sogar ein Alleinstellungsmerkmal (USP) sein. Dies gilt insbesondere für Apps, für die es viele Konkurrenz-Apps gibt, die sich nicht wirklich in ihrer Funktionalität unterscheiden (z.B. Wetter-Apps).

Viel wichtiger ist jedoch, dass Benutzer selbst mittlerweile einen viel besseren Überblick haben, welche Apps die Ressourcen ihrer Smartphones verschwenden. In den iPhone Einstellungen unter „Allgemein->Benutzung->Batterienutzung“ bzw. „Allgemein->Benutzung->Speicher verwalten“ werden alle Apps in einer Rangliste aufgeführt.

iPhone Speicher- und Akkunutzung

iPhone Einstellungen: Batterienutzung (Links), Speichernutzung (Mitte), Speicherintensive App löschen (Rechts)

Möchte der Benutzer beispielsweise eine App löschen, die seiner Meinung nach zu viel Speicherplatz benötigt, so kann er die App direkt dort löschen. Dazu werden nur 2 Klicks benötigt. Wer jedoch sorgsam mit den knappen Ressourcen umgeht, hat offensichtlich nichts zu befürchten.

„Bei uns ist alles anders!“

Jeder von Euch war sicherlich schon in einer solchen Situation:

  • Der Chef kommt von einer Konferenz: „Wir führen jetzt DevOps ein!“
  • Ein Kollege kommt von einer UX-Weiterbildung: „Wir sollten ab jetzt Paper Prototyping machen!“
  • Der Product Owner kommt von einem neuen Kunden: „Wir sollten den Kunden ganz eng in die Entwicklung einbinden!“
  • Der CIO kommt von einem Vortrag über Netflix: „Unsere Software muss jetzt bei Amazon Web Services betrieben werden.“

Alle berichten enthusiastisch über ihre neuen Erkenntnisse und die Reaktion der Kollegen ist häufig die gleiche: „Das ist zwar schön, geht aber bei uns nicht, weil:“

"Bei uns ist alles anders"

Auf den ersten Blick erscheint diese Aussage meist plausibel und wird oft öffentlichkeitswirksam mit einem Beispiel unterlegt. Dennoch hält diese Aussage bei genauerem Hinsehen oft nicht stand. Hierfür sind uns bisher hauptsächlich 2 Ursachen begegnet: Subjektiv wahrgenommene, extreme Komplexität oder eine überzogene Erwartung bezüglich der Präzision von Software Engineering (SE) Methoden.

Wahrgenommene Komplexität

Dass wir uns in der eigenen Domäne besonders gut auskennen, ist eine absolute Stärke und notwendig, um tolle Produkte zu bauen: Wir kennen die Kunden (manche davon sogar persönlich), die Konkurrenz, den Markt, wichtige Einflussfaktoren und vor allem die Historie des eigenen Unternehmens.

Das hat aber nicht nur Vorteile: Weil wir für unser eigenes Unternehmen alle Details und (noch so abstrusen) Spezialfälle kennen, erscheint unser eigenes Business als viel komplizierter als das der Konkurrenz. Weil wir deren Details und Spezialfälle eben nicht kennen, tendieren wir eher dazu, sie zu simplifizieren. In unserem eigenen Unternehmen sehen wir oft den Wald vor lauter Bäumen nicht und die Fähigkeit zur Abstraktion bleibt im Tagesgeschäft auf der Strecke. Wir tendieren somit dazu, die Situation im eigenen Unternehmen zu übertreiben und die Situation von anderen Unternehmen zu untertreiben.

Untertreiben der fremden Situation, Übertreiben der eigenen Situation

Die wahrgenommene Komplexität (im eigenen Unternehmen) nimmt noch dadurch zu, dass Unternehmen oft groß sind und das Wissen auf viele Köpfe verteilt ist. Somit ist es dem Einzelnen meist gar nicht möglich, sich eine Übersicht zu verschaffen. Um trotzdem zur notwendigen Abstraktion zu kommen, müssen sehr viele Leute involviert werden. Die dadurch entstehende Prozesskomplexität wird dann als Komplexität des zu lösenden Problems wahrgenommen. Diese Prozesskomplexität nimmt man bei der Konkurrenz nicht wahr und somit erscheint deren zu lösendes Problem einfacher.

Diagramm - Wahrgenommene Komplexität

Wahrgenommene Komplexität in Abhängigkeit zum eigenen Detailwissen

Schauen wir uns als Beispiel die Einführung von DevOps an. Wir haben von vielen Unternehmen gehört, dass es erfolgreich eingeführt wurde. Soll es aber bei uns zum Einsatz kommen, dann fallen uns alle Details ein, die dagegen sprechen: alle zu involvierenden Personen und ihre Eigenheiten, Machtspiele und Veränderungsresistenzen, die Komplexität in Varianten und Releases der eigenen Produkte und Systeme und alle internationalen Unterschiede. Alle diese Details sind uns von den anderen Unternehmen nicht bekannt und führen somit nicht zu wahrgenommener Komplexität.

"Überzogene Erwartung"

(Uns) Informatikern fällt es besonders leicht, Gegenbeispiele zu finden, die belegen, dass eine Neuerung nicht 100%ig angewendet werden kann. Dies gilt meist sogar für eine Anwendung im Allgemeinen aber auf jeden Fall für eine Anwendung im eigenen Unternehmen. Selbst wenn die Neuerung zu 99,9% angewendet werden könnte, so finden wir die 0,1%, in denen es nicht funktioniert. Somit liefern wir den Todesstoß durch Gegenbeispiele:

  • „Herr Müller aus dem Betrieb würde niemals mit uns zusammenarbeiten, daher können wir kein DevOps einführen!“
  • „Bei uns können nicht alle Mitarbeiter zeichnen, somit können wir kein Paper Prototyping einführen!“
  • „Die meisten unsere Kunden wissen eh nicht was sie brauchen, somit können wir sie auch nicht in die Entwicklung mit einbinden!“
  • „Wir hatten auch schon mal Kunden aus dem militärischen Bereich, somit dürfen wir gar keine Daten in der Cloud speichern und schon gar nicht bei einem Unternehmen aus den USA!“

Häufig ist jedoch unser Anspruch an SE-Methoden zu hoch. Statt zu erwarten, dass sie uns in einem überwiegenden Teil der Fälle helfen, erwarten wir 100% Anwendbarkeit und Präzision, am besten anwendbar ohne viel Vorwissen und trotzdem mit tollen Ergebnissen. Sofern dies nicht vollständig gegeben ist, tendieren wir stark zur Ablehnung der Methode. Eine solch ablehnende Haltung wird dann gleich noch generalisiert und die Anwendbarkeit der Methode grundsätzlich in Frage gestellt. Es erscheint plausibel, die 99,9% Verbesserung sicherheitshalber fallen zu lassen, da die Methode nicht 100% funktioniert.

"Software Engineering ist keine exakte Wissenschaft!"

Dabei vergessen wir leider: Software Engineering ist keine exakte Wissenschaft. Vielmehr dient es dazu, den Umgang mit vielen komplexen Einflussfaktoren in der Entwicklung von Software besser beherrschbar zu machen:

  • Mitarbeit von vielen Menschen mit ganz unterschiedlichen Hintergründen und Wissensständen
  • Lösung immer neuer Problemstellungen durch Software. Diese Problemstellungen sind meist nicht klar, ändern sich über die Zeit und werden von verschiedenen Menschen verschieden wahrgenommen
  • Verwendung innovativer Technologien, die häufig nicht in allen Facetten verstanden sind

In einem solch komplexen und heterogenen Umfeld ist es eigentlich klar, dass SE-Methoden nur mit Abstraktionen arbeiten und Approximationen anbieten können. Sie sind selten wirklich formal und erfordern immer ein gewisses Expertenwissen. Im Umkehrschluss ist es dann die Aufgabe der anwendenden Menschen, die Übertragbarkeit oder Nichtübertragbarkeit zu erkennen und im Falle einer Anwendung auch konkret auszugestalten.

In der konkreten Anwendung von SE-Methoden bleibt daher immer der Mensch gefordert: Er hat Gestaltungsspielraum und kann seine Kreativität einbringen. Softwareentwicklung ist keine überaus planbare und vorhersehbare Aktivität, sondern erfordert einen hohen Grad Forschungs- und Planungstätigkeiten (Gedanken dazu in einem Blog-Beitrag von Ralf Westphal).

"Es gibt keine Flileßband-Tätigkeiten im Software Engineering!" (Foto: Pradit.Ph / Shutterstock.com, http://www.shutterstock.com/gallery-2909461p1.html?cr=00&pl=edit-00)

Tätigkeiten mit extrem hoher Wiederholbarkeit (wie zum Beispiel Montage am Fließband) gibt es bei der Softwareentwicklung fast nicht, insbesondere weil Software, einmal erschaffen, beliebig ohne Aufwand vervielfältigt werden kann. Für alle wiederkehrenden Aufgaben entstehen Tools zur Automatisierung, wie zum Beispiel für die Testautomatisierung oder für Continuous Delivery. Zu großen Teilen  ist Softwareentwicklung aber weniger formal und planbar und fordert mehr den Menschen. Wäre dies nicht so, dann wäre Softwareentwicklung mittlerweile vollständig automatisiert und nicht mehr auf Menschen angewiesen. Obwohl das offensichtlich ist, haben dennoch viele den Wunsch nach einer Supermethode, die perfekt auf jeden Kontext passt, völlig reproduzierbar ist (und im Falle der Existenz direkt alle Jobs kosten würde).

Das alles soll natürlich nicht heißen, dass SE-Methoden nicht noch weitaus besser werden können und müssen. Mary Shaw zeigt sehr gut auf, wie sich Software Engineering gegenwärtig gegenüber anderen Ingenieursdisziplinen positioniert und welches Verbesserungspotential noch besteht. Die (angewandte) Forschung hat also noch viel zu tun!

In diesem Wissen über SE-Methoden müssen alle Beteiligten handeln: nicht vorschnell Methoden und Ideen ablehnen. Bevor wir sagen „bei uns ist alles anders“ sollten wir darüber nachdenken, wo Abstraktion und Approximation am Werk sind. Die Kunst ist es also gerade nicht, durch ein Gegenbeispiel eine neue Idee auszuhebeln, sondern umfassend zu beurteilen, ob in der Summe eine SE-Methode wirtschaftlich und erfolgreich einsetzbar ist. Das Ergebnis einer Beurteilung ist oft nicht offensichtlich, wer jedoch zu einem Ergebnis kommen kann ist offensichtlich ein Experte.

Betroffenheit und Business Artists (BITKOM UUX)

Brandenburger Tor, angestraht mit Herzen und  "We love Berlin"  beim Festival of Light

Ich komme gerade vom BITKOM UUX Fachgruppentreffen in Berlin und warte am Flughafen Tegel auf meinen Rückflug. Die Teilnahme hat sich voll und ganz gelohnt. Zum angekündigten Streitgespräch kam es jedoch nicht. Im Großen und Ganzen waren sich die Teilnehmer einig, obwohl sehr viel und auch sehr emotional diskutiert wurde. Deutlich mehr als bei ähnlichen Veranstaltungen, vor allem sobald das Thema Scrum oder Design Thinking angesprochen wurde.

"Betroffenheit hervorrufen!"

Es wurden zwar unterschiedlichste Themen rund um das Thema Usability und User Experience diskutiert, in jedem Vortrag oder der zugehörigen Diskussion wurde jedoch auf die eine oder andere Art über die Evaluation von Usability und UX gesprochen: Wann sollte man mit welcher Methode und wie oft evaluieren? Ulf Schubert (DATEV) hat hierzu etwas Interessantes erzählt. Bei der DATEV muss das gesamte Entwicklungsteam während einer Usability Evaluation anwesend sein. Es sind somit nicht nur die Qualitätssicherungs- und Usability Experten anwesend, sondern alle an der Entwicklung beteiligten Personen. Das Team kann die Testnutzer durch eine Scheibe im Usability Labor beobachten. So bekommt jeder im Team direkt mit, sobald ein Testnutzer ein Problem mit der Benutzung hat. Kommt ein Testnutzer in größere Schwierigkeiten bei der Benutzung, so löst das beim anwesenden Projektteam Betroffenheit aus. Genau das ist das Ziel von Ulf Schubert: „Im Projektteam soll Betroffenheit hervorgerufen werden.“ Ich habe auch schon die Erfahrung gemacht, dass man deutlich besseres Verständnis im Projektteam erreicht, wenn man Videos von Problemen während der Nutzung von Testnutzern zeigt und nicht nur die Anzahl von Problemen in einer Tabelle listet. Zwar hört sich „18 von 20 Nutzern haben das Produkt nicht auf die intendierte Art und Weise gestartet“ auch nicht gerade gut an, zeigt man aber einen Video-Zusammenschnitt dieser 18 (oder 20) Starts, so stellt sich Betroffenheit und anschließend Verständnis im Projektteam viel schneller und eindringlicher ein. Nach Aussage von Ulf Schubert, funktioniert es aber noch besser, wenn das Projektteam live beim Test mit anwesend ist. Das Projektteam hat auch immer Whiteboards zur Verfügung, um direkt Verbesserungsvorschläge zu diskutieren. Natürlich nur untereinander und nicht mit den Testnutzern. Weitere Tipps von Ulf Schubert gibt es in seinem User Experience Blog. Er hat auch zwei Beträge zum Fachgruppentreffen verfasst (Vormittag, Nachmittag).

"UX Testing - Quo Vadis?"

Eine weitere Interessante Frage, die diskutiert wurde ist: Wer führt zukünftig eigentlich UX Tests durch? Momentan liegt diese Kompetenz hautsächlich bei Beratungshäusern und Usability/UX Agenturen. Derzeit bauen aber immer mehr Design Agenturen diese Kompetenz auf und bieten auch UX Tests an. Hinzu kommt, dass immer mehr Unternehmen eigene UX Test-Kompetenz aufbauen, um die Evaluation selbst durchführen zu können. Immer öfter werden UX Test sogar im unternehmenseigenen UX Labor durchgeführt. Wohin sich das entwickelt, werden wir in den nächsten Jahren feststellen. Es bleibt also spannend.

"Die Erotik-Branche schiebt neue Technologien an."

Mit seinem Vortrag „Do you understand me? Supernatural and innovative interactions“ eröffnete Sascha Wolter (Deutsche Telekom) das Fachgruppentreffen fulminant. Wer die Gelegenheit hat, sollte sich unbedingt einmal eine Präsentation von Sascha Wolter ansehen (hier stehen seine Vortragstermine). Voller Energie und Enthusiasmus berichtete er vom Internet of Things (IoT). Interessant fand ich seine Aussage „Die Erotik-Branche schiebt neue Technologien an.“ Das galt für die das Internet, die DVD, HD-Video, usw. „Als nächstes ist wohl das IoT dran. Es ist unglaublich, was es da schon alles gibt.“

Wenn es um neue Interaktionsmöglichkeiten geht, es ist es wichtig, dass man nicht nur darüber redet, sondern diese unbedingt persönlich ausprobiert. Nur dann kann man wirklich auch wirklich darüber reden. Entwickelt man selbst gerade eine neue Interaktionsform, dann sollte man diese unbedingt prototypisch umsetzen und ausprobieren. Das gilt nicht nur für die Software, sondern auch für die zugehörige Hardware. Es muss ja nicht immer gleich perfekt sein. 3D Drucker, Bausätze und ähnliche Hilfsmittel unterstützen uns heute immer mehr dabei. Sascha Wolter ist ein großer Fan vom Ausprobieren und hat z.B. auch das Autofahren mit einer Blackbox seiner Versicherung getestet, die guten Autofahrern bessere Tarife verspricht: „Ich probiere das alles mal aus und sehe mir an, wozu das führt und erziehe meine Kinder zu einem bewussten Umgang mit Daten.“

Besonders wenn es um das IoT geht bedauert Sascha Wolter, dass die Systeme immer noch zu wenig Empathie besitzen. Wir können heute jede Lampe in jedem Raum unserer Wohnung oder unseres Hauses dazu bringen, genau das richtige Farbschema zu erzeugen, das am besten zu unserer momentanen Gemütslage passt. Allerdings müssen wir dieses Farbschema noch selbst auswählen. Die Systeme können unsere Gemütslage momentan noch nicht ausreichend gut erkennen. Die notwendige Technologie ist hierzu wahrscheinlich sogar schon vorhanden. So gibt es beispielsweise in Japan Getränkeautomaten, die mit einfachen Sensoren die Gemütslage den Käufers (vorgeben zu) erkennen und ein passendes Getränk auswählen.

"Business Artists"

Am Nachmittag hat Dirk Dobiéy (SAP) mit „Learning from creative disciplines for better outcomes in business and society“ eine weitere beeindruckende Präsentation gehalten. „Es wird immer mehr automatisiert, nicht nur der Börsenhandel, sondern sogar die Berichte über den Börsenhandel. Immer mehr Wissensarbeiter werden automatisiert. Welche Eigenschaften müssen wir denn überhaupt zukünftig haben?“ Dirk Dobiéy und seine Kollegen von Age of Artist glauben, dass solche Eigenschaften in künstlerischen Bereichen gefunden werden können und haben mit Künstlern aus unterschiedlichsten Bereichen gesprochen. Dabei haben sie versucht herauszufinden, was Künstler ausmacht, was sie antreibt und ob es gemeinsame Eigenschaften gibt. Diese Eigenschaften werden dann immer in Bezug oder besser in Kontrast zum momentanen Business-Alltag gesetzt. Um wieder das Beispiel der Evaluation aufzugreifen, ist ihnen beispielsweise aufgefallen, dass in der Geschäftswelt leider immer noch oft gesagt wird „Das gefällt mir nicht!“ oder „Ich würde das nicht so machen!“. Künstler sprechen in einer Evaluation subjektiver und emotionaler „Ich sehe hier…“ oder „Ich fühle dabei…“. Dirk Dobiéy gibt folgende Eigenschaften von Künstlern an, die sie von Geschäftsleuten unterscheiden:

  • Planning by Doing. Making to Learn.
  • Exploration without Intention.
  • Substantial Amounts of Search and Reflection.
  • Accepting Ambiguity and Crisis.
  • Appreciating Feeling and Emotions.
  • Everything is a Derivative: Finding again the New.
  • Non-Linear.

Zudem gibt Dirk Dobiéy folgende Eigenschaften an, die wir entwickeln müssen, um „Business Artists“ zu sein:

  • Observation & Listening
  • Dialogue & Conversation
  • Exploring & Deconstructing
  • Abstracting & Simplification
  • Generating Ideas & Experimenting
  • Problem Solving
  • Collaboration & Cooperating
  • Giving Feedback & Dealing with Critique
  • Reframing & Improvising
  • Designing & Performing

Knowledge-Worker benötigen schon heute aber vor allem in der Zukunft andere Fähigkeiten, vor allem Soft Skills. Es reicht zudem nicht aus, nur einen gut ausgeprägten Soft Skill zu haben, sondern wir werden immer mehr beherrschen müssen. Ob es genau diese Skills sind, die im Vortrag angesprochen wurden ist dabei gar nicht so wichtig. Der vorgestellte Ansatz, bei Künstlern nach solche Eigenschaften zu suchen, ist jedoch sehr spannend.

Ich freue mich schon auf das nächste UUX Fachgruppentreffen, das wohl noch dieses Jahr stattfinden wird.

ältere Beiträge

© 2017 mibinu

Theme von Anders NorenNach oben ↑