Zum Inhalt springen

Artikel aus der Kategorie ‘Projekt’

10. Aug 2011

Artikelbild

Use Cases Teil 1: Nutzerziele und fliegende Fische

Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf:

  1. Differenzierung zwischen Nutzerziel und Unterfunktion.
  2. Wie beschreibe ich ein Nutzerziel (Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem).

Der Begriff Use Case lässt sich im Deutschen am besten mit Anwendungsfall übersetzen. Hier passt die wortgetreue Übersetzung sogar ganz gut. Ein Use Case beschreibt, wie ein Nutzer (Aktor) mit einem System in Interaktion tritt, um ein bestimmtes Ziel zu erreichen. Wenn ich hier vom Erreichen eines Ziels spreche, so steckt dahinter zweifelsohne eine Intention. Und die können nur Menschen bzw. Gruppen von Menschen haben. Genau genommen können Use Cases aber auch die Interaktion zwischen verschiedenen Systemen beschreiben. Diese spezielle Form von Use Cases möchte ich hier nicht diskutieren. Mir geht es an dieser Stelle ausschließlich um die Use Cases, die beschreiben, wie ein menschlicher User mit einem System interagiert, um ein fachliches Ziel zu erreichen. Warum ich das fachliche Ziel hervorhebe, lege ich später dar. Weiterlesen

9. Aug 2011

Artikelbild

Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem

Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist (Use Cases Teil 1: Nutzerziele und fliegende Fische). Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten.

Da uns dies (hoffentlich) nicht mehr vorkommt, stellt sich nun die Frage, wie man denn Nutzerziele am besten formuliert. Wie ich schon schrieb, werden da häufig Fehler gemacht. Im Folgenden möchte ich ein paar Tipps geben, wie man diese umgeht.

Lösungs-fixiert?

Weiterlesen

3. Apr 2011

Philippe Back spricht mit Bernd Lohmeyer: Nutzen zentrierter Beratungsansatz und Usability

Philippe Back hat mit mir ein Interview über meinen Nutzen zentrierten Beratungsansatz geführt. In dem Gespräch versuche ich darzustellen, wie ich Unternehmen durch die Kombination von Geschäftsprozessanalyse und Usability helfe, ihre Kundenbindung und die Produktivität ihrer Mitarbeiter zu steigern. Dadurch lassen sich enorme Optimierungspotenziale hinsichtlich des Return On Investment (ROI) entwickeln und ausschöpfen.

Ein paar Stichpunkte:

  • Konzentriere Dich zuerst auf die wirklichen Geschäftsanforderungen.
  • Finde dafür Lösungen, die die Anforderungen erfüllen und einfach zu bedienen sind.
  • Stelle mit Usability Tests sicher, dass das Design wirklich einfach zu bedienen ist.

Weiterlesen

25. Mrz 2011

Korrigierte Projektplanung: Das Qualitätsziel wird reduziert.
2 Comments

Das Eiserne Dreieck: Ignorieren auf eigene Gefahr

In einem kurzen Video spricht Philippe Back über die drei Aspekte im Projektgeschäft. Das Video ist in Englisch. Ich möchte den Beitrag allen Projektmanagern wärmstens empfehlen. Wenn es im Projekt schief geht, ist das Eiserne Dreieck vermutlich missachtet worden. Ich möchte Philippes Vortrag kurz zusammenfassen.

Die drei Ecken (Aspekte) sind:

  • Scope (also das, was vom Projekt geleistet werden soll)
  • Qualität
  • Zeit

Weiterlesen

22. Nov 2010

Ein weiteres Missverständnis: Usability Tests sind teuer

In einem vorigen Artikel schrieb ich schon über verschiedene Usability-Missverständnisse (Usability – Schluss jetzt mit den Missverständnissen!). Ich möchte die Sammlung noch ein wenig erweitern.

