ROI-Berechnung einer Fachapplikation

Schon der Artikel Usability verkaufen steuert auf das Thema ROI hin. Wir müssen die Sprache unserer Partner sprechen. Hierzu gehört es, klare Zahlen auf den Tisch legen zu können. Wie hoch wird die Ersparnis durch den Einsatz von User Experience Design (UX) sein? Das ist immer eine schwierige Frage. Doch wir müssen sie zumindest näherungsweise beantworten, um unseren Gesprächspartner -beispielsweise den Unternehmensvorstand- für UX begeistern zu können.

Zu diesem Zweck möchte ich den Return On Investment (ROI) hinsichtlich verschiedener Kennzahlen betrachten. Gegenstand soll eine Fachapplikation sein, anhand der ich ein kleines Zahlenspiel durchführen möchte. Fachapplikation? Das ist eine Anwendung, die nicht im Web einer Millionen von Menschen zur Verfügung steht. Fachanwendungen sind vielmehr Anwendungen, die von einem kleinen Anwenderkreis innerhalb eines Unternehmens eingesetzt werden. Ja, auch dafür lohnt es sich, in Usability zu investieren.

Nehmen wir also mal folgendes an:

Weiterlesen

Teile diesen Beitrag:

Writing Use Cases: Avoid IF THEN in use case steps

Checking conditions within a use case step blows out the success scenario. The use case is hard to understand. Instead relocate conditions and their actions to exceptions or alternate flows.

When it comes to use cases I often read success scenarios describing lots of conditions.

The use case goes like this:

Teile diesen Beitrag:

Writing Use Cases: Exception or Alternate Flow?

Learn when to describe an exception and when to go into an alternate flow. This is essential to improve readability of your use cases.

As you might all know writing use cases may be tricky. The template is as easy as you can think. But using it efficiently is not that easy. One question I have been asked several times lately is

When do I have to describe an Exception? What is an Alternate Flow?

Actually, the difference is very easy to explain. Weiterlesen

Teile diesen Beitrag:

Poster download: Over-all product flow

You can write books and books about all the artifacts your project members are supposed to produce. And there are thousands of them out there. Such a document could be even another product of your project. But -hand on heart- will anyone care? I thought it might be better designing a poster. It shows the product flow on a high level. According to the feedback I got so far from the business users they like it. It helps them to understand the meaning of their contribution in terms of the big picture. OK, that was my intention.

Download poster

Click image to download over-all product flow (pdf-file, 1,1 MB)

Download poster (pdf-file, 1,1 MB)

Weiterlesen

Teile diesen Beitrag:

Tool Set für Fachspezifikation: Alles von Anforderungen bis Aktivitäten

Eine Fachspezifikation beschreibt die fachlichen Anforderungen und Probleme, die es in einem Projekt zu lösen gilt. Es ist nicht notwendigerweise ein einziges großes Dokument. Ganz im Gegenteil: Es ist sehr viel sinnvoller, die verschiedenen Aspekte in unterschiedlichen Dokumenten und Modellen zu beschreiben.

Im Folgenden möchte ich eine Werkzeugpalette vorstellen, die meines Erachtens alle Mittel bereitstellt, um auch komplexe Zusammenhänge verständlich zu beschreiben. Es ist eine Kombination aus Textdokumenten, BPMN und UML. Wenn ich sage „verständlich beschreiben“, meine ich, dass die Dokumentation von den Projektbeteiligten verstanden werden muss. Das schließt die Auftraggeber und Fachabteilung gleichermaßen ein wie Designer und IT-Architekten. Denn nur, was verstanden wird, kann auch umgesetzt werden. Fehlt es an einer breiten Verständnisbasis, sind einerseits die Ziele unklar. Andererseits wäre es somit purer Zufall, wenn die Projektergebnisse (z.B. eine Software-Lösung) die ursprünglich erhobenen Anforderungen erfüllen.

Die folgenden Modelle und Dokumente müssen nicht in der hier vorgestellten Reihenfolge erstellt werden. Sie entstehen häufig parallel. Bei der Arbeit an einem Teil ergeben sich Aspekte, die Auswirkungen auf andere Modelle / Dokumente haben. Und nicht immer braucht man in jedem Projekt alle hier beschriebenen Artefakte. Man muss also immer wieder prüfen, was wirklich erforderlich ist. Es gilt: So wenig wie möglich, so viel wie nötig. Weiterlesen

Teile diesen Beitrag:

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

Teile diesen Beitrag:

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

Teile diesen Beitrag:

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

Teile diesen Beitrag:

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

Teile diesen Beitrag: