Das erste Agile Experience Design Round Table Meetup

Highres_122464572

Gestern hatten wir das erste Agile Experience Design Round Table Meetup. Wir haben Themen gesucht, welche alle interessieren und die wir in weiteren Meetups angehen wollen.

Vielen Dank an Philipp Schroeder fürs Organisieren, es war toller Abend. Hier ein paar Impressionen.

Im nächsten Treffen, wollen wir die Frage angehen: Was alles soll im Sprint 0 geschehen? Wie viel Design brauchst es up front? Wir werden mehrere Erfahrungsberichte hören oder ein Planspiel dazu organisieren. Stay Tuned.

 

Lesson #1 Take responsibility, gibt nicht den anderen Schuld

Seien wir ehrlich: In Usabilitykreisen klagen und lästern wir gerne. Wie oft erzählen wir uns doch gegenseitig die Geschichten von unseren schlimmsten Projekten und klagen oft, wie wir von Leuten umgeben sind, die kein Gespür für Usability haben.

Wir sollten dringend damit aufhören, es bekommt uns nicht gut. Wir sagen uns damit: Wir können nichts machen. Die anderen sind Schuld.

Ich habe vor ein paar Tagen mit der Lektüre von The Pragmatic Programmer begonnen. Das Buch zeigt auf, wie ein pragmatischer / erfolgreicher Programmierer arbeiten soll. Und Lektion Nummer Eins ist: Take Responsibility

Das ist doch offensichtlich! Oder etwa nicht? Ich glaube, wir übernehmen zwar oft Verantwortung für unseren Teil, wenn aber irgendwo ausserhalb unseres Bereichs etwas nicht so läuft, wie wir uns das wünschen, sagen wir uns zu schnell, dass wir halt nicht machen können. Zu of habe ich schon Dinge gesagt wie:

  • Der Kunde versteht einfach den Wert von Usability Tests nicht! 
  • Der Kunde, weiss einfach nicht was er will. 
  • Der Projektleiter macht alles verkehrt... 


Wir UX Practioners glauben an unsere Tools und den Wert von User Centered Design und wir sagen uns "der Kunde ist dumm", wenn er das nicht einssieht. Aber nein, wir sind die Dummen, wenn wir es nicht schaffen unser Umfeld davon zu überzeugen, was unser Wert und der Wert unserer Methoden sind.

Ein Beispiel

Neulich war ich etwas unzufrieden, weil in einem Projekt der Product Owner das Backlog kaum bis gar nicht pflegte und ich beklagte mich darüber (natürlich ja nicht
zu laut). Es brauchte einen Moment, bis ich das Offensichtliche realisiert hatte: Wenn wir ein gut gepflegtes Backlog wollen, dann müssen wir unseren PO im
Backlog Grooming unterstützen. Also habe ich begonnen regelmässig mit dem Product Owner zusammen das Backlog zu pflegen. Dadurch haben wir nun ein besser
gepflegtes Backlog und der Austausch mit dem PO hat sich massiv verbessert. Es war nicht sein Fehler, dass das Backlog nicht gut gepflegt war, es war unserer:
Wir hatten ihn mit einer Aufgabe, die neu für ihn war, ganz alleine gelassen.

Ich will mir nun jedes mal, wenn etwas nicht gut läuft, egal was und wieso, mir die folgende Fragen stellen: Was kann ich jetzt und hier tun, um optimal weiterzufahren?

Facebook IPO enttäuschend!?

Gestern ging Facebook an die Börse. Und viele schreiben über einen enttäuschenden ersten Handelstag. Die Aktie hat ziemlich genau mit dem Ausgabewert abgeschlossen. 

Inwiefern soll das enttäuschend sein? 

Facebook wurde ein Wert von über hundert Milliarden beigemessen und das bei einem Jahresgewinn von ca. 700 Millionen. 

Wieso sollte die Aktie um 10, 20 oder sogar 30% raufgehen? Mir scheint Facebook hat den Ausgabepreis perfekt gewählt und das Maximum herausgeholt, Während die Anleger vernünftig geblieben sind und die Aktie nicht gehypt haben.

Scheint doch alles ganz vernünftig verlaufen zu sein. Wobei mir die 100 Milliarden schon zu hoch erscheinen, dafür dass Facebook aktuell noch weniger als eine Milliarde Gewinn pro Jahr macht. 

Nice take on responsive tables

Have you ever wondered, what one should do with all these big tables in a responsive design?

Zurb shows a nice way, how to handle it and built the solution right into their foundation framework (http://foundation.zurb.com/). Just make the table scrollable horizontally, while fixing a part of the table:

Image

Picture by Zurb.

You can find an example under http://zurb.com/playground/responsive-tables.>

I like the solution, but it lacks affordance. The table needs to show it is scrollable. btw: this pattern is not new, you can fix columns or rows in Excel and Apple's Numbers does it by default, but appliying it to websites is a cool idea.

Fehler teilen und gemeinsam daraus lernen

Vor zwei Wochen hat Harry Brignull einen spannenden Artikel geschrieben. Er begann ihn mit folgenden Worten:

Do you want to know what interests me about our industry? It’s the fact that we always talk about the importance of making mistakes, and iterating, and learning from our failures, but we never actually share real stories about our mistakes and failures. 

Eine Woche später schreibt auch Jared Spool über Fehler, die sie bei Usability Studien gemacht haben:

Zwei hilf- und lehrreiche Artikel, gerade weil sie über die Fehler sprechen. 

Ich muss Harry Brignull Recht geben: Wir reden viel zu selten über Fehler und was wir daraus lernen. Ich will in Zukunft daraus lernen. 

Paper: Die iPad Sketching App kommt Papier sehr nahe.

Nach dem Ausprobieren vieler iPad Apps zum Skizzieren, hatte ich aufgegeben eine App zu suchen, welche mir entspricht. Dann bin ich auf Paper von 53 gestossen.

Img_0091

  • Paper hat keine Layers.
  • Paper hat Paper hat kein Zoom.
  • Paper hat nur 9 Farben
  • Paper hat fünf Stiftarten und einen Radiergummi.

Die vorgegebenen Farben harmonieren gut miteinander und durch die Kombination der Stifte können schnell schöne Ergebnisse erzielt werden.

Img_0090

 

Im Unterschied zu anderen Apps fühlt sich Paper an, als würde man auf Papier schreiben / zeichnen. Ich kann mit Bleistief etwas vorzeichnen, dann mit dem Füllfederhalter elegant nachzeichnen. Dem ganzen mit Wasserfarben Substanz geben und dann Annotationen hinzufügen.

 

Img_0089
Paper gibt's mit dem Füllfederhalter gratis im Appstore, jedes weitere Zeichenwerkzeug kostet 2 CHF (Wasserfarben sind ein Muss, die anderen braucht man nicht unbedingt).

Ich benutze Paper übrigens mit einem Bamboo Stylus.

 

How to track progress in your Balsamiq Mockups

When we started to use MyBalsamiq.com more and more, we ran into the problem, that developpers could access our sketches, but they never could be sure, wheter our sketches had been approved by the product owner or not.

We solved this prolem very simply. We created a little symbol library with labels. The labels indicate visually if the sketch is a draft, if it should reviewed by the product owner, or if the the mockup is approved.

Labels_to_indicate_progress

So every time a status changes, we just delete the old label and add ad a new one. On the overview Screen of MyBalsamiq you can immediately see, what mockups are approved and which ones need reviewing.

Example

Download the .bmml-File here:

Click here to download:
Labels to indicate progress.bmml (8 KB)