Gerne werden an allen Ecken und Enden Kosten gespart. Und da wird gerne auf Usability Tests verzichtet: “Das hat ja schließlich ein guter Designer entworfen…” Nun, auch Designer sind nur Menschen und können Fehler machen. Die sollte man schon aus Gründen des Investitionsschutzes frühestmöglich aufdecken. Und dazu sind eben Usability Tests da. Doch nun zu den Kosten. Denkt man an solche Tests, fallen häufig Stichwörter wie Usability Labor, Eye Tracking, Erhebungskampagnen, statistische Validierung etc. Ja, das kann alles dazu gehören – muss es aber nicht. Die Buchung und Beauftragung eines professionellen Usability-Labors ist kostenaufwendig. Aber selbst das lohnt sich in den meisten Fällen. Ich möchte hier aber zwei sehr einfache Testmethoden vorstellen, die mit wenig Aufwand durchzuführen sind und dennoch wertvolle Erkenntnisse liefern.

Papierprototypen-Test

Wie zuvor schon kurz erwähnt braucht man für diesen Test noch nicht mal lauffähigen Sourcecode. Es reichen Papierskizzen, die man aus dem Entwurfsprozess (frühe Konzeptionsphase) extrahiert. Diese Skizzen (Mockups) fallen da ja eh an, da man anhand dieser die Benutzerinteraktion durchdenkt und visualisiert. Nun überlegt man, welche Szenarien man mit welchen Nutzern überprüfen möchte. Man wählt die entsprechenden User Interface-Skizzen aus und lädt die Testteilnehmer ein. Eine Auswahl von fünf bis sechs Testteilnehmern sollte reichen. Mehr Teilnehmer erhöhen den Erkenntnisgewinn in der Regel nicht. Und statistisch belastbare Aussagen wird man auch mit 20 Teilnehmern nicht erreichen. Darum geht es aber auch gar nicht. Und wer keine sechs Teilnehmer “loseisen” kann, beschränkt sich eben auf zwei. Lieber einen kleinen Test machen als gar keinen!

Weiterlesen

25. Okt 2010

Ohne UML in die Word-Falle

Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unverzichtbar – gehen aber verloren.

Das andere Extrem

Doch es gibt auch das andere Extrem: den Versuch einer kompletten Fachspezifikationen in einem einzigen Dokument. Und das auch noch ohne grafische Übersichten.

Weiterlesen

20. Aug 2010

1 Kommentar

Usability – Schluss jetzt mit den Missverständnissen!

Der folgende Artikel ist in einem internen Newsletter meines Arbeitgebers Steria Mummert Consulting erschienen. Er wendet sich an Berater und Projektmanager, die in der Regel keine Usability Professionals sind. Dennoch könnte der Artikel auch hier den ein oder anderen interessierten Leser finden. Zusätzlich habe ich einige Links zu anderen Artikeln eingefügt.

Begrifflichkeit: Usability ist ein Kunstwort (use + ability) und beschreibt die Gebrauchstauglichkeit eines Gegenstandes oder einer Software. Usability ist heute kein Luxus mehr sondern eine unumgängliche Voraussetzung für den wirtschaftlichen Erfolg. Leider wird der Begriff von zu vielen als leere Hülse verwendet – mehr als Buzz Word denn als Prio-1-Projektziel. Unter dem Begriff der Usability werden heute auch alle Aktivitäten zusammengefasst, die geeignet sind, eben diese Usability zu erreichen. Begegnen Ihnen Schlagwörter wie User Experience Design, User Interaction Design, User Interface Design, Usability Testing, User Centered Design usw., so hat das alles mit Usability zu tun.

Was kann man um das Thema Usability alles falsch machen? Leider mehr als ich hier aufzeigen kann. Ich möchte im Folgenden nicht auf die Dos and Don’ts des Screen Designs eingehen. Die Liste wäre extrem lang. Jenseits schräger Maskengestaltung und wirren Dialogsalats sehe ich ein gravierendes Problem darin, dass sich um das Thema Usability viele Missverständnisse ranken. Einige möchte ich aufdecken. Vielleicht erreichen wir so eine größere Bereitschaft, in dieses Thema zu investieren und so bessere Software anbieten zu können. Weiterlesen

7. Jun 2010

Das User Interaction-Masterdocument

Ist es Euch auch schon mal passiert: Da wird eine Änderung einer bestimmten Funktionalität diskutiert, Ihr habt ein mulmiges Gefühl dabei. Irgendetwas ist faul. Ihr wisst genau, wenn ich dem jetzt zustimme, hat das Auswirkungen auf einige Storyboards…

Warum? Weil eine Funktionalität diskutiert wird, die ein oder mehrere User Interaction Patterns betreffen, die Ihr im längeren Projektverlauf mühsam entwickelt und abgestimmt habt. Und jetzt soll diese Änderung vorgenommen werden!

