Hilfe wir sind Blind! Usability Testing während der Entwicklung
Nächste Woche stehen Usability Tests für unseren B2B SaaS Dienst an. Sicher kämpfen wir dauernd mit der Usability – da sind die Inder einfach nicht die Stärksten und wir sind manchmal vor lauter kritisieren total abgekämpft. Wir versuchen vorher noch die grössten Böcke herauzunehmen. So haben vorab noch einige Tester Feedback gegeben und jeman hat einen technischen Review. Dabei haben wir festegestellt, dass wir total Blind sind. Einige so offensichtliche Dinge haben wir nie bemerkt.
Wir haben bei Verifikationscodes vergessen, dass man einen neuen anzeigen lassen kann. So haben viele User wohl die allererste Hürde nicht geschafft weil sie den Verifikationscode nicht lesen konnten
Neues Passwort anforder ist ebenso unter gegangen. Peinlich, hat jemand sein Passwort vergessen kommt er nie mehr zu seinen Business-Daten.
Das Layout sieht noch ziemlich technisch aus. Diesen Punkt können wir erst dann “fast” endgültig erledigen, wenn alle Funktionalitäten eingebaut sind – sonst machen wir das mehrmals. Wir machen das was wir können. Ein Gestaltungsprofi kommt so ziemlich am Schluss zum Feinschliff.
Einige Seiten sind zu langsam – Pseudo-Ajax mit Reload - viel zu langsam – es werden keine Javascript Events verwendet. Es hat auch unnötige Sessionproblem, bei dem der Status zu lange behalten wird. Es gibt unnötige Reloads von Seiten und einige Seiten fehlen ebendiese. Nicht alle Programmierer sind gleich gut. Juniors machen halt oft solche Fehler.
Nächste Woche haben wir 4 Personen eingeladen. Sie kennen das Programm nicht, sind aber in der Zielgruppe. Wir werden ihnen Aufgaben geben und ihnen dabei zuschauen.
Wir möchten wissen:
- wie packen sie die Aufgabe an?
- finden sie sich auf den Seiten zurecht?
- was würden sie als nächsten Schritt erwarten
- finden sie Features die nicht offensichtlich sind?
- finden sie offensichtliche Features nicht?
- wie beurteilen sie unsern Dienst gegenüber anderen Programmen die sie einsetzen
Ich bin überzeugt, dass wir wieder eine Menge lernen werden. Im September möchten wir eine Private-Beta-Phase einläuten. Im nächsten Jahr wollen wir mit einer neuen Version online gehen. Dann sollten wir alle Features eingebaut haben.
Usability Testing mit der Zielgruppe werden wir laufend machen. Wir sind wohl gezwungen dies sogar in mehreren Ländern zu tun. Darauf freue ich mich besonders. Wie wohl die Asiaten reagieren?
Welches sind eure Erfahrungen mit Usability-Tests? Welche Erfahrung habt ihr bei Programmierung? Dieselben Probleme wie wir? Wie geht ihr damit um? Wann und wer macht Usability?
2ni schrieb:
Was viel bringt, ist wenn die Coder den Usecase verstehen und selber auch von der zu programmierenden Site profitieren, resp. benutzen.
Sprich, wenn die Programmierer sozusagen auch Targetusers sind.
Häufig ist der Programmierer aber mit der Zeit blind, weil er die Site in und auswendig kennt. Da hilfts mal, wenn ein anderer Programmierer (auch Targetuser) die Website mal benützt oder er sie seinem Bekanntenkreis zeigt.
Kommentiert am 27-Jul-09 um 9:49 am | Permalink
Reto Hartinger schrieb:
Genau das ist das Problem beim Outsourcing. Die Programmierer sind in einer gaaanz anderen Welt und können den Usecase nicht verstehen k ö n n e n. Wir können das von ihnen nicht verlangen, auch sind sie meist noch viel zu jung.
Kommentiert am 27-Jul-09 um 11:50 am | Permalink
Daniel Niklaus schrieb:
Für die Auswahl der Programmierer bist aber du verantwortlich. Wenn du zu junge, unerfahrene Programmierer wählst, die überhaupt keine Ahnung von deinem Thema haben…
Kommentiert am 27-Jul-09 um 12:19 pm | Permalink
Reto Hartinger schrieb:
bei einem nearshorer oder offshorer kannst du nur bedingt wählen wer programmiert. und lebensverhälntisse sowie surfgewohnheiten der programmierer wirst du wohl nicht abklären.
in inden wird kaum web2.0 benutz – facebook und konsorten sind nicht die bringer
wer tagsüber programmiert und abends in die slums geht hat einen anderen hintergrund als jemand hier in der schweiz und zu den usa hat es wohl wieder unterschiede
ich hatte ja schon hier probleme mit schweizer techies die sich eine busniesswelt nicht vorstellen konnten und wir haben bei search.ch ja auch keine wahnsinnssachen gemacht. meist waren es dinge die jemand selber auch hätte gebrauchen können. nur mit dem internen team war es besser – obwohl auch die keine berührung mit dem business haben/hatten
ich habe mich gefragt, wieso eigentlich inder so komplexe seiten abliefern können. wahrscheinlich weil das meistgebrauchte programm die microsoft .net entwicklungsumgebung ist und etwa so sehen dann die seiten auch aus. nur so ne vermutung
Kommentiert am 27-Jul-09 um 12:43 pm | Permalink
Daniel Niklaus schrieb:
Was nichts daran ändert, dass du die Inder gewählt hast. Was man sich auch fragen darf, wurde zuerst Programmiert und das Gui entstand so nebenbei oder hat sich jemand um das Gui gekümmert?
Kommentiert am 27-Jul-09 um 12:52 pm | Permalink
2ni schrieb:
Dann brauchst Du eine gute Schnittstelle zwischen den Programmierern und Deinen Anforderungen. Also eine Person, die beide Parteien versteht und die Wünsche versteht und umsetzen kann (in beide Richtungen).
Oder aber Du integrierst die Inder viel stärker ins Projekt. Zb sind sie eine Eigenständige kleine Firma? Dann werden sie ja Dein Tool auch brauchen. Das benötigt aber viel mehr Zeit und Geduld (auch vor Ort).
Tja, Offshoring hat nicht nur Vorteile :-(
GUI würd ich eigentlich auch vorher definieren (entweder als Skizze, HTML Template oder Gimp oder sowas)
Kommentiert am 27-Jul-09 um 12:59 pm | Permalink
Reto Hartinger schrieb:
Was nichts daran ändert, dass du die Inder gewählt hast.
richtig – der SaaS läuft auf der Grundlage einer Software welche diese entwickelt haben. So freiwillig war das also auch nicht ;-)
Was man sich auch fragen darf, wurde zuerst Programmiert und das Gui entstand so nebenbei
Wir entwickeln in Sprints (nicht wirklich nach Scrum). Wir beschreiben das Problem, dann wird ein PPT mit dem Design gemacht, dann wird das umgesetzt und nachher in verschiedenen Iterationen die Usability verbessert. Das ist nicht ganz einfach – aber Usability ist nie einfach
oder hat sich jemand um das Gui gekümmert?
Da das Projekt laufend entsteht und wir nicht wasserfallen, hat niemand eine 200seitiges Designmanual gemacht
Dann brauchst Du eine gute Schnittstelle zwischen den Programmierern und Deinen Anforderungen.
Daran sind wir vor allem mit unseren wirklich guten 5 Russen bei search.ch bescheitert. Damals hat sich niemand um die wirklich gekümmert, sie haben einfach ohne Vorgaben vor sich hin entwickelt. Es gab keine regelmässigen Reviews. Das ist beim meinem heutigen Projekt besser – aber die Programmierer sind deutlich weniger gut als die Russen.
Oder aber Du integrierst die Inder viel stärker ins Projekt. Zb sind sie eine Eigenständige kleine Firma?
Ja sie sind eine kleine Firma – sie sind dediziert mir zugeteilt oder einige Seniors werden Adhoc beigezogen. Die Programmierer können das Tool nicht selber brauchen aber die Firma tut es und ich wundere mich dass von denen so wenig Feedback kommt.
GUI würd ich eigentlich auch vorher definieren
Das machen wir schon – aber halt nicht so gut wie es sein könnte. kann man das überhaupt? Sie verstehen es manchmal nicht einmal wenn man sagt es muss so sein wie in z.B. Facebook. Hergotthimmel ein besseren vorschlag könnte ich in keiner Form bringen und sie machen was anderes.
Das tönt ja alles sehr negativ – aber das erlebe ich auch mit Schweizer Software. Dani – vieles in DEMANDIT war nicht usable. Die Frage zurück – wie ist das GUI entstanden. Dinge sind komplex – vor allem wenn man Abläufe programmieren muss. Das versteht man nicht gleich zu Beginn. Auch ich lerne ja immer nach jedem Design dazu und weiss erst dann was zu machen ist. Das geht dir selber sicher auch so
Kommentiert am 27-Jul-09 um 1:16 pm | Permalink
Reto Hartinger schrieb:
Ein kleines Besipiel eines Problems. Es hat eine Apply-Button. Der User dankt ich klicke ihn und habe damit ausgewählt was rechts daneben steht. Loisch oder? Tut es nicht – es macht was anderes, es wählt nur das Ding aus – danach muss man den use-it Button klicken um es anzuwenden.
Kommentiert am 27-Jul-09 um 1:19 pm | Permalink
Reto Hartinger schrieb:
Zwischen Apply und Use-it kann man eben noch viel machen. Man lerne, der Button sollte View heissen
Kommentiert am 27-Jul-09 um 1:20 pm | Permalink
Daniel Niklaus schrieb:
Genau, vieles entsteht erst bei der Entwicklung und was für den einen angenehm ist, muss der andere noch lange nicht verstehen. Darum ist auch eine Aussage wie: “genauso wie in Facebook” absoluter Schwachsinn. Facebook hat eine gänzlich andere Aufgabe und was soll genauso sein? Der Look, die Funktionen, der Ablauf und was ist, wenn etwas kommt, dass Facebook nicht anbietet? Diese Aussage ist für den Auftraggeber ganz angenehm, weil er sich damit jede Denkarbeit erspart und glaubt, dass dies keine eigene Aufgabe ist. Ein Programmierer kann damit aber wenig bis gar nichts anfangen, weder in der Schweiz, Russland noch in Indien.
Kommentiert am 27-Jul-09 um 1:49 pm | Permalink
Reto Hartinger schrieb:
genauso wie in facebook hat bei den russen extrem gut geklappt. bei den indern nicht
es ist die genauesta anweisung was design und funktionalität anbelangt, wenn ich einen bestimmten teil sogar ansehen kann wie er funktionieren soll – schwachsinn ist das sicher nicht
Kommentiert am 27-Jul-09 um 1:54 pm | Permalink
Daniel Niklaus schrieb:
wir reden hier von Programmierern. Wenn du erwartest, dass diese deine Aussage “genauso wie Facebook” auseinander nehmen. Dann musst du dies als gesonderten Task verstehen und in Auftrag geben. Da ist dann die von Denis angesprochene Person/Schnittstelle notwendig.
Kommentiert am 27-Jul-09 um 2:00 pm | Permalink
Reto Hartinger schrieb:
siehste hier haben wir genau so einen fall – ich sage dir nicht genau was ich meine du verstehst es nicht weil du das verstehst was deinem hintergrund entspricht und ich das was meinem hintergrund entspricht
wenn ich sage macht den chat so wie in facebook dann denke ich ist das eine ziemlich gute ausssage – sonst würde ich nämlich einfach screenshots davon machen und ihnen senden. wäre das besser?
Kommentiert am 27-Jul-09 um 2:10 pm | Permalink
Daniel Niklaus schrieb:
Ob das besser ist? Bestimmt!
Ich ging bei deinem Beispiel davon aus, dass du das Userinterface für das gesamte System meinst. Wenn wir vom Chat sprechen, ist das schon etwas anderes…du siehst, wie schnell es geht und da ist der Auftraggeber halt auch in der Pflicht.
Kommentiert am 27-Jul-09 um 2:53 pm | Permalink
Reto Hartinger schrieb:
So die ersten zwei Test sind vorüber und waren extrem interessant. In einigen Dingen haben beide die gleichen Probleme – bei anderen wollte der eine etwas nicht, der andere hat es aber sofort benutzt und gut gefunden.
Ich bin gespannt auf die beiden Tests von morgen. Was wird sich erhärten.
Wir haben auf jeden Fall sehr guten Input bekommen.
Kommentiert am 29-Jul-09 um 6:29 pm | Permalink
ThomasK schrieb:
Meine Wenigkeit kann da nicht wirklich seitens der Projektplanung mitreden.
Jedoch erinnere ich mich noch gut, dass ich mal einen Styleguide entwarf für ein “größeres Projekt”. Da war ich externer, der nur am Anfang dabei war (Kickoff-Meeting und erste Besprechungen) und dann noch bevor am Frontend irgendwas gecodet wurde den Styleguide abgab.
Später wurden dann Icons und manche Formular-Elemente und Buttons nachgeliefert.
Die Interface-Philosophie und Logiken waren rein abstrakt und “extensiable” bzw. meist noch mit konkretem Inhalt zu “bestücken”. Skizzen und ein kompetenter Ansprechpartner waren meine Grundlage, die wiederum Ergebnis der ersten Besprechungen waren.
So weit ich weiss, gab es dann Objekte/Klassen für die GUI-Elemente, die wiederum den Entwicklern die Arbeit erleichterten… und das alles an sich kein Thema mehr.
—
Ob das übertragbar ist, kann ich nicht beurteilen.
Frech gefragt:
Warum sollte es keinen Vorteil bringen, von Anfang an den/die GUI-Grafiker mit einzubeziehen + Styleguide?
Ab wann baut man denn sinnigerweise MockUps / Dummies … z.B. in statischem HTML aber mit JavaScript-Feeling?
Kommentiert am 30-Jul-09 um 7:21 pm | Permalink
Benny schrieb:
Offshoring braucht halt wie bereits erwähnt einfache ein gute Person an der Schnittstelle, welche die Business-Logik der Applikation im Detail kennt und die den Programmierern auch eindeutig beschreiben kann. Wenn etwas zweideutig ist, wird es auch mal schiefgehen, ganz nach Murphy’s Law.
Anfoderungen “wie facebook” lässt aus meiner Sicht auch einfach zu viele Fragen offen. Z.B. hat der Programmierer nicht viele Buddys auf Facebook und chattet so nie mit mehr als einer Person, somit weiss er gar nicht dass es auch eine Funktion braucht dass zwei Chatfenster gleichzeitig im Footer offen sein könnten.
Generell gessagt braucht das Offshoring einfach mehr Aufwand bei den Anforderungen, ist halt der Tradeoff gegenüber dem günstigeren Preis. Wenn man saubere Usecases schreibt, kann man aber hier relativ effizient vorwärts kommen. Und es gibt gute Tools auf dem Markt, die eine Menge Zeit einsparen können, Vorraussetzung dass man das richtige Tool für das richtige Problem nutzt: Axure, Balsamiq Mockups, Protoshare, etc.
Kommentiert am 02-Aug-09 um 10:29 am | Permalink