Jul
21
2009

Praxis, Mimikry, Identität, Selbstaktivierung – Elemente eines Design-Frameworks für Social Software

[I]n order to create social software, a designer has to address in one way or the other all issues of enabling practice,  mimicking  reality,  building  identity  and  actualizing  self.

Mitarbeiter an der Universität von Amsterdam haben sich bereits im Jahr 2007 den Erfordernissen von Design für Social Software in einer Weise gewidmet, die mir sehr gefällt. Mit dem thematischen Hintergrund der Autoren wurde ich während meiner Ausbildung in der Wissenschafts- und Technikforschung vertraut. Dieser Hintergrund lässt sich kurz und prägnant auf den Nenner Wissensarbeit als Alltagspraxis bringen, worüber ich auch schon einmal ein Paper verfasst habe.

Die Autoren stellen neben des Aspekten Nachahmung, Identitätsbildung und Selbstaktivierung die Praxis, in diesem Fall die Aktivitäten der User als Gruppe, in den Vordergrund und möchte daraus Folgerungen für das Design von Social Software ableiten. Vielleicht verfängt sich ja etwas bei jenen von euch, die sich mit Software-Design beschäftigen. Aber auch diejenigen, die Web 2.0 zu produktiven Zwecken (z.B. in einem Unternehmen) einführen möchten, sollten hier mal genau reinschauen:

Bouman, W., Hoogenboom, T., Jansen, R., Schoondorp, M., Bruin, B. de, Huizing, A. (2007), ‘The Realm of Sociality: Notes on the Design of Social Software’, Conference Proceedings 28th Annual International Conference on Information Systems (ICIS), Montreal, Canada.

Die Autoren haben auf dieser Konferenz den ICIS 2007 Best Paper Award gewonnen. Man kann es auch hier herunterladen: http://sprouts.aisnet.org/8-1

Sozialität kann nicht designed werden, sondern nur für Sozialität

Was ist Sozialität im Kontext von Social Software? Bouman et al. gehen davon aus, dass Sozialität in vier verschiedenen Formen in Erscheinung tritt (vgl. Tab. 1):

  • Netzwerk-zentrierte Sozialität
  • Gemeinschaft-zentrierte Sozialität
  • Objekt-zentrierte Sozialität
  • System-zentrierte Sozialität

Zwischenablage03

Zwischen diesen vier Weisen von Sozialität gibt es gewisse Dynamiken. Aus einem Netzwerk, in welchem Menschen mit unterschiedlichen Rollen in einer bestimmten Weise aufeinander bezogen sind (z.B. als Mitarbeiter in einem Unternehmen), bilden sich für gewöhnlich auch Gemeinschaften (Communities). D.h. das Netzwerk offizieller Arbeitsbeziehungen wird angereichert durch Beziehungen anderer Art (Freundschaft, Vertrauen, etc.).

Gerade in Bezug auf Produktentwicklung und Innovationen bilden sich Netzwerke allerdings nicht nur zwischen Personen, die durch offizielle Aufgaben miteinander verbunden sind. Sie bilden sich vielmehr durch Objekte. Das kann z.B. ein zu entwickelndes Produkt sein.

Solche Objekte binden wiederum Personen aneinander, formieren neue Beziehungen etc. Es entsteht ein System aus Objekten und Personen, Beziehungen zwischen Objekten, zwischen Personen und Objekten und Personen untereinander.

Ein anschauliches Beispiel ist das Musikportal Last.fm. Darin kann man Musik hören, sich eigene Playlisten zusammenstellen (Person-Objekt), die andere einsehen können (Person-Objekt-Person); man kann die Musik-Empfehlungen anderer lesen (ebenfalls Person-Objekt-Person), Freundschaften mit anderen schließen (Person-Person), Diskussionen über Musikstücke oder über Musiker führen (Person-Objekt-Person), etc. [meine eigene Playlist ;-) ]

Eine solche System-zentrierte Sozialität bildet nun ein sehr komplexes Netzwerk. Und sie ist diejenige, auf welche Social Software (also z.B. das Musikportal Last.fm) fokussiert ist.

Ein Design-Framework

Die Autoren stellen nun in Bezug auf das Design von Social Software die folgende Hypothese auf:

We hypothesize that, in order to create social software, a designer has to address in one way or the other all issues of enabling practice,  mimicking  reality,  building  identity  and  actualizing  self.

Praxis ermöglichen, nachgeahmte Realität, Identitätsbildung und Selbstaktivierung sind also die Schlüssel für ein adäquates Design. Um auf diese Phänomene zu kommen, greifen die Autoren tief in die Theorienkiste von Management-, Sozial- und Kommunikationswissenschaftlern des 20. Jahrhunderts. Das soll hier erst einmal ausgespart bleiben.