Was bedeutet das denn nun wirklich? Wäre es da nicht schön, wenn man eine zentrale Stelle im Projekt hätte, die darüber Auskunft geben könnte. Tja, genau diese Stelle sind wir als verantwortliche User Interaction Designer normalerweise. Doch, Hand auf’s Herz. In einem Projekt, das seit einem Jahr läuft kann man sich nicht mehr an jeden Entscheid erinnern, der irgendwann getroffen worden ist. Jetzt könnte man einen Stapel von Protokollen durchsehen – oder den Styleguide befragen. Das erste ist zu langwierig, das zweite ist zu allgemein. Man könnte auch alle Storyboards durchsehen. Da steht ja drin, wie User Interaction laufen soll (siehe hierzu Storyboards: Eine Erfolgsgeschichte). Doch dazu fehlt die Zeit.  Also: keine Antwort, nur ein schlechtes Bauchgefühl.

Beispiel eines User Interaction-Grundsatzes

Weiterlesen

4. Mai 2010

4 Comments

Management in der UML-Falle

Der Titel ist provokant. Das ist mir bewusst. Ich möchte zeigen, dass der unreflektierte Glaube in UML-Modelle zu einem echten Problem im Projekt führen kann. Und das droht besonders bei einem zeitlich engen Projektplan. Also genau dann, wenn man geneigt ist, es bei UML-Diagrammen zu belassen.

Der Werkzeugkasten UML

Die Unified Modelling Language –kurz UML- ist an sich gar nicht schlecht. Ganz im Gegenteil. Sie fasst verschiedene grafische Werkzeuge und Notationen für die Spezifikation von Software zusammen. Dazu gehören sehr unterschiedliche Diagrammtypen wie beispielsweise Aktivitäts- und Sequenzdiagramme zur grafischen Darstellung von Abläufen oder unterschiedliche Klassenmodelle zur Zerlegung der realen Welt in handhabbare Objekte. Und wie das bei Modellen eben so ist, haben sie Vor- und Nachteile. Einerseits machen sie die schier unvorstellbare Komplexität der echten Welt fassbar, andererseits laufen sie aber auch Gefahr, die Realität zu sehr zu vereinfachen oder zu oberflächlich zu betrachten. Wie hilfreich ein Modell wirklich ist, hängt letztlich von dem Modellierer ab – und der Fähigkeit des Empfängers, es richtig zu lesen und zu interpretieren.

Die UML definiert einen sehr guten Werkzeugkasten. Leider ist aber eine gut eingerichtete Tischlerwerkstatt kein Garant dafür, dass dort auch gute Möbel entstehen. UML verhindert eben nicht, dass man einen Stuhl mit vier Beinen entwirft aber nur drei Beine anfertigt. Das wird wackelig!

Weiterlesen

20. Apr 2010

1 Kommentar

Storyboards: Eine Erfolgsgeschichte

Was sind Storyboards?

Storyboards sind Geschichtenbretter – jedenfalls wörtlich übersetzt. Ok, wir malen die nicht auf Holz. Storyboards beschreiben die Umsetzung eines fachlichen Anwendungsfalls in eine konkrete Software-Benutzeroberfläche. Beschreibt ein Anwendungsfall (Use Case) die rein fachlichen Abläufe (z.B. Anlegen eines Kontos), so beschreibt das entsprechende Storyboard, wie das in der Software-Oberfläche vor sich geht.

Herkunft

Storyboards verbindet man eher mit der Erstellung von Trickfilmen oder der Planung von Werbespots. Verschiedene Scribbles (flüchtige Skizzen) werden mit Pfeilen und Symbolen miteinander verbunden. Ziel ist es, eine Geschichte zu erzählen und den Ablauf der Geschichte zu verdeutlichen. Nun, da hat die gute alte IT-Welt mal von so neumodischem Kram wie Zeichentrick und Werbung gelernt. Wobei ich mir jetzt gar nicht so sicher bin, ob Storyboards nicht schon viel früher im Filmgeschäft eingesetzt wurden. Das Ziel sollte dasselbe gewesen sein: eine Geschichte erzählen. Wie dem auch sei, die Storyboards haben in die IT Einzug gehalten. Weiterlesen

Seite 1 von 212