Wichtig ist ihnen jedenfalls, dass eine Social Software diese vier Möglichkeiten des sozialen Daseins im Web bieten muss:

  • Praxis ermöglichen: Passives Rezipieren wie am Fernseher oder Radio gibt es am Computer nicht. Mit Blick auf Social Software sollte der Designer darauf achten, dass er einer sozialen Gruppe die Möglichkeit gibt, im Sinne der Gruppe aktiv zu sein. Er muss sich fragen, wie eine potentiell existierende Gruppe interagieren würde. Dies betrifft nicht nur die Produktion von User-Content, sondern im Idealfall auch die strukturelle Basis der virtuellen Umgebung; die Nutzer sollten auch auf diese Einfluss nehmen können.
  • Realität nachahmen: Die Teilnahme sollte auf ähnliche oder gleiche Weise geschehen, wie wir auch in der Realität agieren: “people  actually  are more  inclined  to  use software  systems  that  resemble  their  daily  routines,  language  and  practices  than  to  adopt  whole  new concepts, interfaces and methods”. Hier schlagen die Autoren die Nutzung von Metaphern vor (später mehr dazu).
  • Identitätsbildung: “A large part of this realm is concerned with the ability to show others a desired  picture  of  self,  a  version  of  one-self  that  is  goal-relevant.” Es ist also drauf zu achten, dass die Aktionen des Users eine Spur hinterlassen, die ihm eine Identität verleiht.
  • Selbstaktivierung: Hiermit sind Mechanismen gemeint, die zur Selbstentwicklung beitragen – dass die Nutzung also in einen individuellen Vorteil resultiert. Lernen wäre ein solcher Vorteil (Wikipedia, last.fm), aber auch Kontakte knüpfen (Xing, Dating-Seiten).

Diese vier, für Social Software notwendige Eigenschaften, lassen sich spezifizieren. Bouman et al. tun dies, indem sie das notwendige Design von Social Software beurteilen mit Blick auf

  • Kriterien, die erfüllt sein müssen,
  • Prinzipien, denen die Software folgen muss,
  • Parametern, mit denen die Erfordernisse verwirklicht werden können,
  • Dilemmata, mit denen sich die Software-Designer auseinander setzen müssen.

Zwischenablage02

In einer Kreuztabelle (vgl. Tab. 2) ergeben sich nun allerlei Informationen, die ich nicht im Einzelnen erörtern brauche. Die Autoren tun dies auf den Seiten 15-17 ihres Papers recht anschaulich.

Aber zu einigen Feldern möchte ich gerne einige Stichpunkte anführen:

ENABLING PRACTICE

  • Economic Criteria: gute Usability und effektive Kommunikationsstandards
  • Parameter (Practice): Räume zum Austausch, eigene Beiträge ermöglichen, Erlebnischaracter herstellen
  • Dilemma: Hindernisse beim Implementieren von neuen virtuellen Austauschpraktiken (all die Probleme bei der Einführung von Web 2.0)

MIMICKING REALITY

  • Empirical Criteria: Suche nach Modellen in der realen Welt
  • Parameter (Metaphor): aus diesen Erfahrungen gut funktionierende, interessante Metaphern bilden, die sich in Social Software umsetzen lassen (z.B. Bewertungssysteme auf Amazon, Genre-Radio auf last.fm)
  • Dilemma: Bezug zwischen realer und virtueller Welt kann verloren gehen

BUILDING IDENTITY

  • Social Criteria: Vertrauen, Verbundenheit, Identifikationsmöglichkeiten und Aktivitätspfade
  • Parameter (Presentation): Profilierung ermöglichen; Austauschbeziehungen ermöglichen, die  auf Personenaktivitäten zurückschließen lassen
  • Dilemma: Verhindern, dass in diesem Bereich Wildwuchs entsteht (’Trolle’ kontrollieren, ‘Overorganizer’ bremsen, etc.)

ACTUALIZING SELF

  • Individual Criteria: Gewinn an Wissen und Kreativität, ästhetische Befriedigung, soziale Kontakte (z.B. Liebe, Zuneigung, Bewunderung)
  • Parameter (Feedback): Das Lehrreiche am Feedback, an Bewertungen und Einschätzungen anderer sollte in den Vordergrund treten können
  • Dilemma: Anschlussfähigkeit muss gewährleistet sei, d.h. die Feedbackschleife sollte vom Inhalt her interessant sein, Betroffenheit auslösen, etc., sonst wirkt sie nicht

Designer von Social Software sollten sich mit all diesen Bereichen beschäftigen, weil sie alle in irgend einer Form (sozial-) funktional sind. Allerdings gibt es hierbei erhebliche Unterschiede in der Fokussierung. Im Vergleich zwischen LinkedIn (englischsprachiges Pendant zu Xing) und Frienster etwa stellen die Autoren in Bezug auf Identitätsbildung sowie Selbstaktualisierung unterschiedliche Akzente fest:

Frienster zielt eher exklusiv auf Identitätsbildung, ohne dass ein konkretes Ziel ausschlaggebend ist, während bei LinkedIn der individuelle Mehrwert im Zentrum steht. Sich auf der Webseite ein Profil geben zu können scheint hierbei die Lösung zu sein, die LinkedIn mit entsprechener Mimikry Business-Welt nachbildet (Prinzip: Visitenkarte, berufl. Werdegang, etc.). Entsprechend sind z.B. Fakes hier nicht zu tolerieren, wohin gegen sie in Friendster (Profilierung erfolgt im Kommunikationsvollzug) einen nicht unerheblichen Teil der Mitglieder ausmachen – und dem Funktionieren der Seite dabei nicht abträglich sind.

Aber auch die Praxis ist sehr unterschiedlich. Wo bei LinkedIn  die Konnektivität in einem wertvollen Netzwerk eher statisch hergestellt werden kann, spielt bei Frienster die dynamische Interaktion eine größere Rolle. LinkedIn akzentuiert also eher ein Sein, während Frienster eher das konkrete Tun fokussiert.

Aufgrund all dieser Unterschiede ergeben sich schließlich Differenzen in den Designs der beiden Portale – bei Frienster mehr dynamische, auf Kommunikation zielende Werkzeuge, bei LinkedIn mehr Möglichkeiten der formalen Präsentation, des Profilierens und des Schaffens von Vertrauen.

Diskussion: Design für Web 2.0 Systeme kommt nicht ohne sozialwissenschaftliche Expertise aus

Bisher habe ich noch kein Papier gelesen, das derart dezidiert den soziotechnischen Diskurs der letzten 30 Jahre in die Diskussion rund um Web 2.0 einwebt. Dabei kratzen die Autoren der Universität Amsterdam bisher allerdings lediglich an der Oberfläche. Es ließen sich viele Fragen an diese Thematik anschließen – etwa inwiefern die vier Domänen in Beziehung zueinander stehen, inwiefern sie sich je nach Social-Platform unterschiedlich ausbalancieren, ob sie in jedem Fall alle vier eine Rolle spielen, inwiefern sich dies ändert, wenn wir von organisationsinternen Plattformen reden. Oder aus einer mehr sozio-theoretischen Sichtweise: ob diese vier Domänen die einzigen sind, oder ob es gar zu viele sind, die Autoren mithin zu ekletizistisch argumentieren (z.B. lässt sich aus Sicht von Rational-Choice-Theoretikern die Domäne Identitätsbildung weitgehend in die Domäne Selbstaktivierung integrieren).

Diese Fragen lassen die Autoren bisher noch offen. Sie wünschen sich jedenfalls etwas mehr Demut beim Designen von Social Software:

In the end, it is not social software as such that determines its social-ness, but people choosing freely to use this software to engage in social relationships. [...]

Designers may think that they can design the mechanisms that make social software social, yet from our research we learn that they can only aim to create triggers activating mechanisms, which encourage people to explore their social environment and seek or enjoy companionship.

Ich finde, dass sie durchaus recht haben. Aus sozialwissenschaftlicher und psychologischer Sicht werden beim Software-Design bisher lediglich Usability-Konzepte systematisch behandelt – also etwa an Ausbildungsstätten gelehrt oder dazu geforscht. Dies ist in der Matrix (Tab. 2) aber nur ein Feld unter vielen anderen. Die anderen Felder sind bisher noch immer relativ unangetastet (bedenkt: das Papier wurde bereits im Jahre 2007 vorgestellt). Vereinzelt gibt es erste Ansätze zum Design für Sozialität, so z.B. Böhringer/Richter/Koch mit Blick auf Awareness.

Genauso selbstverständlich, wie angehende Städtebau-Architekten das Studienfach Stadtsoziologie belegen müssen, sollte zukünftig auch im Curriculum für die Ausbildung von Software-Designern die Thematik der Sozialität seinen Platz finden. Im Grunde lässt sich diese als eine riesige, sehr interessante Spielwiese für Interdisziplinarität auffassen.

Obwohl in dem Paper von Bouman et al. noch viele Fragen offen bleiben, kann Tabelle 2 durchaus als eine Matrix dienen zur Kreation von Portalen und zur Umsetzung von Maßnahmen rund um Enterprise 2.0 und Collaboration. Ich könnte mir vorstellen, dass sie den Hintergrund einer Blaupause darstellt, dass man, bevor man die konkrete Umsetzung plant, zunächst Sinn und Zweck der Collaboration herausarbeitet und dann die entsprechenden Trigger aus der Tabelle heraus liest bzw. sich um die jeweiligen Dilemmata Gedanken macht, bevor man mit dem Designen beginnt.

Da es uns vor allen Dingen um den Einsatz in Unternehmen und Organisationen geht, möchte ich Folgendes noch nachschieben: Alleine durch Software, sei sie auch noch so ausgeklügelt, wird Collaboration nicht gelingen. Zwar sind die hier vorgestellten Trigger sehr hilfreich. Sie sind womöglich sogar die Voraussetzung für erfolgreiche Collaboration. Dennoch sind so gut wie immer auch weitere Management-Maßnahmen erforderlich, um den Erfolg sicher zu stellen.

Powered by WordPress. Theme: TheBuckmaker. Viverto Suchmaschine, selber bauen